[SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

CryogEnix · 2026-06-25 03:12:44

The title is the same as for https://bbs.archlinux.org/viewtopic.php?id=269588
My case is different in that $ uname -a gives me the kernel that I just installed: linux 7.0.13-arch1-1 (Looking up the official repos, I see that this package was flagged out-of-date, today... Bad coincidence?)

Here is the string of events that lead to this:

   # pacman -Syu

I then get an ERROR message indicating failure to rebuild something against the latest regular kernel because I had it listed in pacman.conf "Ignore" array, so after the installation finishes I comment out that line and re-run # pacman -Syu just to get the regular kernel as well.
I reboot...and as I start Hyprland in a TTY, it launches with only the usual background wallpaper and no sign of anything responding to keyboard input.
I jump to another TTY – the systemd journal does not show anything out of the ordinary with:

   $ journalctl -p 3 -xb

I then reboot into the lts kernel, and the same thing happens.
Unsure of what is going on, I go back into the regular one, comment out these variables in my hyprland.conf:

env = $XDG_SESSION_DESKTOP,Hyprland
env = $XDG_CURRENT_DESKTOP,Hyprland
env = $XDG_SESSION_TYPE,wayland

and reboot again, to no avail, so I run the following command to use the snapshot I took just before the first -Syu:

   # timeshift --restore

Another reboot, and I end up in the emergency shell.

Does anyone have an idea of when or why my /boot partition could have gotten unmounted?
Was it Timeshift bringing back an older kernel that is no longer used by Grub...but then, should I have done a grub-mkconfig before rebooting the first time?... And what about the first pacman installation command in which linux-lts among other things was installed?... I'm really not sure what is going on, here, and it feels like there are multiple problems causing all of this. I can't even mount the /boot partition because the vfat filesystem is unrecognized.
For the record, I updated the system five days ago without any issue...though I didn't try to use Flameshot since then, until today.

Side note: Flameshot would not take any screenshot prior to everything described here because:

   $ flameshot full
flameshot: error: Could not locate the `org.freedesktop.portal.Desktop` service
flameshot: error: Unable to capture screen
flameshot: info: Screenshot aborted.

just like in here https://bbs.archlinux.org/viewtopic.php?id=313917, so as I'm on Wayland I thought of updating my system before trying anything else, as $ checkupdates indicates an update for xdg-desktop-portal.
EDIT: I think I remember that in my case, the message was that `org.freedesktop.portal.Desktop` service failed to start...

EDIT #2: After verifying the output of $ uname -a with both the regular and lts kernels, it appears that GRUB is indeed using the most recent versions despite timeshift reverting the system back to where it was BEFORE my installing both of them:
linux 7.0.13-arch1-1
linux-lts 6.18.36-1-lts
And I can tell that Timeshift DID revert the system when looking at the pacman log file and # pacman -Ss showing me an older version...so actually, now that I think about it, only the root "/" of the system was reverted...which means that I have to # mkinitcpio to use an older kernel version...?

Last edited by CryogEnix (2026-06-25 11:49:07)

seth · 2026-06-25 05:55:31

I then get an ERROR message indicating failure to rebuild something … the systemd journal does not show anything out of the ordinary … timeshift --restore

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Get us the pacman log and the last journals, you might have to access them chrooting in from the install iso or https://wiki.archlinux.org/title/System … al_to_view
You can upload texts using the 1st link below
Please post your complete system journal for the boot:

sudo journalctl -D /mnt/var/log/journal -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'
sudo journalctl -D /mnt/var/log/journal -b -1 | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

Once you lost access to the vfat module, /boot will simply not have mounted and timeshift'ing out of that situation would write the kernel into the mountpoint (/boot on the root partition)

Mounting the /boot partition after the root partition (/mnt) into /mnt/boot before arch-chrooting into /mnt and re-installing the kernel package(s) should™ take care of that.

CryogEnix · 2026-06-25 08:20:03

Thanks for the reminder, Seth.

system.journal: https://paste.c-net.org/************
user-1000.journal: https://paste.c-net.org/PoochMayhem
pacman.log: https://paste.c-net.org/InboundFriendly

I couldn't get the user journal files for the rest of what happened before Hyprland was no longer responding on the first reboot...though I think the one I provided here describes some of it.

Once you lost access to the vfat module, /boot will simply not have mounted and timeshift'ing out of that situation would write the kernel into the mountpoint (/boot on the root partition)

While I was still in the emergency terminal, the /boot directory was empty.
I think I understand what you mean, but again (1) I timeshift'ed three reboots—where I could still launch a graphical session, albeit unresponsive—after the kernels were updated, at which point I ended up losing the module, and (2) the kernels aren't even on btrfs, so I don't see how I could have lost the vfat module at that point... Is there something I'm missing about how kernel updates work?

Also, is it fine to install the now-flagged-out-of-date kernel?
EDIT: Here is the pacman log after re-installing the kernels https://paste.c-net.org/PrivatesMounting

Last edited by CryogEnix (2026-06-25 14:28:04)

seth · 2026-06-25 10:38:35

Jun 25 05:34:49 archlinux kernel: Linux version 6.18.36-1-lts

[2026-02-07T08:06:49-0400] [ALPM] upgraded linux-lts (6.12.68-1 -> 6.12.69-1)
[2026-02-12T17:11:23-0400] [ALPM] upgraded linux-lts (6.12.69-1 -> 6.12.70-1)
[2026-02-22T14:47:09-0400] [ALPM] upgraded linux-lts (6.12.70-1 -> 6.12.74-1)
[2026-03-17T15:38:49-0300] [ALPM] upgraded linux-lts (6.12.74-1 -> 6.18.18-1)
[2026-04-24T21:59:19-0300] [ALPM] upgraded linux-lts (6.18.18-1 -> 6.18.24-1)
[2026-05-17T17:24:09-0300] [ALPM] upgraded linux-lts (6.18.24-1 -> 6.18.31-1)
[2026-06-19T03:50:13-0300] [ALPM] upgraded linux-lts (6.18.31-1 -> 6.18.35-1)
[2026-06-25T06:44:50-0300] [ALPM] upgraded linux-lts (6.18.35-1 -> 6.18.36-1)

The kernel you were booting first shows up in the second pacman log, postdating that boot.
Does it work now?

Jun 25 05:34:49 archlinux kernel: Command line: BOOT_IMAGE=/vmlinuz-linux-lts

You're booting from some boot partition, so mounting that is important and the path on the root partition must not be used.

so I don't see how I could have lost the vfat module at that point...

This is a common symptom of booting a kernel that's not/longer installed because the on disk modules in /lib/modules for that kernel are missing.

CryogEnix · 2026-06-25 11:23:50

This is a common symptom of booting a kernel that's not/longer installed because the on disk modules in /lib/modules for that kernel are missing.

I see... Since the new kernels became no longer "installed"/available due to Timeshift removing the directories named after them containing the modules on the root partition, that's how I ended up in the emergency shell.

Things appear to be normal, now...even Flameshot... I don't know how.
There's just one thing that worries me at the very end of that second pacman log.

Last edited by CryogEnix (2026-06-25 11:32:07)

seth · 2026-06-25 11:28:29

That's from https://archlinux.org/packages/extra/an … -detector/
https://github.com/max-baz/rebuild-detector - maybe "checkrebuild -v" provides details on that but since

[2026-06-25T06:45:04-0300] [ALPM-SCRIPTLET]   Skipped: Running in chroot.

you should first check whether this actually still occurs in a regular environment.

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

CryogEnix · 2026-06-25 11:41:46

I mean this:

[2026-06-25T06:45:04-0300] [ALPM-SCRIPTLET] fatal library error, lookup self

or is it referring to the same thing?

$ checkrebuild is not giving me anything, so I'll mark this as solved.

Last edited by CryogEnix (2026-06-25 11:48:09)

seth · 2026-06-25 11:49:13

referring to the same thing

This - and I somewhat suspect it's because of the chroot.

CryogEnix · 2026-06-25 12:33:01

the path on the root partition must not be used.

Just to be absolutely clear—you mean the path "/boot" on the root partition of the iso is the one to be avoided and not "/mnt/boot" from my system while in the iso's shell, correct?
I keep thinking back on that, and the more I do the more I wonder where those kernels ended up, at least based on what you're describing...because again, the /boot directory you were referring to at that point was empty.
I'm pretty sure that they were in the right place all along—I just could no longer access the partition from within my system because of Timeshift.
I suppose the kernels don't need to be on a mounted filesystem to be initialized.

Last edited by CryogEnix (2026-06-25 13:21:24)

seth · 2026-06-25 13:00:02

You need to have the boot partition mounted into /boot (or /mnt/boot before chrooting from the install iso) when updating the kernel or recreating the initramfs (or updating grub or it's config)
Otherwise it's not required to be mounted for regular business.
But the main point is that /boot should be empty when nothing's mounted there.

Arch Linux

#1 2026-06-25 03:12:44

[SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#2 2026-06-25 05:55:31

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#3 2026-06-25 08:20:03

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#4 2026-06-25 10:38:35

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#5 2026-06-25 11:23:50

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#6 2026-06-25 11:28:29

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#7 2026-06-25 11:41:46

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#8 2026-06-25 11:49:13

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#9 2026-06-25 12:33:01

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

#10 2026-06-25 13:00:02

Re: [SOLVED]Failed to mnt /boot -- Dependency failed for Local FileSystems

Board footer