#Kernel Panic

122 messages · Page 1 of 1 (latest)

devout raven
#

Kernel Panic after running pacman -Syu

EndeavourOS booting using Systemd and dracut, not mkinitcpio

Pretty straight forward kernel panic but in no expert on linux yet. I did grab the panic log from the QR code here unless i somehow missed something:
https://t.ly/P1nR8

I did try running the dracut command to generate an initramfs under 2)Usage on https://wiki.aechlinux.org/title/Dracut but it didn't work at resolve my issue.

dusky ore
#

the kernel tried to find an init executable to run

#

and couldn’t find anything, and hence panicked

devout raven
#

Damn. What are my options?

dusky ore
#

can you mount your root filesystem in a live system and check whether /usr/bin/init exists?

devout raven
#

Does using the fallback qualify?

dusky ore
#

hm, oh right

#

this seems to be the systemd in the initramfs

#

so not an issue of the systemd on the main system

#

I mean, have you tried regenerating the initramfs already?

devout raven
#

Yes i used the command in the arch wiki for dracut to generate a initramfs

dusky ore
#

did you see some modules named systemd being added while it was generating?

#

anyway, the main issue seems to be your hostonly initramfs as generated by dracut seems to be missing some parts, so that’s what we need to focus on fixing

devout raven
devout raven
dusky ore
#

you can try generating it again now and see what pops up

#

boot into your system via the fallback, since that one works

#

anyway, you can also run lsinitrd [image] | less to see what’s inside the image

devout raven
#

Is it safe if i run the dracut command using --force?

dusky ore
#

yup, that just forces regeneration

#

dracut refused to overwrite a file that exists unless you pass --force

#

which just deletes the old file if it exists before generating

devout raven
#

Should i paste the output here?

dusky ore
#

sure!

devout raven
#

Too long. Would a text file be safe?

dusky ore
#

yea, sure

devout raven
dusky ore
#

that does seem about right

#

it’s including systemd and dracut-systemd

#

can you do the lsinitrd command above to check if /init or /usr/bin/init exists?

devout raven
#

I dont see that directory listed. Explored that using dolphin and couldn't find a directory called that either in that location

dusky ore
#

hm…

#

that’s odd

#

can you generate a new fallback initramfs somewhere else (not overwriting your current one) to compare?

devout raven
#

How would i do that and ensure i don't deep fry my fallback?

dusky ore
#

just make it as a different name

devout raven
#

Ah

dusky ore
#

I’m testing looking at a dracut initramfs I have

#

how were you looking at the image in dolphin before?

#

using Ark it seems it only shows partial contents

#

more specifically I only get early_cpio and kernel

devout raven
#

I was saying i couldn't find the directory /usr/bin/init

dusky ore
#

oh, I meant like

#

inside the initramfs

#

since that is the issue here

#

the initramfs is its own filesystem

devout raven
#

I haven't opened it manually

#

I've never done that before so i'm not yet sure how

#

I generated an extra fallback located in tmp

#

Though i didn't run it as root so unsure if i absolutely needed to

dusky ore
#

the goal is just to look at it

#

can you do lsinitrd on the new fallback and save it to a file?

#

and then same thing with the regular one that’s not booting

devout raven
#

Do i just use that command and the filename after it to accomplish that?

dusky ore
#

yea, that’s right

devout raven
#

So i have the original but looks like my attempt to generate an extra of the fallback initramfs didn't succeed originally.

#

To generate a fallback it says the command is
dracut /boot/initramfs-linux-fallback.img

To create an extra without overwriting the fallback do i just rename it in the command?

dusky ore
#

yup

#

the name doesn’t matter, what actually makes it a fallback is not using the hostonly option

#

and you probably need to run it as root since it includes a bunch of files that may not be accessible as non-root

devout raven
#

Ah. So this extra won't interfere with the fallback and can be deleted later?

dusky ore
#

yup

#

it’s just a separate file

#

if it’s not sitting where the bootloader expects initramfs files to be it won’t do anything

devout raven
dusky ore
#

…hm, but init seems to exist in both

# 
lrwxrwxrwx   1 root     root           23 Apr 28 19:13 init -> usr/lib/systemd/systemd
#

if you reboot, do you still get the same panic?

devout raven
#

Yep

dusky ore
#

oh, error −2 the panic log says

#

hm, okay

#

I searched this up and the forums were unhelpful

#

one systemd issue simply got closed with ‘updating fixed it’

#

I really can’t tell why the default initramfs would fail here

#

I guess you can switch your boot entries to use the fallback initramfs by default in the meantime

#

but I genuinely can’t figure out why systemd would be failing to start from this

devout raven
#

This panic was after an update using pacman -Syu. But could having installing lib32-libpipewire have caused this? It was installed before the update

dusky ore
devout raven
#

Ah

#

Would reverting the kernel version help or was that not updated?

dusky ore
#

your kernel version was probably updated

#

the question is from which version

devout raven
#

Those are cached right?

dusky ore
#

mhm, yea

devout raven
#

If i can find it manually i can probably find the version

dusky ore
#

in /var/cache/pacman/pkg

devout raven
#

The filename would have the word headers in it right?

dusky ore
#

no, just linux

#

linux headers is a separate thing

#

though it should follow the same versioning

devout raven
#

It upgraded from 6.14.3 to 6.14.4 today when the update ran

#

From the fallback how do i downgrade and not mess up the fallback?

dusky ore
#

well, your initramfs is tied to your kernel version

#

if you downgrade your current fallback just won’t work anymore

devout raven
#

So is this reinstall the OS worthy then? I don't even know how this imploded

dusky ore
#

you could at least try mkinitcpio

#

I’m not sure what happened here either but my main system uses mkinitcpio

#

and upgrading from 6.14.3 to 6.14.4 had absolutely zero issues

devout raven
#

But doesn't that interfere with dracut that's the default of my system?

dusky ore
#

oh, right, you use EndeavourOS

#

if EndeavourOS packages mkinitcpio, all you would need to do would be to swap out the pacman hooks

#

if it doesn’t… your choices would be either to downgrade or reinstall

devout raven
#

So then i will try using downgrade if i can figure how to use it on a kernel (if you know id appreciate the assist) and since that will screw my fallback i am no worse a position than i already am

dusky ore
#

but you probably want someone else to double check

#

I’m very sleep deprived and hungy and I need to do some stuff in a moment

devout raven
#

I'm discovering endeavouros has something called shifttime

dusky ore
#

timeshift? or is it a separate thing

#

normally that’s what you use since it rolls back the entire system

#

which is more reliable than downgrading a few packages

#

I didn’t know if you had it set up so I didn’t ask about it

devout raven
#

Using the command eos-shifttime i can revert to a specific date configuration

#

Its built into endeavouros

#

So i set it to shift back to yesterday and will see how this goes

devout raven
#

So i used eos-shifttime to revert the packages back to yesterday. Then i installed the lts kernel for arch as a test and used the --kver variable in dracut to specify the lts kernel i installed and it generated a new initramfs and it boots now

#

So its definitely the new kernel that deep fried my initramfs. Or at the least an operation involving that kernel update was the culprit.

devout raven
#

@dusky ore thank you for your help. You made it possible for me to successfully recover my system

weary hearthBOT
#

fleuriafluoride received a thank you cookie!

dusky ore
#

oh, of course!

#

if there’s nothing else you can mark your post as [SOLVED]