Felix Miata <mrma...@earthlink.net> writes:
> Save yourself many keystrokes by using the symlinks in the root directory
> instead
> of the long-winded full version-named /boot/vmlinuz-4.19.0-5-686-pae....
This is wonderful to know and in the root or / directory of this
disk, there is
initrd.img, initrd.img.old, vmlinuz and vmlinuz.old
Those all point to valid targets. I presently have the
no-boot disk mounted on a working linux system where it's root
directory is /dev/sde1 and the current links plus the old links
are as follows:
lrwxrwxrwx 1 root root 32 Jun 26 2019 initrd.img ->
boot/initrd.img-4.19.0-5-686-pae
lrwxrwxrwx 1 root root 31 Jun 26 2019 initrd.img.old ->
boot/initrd.img-4.9.0-9-686-pae
lrwxrwxrwx 1 root root 29 Jun 26 2019 vmlinuz ->
boot/vmlinuz-4.19.0-5-686-pae
lrwxrwxrwx 1 root root 28 Jun 26 2019 vmlinuz.old ->
boot/vmlinuz-4.9.0-9-686-pae
I finally have found something that may be a clue to
what's actually wrong. While trying to manually make that drive
boot, I got this:
grub rescue> set prefix=(hd0,1)//boot/grub
grub rescue> insmodnormal
Unknown command `insmodnormal'.
That was a good old syntax error so I tried
insmod normal with a space
grub rescue> insmod normal
error: symbol `grub_calloc' not found.
I'm pretty sure that shouldn't happen at all and is
what's behind the failure to boot.
I haven't found any uuid's that are different although I
first thought I had as I looked at some links which had uuid's
but they were good when I looked at the actual partition. It's
easy to go down a rabbit hole if one doesn't watch out.
I think there may be something about grub that got left
out or changed during the upgrade.
Martin
Martin
