After online update mkinitrd did not run so initrd was not created. When I use rescue disk to mount and chroot system mkinitfs returns this error:
find "/lib/modules//kernel/drivers/scsi ": no such file or directory. The kernel version number is not added to the script and so mkinitrd fails. Note the double slash// in the text. Any clue as to what broke the mkinitrd? What provides the version number to the mkinitrd package?
On 09/23/2014 10:34 AM, jbergman wrote:[color=blue]
After online update mkinitrd did not run so initrd was not created. When
I use rescue disk to mount and chroot system mkinitfs returns this
error:
find "/lib/modules//kernel/drivers/scsi ": no such file or directory.
The kernel version number is not added to the script and so mkinitrd
fails. Note the double slash// in the text. Any clue as to what broke[/color]
The double-slash wouldn’t hurt, except that I think you’re saying it’s a
sign of something missing, specifically the kernel version.
Hmmmm… is the kernel installed on the box? It should be, sure,
but perhaps something went amiss there. I would not be surprised (without
looking) If the mkinitrd script used the output of ‘rpm -qi kernel’ or
something like that to find the correct version to use in there.
[color=blue]
the mkinitrd? What provides the version number to the mkinitrd package?[/color]
Have you tried hacking around this by having something like
/lib/modules/kernel be created as a symlink (or hardlink even) to
/lib/modules/YOUR-VERSION-HERE/kernel to see if that fools mkinitrd enough
to keep going until you can boot and then look for a root cause?
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 23/09/2014 17:34, jbergman wrote:
[color=blue]
After online update mkinitrd did not run so initrd was not created. When
I use rescue disk to mount and chroot system mkinitfs returns this
error:
find "/lib/modules//kernel/drivers/scsi ": no such file or directory.
The kernel version number is not added to the script and so mkinitrd
fails. Note the double slash// in the text. Any clue as to what broke
the mkinitrd? What provides the version number to the mkinitrd package?[/color]
What do “uname -r” and “ls -ld /lib/modules/*” produce?
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
[QUOTE=jbergman;23777]After online update mkinitrd did not run so initrd was not created. When I use rescue disk to mount and chroot system mkinitfs returns this error:
find "/lib/modules//kernel/drivers/scsi ": no such file or directory. The kernel version number is not added to the script and so mkinitrd fails. Note the double slash// in the text. Any clue as to what broke the mkinitrd? What provides the version number to the mkinitrd package?[/QUOTE]
Well, it looks like I need to check my box over carefully. In the mkinitrd dirs /setup /boot 5 sym links had been changed to hard links. Even though I had rerun the mkinitrd_setup these links were not refreshed. The answer seems to be to delete these directories and rerun mkinitrd_setup to recreate the links. I would have just reinstalled the whole package after a delete but I am not a big fan of the command line interface. Im not sure what made these changes as I have not changed this os package much over the last few years, thus i have not run the mkinitrd. Thanks for the replies. A more interactive version of mkinitrd or a mkinitrd_setup that really checked its install carefully might be in order as this is a critical install/update package.