[SOLVED] Arch Linux Kernel Panic on Boot

Hello all. I’ve been a subscriber since the time prior to Level1Techs but never really became involved in the forum, so if this post in the wrong place I apologize. I’m still new to this side of L1T.

I installed Antergos on my work laptop about a month ago. It’s been working fine until the other day. I ran pacman -Syyu and walked away and let it do its thing. About a day later I restarted the machine and when it booted I received this kernel panic on the screen:

I attempted to select alternate kernel versions (Antergos has options for LTS and Fallback in Grub) but every option nopes into the above kernel panic screen.

Here’s what I have tried to fix it:
I started by creating a new Antergos live ISO and used the instructions located here to chroot into the OS. I ran a whole series of things from forums all over.

I’ve tried running pacman -Syyu again and it installed more items including the linux kernel. I’ve tried specifically to pacman -Su linux linux-headers. I’ve also tried to run mkinitcpio since the potato screen post I uploaded said /init/ couldn’t be started. All of these operations finished without error, but when I reboot I still get the kernel panic.

I’m at a loss here. There isn’t anything on this computer that I’m afraid to lose, I’m just trying to make sure I’ve fully exhausted my repair options before I resort to a clean install because I like to learn new things and this is the first time I’ve had a kernel panic. I have Antergos on my work desktop and my home desktop and haven’t had this problem (yet).

Thanks for all input.

Maybe re-generate initramfs: https://wiki.archlinux.org/index.php/Minimal_initramfs

Are the permissions correct on your FS? Looks like it could find the init binaries but couldn’t execute them. They must have execute bit set to work.


Also check if the root FS is correctly passed to kernel command line.

I.e. I have:

root=PARTUUID=b9e9da85-b231-49e7-abee-a39d767b6dcd

If you had something like root=/dev/sda1 and added new disk or even usb the sda is not a unique name for a device and might change. If it did, the kernel is looking for init program in the wrong place.

Thanks for the reply. I did run mkinitcpio, doesn’t that do the same as in the article you linked? I’m a little confused on that point.

off the topic, what is the deal of “disks and naming” for example, if I add new hdd/ssd it messes up naming. Have to use uuid in fstab, does it have to do with ports numbering or its randomly scrubbling when adding new devices?

I think it just depends on the order of the device discovery.

How would I check the permissions? Would it be using the chroot environment then running ls -la on / and see what the output is? I tried using ls on / but I didn’t see a folder called /init like the panic was referencing. Am I looking in the wrong place?

Secondly, the line you have to check if the FS is passed to kernel…was that in GRUB? I looked and didn’t see a similar line.

Sorry for these questions. This is a lot of new territory for me.

Don’t worry about it :wink:

don’t even need to be in chroot, you want any of the init files to have executable flags set (-rwxrwxrwx) other flags don’t really matter.

Yeah it should be in GRUB (I am not using it so not sure where it is 100%). I think it should be in /etc/default/grub

GRUB_CMDLINE_LINUX= ...

Now, tho. Since it finds the init files, the problem is likely not in this. Since if it couldn’t mount root fs, it would’t be able to even try all those files.

It’s probably in the initramfs like @Hujkis said. My bad. systemd should act like it. So it’s probs just a link. In any case. try to chroot and rebuild initramfs.

mkinitcpio -p linux

So I was able to locate the line in GRUB and it’s pointing to a UUID and not an sda so that seems to be fine.

mkinitcpio -p linux did not resolve the issue. The exact same panic reoccurs. I’m still trying to wrap my head around the suggestion @Hujkis gave.

They’re saying to do what I said, but also check if the configs are good.

Honestly I am a bit at a loss here.

When you’re in chroot does lsinitcpio /boot/initramfs-linux.img work? Does it spew out list of files?

When you’re in chroot, did you mount all your partitions. It’s important to mount /boot


heading to bed, good luck

1 Like

Alright it’s been solved. I was incorrectly mounting the partitions when prepping my chroot environment. I repeated this error EVERY time.

I was mounting /mnt and /mnt/boot as the SAME partition…/dev/sda3

So that was it. It finally dawned on me.

So this was what fixed it:

mount /dev/sda3 /mnt
mount /dev/sda2 /mnt/boot
arch-chroot /mnt
pacman -Syu

This time it updated SO much more and mkinitcpio was able to generate using the correct partition. I’m now in the system and using it like normal.

Thanks @oldgek for sticking with me through my temporary instanity. Is there a way to mark this as “solved”?

1 Like

Is it temporary though, ross
madness? :wink:

Glad it worked for ya!

1 Like