Unable to boot Manjaro kernel 4.19 - Kernel panic

Support Kernel
1

Despite using both GUI and CLI apps to reinstall linux419 …
( had a previous problem with filesystem so I had to reinstall all the packages…)

But recently i have found thta kernel 4.19 is not bootable.
Usually I have installed several kernels: the latest testing and a major version with the corresponding LTS kernel .

All the kernels were installed via the Manjaro Settings GUI with no errors whatsoever …

For some reason all the kernels are fine except the 4.19 .

Which reports something like :

Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Any ideas to understand why does this specific kernel fails to boot ?

2

Then … dont use 4.19 ?
Its the oldest available kernel.
And it will be dead by the end of the year.

2 Likes
3

Depending on the age for your hardware try a newer on eg. 5.4 but it’s better to try the newest LTS first 6.6 or 6.1

https://kernel.org/category/releases.html

4

Why would you need all kernels installed?

Of course - there is no rule to that - but it seems like an overkill.

Usually new kernels means better support for new hardware but 4.19?

4.19 is projected EOL Dec, 2024 - so there is no reason to keep it around if other kernels work as expected.
5.4 is projected EOL Dec, 2025

So unless you have very compelling reasons to use those kernel - my personal opinion is - it is time to :red_car: move on

3 Likes
5

My hardware is now showing its age …

( I have a P8Z77 motherboard and started to use Manjaro since 2015 …
Never reinstalled from zero …
Started with kernel 3.18 or something … and Manjaro were one of the first distros to have the 4.xx kernel available …)

Most of the time I have the latest kernel but sometimes when some strange behaviour appears I like to go back to a previous kernel to find if it something “new” or something that I missed before …

So in this case I am just asking if some else in the forum has the same problem as I have now …

Nonetheless I believe that the problem might be related to the init image compression …
I think I have actived ( it seems globally … ) the init images to be compressed in lzma …

Now my question is more of a : why did the mkinitcpio did not report any warning or information … ?!?

6

sudo file /boot/initramfs-*
will tell …

Curious as I am, I just changed /etc/mkinitcpio.conf and set lzma as the compression option.
(default is gzip)
It “feels” like lzma causes the image creation to take a long time - especially for the fallback image.

But both 5.15 and 4.19 boot and work just fine.

Why would you suspect the compression algorithm to be a cause of the problem?
What should it have warned about?
It will tell you what it does and which compression is used - certainly if you run sudo mkinitcpio -P linux from terminal

zstd cannot be used for lower versions than 5.9 - but otherwise, compression used should not matter for functionality.

I just saw in the Arch Wiki that zstd is the default there - but the text in /etc/mkinitcpio.conf here on Manjaro says the default is gzip. :man_shrugging:

will check now what it actually is …

result:
default compression option is still gzip

1 Like
7

Once I tried to make some experiences related to the initramfs ( compression algorithms and startup speed ) … But did not reach any conclusion.

Nonetheless calling file /etc/initramfs I get :

boot/initramfs-4.19-x86_64-fallback.img: ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-4.19-x86_64.img:          ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-5.15-x86_64.img:          ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.6-x86_64.img:           ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.8-x86_64-fallback.img:  ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.8-x86_64.img:           ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.9-x86_64-fallback.img:  ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.9-x86_64.img:           ASCII cpio archive (SVR4 with no CRC)

Which I interpret that I do not have compression … !?
Or am I missing something ?

8

Correct.
This is not default.

You must have set

COMPRESSION="cat"

in the COMPRESSION section of /etc/mkinitcpio.conf

9

Odd , as I have in /etc/mkinitcpio.conf :

...
 COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
COMPRESSION="zstd"

...

That means that something is not working as expected …

How can I force a full initramfs rebuild manually ?
( normally I expect the “update-grub” script to execute , once a new kernel is updated …)

10

mkinitcpio -P linux

watch the output

possibly followed by
update-grub

just update-grub by itself will not trigger a recreation

11

The initial problem is now solved as apparently I had defined the zstd compression in the /etc/mkinitcipio.conf …

As soon as I recreated the initramfs files with the default “gzip” COMPRESSION everything worked as expected .

Problem solved .
Thank you for the fast reply and support .

2 Likes
12

That won’t work with 5.4 and 4.19. Ah this was already said. Also next time mark the most appropriate answer as a solution instead of selfishly marking your own repeat.

1 Like
13

FYI my output is the same even though i use the default mkinitcpio so it says it should be compressed

14

If you leave /etc/mkinitcpio.conf totally untouched
all the possible compression methods are commented out
and the default should be used - which is gzip

If you explicitly use cat
or if you uncomment a method for which you do not have the necessary program installed
(this is the case for me when I try to use lzop)
then the fallback that is used is cat - which produces the result you see (uncompressed cpio archive)

15

yes, i have upstream mkinitcpio from pacnew and all are commented, and it show same output as above. I used to have modified one but reverted to upstream when i did large update to plasma6 to rule out any hacks i have made as potential issues for the update.

16

Then I don’t know.

sudo mkinitcpio -P linux

and watch the output carefully

One of the lines will be:

==> Creating gzip-compressed initcpio image: '/boot/initramfs-5.15-x86_64.img'

vs

==> Creating uncompressed initcpio image: '/boot/initramfs-5.15-x86_64.img'

when cat is used or when the compression program is not installed.

1 Like
17

==> Creating gzip-compressed initcpio image: ‘/boot/initramfs-6.6-x86_64-fallback.img’
→ Early uncompressed CPIO image generation successful
==> Initcpio image generation successful

And with this i have same output from the file command as was earlier taken to mean the image is uncompressed. So 1 of the 2 interpretations are wrong. Or is the output i posted saying it outright: it “generates gzip” but outputs “uncompressed” ?

18

The two lines of the message clearly contradict each other.
First says gzip-compressed, second says uncompressed.

Perhaps you have edited some options in the preset files?
/etc/mkinitcpio.d/linuxXYZ.preset

I really don’t know.
You spoke of .pacnew files - are they properly merged / the changes incorporated into the .conf files?

grep COMPRESSION /etc/mkinitcpio.conf
for me returns only lines with a # in front - which is the default

1 Like
19

cat linux68.preset

# mkinitcpio preset file for the '%PKGBASE%' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-6.8-x86_64"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-6.8-x86_64.img"
#default_uki="/efi/EFI/Linux/manjaro-6.8-x86_64.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-manjaro.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-6.8-x86_64-fallback.img"
#fallback_uki="/efi/EFI/Linux/manjaro-6.8-x86_64-fallback.efi"
fallback_options="-S autodetect"

why this is relevant i don’t know? I already told you mkinitcpio is same as upstream. It would be bad if some preset file elsewhere can f you up.

20

There is one, uncompressed cpio archive prepended to the actually compressed one. And when you run

file /.../initramfs*.img

it will show info of the first one. Case closed. :stuck_out_tongue: