Impasse reached in failed upgrade to Trisquel_11
Following Magic Banana's sage advice, I attempted the distribution upgrade from
Trisquel_10 (nabia) to Trisquel_11 (aramo) using the command do-release-upgrade-d
but it failed, entering Emergency Mode, from which I logged in with the command login
arriving as root at the base of a large tree.
Following another's sage advice, I mounted the root partition of /dev/sda1 with the command
mount /dev/sda1 /mnt whence I corrected some of my own errors in fstab with nano, using the command nano /mnt/etc/fstab and saved fstab as fstab.nanobak.
After saving the original /etc/fstab as fstab.bak and overwriting /etc/fstab with the command
cp /mnt/etc/fstab.nanobak /mnt/etc/fstab I rebooted, again arriving in Emergency Mode.
However, /var/log/boot.log has only two logs dated today, /var/log/wtmp & /var/log/boot.log. The only one of those I can open is boot.log, and that shows no errors other than one USB storage device that times out and two swap devices that are in fstab but are on devices that aren't installed.
I think I need to open the upgrade log, dated yesterday, as that was full of warnings and error messages, only one set of which (repeated umpteen times) had to do with that duplicate entry in my fstab file. I think I can find it, but I'd like to collect those lines that seem pertinent and save them to a portable USB dongle. The main obstacle now is that I haven't been able to get the device names (/dev/sda1, /dev/sdb1, /dev/sdc1, etc.) Gparted doesn't have any display in Emergency Mode. Does Disks ?
it failed, entering Emergency Mode
It is unclear to me what you are facing. Did do-release-upgrade apparently do its job without any error? Did you get a text terminal for recovery after a reboot? If so, the issue may deal with the bootloader and not with /etc/fstab. Can you actually fire any command? If so, try:
# update-grub
To verify /etc/fstab:
# findmnt -x
Magic Banana asks:
Did do-release-upgrade apparently do its job without any error?
do-release-upgrade got nowhere, but
do-release-upgrade -d went right to work, upgrading nabia as well as all (?) the installed applications, which tool several hours while I watched, transfixed. There were many errors, warnings & bugs flagged, but the process went to completion and then rebooted into Emergency Mode. I did manage to find many errors in the /etc/fstab file, which I eventually corrected with the aid of a spare T420 that I could plug into the dock into which the external HDD is USB-attached; there is another USB-attached 500GB card that I got from Think Penguin whose UUID and device name I got from the spare T420 (by moving the 500 GB card from the target T420 to the spare T420) so I can now direct command outputs to that 500GB card for reading on the spare T420. I'm getting better at moving around the target T420's hard drives, etc. by mounting them as for /dev/sda1, but to different directories.
I'm finding that some command outputs don't redirect to the target file, but others do redirect OK. Either way, a target filename appears, but empty for the former and filled for the latter.
Update-grub runs OK but adds some comments after the list of detected images: Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry
Findmnt detects one device that doesn't appear in my fstab file but cannot open it, and and the 500GB card times out, even though I can mount it and read its contents and even write to it. More about all this later...
Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry
That's part of the new Ubuntu, and hence Trisquel. The Ubuntu people did it for "Security" with the idea to not search other partitions for operating systems, since it requires that the system mount and search other partitions to see if they have an operating system in order to add them into GRUB and maybe it could be abused somehow. Unless you have a set up with multiple operating systems on different partitions then that being turned off by default doesn't affect you.
Here's the "more-later"
Findmnt flags as "errors" two devices that are unreachable, but which I removed to simplify things: Data-TP, the 500GB card, which isn't storing any applications and which times out during bootup and usb-JMicron_Generic_0123456789ABCDEF-0:0, which was an empty directory that I removed recently. On further investigation, I looked in /dev/disk/by-id (not /mnt/dev/disk/by-id) and found only the three main HDDs, /dev/sda, /dev/sdb & /dev/sdc, only /dev/sda1 containing any OS & app's. All the various partitions are also listed. Modesty prevents me from showing the screen grab.Yesterday I discovered that the command journalctl -xb | more lists syslog, but the most recent version, not the previous version. No fatal errors ... On exit, at first nabia's background image appeared ... then aramo's (gloomy !) and a login screen. It appears that aramo will boot without the superfluous HDDs in place. Thanks for the suggestions.
...
Alas, on reboot, aramo again goes into emergency mode.
Removing both the 500GB card and the Western Digital external 4TB HDD is of no help.
There's another set of errors about which nabia cared not a whit: ima: error communicating to TPM chip
which is repeated eight times on every startup on all my nabia installations.
Sometimes, on exit from emergency mode, I get this dire warning: Failed to start default target: Transaction for graphical.target/start is destructive (emergency target has :start" job request, but "stop" is included in transaction).
For a start, comment all the unessential filesystems in /etc/fstab. If the problem persists, check the essential filesystems and try to repair them if they are corrupted. You can use fsck in the terminal or, for instance, GNOME Disks from a live system.
Following Magic Banana's suggestion, I commented the 500GB flash disk (in /etc/fstab) which fits the card reader built into the Thinkpad T420. An external 4TB HD appears not to have any issues. The 500GB flash card gives a time-out error when it's active in fstab. It works OK in nabia on a Thinkpad T400. I would reconcile myself to hot-plugging the 500GB flash drive, except that it's renamed from Data-TP to Data-TP1 when I do so, even after I've removed any reference to the card in fstab.
It is unclear to me whether commenting the line in /etc/fstab solved your issue (except for the name problem when the flash disk is auto-mounted).
With the 500G flash disk removed from the T420's built-in card reader and placed instead in an aftermarket USB-connected multi-port card reader, aramo boots up without the time-out issue. What's more, the Western Digital 4GTB USB-connected HDD is also read _and_ no longer requires a Keep-Alive script to work around Western Digital's idle-triggered restarts that could not reconnect to the USB port in nabia.
The name change of the 500GB flash card remains an annoyance. If it's not listed in /etc/fstab what other residual should be examined to find that reference ? Could I simply change its UUID with Gparted ?
In Disks, the 500GB flash drive is now recognized as /dev/sdc1, not dev/mmcblk0p1 when it was in the built-in card reader. It could be that the T420's card reader driver needs to be updated.
After finding both the desired name of the 400GB flash drive and the unwanted name listed in /media, I unmounted the flash drive and removed the unwanted directory name. Disks told me where it had been mounted, so I put the newly created UUID for the flash drive and its intended mount point in /etc/fstab, rebooted aramo, placed the flash drive in its USB-connected external card reader, and mounted the flash drive. Now aramo boots with the 500GB flash drive as well as the Western Digital 4TB HDD on the desktop as I would have them appear.
Morale of the story: The "residual" that I was looking for was in /media and the boot process kept picking the unwanted name until I removed that mount point, leaving the desired name still in /media. The Western Digital idle-triggered restarts may still be happening, but aramo deals with them while nabia could not. Kudos to the Trisquel developers for that improvement !
Being able to move the 500GB flash drive from one 'puter to another without wearing out their USB ports is a big plus. The USB-connected card readers can remain plugged in to their dedicated USB ports and are also easily rplaceable. I'm just moving the flash card from one card reader to the other or switching the Thinkpads on their common port-extender dock.
Following uo on some messages that repeatedly flash on the screen during reboot, I checked dmesg and found:
[ 2.671353] scsi host7: usb-storage 1-1.5.4:1.0
[ 3.153538] scsi 6:0:0:0: Direct-Access WD easystore 25FB 3004 PQ: 0 ANSI: 6
[ 3.154172] scsi 6:0:0:1: Enclosure WD SES Device 3004 PQ: 0 ANSI: 6
[ 3.159917] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 3.160225] scsi 6:0:0:1: Attached scsi generic sg3 type 13
[ 3.698277] scsi 7:0:0:0: Direct-Access Generic STORAGE DEVICE 9454 PQ: 0 ANSI: 0
[ 3.698922] sd 7:0:0:0: Attached scsi generic sg4 type 0
[ 6.367371] scsi 6:0:0:1: Wrong diagnostic page; asked for 1 got 8
[ 6.367434] scsi 6:0:0:1: Failed to get diagnostic page 0x1
[ 6.367481] scsi 6:0:0:1: Failed to bind enclosure -19
These pertain to the Western Digital 4TB USB-connected HDD and the 500GB flash drive which work OK nevertheless.