Announcement

**Snowhog** · Sep 12, 2023, 10:01 PM

“A backup program”

Can you be more vague! What backup program?

**TinyTim** · Sep 12, 2023, 11:19 PM

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.

**jlittle** · Sep 12, 2023, 11:28 PM

Originally posted by TinyTim View Post

Code:

/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** · Sep 13, 2023, 12:15 AM

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.

**GreyGeek** · Sep 13, 2023, 12:30 PM

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

**claydoh** · Sep 13, 2023, 02:37 PM

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

Code:

#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

**TinyTim** · Sep 14, 2023, 09:11 AM

Originally posted by GreyGeek View Post

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.

**Snowhog** · Sep 14, 2023, 09:57 AM

Originally posted by TinyTim View Post

/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** · Sep 14, 2023, 11:55 AM

Originally posted by Snowhog View Post

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.

**TinyTim** · Sep 14, 2023, 05:55 PM

Originally posted by jlittle View Post

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.

**jglen490** · Sep 14, 2023, 06:01 PM

I would modify the /etc/fstab file by commenting the USB entry, such that is looks like

# /dev/sdg1 /media/unity/sdg1 ext4 defaults >

. Then try a reboot. The boot process should ignore that line because it has the # in the first position.

**TinyTim** · Sep 14, 2023, 06:20 PM

Originally posted by claydoh View Post

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

Code:

#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

I was like you on the 'nofail' option because it made no logical sense, imagine my surprise when it worked.
I have found documents, 4 pages long inside their systems readme file, and discussions of Timeshift using mount hooks and triggers, Timeshift is pleased with their efforts regarding this. (I'm assuming... they don't want to boot up on a machine that has not reconciled this very pertinent USB device, maybe for protection and integrity of the backup itself) TeeJee PPA even claimed to have a fix for the dismount problem, I used it and it did not work.

I did assign a UUID to the the /dev/sdg1 node, the machine would not boot at all with any ext4 usb in any port. (I did not run tuning on it, because the instructions did not call for it) **The strangest thing, if I remove 'nofail' from the default and boot default, it will except ""ANY"" ext4 formatted USB, in ""ANY"" port. "It is possible that installing Timeshift with a node instead of UUID could be the problem.

Ultimately, requiring a ext4 plugged in to operate machine, with mount and unmount issues, admitted by TImeshift, before and after it is uninstalled, is a red flag to me. I don't know, but I do want to find out. Thanks

)

**TinyTim** · Sep 14, 2023, 06:24 PM

Originally posted by jglen490 View Post

I would modify the /etc/fstab file by commenting the USB entry, such that is looks like . Then try a reboot. The boot process should ignore that line because it has the # in the first position.

I will check that out eventually out of curiosity. However, I'm fairly sure, it will look for that device, (for some strange unknown reason) not find it and go to emergency mode.

**jglen490** · Sep 14, 2023, 07:05 PM

Understand, but at least it would be possible to eliminate fstab as the source of the behavior. It might still be an entry in Removable Storage under the System Settings menu.

Announcement

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment