New Kernel lost track of my SATA HDD's



Day before yesterday, I used the old DVD image from 02-27 to install the system on a 3rd HDD. It worked, and I was able to Triple Boot Windows 10, Ubuntu 17.04, and TrueOS. After booting into TrueOS, I completed the setup, logged in as my new user and was informed by pc-updatemanager that updates were available. Being used to this behavior and after reading the Handbook on updates, I downloaded them, rebooted, let them install, and restarted. To my disappointment, the update failed. The new kernel refuses to mount my ZFS root, and reports CAM STATUS errors on all drives.

Drive Information via Ubuntu

       physical id: a
       logical name: scsi0
       capabilities: emulated
          description: DVD-RAM writer
          product: DVD-RAM GH22LP20
          vendor: HL-DT-ST
          physical id: 0.1.0
          bus info: scsi@0:0.1.0
          logical name: /dev/cdrom
          logical name: /dev/cdrw
          logical name: /dev/dvd
          logical name: /dev/dvdrw
          logical name: /dev/sr0
          version: 2.00
          capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
          configuration: ansiversion=5 status=nodisc
       physical id: b
       logical name: scsi2
       capabilities: emulated
          description: ATA Disk
          product: WDC WD5000AAKS-0
          vendor: Western Digital
          physical id: 0.0.0
          bus info: scsi@2:0.0.0
          logical name: /dev/sda
          version: 3B01
          serial: WD-WCAYU8119883
          size: 465GiB (500GB)
          capabilities: partitioned partitioned:dos
          configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=0004097e
       physical id: c
       logical name: scsi3
       capabilities: emulated
          description: ATA Disk
          product: ST3500418AS
          vendor: Seagate
          physical id: 0.0.0
          bus info: scsi@3:0.0.0
          logical name: /dev/sdb
          version: CC38
          serial: 6VMD0KGY
          size: 465GiB (500GB)
          capabilities: partitioned partitioned:dos
          configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=c86b6dbc
       physical id: d
       logical name: scsi4
       capabilities: emulated
          description: ATA Disk
          product: ST500DM002-1BC14
          vendor: Seagate
          physical id: 0.0.0
          bus info: scsi@4:0.0.0
          logical name: /dev/sdc
          version: JC4B
          serial: Z2ABBV82
          size: 465GiB (500GB)
          capabilities: gpt-1.00 partitioned partitioned:gpt
          configuration: ansiversion=5 guid=17f170cf-1752-11e7-93ce-1c6f6559405c logicalsectorsize=512 sectorsize=512
       physical id: e
       logical name: scsi5
       capabilities: emulated
          description: DVD-RAM writer
          product: DVDRAM GH24NS70
          vendor: HL-DT-ST
          physical id: 0.0.0
          bus info: scsi@5:0.0.0
          logical name: /dev/sr1
          version: GN00
          capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
          configuration: ansiversion=5 status=nodisc

Motherboard Model: GA-M68M-S2P rev 2.3
True OS Install Drive: ST500DM002-1BC14

Things I Have Tried

  1. Thinking I had done something wrong, I downloaded and burned the new DVD image yesterday, only to find out that the new DVD produces the same issue as pc-updatemanager does on my already installed system. (TrueOS-Desktop-2017-03-31-x64-DVD.iso)
  2. Thanks to the Boot Environment, I can get back to my initial BE that works except for the fact that I can’t install packages from AppCafe due to the fact that updatemanager complains that my local repository is out of sync.

I’d like some pointers on investigating the differences between the kernel that boots the initial BE versus the non functional BE(I know this is not a failing drive issue, as the initial BE’s kernel boots normally. The functional BE was installed using the 2-27 iso). I’m thinking maybe a module is missing etc, but I’m too new to *BSD style OS’es to know where to look. Note that I’m experienced with Gentoo, so if you tell me where to look, I’ll know what to look for.

See Also: Git Issue #379
Any Help is Appreciated!


I know this might not really address the issue but They put out another update yesterday and now my SATA drives are working again. as well as my video problems. Also solved. But I am in a virtual machine in this particular case.
Something significant went wrong I think. Especially with an additional update just 3 days later.



Were some empty places on the HDD between the volumes of the windows,Ubuntu and TrueOS?

I’m meaning for this for example (the sequence of the OP systems is all the same):

/WINDOWS volumes/ Empty place/ UBUNTU volumes/Empty place/ TrueOS volumes

I got similar messages when the PCBSD 10,2 couldn’t recognize normally the new DVD writer of my old notebook. After six times “Retrying command” the system could boot up (3 minutes longer the boot time), later I took out the DVD writer and the problem has gone.


I can’t help you with your initial/main problem (might be fixed with the new updates as @Troub wrote) but if you need to install some programs for testing or otherwise you could try this note that should appear when you try to install a program (see item 3):


I have noticed (unless I got it wrong) that the size of the active (= currently running) BE is most of the time bigger than the inactive one(s) - or at least that the size displayed by the BE manager differs for a specific BE depending on if it’s active or inactive.
At least that’s what I thought I understood from the nature how BEs are connected/derived from another. Also the size of the active BE should change if one deletes an inactive one. I really should write those numbers down one day to be able to make more definitive statements. :slight_smile:

For now I’m just hoping I’m not totally wrong - I’m not currently on my TrueOS partition/system. Just wanted to mention my “memories” before I forget about it until the next time I’m on TrueOS.


I don’t believe so, as I used GRUB2 to chainload the bootloader . I’ll try Troubs suggestion now and report back on what I find after the update.


Tried today’s update… No go… The Kernel version s.201703311845xxx.xz is the culprit here. As long as that version number stays the same, I’m stuck.


you are correct 331 is no good but I’m on 2017404-073853 as of yesterday. I’m not sure why the date is still1 day ahead of now 4/3 however I upgraded yesterday and got 404.

I’ve tried it now on my physical machine as well as my virtual machine. The SATA drive came back again magically after upgrading. I however DELETED the boot Environments for 331 and booted off of 301 then did the upgrade to 404
On my physical machine which had a problem with x windows and kernel mode drivers for old intel cards, all is OK as well. I had to delete the xorg.conf file from etc/x11 but after that all was well with 404.


Hmm, sounds like I need to reinstall with the disk that works then try the update again… I’ll let you know shortly.


There isn’t an update in the tree yet, that updates my version numbers for the affected packages. I’ve compiled a list. Note that there may be more:

FreeBSD-libcam: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusbhid-profile: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusbhid-lib32-profile: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusbhid-lib32-development: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusbhid-lib32: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusbhid-development: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusbhid: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusb-profile: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusb-lib32-profile: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusb-lib32-development: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusb-lib32: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusb-development: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-libusb: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]
FreeBSD-kernel-generic: 12.0.s20170222000447 -> 12.0.s20170330184551 [trueos-base]


3 or 4 years ago I used together in tree boot the W7-Ubuntu 12.04-PCBSD 9,2 and I had not problem, only without free space between the Ubuntu’s and PCBSD’s volumes.

Sorry, but if you will update your system on every day ( or on every third day) than I think you will have a lot of problen. Believe me.


While I understand your point, I updated because these packages are in the STABLE branch and being marked STABLE means that I should be able to update, be it 3 days or 3 months. I understand that frequent updating can cause problems, but I also saw that the developers trusted these updates enough to make a new ISO.

What I’m describing here is a regression, plain and simple. Someone updated something somewhere, and while it worked for him it caused unintended consequences for me. All I’m asking for is the behaviour I had before the update, so that I can update the packages that need updating properly. See this discussion from Linus Torvalds on regression, and this snafu at Ubuntu for examples.


Why are we comparing Linux to TrueOS (FreeBSD)?.. I read that email from Linus Torvalds who has zero to do with TrueOS and I’m not sure why you think we should take orders from him.

TrueOS is a relatively new project and it has it’s quirks. For a project it’s age it is way more mature than the projects that existed decades before it. Occasionally we have a hiccup here and there, but we live with it especially because they gave us Boot Environments which means we can always activate the previous Boot Environment, gather as much info as we can, give it to the devs, and then reject the updates on the working Boot Environment, at least until there is another round of updates that we can try.


I’m not saying we should take orders from Linus at all. I was trying to
find an easy way to explain what a regression is, and why it causes an
issue. I’m not trying to start a flame war etc. Each OS has it’s quirks
I get that also. Your method is exactly what I’m doing, if you’ll take
the time to look in the Gitter Lounge istead of attacking me for
explaining to someone what kernel regression is and why it’s important
in this case.


I wasn’t attacking you. We have a lot of people that think that TrueOS is a “Linux Distro” so I was just making sure we were on the same page. :wink:


No, not at all… A little History:

  • I started using Linux with SuSE before Novell bought it.
  • I began to realize that Linux was all about the package manager, so I switched to Gentoo as my primary Linux OS, in order to explore OS freedom through source code. Problem is, even Gentoo relies on Portage.
  • I recently added a 3rd HDD, and thought I’d explore even more freedom through ports etc, but wasn’t comfortable jumping off the deep end quite yet(no package manager at all), but with this regression going on I’ve decided to install FreeBSD-11 Release alongside TrueOS so I can help out where needed. I plan on truly using TrueOS when this regression is fixed…


SO I found something( might be random…) however… with my SATA drives: when I removed my USB3 card the drives work with an upgrade and no problem… In fact if I add the USB3 after I have the SATA drives going it will hang the boot.
Still testing on 331