IMHO microcode-intel is not the culprit because it is used after the boot and not by grub while here the problem is that gurb can’t show it menu at all.
I answered here but maybe the answer was too short. In anyway the easiest method its to use Preformatted text (or Ctrl+Shift+C) or the button with the </> icon. A more complete guide can be found, for example, here. This is valid for all forums using discourse. If the file you want to show is too much long you may upload it instead.
I don’t think microcode-intel is the most likely culprit myself. But it is known that it does change completely the syntax of initrd entries in grub2 to something that won’t boot secondary OM systems. My thought was to remove that as it is easy to do and eliminate that possibility. And OP probably does have that package because it is what creates the ‘microcode.img’ file. Also I was thinking that while in a OM-chroot if he ran ‘update-grub2’ that would tell us a lot of other things we need to know to fix this. And we’d all be well on our way to resolving this issue.
But you can’t just mount a partition and switch to it and run commands. That doesn’t work. You have to mount the partition, then mount to it, at a minimum, /sys, /dev, and /proc, and maybe also /run. Then you chroot into the mounted system and can run commands.
Edit: And here is where I may have made my first mistake. I said in post # 7 to Google how to do a chroot as this is well explained in many places. That seems to have been missed or something.
For what it’s worth being able to chroot into a system is especially helpful for fixing boot problems. But there is lot’s of things you can fix in a broken Linux system this way.
O.K. Thanks for all your responses. I will work through them and let you know the results as soon as possible. @mandian
Have executed your suggestions (of course!) but without success. I think perhaps I have done this not correctly. Will let you know more in due time.
So long I wish to write a guide on how to make from scratch an emergency usb key to boot a SO whe grub fails but I have never found the time do make it .
As promised:
I first started to look for kernel info in the OMA’s grub.cfg and found it was 4.15.3.
And its / on partition sdc2. So I copied and pasted this into my GRUB-Legacy file:
title OpenMandriva_emergency
kernel (hd2,1)/boot/vmlinuz-4.13.5-desktop-1omv root=/dev/sdc2 ro
initrd (hd2,1)/boot/1234567890/vmlinuz-4.13.5-desktop-1omv/initrd
Then rebooted the system and I got a black screen with this text:
At first I thought that /1234567890/ was to be substituted by the bunch of digits I found in that grub.cfg file so I did that but got the same response.
That bunch of digits (combination of numbers and letters) is actually the name of a directory and should not be changed. And in that directory is now where your initrd files are. That’s one of the changes in boot entries that we’ve been gifted with from upstream.
This is one of my initrd entries in ‘/boot/grub2/grub.cfg’ as an example:
As you can understand from my response I already suspected that those bunch of digits was something else than 1234567890 and I copied the digit string from my grub.cfg and replaced those 12345…etc with it , but I also wrote that the result was the same: black screen with that particular text.
And my particular entry in that .cfg file is:
Looking at that digit string I also had the idea that this could represent the UUID of the / partition of OM but that was not the case.
I do not understand your
“Edit2: Also that is an initrd entry on a system with package ‘microcode-intel’ removed.”
What should I do with it? Remove it as you suggested earlier?
That all looks correct. The Edit2 comment means it is the microcode-intel package that adds ‘/boot/microcode.img’ to the initrd line if the microcode-intel package is removed and then update-grub2 is run that part is removed from initrd line.
No, it will not. Same black screen with same text.
I think the best way is to uninstall OM / and reinstall it with again its bootloader again installed in / .
But I doubt if that problem does not appear gain when I install a next update of OM and I have to do things all over again.
Well sorry that didn’t work. By your suggestion does that mean if you reinstall with it’s bootloader installed to / then it will boot until there is an update?
No, I mean that if I do install OM again, and placing during the installation procedure its bootloader in
“/” instead of what it will do when you do not change the destination, I will simply add in my GRUB-Legacy file:
title OpenMandriva
rootnoverify (hd2,1)
chainloader (hd2,1)+1
And that will hopefully work again. All my other distro’s on that computer (LinuxMint 17.1 MATE and Linux Mint 18.2 KDE are treated that way without having any problems. They both have, as you will now, GRUB2 as bootloader.
Also, when I run their updates I have never faced any problems after those updates concerning booting the system.
But now I am not sure that this will also be the case with OM in future.
This means the file is too big to be loaded. Or this is unreachable. Please try to check if the paths and the names of the file are correct. For example a kernel version like 4.15.3 sound strange, according to the repo it could be 4.13.5 instead. However if you have access to the OMV /boot/grub/grub.cfg_ you may retrieve such informations from there.
You are absolutely correct about the kernel version. I made a typo error here. It should be 4.13.5
and NOT 4.15.3 as I wrote.
But from the strings I copied into GRUB there is the correct version as you can see above.
.
)