Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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.

    ​​ Click image for larger version  Name:	image.png Views:	8 Size:	78.9 KB ID:	673868

    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.
    Last edited by TinyTim; Nov 27, 2023, 07:21 PM.

    #2
    “A backup program”

    Can you be more vague! What backup program?
    Using Kubuntu Linux since March 23, 2007
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes

    Comment


      #3
      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.
      Last edited by TinyTim; Sep 16, 2023, 01:09 AM.

      Comment


        #4
        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.
        Regards, John Little

        Comment


          #5
          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.

          Comment


            #6
            I'm curious: If you uninstalled TimeShift did you do so before you deleted all the snapshots it made, or deleted them manually afterwards?
            "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
            – John F. Kennedy, February 26, 1962.

            Comment


              #7
              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


              Last edited by claydoh; Sep 17, 2023, 08:57 PM.

              Comment


                #8
                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.

                Comment


                  #9
                  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.
                  Using Kubuntu Linux since March 23, 2007
                  "It is a capital mistake to theorize before one has data." - Sherlock Holmes

                  Comment


                    #10
                    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.

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        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.
                        The next brick house on the left
                        Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.24.7 | Kubuntu 22.04.4 | 6.5.0-18-generic

                        Comment


                          #13
                          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 )

                          Comment


                            #14
                            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.

                            Comment


                              #15
                              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.
                              The next brick house on the left
                              Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.24.7 | Kubuntu 22.04.4 | 6.5.0-18-generic

                              Comment

                              Working...
                              X