Skip to main content ↑ ↓
Topic: ERROR: invalid kernel specified: `/boot/vmlinuz-linux' (Read 3484 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: ERROR: invalid kernel specified: `/boot/vmlinuz-linux'

Reply #30 –
Possibly this is related to what you said earlier about moving /boot/efi. I've sometimes accidentally created situations where the /boot partition is not mounted on /boot, things get written to the mount point, then hidden when the partition is mounted, and later could be revealed accidentally again but are the wrong version and so on, check files are where you expect and have the right modification times. And check grub.cfg (or equivalent) has the right partition UUID in the kernel commandline.

Re: ERROR: invalid kernel specified: `/boot/vmlinuz-linux'

Reply #31 –
Possibly, but remember I did this early on:

Code: [Select]
mkdir /boot/EFI/grub
cp /boot/EFI/BOOT/BOOTX64.EFI /boot/EFI/grub/grubx64.efi

I think it is okay to have both a /boot/EFI/BOOT/BOOTX64.EFI and a/boot/EFI/grub/grubx64.efi. I think that is how I made my MSI motherboard work before I read about the --removable option for grub-install.

Re: ERROR: invalid kernel specified: `/boot/vmlinuz-linux'

Reply #32 –
Yes, I guess, I'm still using BIOS boot, so my knowledge is very limited on EFI! But as a general principle I would be looking at chrooting in, downgrading recent updates by checking /var/log/pacman.log, packages may still be in /var/cache/pacman/pkg, checking /etc/fstab if anything has changed in that respect, looking back through .bash_history if I had changed anything important recently, and trying to successfully re-run mkinitcpio either manually or as part of a kernel installation process. I think it's probably a typo but your earlier grub-mkconfig command is grub-install which is something totally different if you actually did think it was grub-mkconfig.  :D  While probably not related I did recently discover that os-prober will take it's command line from the grub.cfg in other distros, so if update-grub has not been run in them (even though grub is not really being used there) it can point to the wrong place. If there was a problem with vmlinuz-linux it wouldn't boot as that is required, and it seems the efi partition can sometimes be corrupted when dual booting with Windows. Sorry the mkinitcpio did not work though, usually if that can be run then it will allow a reboot.

Re: ERROR: invalid kernel specified: `/boot/vmlinuz-linux'

Reply #33 –
I don't think this is related to EFI boot. Like I said earlier, we have determined the location of the error, but the error itself doesn't make sense.
Quote
# /usr/bin/bash --norc
bash-5.1# source /usr/lib/initcpio/functions
bash-5.1# set -x
bash-5.1# kver /boot/vmlinuz-linux
+ kver /boot/vmlinuz-linux
+ local kver 're=^[[:digit:]]+(\.[[:digit:]]+)+'
++ hexdump -s 526 -n 2 -e '"%0d"' /boot/vmlinuz-linux
+ local offset=14464
+ [[ 14464 = +([0-9]) ]]
+ read kver _
++ dd if=/boot/vmlinuz-linux bs=1 count=127 skip=14976
+ [[ You =~ ^[[:digit:]]+(\.[[:digit:]]+)+ ]]
+ return 1

Instead of "You" (where does that string even come from?!) in the line before the last, there should be a kernel version number. The command in question, which is
Quote
read kver _ < <(dd if=/boot/vmlinuz-linux bs=1 count=127 skip=$(( 14464 + 0x200 )) 2>/dev/null)
reportedly works when called from the interactive shell on the OPs system, but when put in a script it doesn't. The script (/usr/lib/initcpio/functions) has /bin/bash as a shebang, and the user reportedly uses bash as his shell now (was using zsh), so the command should work in theory, provided the OP is telling the truth and not trolling the forum, of course.

Update 2021-08-24: There is a thread about a similar issue at Stackexchange, but there the script's shebang is #!/bin/sh instead of #!/bin/bash which is present in both /usr/lib/initcpio/functions and /usr/bin/mkinitcpio.
 

Re: ERROR: invalid kernel specified: `/boot/vmlinuz-linux'

Reply #34 –
Since there was recently a topic about a similar issue, which was solved, it is highly likely that the solution for this case is also similar.

Namely, the OP should check if there are any custom-made scripts (in /usr/local/bin for example), shell functions or aliases named "dd" and rename or remove them.