My latest TrueOS experience


#1

In the past, I installed PC-BSD more than once. Each time, I became very frustrated with its particular set of faults at the time (every system has faults, it’s simply a case of which faults each of us will choose to put up with), and each time, I uninstalled it again soon after, replacing it with something else.

Lately, I’ve installed TrueOS, and this time I seem to be sticking with it. The things I once complained about have been fixed, and the new faults are ones I’m quite willing to live with. (Mainly: Lumina is noticeably immature, but it works for what it does, it avoids doing stupid things, and it’s improving.)

I should add that I’m grateful for the “Stable” branch; without it, I probably would have given up due to the frequency of TrueOS updates, even though those updates probably work.

Thanks to all who make TrueOS what it is.


#2

Agree, even though I’m relatively new to this OS, I do love my TrueOS experience. Can’t wait for next stable update in December!


#3

Change is the only constant in this world. So we have to live with updates. Because of update trouble I removed PC-BSD 10 (Joule). Now I am on my third install of TrueOS and don’t know, if the next update will cause again a fresh install. Truth to be told I could wait a little longer for the next update but there is hope because here on discourse.trueos I got the information about the correct command to initiate the update process.


#4

Here’s the thing about updates: just because a new one is available, doesn’t mean you have to apply it (unlike Windows 10). UNSTABLE is for folks that have problems with installing STABLE or folks that want to be involved more in testing (the more different hardware configurations the better). That’s why STABLE was pushed to a 6 month cycle, with UNSTABLE being every few weeks or “as needed”. UNSTABLE eventually becomes STABLE, so it’s important to note any problems you may have with UNSTABLE here on discourse (easier to search and find then over on gitter). Since TrueOS is based on FreeBSD 12-CURRENT, it also makes sense to keep an eye on the FreeBSD mailing lists (svn-src-head and the security lists) so you know what may be coming up in a next release. You don’t need to subscribe, there is a web interface for reading; if you want to post or get the daily digest you’ll need to subscribe.


#5

I’m glad that after several months of absence from my desktop computer, I came back and see this post. Like @david_a, I’m also excited about steady progress of TrueOS. I’d like to congrat the developers for putting back the step in installer on latest current 14.nov 2017 that enables you choosing of graphic drivers for nVidia owners. I had complained in the past that I had lots of work because I own older card that requires 340 series of drivers and all the fiddling with various rc.conf and others had now gone, by simply choosing appropriate driver during install. Big thumbs up for devs! <3


#6

App Café doesn’t seem to be very ‘willing’ in installing anything, if there is a pending update since the repo database needs to be updated first.
Using the STABLE version I didn’t expect an update already in January when the last update was in December, but it was sitting there in the update manager for a few days. Since nobody wrote anything about it I thought ‘no news are good news’ and installed it. No problem at all, after a few minutes the system was up again and seems to be very healthy now. :slight_smile:
It would be helpful, if there was some kind of anouncement within the Announcement category why this update became necessary for the STABLE version. Also it is always a surprise when the update manager is telling you there are 3 packages to be updated but afterwards is announcing 444 packages to be downloaded which fortunately wasn’t done. Here from the pc-updatemanager.log:

...
Checking for upgrades (529 candidates): .

trueos-desktop-201712111405 is locked and may not be modified
Checking for upgrades (529 candidates)............ done
Processing candidates (529 candidates): . done
Checking integrity... done (0 conflicting)
The following 3 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
	sysadm-client: 201712070942 -> 201801031217 [trueos-major]
	sysadm: 201712070943 -> 201801031354 [trueos-major]
	pcdm: 201711221041 -> 201801031222 [trueos-major]

Number of packages to be upgraded: 3
[1/3] Upgrading sysadm-client from 201712070942 to 201801031217...
[1/3] Extracting sysadm-client-201801031217: .......... done
[2/3] Upgrading sysadm from 201712070943 to 201801031354...
[2/3] Extracting sysadm-201801031354: .......... done
[3/3] Upgrading pcdm from 201711221041 to 201801031222...
[3/3] Extracting pcdm-201801031222: .......... done
Moving updated pkg repo...
Extracting distribution files...
Warning: Failed extracting distribution upgrade files
Updating OpenRC settings...
Running OpenRC Migration...
Unmounting stage BE...
Copy upgrade.log to new BE...
Running: cp /var/db/pc-updatemanager/.pkgUpdateLog /.updateStage/usr/local/log/pc-updatemanager/upgrade.log
Running: cp /var/db/pc-updatemanager/.removed-pkg-list /.updateStage/removed-pkg-list
Determine new BE name...
Cleanup mounts...

Not so promising is the line: ’ Warning: Failed extracting distribution upgrade files’ and I can’t remember to have locked the ‘trueos-desktop-201712111405’.
Unfortunately I still have to start the ‘automountd’ manually since it is always stopped by an unknown event after system start.

All that said I am a happy camper now with three boot environments in my list. :slight_smile:


#7

First Scan

Using a Canon MP270 connected via USB as printer on TrueOS 17.12 STABLE (Lumina desktop environment) was easy but using this device as scanner was even easier.
After installing xsane from AppCafe I just opened this application from the main menu and clicked the button ‘scan’. It worked out of the box without any adjustment anywhere.
In comparison even the setup as printer in CUPS required more action since you had to install the device with a few clicks and looking for the correct driver.
Typically we all write only, if we stumble across some obstacle. Here for a change I wanted to share this positive experience where everything functioned automatically.


#8

USB Thumb Drive Trouble

Suddenly TrueOS 18.03 STABLE (Lumina) froze when I tried to get access to a 64GB thumb drive (FAT 32). On Devuan Jessie and Windows 10 it was working without a problem and some days ago it did on TrueOS as well.
First only Lumina File Manager (Insight) got frozen. Here are the corresponding messages from /var/log/messages:

Jul 10 16:41:47  kernel: ugen0.2: <Kingston DataTraveler 3.0> at usbus0
Jul 10 16:41:47  kernel: umass0 on uhub0
Jul 10 16:41:47  kernel: umass0: <Kingston DataTraveler 3.0, class 0/0, rev 2.10/1.00, addr 1> on usbus0
Jul 10 16:41:47  kernel: umass0:  SCSI over Bulk-Only; quirks = 0xc101
Jul 10 16:41:47  kernel: umass0:4:0: Attached to scbus4
Jul 10 16:41:47  kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
Jul 10 16:41:47  kernel: da0: <Kingston DataTraveler 3.0 PMAP> Removable Direct Access SPC-4 SCSI device
Jul 10 16:41:47  kernel: da0: Serial Number 60A44C413942B051098D0096
Jul 10 16:41:47  kernel: da0: 40.000MB/s transfers
Jul 10 16:41:47  kernel: da0: 59211MB (121264128 512 byte sectors)
Jul 10 16:41:47  kernel: da0: quirks=0x2<NO_6_BYTE>
Jul 10 16:42:18  kernel: WARNING: autofs_task: request 11 for /.autofs/ timed out after 30 seconds
Jul 10 16:42:18  kernel: WARNING: autofs_trigger_one: request for /.autofs/ completed with error 60
Jul 10 16:42:23  automountd[3410]: AUTOFSDONE: No such process
Jul 10 16:42:30  kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 01 84 2a 80 00 00 40 00 
Jul 10 16:42:30  kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
Jul 10 16:42:30  kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition
Jul 10 16:42:30  kernel: (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
Jul 10 16:42:30  kernel: (da0:umass-sim0:0:0:0): Error 5, Unretryable error
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36372480, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36438016, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36503552, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36569088, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36634624, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36700160, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36765696, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36831232, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36896768, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=36962304, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=37027840, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=37093376, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=37158912, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=37224448, length=65536)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=37289984, length=32768)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=81166336, length=32768)]error = 5
Jul 10 16:42:30  kernel: g_vfs_done():da0s1[READ(offset=13020561408, length=32768)]error = 5
Jul 10 16:42:36  kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 01 84 2a 80 00 00 40 00 
Jul 10 16:42:36  kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
Jul 10 16:42:36  kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition
Jul 10 16:42:36  kernel: (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
Jul 10 16:42:36  kernel: (da0:umass-sim0:0:0:0): Error 5, Unretryable error
Jul 10 16:42:36  kernel: g_vfs_done():da0s1[READ(offset=13020561408, length=32768)]error = 5

The only thing I really understood was “Unrecovered read error”. In “Error 5, Unretryable error” I didn’t and don’t know what the number was indicating.

After that the whole system froze when I tried to open the thumb drive. Automount was working and the icon was displayed.
Here the corresponding messages:

Jul 10 16:59:00  kernel: ugen0.2: <Kingston DataTraveler 3.0> at usbus0
Jul 10 16:59:00  kernel: umass0 on uhub1
Jul 10 16:59:00  kernel: umass0: <Kingston DataTraveler 3.0, class 0/0, rev 2.10/1.00, addr 1> on usbus0
Jul 10 16:59:00  kernel: umass0:  SCSI over Bulk-Only; quirks = 0xc101
Jul 10 16:59:00  kernel: umass0:4:0: Attached to scbus4
Jul 10 16:59:00  kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
Jul 10 16:59:00  kernel: da0: <Kingston DataTraveler 3.0 PMAP> Removable Direct Access SPC-4 SCSI device
Jul 10 16:59:00  kernel: da0: Serial Number 60A44C413942B051098D0096
Jul 10 16:59:00  kernel: da0: 40.000MB/s transfers
Jul 10 16:59:00  kernel: da0: 59211MB (121264128 512 byte sectors)
Jul 10 16:59:00  kernel: da0: quirks=0x2<NO_6_BYTE>
Jul 10 16:59:10  kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 01 84 2a 80 00 00 40 00 
Jul 10 16:59:10  kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
Jul 10 16:59:10  kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition
Jul 10 16:59:10  kernel: (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
Jul 10 16:59:10  kernel: (da0:umass-sim0:0:0:0): Error 5, Unretryable error
Jul 10 16:59:10  kernel: g_vfs_done():da0s1[READ(offset=37322752, length=32768)]error = 5
Jul 10 16:59:10  kernel: g_vfs_done():da0s1[READ(offset=38338560, length=32768)]error = 5
Jul 10 16:59:10  kernel: g_vfs_done():da0s1[READ(offset=13020561408, length=32768)]error = 5

It was looking very similar but after the access to the thumb drive the only thing working was the hardware RESET button.

A not so convenient way to get it working again was to make a backup of the thumb drive on Devuan Linux and moving most of the files to the hidden trash folder (some were deleted immediately). The only thing I did after that was removing the boot flag via fdisk from the FAT32 partition. Now it is working again but how long?

Does anybody know the reason behind this error and if it happens again, what can be done to the thumb drive to get it working on TrueOS again without moving all the files to the trash folder?


#9

I think your post is misplaced here. It’s more likely somebody with a solution will come to you after you post your problem with a meaningful title in a proper thread.


#10

Thank you for your reply @Sergio!

At least you found it. :wink: There isn’t so much traffic here on discourse and I trust in the flexibility of the audience to take a look even if a post isn’t in the #help-support category.


#11

Basically the kernel driver is saying “read this device at offset blah” and something goes wrong. It could be real, it could be the BSD kernel is stricter in interpreting the device status codes. Did you ever use this exact device on your TrueOS stable without a problem? Thumb drives are basically disposable; some last forever, some fail the second time you use them, some fail the first. Try it in a different USB port. If it’s a USB3 drive put it in a USB3 port. USB2 put in a USB2. My experience has been errors like this are usually real errors.


#12

Thank you for your clarification @mer!

It was one of the main vehicles to get data on the TrueOS STABLE back in November last year when it was installed. After that it was sporadically used time and again and never indicated any problem until yesterday.
Good luck I never experienced this freezing when just in the middle of unsaved work. :slightly_smiling_face:
Now I will be more careful and think twice before trying to access any thumb drive when some work is in an open state.


#13

At the very base of a thumb drive is “Flash device” technology. This has limited number of erase cycles and treating something like an oldfashioned spinning platter tends to make erase blocks move around and it can eventually much you up.

Consumer grade devices have shorter lifespans than commercial grade.
On any given device I’d expect about 10% unusable right from the factory, you just don’t know where any of that 10% is located.


#14

I don’t think his (hers?) 64 GB thumb drive is very old one.


#15

Maybe not, but in this case “old” directly relates to how many erase cycles any given flash block may have had, not “when was it bought”. I’ve had some that right out of the package (or “brand spanking new”) that failed.


#16

How old or used it ever is, because of the trouble I did an fsck and got:

** /dev/da0s1 (NO WRITE)
** Phase 1 - Read and Compare FATs
FAT starts with odd byte sequence (f8ffff0ffffffff7)
Correct? no
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
/.Trash-1000/files/Samajona/CRE/#���h��c.��� starts with cluster out of range(4161253671)
Remove? no
/.Trash-1000/files/Samajona/CRE/��IC3.�)9 starts with cluster out of range(1126260808)
Remove? no
/.Trash-1000/files/Samajona/CRE/�����>:.^)@ starts with cluster out of range(644276731)
Truncate? no
/.Trash-1000/files/Samajona/CRE/��H3X�H.��� starts with cluster out of range(891295859)
Remove? no
/.Trash-1000/files/Samajona/CRE/J������&.E  starts with cluster out of range(1427799171)
Truncate? no
/.Trash-1000/files/Samajona/CRE/��4��a\.�� starts with cluster out of range(1276224397)
Remove? no
...
... and more than 3700 lines like that
...
** Phase 4 - Checking for Lost Files
Lost cluster chain at cluster 16691
1 Cluster(s) lost
Reconnect? no
Clear? no
Lost cluster chain at cluster 16692
1 Cluster(s) lost
Reconnect? no
Clear? no
Lost cluster chain at cluster 16693
555 Cluster(s) lost
Reconnect? no
Clear? no
Lost cluster chain at cluster 17248
42 Cluster(s) lost
Reconnect? no
Clear? no
Lost cluster chain at cluster 17290
58 Cluster(s) lost
Reconnect? no
Clear? no
...
and more than 900 lines like that

Now I deleted the partition and created a new one with gpart. That was not simple since automount and automountd needed to be stopped to prevent the thumb drive from mounting. On TrueOS I couldn’t create a new file system on the new partition since the newfs command always aborted with input/output error (sometimes very early and sometimes very late when walking through the partition). So I switched to Devuan and created a new file system via the command mkfs.fat which worked without a problem and produced a vfat file system.
The thumb drive is working now on TrueOS but I won’t trust it very much anymore.


#17

And that is the smart thing to do. I know they cost real money, but you really need to consider them disposable. Maybe a “write one or two times” and leave it alone.