I accepted a kernel update on YaST today, and rebooted to see the following message:
kernel /boot/vmlinuz-2.6.25.5-1.1-default
…
Error 15: File not found
What is the path to the new kernel?
The new version here is ‘2.6.25.9-0.2-pae’, so that would be /boot/vmlinuz-2.6.25.9-0.2-pae or just /boot/vmlinuz for the symbolic link.
Is there maybe a second boot item in your menu for the new kernel?
Happened to me also, after update… stopped booting
please check
Error while parsing number (again) - openSUSE Forums
If anyone knows how to solve the problem, please respond.
I am on the verge of putting 10.3 back
Presuming the kernel files are there (in /boot) try running the repair utility on the install DVD to repair the boot process.
If this does not work you might have to run mkinitrd to rebuild your kernel files.
Others here might have better suggestions as I’m no expert here. Try the repair option first on the DVD & let us know how that went.
Fingers crossed,
Wj
Had that error also after updating.
After much googling (thank god for splashtop) i found out that the update hadnt put the correct path in.
Before update the path would be ~ kernel (hd0,4)/vmlinuz-2.6.25.5-1.1-default
but after update it was ~ kernel (hd0)/vmlinuz-2.6.25.9.0-2.default
had to edit it at grub loader and put the 4 into (hd0,4) then it booted fine.
im a complete linux/suse noob and think i might of fluked something by getting it to work.
Hi WiTcHkInG, 
Thanks for posting that as I am sure it will help others & good for you for getting that sorted!
The thing that sticks out is that it seems to be happening for those having the ‘default’ version of the kernel and those using the ‘pae’ version are not running into this. To explain the versions : the kernel version installed is determined by the processor you are using, you seem to be running on older hardware (AMD XP/Pentium IV or older)? Correct?
Cheers,
Wj
Well i hope its not considered older hardware by now.
Intel xeon X3350 on an Asus P5Q Deluxe 
You know how it is in the IT… new kid on the block is old and forgotten by the time he enters the door.
Wonder why you have the default kernel and not pae?
Might do some digging, need to get myself out the door now.
Way to go opensuse QA team, way to go… a pushed update that botches so many systems…
in my system the kernel “update” from 2.6.25.5 to .9 not only failed but also managed to delete all entries from the grub menu.lst file, and more importantly also delete ALL initrd / vmlinuz files, rendering a completely unbootable kernel-less system.
the repair option also did nothing:
- the boot loader is in perfect order displaying an empty screen
- the repair base (or all) packages also did nothing. now, we wouldn’t call a kernel a “base” package, would we? Maybe it didn’t find any kernel package and decided there’s nothing to repair…
so now it’s up to mkinitrd and some kernel from my other suse systems (which i chose not to “update” after this wonderful event) to make the system usable again…
someone from the openSUSE team should rise up and post something about this…
Didn’t have any problems here. Not saying that there is no problem but that it didn’t fail everywhere.
yeah ok, i’m sure it doesn’t fail on all systems otherwise it couldn’t possibly have gone out the door on the official update channel…!
well, the rescue system from the dvd is useless since its mkinitrd is broken. It’s a wrapper script in perl which does not work.
A knoppix live cd i used has its own version of mkinitrd (the debian version), which is completely different, different parameters / configuration and also does not work.
I’m left perplexed:
- either i have to download a real opensuse live cd and hope it has a proper mkinitrd
- or copy an initrd image from another system which loads the same modules (would this work?)
- or do a re-install…???
btw. the initial install on my laptop had failed to create a bootloader in the first place. suse 11 fixed speed on package management and must have broken stuff which were more important
nikolaki wrote:
>
> yeah ok, i’m sure it doesn’t fail on all systems otherwise it couldn’t
> possibly have gone out the door on the official update channel…!
>
> well, the rescue system from the dvd is useless since its mkinitrd is
> broken. It’s a wrapper script in perl which does not work.
>
> A knoppix live cd i used has its own version of mkinitrd (the debian
> version), which is completely different, different parameters /
> configuration and also does not work.
>
> I’m left perplexed:
> - either i have to download a real opensuse live cd and hope it has a
> proper mkinitrd
> - or copy an initrd image from another system which loads the same
> modules (would this work?)
> - or do a re-install…???
>
>
> btw. the initial install on my laptop had failed to create a bootloader
> in the first place. suse 11 fixed speed on package management and must
> have broken stuff which were more important
>
>
You can use a SuSE 10.3 cd/dvd to boot from for a working rescue system too.
Boot the rescue system, mount your /root somewhere
mount /dev/sda2 /mnt/mine
chroot /mnt/mine bash
mkinitrd
exit
umount /dev/sda2
reboot
You may get some errors concerning /dev/zero or /dev/null. Ignore them.
I’ve done this in the past (not this week!) to recover a system which failed
as this last kernel update has caused.
A good CD to download for emergency work is ‘INSERT’, it’s about 55-60 megs,
boots in a moment, and can get you into almost anything… it works in this
instance too.
INSERT homepage: http://www.inside-security.de/INSERT_en.html
Take Care,
Loni
L R Nix
lornix@lornix.com
I had no problems with the update.
One thing I ALWAYS do with a kernel update, is prior to the update, make a backup copy (soon to be obsolete) of my /boot/grub/menu.lst file.
Then I do the kernel update.
Then before rebooting, compare the new updated /boot/grub/menu.lst file to the backup file, comparing the two. If a mistake was made to the grub boot, it will often happen in the menu.lst, and by comparing one can more easily spot the mistake. One can then fix the file, before rebooting.
Hi,
I ran into problems with the kernel update in Opensuse 11 as well. I’ve rolled back to 2.6.25.5-1.1-default and all is working OK.
I run an AMD Athlon™ 64 Processor 3200+ with the 32bit Opensuse.
Opensuse installed OK but after the first kernel patch was installed I wasn’t able to boot from the default kernel, I needed to use the pae kernel.
When I applied the latest kernel update (2.6.25.9) I was unable to boot from the default kernel and the pae kernel.
I don’t have the exact error message, but it was something like
*boot/01 devfunctions.sh 68
multipath command not found.
*
My assumption was that this was occurring in the initrd but I am not sure.
My plan now is to manually install the latest update kernel to try and replicate the problem.
Cheers, Barrie
One can install a dual boot to different kernels. In the SF archives, snakedrive has a good how to on this.
In essence one downloads the new kernel rpm to one’s hard drive, and then installs it with:
rpm -ivh kernel-<version number>.rpm
Then go into /boot/grub/menu.lst and check to ensure it allows a boot to both the old and new kernel. Note the “rpm -ivh” in this case is necessary as it keeps the old kernel, while a “rpm -Uvh” would remove the old kernel.
FWIW no problems here
Linux **** 2.6.25.9-0.2-default #1 SMP 2008-06-28 00:00:07 +0200 x86_64 x86_64 x86_64 GNU/Linux
I’m surprised the kernel was released in that state. I installed the 2.6.25.9 a week or so ago after having the 2.6.26 kernel of the day break bootsplash and console login. I got the (hd0,4) grub entry, but assumed grub was the culprit. I set the correct location, reinstalled grub and haven’t seen that error since, even though I’ve removed and installed the kernel a couple of times.
Way back when I was using smart on opensuse (10.1-10.2 days iirc), I recall smart used to do this automatically. After updating the kernel, the previous version was saved and added to menu.lst as Previous Kernel or something. There was always two kernel versions available. Dunno if smart still does this, but the opensuse team may want to implement something similar.
Since this update the os selection screen is a black screen with text. How can i get the green Suse background gui back?
I have tried using a manual install of the latest update kernel
kernel-default-2.6.25.9-0.2 but I ran into the same problem. I am still able to boot from kernel-default-2.6.25.5-1.1.
These are the relevant entries from /boot/grub/menu.lst
This doesn’t work
title openSUSE 11.0 - 2.6.25.9-0.2 (default)
root (hd0,1)
kernel /boot/vmlinuz-2.6.25.9-0.2-default root=/dev/disk/by-id/scsi-SATA_ST3250820AS_5QE0ET1A-part2 resume=/dev/data/swap splash=silent showopts vga=0x317
initrd /boot/initrd-2.6.25.9-0.2-default
This one does work.
title openSUSE 11.0 - 2.6.25.5-1.1 (default)
root (hd0,1)
kernel /boot/vmlinuz-2.6.25.5-1.1-default root=/dev/disk/by-id/scsi-SATA_ST3250820AS_5QE0ET1A-part2 resume=/dev/data/swap splash=silent showopts vga=0x317
initrd /boot/initrd-2.6.25.5-1.1-default
I have a screenshot of the boot screen when the errors occur but I can’t find a way to attach an image here.
Here is what it shows
Trying manual resume from /dev/data/swap
Invoking in kernel resume from /dev/data/swap
PM: Starting manual resume from disk
Waiting for device /dev/disk/by-id/scsi-SATA_ST3250820AS_5QE0ET1A-part2 to appear multipath: command not found
!boot/01-devfunction.sh: line 68: multipath: command not found
!boot/01-devfunction.sh: line 68: multipath: command not found
!boot/01-devfunction.sh: line 68: multipath: command not found
.
.
.
!boot/01-devfunction.sh: line 68: multipath: command not found
Could not find /dev/disk/by-id/scsi-SATA_ST3250820AS_5QE0ET1A-part2.
Want me to fall back to dev/disk/by-id/scsi-SATA_ST3250820AS_5QE0ET1A-part2? (Y/n)
If I answer Y, the process repeats. If I answer n it drops to a prompt.
Any help appreciated.
Cheers, Barrie
Hi
had exactly the same problem with the “mulitpath” error… tried the mkinitr as suggested in a previous post, but got perl errors, but then I found some info in the man page for mkinitrd that did the trick for me:
mount your file system under say /mnt, including all partitions in case you have any, then do
- mount --bind /dev /mnt/dev
- chroot /mnt
- mount /proc
- mount /sys
- mkinitrd
and mkinitrd returned without error and my system was booting again…
HTH
Arun