Issues booting after kernel upgrades
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. Does anyone have tips for how to potentially fix this? /Lucie
What are you doing manually that the install isn't doing for you? Do you have a log of what a chroot and manual install looks like so we can compare it to what the package is normally doing? On Tue, Apr 21, 2026, at 2:44 PM, Lucie Scarlet wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now.
Does anyone have tips for how to potentially fix this?
/Lucie
*Attachments:* • OpenPGP_0x257D35EF5E938593.asc • OpenPGP_signature.asc • publickey - lucie@scarlet.moe - 0x4C91F9E3.asc • signature.asc
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now.
A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead. Compare the mounts you do in the archiso with those made when your system boots.
On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
A good practice is to set chattr +i on directories that are mount points for filesystems. Regards, Łukasz
On 4/22/26 3:30 AM, Łukasz Michalski wrote:
On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
A good practice is to set chattr +i on directories that are mount points for filesystems.
Why would/should I want to do that? What would be the advantage for doing so? I ask this because I have not done so since running Linux since 1995. This is the first time I have seen this recommendation. -- Hindi madali ang maging ako
On 2026-04-22 16:52, Pocket wrote:
On 4/22/26 3:30 AM, Łukasz Michalski wrote:
A good practice is to set chattr +i on directories that are mount points for filesystems.
Why would/should I want to do that? What would be the advantage for doing so? I ask this because I have not done so since running Linux since 1995. This is the first time I have seen this recommendation.
A look into `man chattr` will tell you what it does: disallowing changes to the directory or to files in it, but it doesn’t apply to the mounted filesystem. Though in this case Lucie mounted a wrong partition, so it wouldn’t have helped here. Best, tippfehlr
On 4/22/26 12:38 PM, Jonathan Grotelüschen wrote:
On 2026-04-22 16:52, Pocket wrote:
On 4/22/26 3:30 AM, Łukasz Michalski wrote:
A good practice is to set chattr +i on directories that are mount points for filesystems.
Why would/should I want to do that? What would be the advantage for doing so? I ask this because I have not done so since running Linux since 1995. This is the first time I have seen this recommendation.
A look into `man chattr` will tell you what it does: disallowing changes to the directory or to files in it, but it doesn’t apply to the mounted filesystem. Though in this case Lucie mounted a wrong partition, so it wouldn’t have helped here.
I have read the manual page and I do known what it does. What I am trying to ask here is why you would want to use chattr +i to make mount points immutable? Here is the top level of my current desktop mounted at /mnt ls /mnt Cache Home System [root@alarm ~]# cat /etc/fstab # Static information about the filesystems. # See fstab(5) for details. # <file system> <dir> <type> <options> <dump> <pass> UUID=9514386f-6ba0-42b6-942a-939e87857591 / btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/System 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /home btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/Home 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /var/cache/pacman/pkg btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/Cache 0 0 UUID=97BB-2AFA /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 2 UUID=4d995c91-fee4-4289-bade-85496d49e572 none swap defaults 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /mnt btrfs noauto,rw,relatime,compress=lzo,discard=async,space_cache=v2 0 0 So how would chattr +i help my installation? -- Hindi madali ang maging ako
[root@alarm ~]# cat /etc/fstab # Static information about the filesystems. # See fstab(5) for details. # <file system> <dir> <type> <options> <dump> <pass> UUID=9514386f-6ba0-42b6-942a-939e87857591 / btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/System 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /home btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/Home 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /var/cache/pacman/pkg btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/Cache 0 0 UUID=97BB-2AFA /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 2 UUID=4d995c91-fee4-4289-bade-85496d49e572 none swap defaults 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /mnt btrfs noauto,rw,relatime,compress=lzo,discard=async,space_cache=v2 0 0
I think there's a mistake with regards to <pass> / is already at pass 0 (correct) Everything else should be at pass 1 (or above). If you have multiple file system at pass 0, it's possible that when /boot (pass 2) wants to be mounted, it doesn't have a mountpoint, and it won't be mounted If you restart the computer, does /boot always get mounted as rw? What's your bootloader? (what device is this?) I saw that you're using alarm. ARM boot process can be complicated depending on what device you use. Are you using UEFI, depthcharge? Is this a raspberry pi or something? Did you make any changes in boot process / use custom kernel?
On 4/22/26 8:13 PM, evansjahja13@gmail.com wrote:
[root@alarm ~]# cat /etc/fstab # Static information about the filesystems. # See fstab(5) for details. # <file system> <dir> <type> <options> <dump> <pass> UUID=9514386f-6ba0-42b6-942a-939e87857591 / btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/System 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /home btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/Home 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /var/cache/pacman/pkg btrfs rw,relatime,compress=lzo,discard=async,space_cache=v2,subvol=/Cache 0 0 UUID=97BB-2AFA /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 2 UUID=4d995c91-fee4-4289-bade-85496d49e572 none swap defaults 0 0 UUID=9514386f-6ba0-42b6-942a-939e87857591 /mnt btrfs noauto,rw,relatime,compress=lzo,discard=async,space_cache=v2 0 0 I think there's a mistake with regards to <pass>
/ is already at pass 0 (correct)
Everything else should be at pass 1 (or above). If you have multiple file system at pass 0, it's possible that when /boot (pass 2) wants to be mounted, it doesn't have a mountpoint, and it won't be mounted
There isn't any mistakes in my opinion as the btrfs doesn't need need fsck. /boot is vfat so it fsck at boot time isn't meaningful. It is marked to fsck on boot but this happens: sudo fsck -f /dev/sdb1 fsck from util-linux 2.41.3 fsck.fat 4.2 (2021-01-31) There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 65:01/00 1) Copy original to backup 2) Copy backup to original 3) No action [123?q]? 3 Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. 1) Remove dirty bit 2) No action [12?q]? 1 ** Filesystem was changed *** The changes have not yet been written, you can still choose to leave the filesystem unmodified: 1) Write changes 2) Leave filesystem unchanged [12?q]? 1 /dev/sdb1: 420 files, 15432/130811 clusters
If you restart the computer, does /boot always get mounted as rw?
Yes, all mounts are rw
What's your bootloader? (what device is this?) I saw that you're using alarm. ARM boot process can be complicated depending on what device you use. Are you using UEFI, depthcharge? Is this a raspberry pi or something? Did you make any changes in boot process / use custom kernel?
This is a raspberry pi 5 This is not archlinuxarm/alarm. The alarm is just the hostname for this box and will be changed when I finish my project. hostnamectl Static hostname: alarm Icon name: computer Machine ID: 0e60745bb1214cd691de942658ab16c6 Boot ID: e6d9b6d1b47b4781acc0e98d9704cc66 Operating System: Arch Linux ARM Kernel: Linux 6.18.20-1-rpi Architecture: arm64 pacman -Qq|grep rpi linux-rpi <-- This will chg to 16k kernel current build process is for rpi 4 linux-rpi-headers rpi4-eeprom pacman -Qq|grep rasp firmware-raspberrypi raspberrypi-bootloader raspberrypi-utils Is what I use. I also built all the packages from the archlinux x86_64 PKGBUILD's All build except the following argyllcms: BARFS icmake: BARFS fbida: BARFS libtpms: BARFS mupdf: BARFS sequoia-sq: BARFS python-dbus-deviation: BARFS I am working to get those to build It currently using lxqt desktop, all packages were built with CFLAGS='-mcpu=cortex-a72 -O2 -pipe -ftree-vectorize -fomit-frame-pointer' CXXFLAGS="-Wp,-D_GLIBCXX_ASSERTIONS" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now \ -Wl,-z,pack-relative-relocs" No LTO, that will be on the next build I did use LTO when I was building using RPM Currently my project is running on two desktops rpi 5 and a single rpi 4 which is running PiHole nginx unbound and gitweb I also has a btrfs RAID 1 as network storage. I don't do x86_64 any more. -- Hindi madali ang maging ako
linux-rpi-16k is not compatible with rpi5 https://github.com/archlinuxarm/PKGBUILDs/blob/b4d1ebe751c9f01cea4170583b9c1... When installing linux-rpi there could be errors, are you seeing any https://github.com/archlinuxarm/PKGBUILDs/blob/b4d1ebe751c9f01cea4170583b9c1...
On 4/22/26 10:33 PM, Evans Jahja wrote:
linux-rpi-16k is not compatible with rpi5
https://github.com/archlinuxarm/PKGBUILDs/blob/b4d1ebe751c9f01cea4170583b9c1...
When installing linux-rpi there could be errors, are you seeing any
https://github.com/archlinuxarm/PKGBUILDs/blob/b4d1ebe751c9f01cea4170583b9c1...
No, I build it myself -- Hindi madali ang maging ako
On 4/22/26 10:33 PM, Evans Jahja wrote:
linux-rpi-16k is not compatible with rpi5
Yes it is , it is not compatible with rpi4
https://github.com/archlinuxarm/PKGBUILDs/blob/ b4d1ebe751c9f01cea4170583b9c1960d8c6f3da/core/linux-rpi-16k/linux- rpi-16k.install#L28 <https://github.com/archlinuxarm/PKGBUILDs/blob/ b4d1ebe751c9f01cea4170583b9c1960d8c6f3da/core/linux-rpi-16k/linux- rpi-16k.install#L28>
When installing linux-rpi there could be errors, are you seeing any
https://github.com/archlinuxarm/PKGBUILDs/blob/ b4d1ebe751c9f01cea4170583b9c1960d8c6f3da/core/linux-rpi/linux- rpi.install#L48 <https://github.com/archlinuxarm/PKGBUILDs/blob/ b4d1ebe751c9f01cea4170583b9c1960d8c6f3da/core/linux-rpi/linux- rpi.install#L48>
Nope no errors, /boot is mounted when I install/upgrade the kernel -- Hindi madali ang maging ako
On Wed Apr 22, 2026 at 7:08 PM CEST, Pocket wrote:
[...]
I have read the manual page and I do known what it does.
What I am trying to ask here is why you would want to use chattr +i to make mount points immutable?
As explained, the `chattr` doesn't impact the mounted filesystem. It impacts the mount point. So if there's nothing mounted on /boot you can't write files to it because it's immutable. If something is mounted, this filesystem is not impacted by the immutable flag and the write will work. This habit will function as a sanity check that you in fact do have something mounted to /boot and aren't writing files to the filesystem mounted at root. Think of it like an `assert(boot_is_mounted)`. Br, Linus
On 4/22/26 4:52 PM, Pocket wrote:
On 4/22/26 3:30 AM, Łukasz Michalski wrote:
On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
A good practice is to set chattr +i on directories that are mount points for filesystems.
Why would/should I want to do that?
What would be the advantage for doing so?
This will save you if the target file system is not mounted for some reason. In the original post scenario, if the /boot file system had not been mounted, the kernel update would have failed. This is because the root file system's /boot has +i, which prevents any changes from being made. This ensures that you cannot mistakenly write vmlinuz, initrd, and other files there. Not very helpful for non-system directories like /mnt when you mount stuff as needed, but I set this flag for permanent mounts just for safety. Regards, Łukasz
On 4/22/26 4:20 PM, Łukasz Michalski wrote:
On 4/22/26 4:52 PM, Pocket wrote:
On 4/22/26 3:30 AM, Łukasz Michalski wrote:
On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
A good practice is to set chattr +i on directories that are mount points for filesystems.
Why would/should I want to do that?
What would be the advantage for doing so?
This will save you if the target file system is not mounted for some reason. In the original post scenario, if the /boot file system had not been mounted, the kernel update would have failed. This is because the root file system's /boot has +i, which prevents any changes from being made. This ensures that you cannot mistakenly write vmlinuz, initrd, and other files there.
Not very helpful for non-system directories like /mnt when you mount stuff as needed, but I set this flag for permanent mounts just for safety.
Regards, Łukasz
I see, you make all the fun go away doing that..... I am not sure it would have the intented purpose if the file system was btrfs and not partitioned. -- Hindi madali ang maging ako
This is actually quite interesting, didn't know about this. I could try this for my permanent mounts. You learn something new every day! On Wednesday, April 22nd, 2026 at 10:21 PM, Łukasz Michalski <lm@zork.pl> wrote:
On 4/22/26 4:52 PM, Pocket wrote:
On 4/22/26 3:30 AM, Łukasz Michalski wrote:
On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
A good practice is to set chattr +i on directories that are mount points for filesystems.
Why would/should I want to do that?
What would be the advantage for doing so?
This will save you if the target file system is not mounted for some reason. In the original post scenario, if the /boot file system had not been mounted, the kernel update would have failed. This is because the root file system's /boot has +i, which prevents any changes from being made. This ensures that you cannot mistakenly write vmlinuz, initrd, and other files there.
Not very helpful for non-system directories like /mnt when you mount stuff as needed, but I set this flag for permanent mounts just for safety.
Regards, Łukasz
On Wed, Apr 22, 2026 at 09:30:15 AM, Łukasz Michalski <lm@zork.pl> wrote:
On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now. A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
A good practice is to set chattr +i on directories that are mount points for filesystems.
Regards, Łukasz
-- Regards, Andreas
Hi, I was pretty sure I had made it so that /boot was mounted on /dev/nvme0n1p1, that's how I mount it in archiso, but running `df /boot` shows that it's on /dev/nvme0n1p2, which is where everything else is installed to as well. I noticed as well that /boot seemed very empty, but after mounting it correctly it seems to be all good now. Fingers crossed that it all works properly going forwards, and thank you all so much for the replies! :3 On 4/22/26 2:36 AM, Jan Alexander Steffens (heftig) wrote:
On Wed, Apr 22, 2026 at 12:24 AM Lucie Scarlet <lucie@scarlet.moe> wrote:
Hi, Whenever I upgrade my Linux kernel, my computer never properly boots. I have to boot into archiso and reinstall the kernel in chroot before I can get it booting again. Not very sure where to begin looking, but it's an issue that has been bugging me for a good while now. The fix for it is easy enough which is why I've put off mentioning it before now.
A common issue is that a split /boot partition isn't mounted, which causes the kernel upgrade to place new kernels and initrds in the root partition's /boot directory instead.
Compare the mounts you do in the archiso with those made when your system boots.
I noticed as well that /boot seemed very empty, but after mounting it
Could it be that you're not auto-mounting /boot in /etc/fstab? Also, what's your ROOT=... kernel parameter during boot? Maybe you need to use something stable like UUID
participants (11)
-
Andreas
-
Evans Jahja
-
evansjahja13＠gmail.com
-
Jan Alexander Steffens (heftig)
-
Jonathan Grotelüschen
-
Linus Probert
-
Lucie Scarlet
-
Pete's Lists
-
Pocket
-
Pocket
-
Łukasz Michalski