SOLVED: A backup program set a binding hook into systems mount.

[TinyTim]

Those two lines are definitely not good and should not be there in that form (fstab entries should use LABEL= or UUID= ; I suggest reading the fstab man page.) However I don't think they can cause your trouble.

A reinstall of grub might clean up your boot, overwriting the mess the mysterion has caused. You may have to do that while booted from a Live USB; just ask if you don't know how.

Assuming UEFI, the utility efibootmgr might be useful; it can show the boot variables in non-volatile RAM. A normal boot is the UEFI reads the boot variables, which point to /boot/efi/EFI/ubuntu/grub.cfg, which points to /boot/grub/grub.cfg. I'd look at each of the NVRAM boot variables and the grub.cfg files, looking for evidence.

Is efibootmgr in /etc/ and can it be edited with sudo nano? I added the UUID number where the /dev/sdg1 node is. The machines would not boot even with a ext4 formatted USB plugged in. Had to boot 'live' to edit the fstab back to the way it was. Note: the work around to boot without a ext4 usb plugged in was to add ''nofail'' to the default in fstab. I have a lot of info about Timeshifts mounts and errors from the Journalctl, I don't understand most of it.

[TinyTim]

Is the 'Hook' you mention the /dev/sdg1 /media/unity/sdg1 ext4 defaults entry in /etc/fstab? If 'yes', you just need to edit /etc/fstab and remove that entry.

It currently has "users,nofail". (the work around the hook was "nofail") I just now tried changing /dev/sdg1 node to UUID, to see if that would work, and the machine would not boot no matter what. Booted onto a live usb and edited the fstab, put it back "users,nofail" and it booted. I did look at the "journalctl" and I have also looked over Timeshifts mount doctrine on a readme file they have buried in there. I can see them talking about the problem, but I don't really understand enough of it. I have links to discussions in Linuxmint forums, and even links where Timeshift is actually very proud of it, or to them it is not a bad thing, they do want to improve on it. I found their "fix" and it did not work. Appreciate the input, if you think of anything else, it is welcome. * I may try leaving the default entry completely blank if that is not unusual and if you think it is worth a shot.

[Snowhog]

/dev/sda1 /mnt/SSD2 ext4 defaults >
/dev/sdg1 /media/unity/sdg1 ext4 defaults >

Will boot/shut down with any USB with ext4 format.
Hook still there. Have sample of the suspected "hook", if requested.

Is the 'Hook' you mention the /dev/sdg1 /media/unity/sdg1 ext4 defaults entry in /etc/fstab? If 'yes', you just need to edit /etc/fstab and remove that entry.

[TinyTim]

I'm curious: If you uninstalled TimeShift did you do so before you deleted all the snapshots it made, or deleted them manually afterwards?

Good question. On the Kubuntu machine, I uninstalled Timeshift before and left the snapshots; reinstalled to remove them, it would only let me trash them, where it wrote "trash" on the folder and left them there. The Ubuntu machine I removed the snapshots before I uninstalled Timeshift. I'm getting the same result both machines. Neither system will boot or shutdown without a "ext4 usb drive in any usb port" that is all it wants to see, installed or uninstalled.

*The workaround was to enter "nofail" next to default in the fstab*. The hook is still there, but it will boot without the ext4 USB attached.

*looking at possibility that instead of using a UUID in the fstab for the USBdrive/mount I used /dev/sgd1, learning to change that; -and am thinking maybe that is why Timeshift is doing what it is doing. I have found Timeshifts mount process doc, it is 4 pages long, they are all up in there, big time, they are mounted into everything, and using (proc). (will post it if requested)

I found a TeeJee PPA that had his latest version which claimed it would fix the mount problem, It did not, all it would do is allow to unmount without a password in Dolphin, (the boot/shutdown problem remained) but the ext4 USB still had to be in the USB port for shutdown/boot. Then the next time I tried to unmount in Dolphin, it asked for a password, Fickle thing.

I hope I have not overwhelmed you with all this chat, but I'm just learning about the terminal, and I got it set in my head to crush Timeshifts error. I would not be bent up, if only it would of not left the hook in after I uninstalled it.

[claydoh]

I have a suspicion that NOT using uuid or labels for the drives may have been the culprit, maybe, possibly, maybe?

Why would setting sdg1 to use 'nofail' have an effect on something ion the error listed as sdc1, which is not referenced?

/dev/sdX are well known to not be consistent between boots or plug-ins, and I wonder if there were collisions, so to speak, between the kernel trying to assign names to things (the order of which can be affected by the connection type and controller - my PC has iirc 3 USB controller ), the fstab specifying sdg1, and the device that *should* be /dev/sdg1 changing depending on the other connected USB devices.

I imagine using KSystemLog to view more details might reveal more, but it is probably moot now

Timeshift doesn't sink any 'hooks' the boot process at all, it doesn't even run until after booting (10 mins after a reboot) , and is run by a cron timer. No services or anything like that.


Now, to prevent this sort of thing, it is pretty easy to convert the fstab to use UUIDs for your other mounts, similar to what it shows for your "/"

run sudo blkid to find the info. Unplug any USB drives you don't normally keep plugged in, if things are harder to decipher.

Then, transfer the UUID-"xxxxxx" found for each item to the fstab

#My extra data drive
UUID=12345678-1234-8765-1234-bcdefghijklm   /mnt/SSD2/    ext4     defaults,nofail       0 0
# My other extra drive
UUID=02345678-2345-4365-3456-abcdefghijkl /media/unity/sdg1   ext4     defaults,nofail       0  0

[GreyGeek]

I'm curious: If you uninstalled TimeShift did you do so before you deleted all the snapshots it made, or deleted them manually afterwards?

[TinyTim]

Appreciate that, I may have some questions for you later. Does this sound right, from a Linuxmint forum > I found that by using the UUID of the drive as the mount point solves the issue? Also does the non-volatile RAM, you mention, deal with (proc) "process information pseudo-file system"? The program that caused the problem is Timeshift by TeeJee. I would not mind, except when you uninstall TS, it leaves the hooks in, forcing you to keep the ext4 USB in 4ever to boot.

[jlittle]

/dev/sda1 /mnt/SSD2 ext4 defaults
/dev/sdg1 /media/unity/sdg1 ext4 defaults

Those two lines are definitely not good and should not be there in that form (fstab entries should use LABEL= or UUID= ; I suggest reading the fstab man page.) However I don't think they can cause your trouble.

A reinstall of grub might clean up your boot, overwriting the mess the mysterion has caused. You may have to do that while booted from a Live USB; just ask if you don't know how.

Assuming UEFI, the utility efibootmgr might be useful; it can show the boot variables in non-volatile RAM. A normal boot is the UEFI reads the boot variables, which point to /boot/efi/EFI/ubuntu/grub.cfg, which points to /boot/grub/grub.cfg. I'd look at each of the NVRAM boot variables and the grub.cfg files, looking for evidence.

[TinyTim]

Timeshift did it. Update: I probably did it. I downloaded from one from PPA, claiming it had fix for the bug. All it did was remove the part where a password was required to unmount. The hook is still in there. A USB ext4 has to be plugged in for it to boot and shut down. I would not mind this requirement so much, but when you uninstall the program, it leaves the binding in, and you need a USB ext4 plugged in 4ever after being raped by Timeshift. It is like having to ask someone for your own car keys every time you want to drive your car. Let me know if you need any more info.

[Snowhog]

“A backup program”

Can you be more vague! What backup program?

[TinyTim]

Solved: "nofail" was a good workaround; but the problem was in the fstab, outside the viewing area, /dev/sdg1 was in the same line with the main drives partition SSD2 entry. Once I removed that errant entry, it behaved normally. I also removed any reference to the external ext4 USB from the fstab

***THIS IS WHAT HAPPENED. I installed TimeShift, when I was formatting the USB to Ext4, I unmounted and formatted it. Gparted had not option to MOUNT the device. When trying to MOUNT in bash konsole, it proclaims "can not find in fstab". So what a new guy like me does is enter the USB into the fstab because that is what i 'think' it needs due to the message. All I had to do is reboot, and it would of automounted, but that was never clearly recognized. Since the USB was now in the fstab, it would not boot or allow it to be removed without a password. It was part of the boot system.***

Kubuntu and Ubuntu 22.04 machines with same issue.

Here is the boot up error message.
( 13.098039) EXT4-fs (sdc1): VFS: Can't find ext4 filesystem
( 14.437082)
You are in emergency mode. After logging in type "Journalctl -xb"
to view
system logs. "systemctl reboot" to reboot "systemctl default" or "exit"
to boot into default mode.
(or press Control-D to continue):

Here is Kubuntu 22.04 fstab.
fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=8256fca0-2723-4e9a-bc64-ac669b1cdd7d / ext4 errors=remount-ro>
# /boot/efi was on /dev/sda2 during installation
UUID=A9EF-3FF7 /boot/efi vfat umask=0077 >
/swapfile none swap sw >
/dev/sda1 /mnt/SSD2 ext4 defaults >
/dev/sdg1 /media/unity/sdg1 ext4 defaults >

Machine will hang at boot, will not boot. Put a ext4 USB in, and it will boot, if not it eventually will go to error and try to repair/instruct. Same with shut down. Pulled readme file off of the root in the offending program giving details of the mount and bindings.

Tried using this fix, did not work.



Answer: *adding the "nofail" option to the fstab on the /dev/sdg1 fixed the problem.*
Note: uninstalled errant Timeshift (TeeJee) mount hook is still there, the "nofail" option is a effective "work around".

Here are some of the error msg. in "journalctl log"
- ACPI BIOS Warning (bug) : Optional FADT field Pm2ControlBlock
- pc1 0000:02;00.0: (Firmware Bug) : disabling VPD access (can***?
- device-mapper: core: CONFIG_IMA_DISABLE_HTABALE is disabled
-platform eisa-0: EISA Cannot allocate resource for mainboard
(which I guess is regarding a EISA card, there is only one ISA card that is a nvidia card)
*I will add more as I go.