One of the primary reasons for developing grub2 was to improve the ability of boot loader to handle multi-boot situations. And it does.
Edit: Also Grub Legacy is no longer being developed, hasn’t been in development for quite a while now.
1 Like
I don’t understand how that initrd entry can work when AnalogueMan says his initrd is this:
initrd /boot/microcode.img /boot/222b02b90808463aaeca88f2a669496b/4.13.5-desktop-1omv/initrd
trying to bypass ‘/boot/microcode.img’ when it is in fact there doesn’t seem likely to work.
I’m not sure grub legacy can handle two argument at initrd statement.
1 Like
I suspect it can’t. Which led someone earlier to suggest removing ‘microcode-intel’ and running ‘update-grub2’ so there wouldn’t be a two argument initrd. It may have to be done to continue using grub legacy.
FWIW: This issue with microcode and the new directories in boot in not an OpenMandriva creation it is from upstream and will get to other Linux distros soon enough. It already was reported in Arch and Manjaro when we started dealing with it. And as you can see from this issue report it is a problem in Grub2 as well.
Edit: And apologies for hijacking the thread, didn’t mean to…
So I.
I tried to remove /boot/microcode.img from initrd in my box without
un-installing microcode-intel package all my system booted fine. I don’t fully understand what is the role /boot/microcode.img plays but it seems to me it is not mandatory even when microcode-intel packages is installed. Of course I can’t test it with grub legacy.
Your contributions are always sincerely appreciated here 
.
1 Like
Then I was wrong on that point to an extent but AnalogueMan would have to also remove the ‘/boot/microcode.img’ from his entry in his OM ‘/boot/grub2/grub.cfg’ for such an entry to boot? Or so I think.
I’m not sure I’m clear on that either. I’m sure it isn’t mandatory as I’m maintaining 4 OM Lx 3 systems with ‘microcode-intel’ package removed as we speak (with no ill effects noticed). My partial understanding is that if you have an Intel CPU it will use microcode information from BIOS firmware rather than that package. My partial understanding also is that this information is used to more or less equalize load between different cores of the CPU.
1 Like
As I understand the problem is grub2 can’t read /boot/grub2/grub.cfg at all or this contains an invalid syntax so grub2 refuses to show the menu. If so the presence of /boot/microcode.img is of secondary importance at this stage because it eventually may break the system boot and not grub2.
Well, reading all those suggestions after my last response:
@mandian
I already did both
root (hd2,1)
and
rootnoverify (hd2,1)
Both with the same result : it came with black screen and the error14.
And I always use ext4 as filesystem for all my distro installs which is handled nicely by GRUB-legacy.
If I run the live DVD of OM and then try to repair GRUB2 by reinstalling it what is the exact command string?
This?:
grub-install /dev/sdc2
Or:
grub2-install /dev/sdc2
@ben79
Perhaps GRUB-Legacy is no longer developed, but all my PCLinuxOS distro’s have GRUB-Legacy and it is the only Grub which I have gained a little understanding of its content. I am running linux for only two years since I abandoned Windows so I am still in the learning process.
I tried to follow your “this issue report” (the link in your last reply) but it is far beyond my knowledge.
I am very very reluctant to do further experiments because of the fear getting things messed up and in the end facing a broken system. Hope you can understand that.
But one thing I do not understand:
I am chainloading OM so I suppose it is using its own GRUB2 to boot and GRUB does not have anything to do for booting things correctly. Or do I completely misunderstand things here?
That is how I think chainloading is supposed to work. So it doesn’t make sense, yet, why your OM won’t boot. One thing I do know is that the problem happened at the same time as big changes (due to microcode-intel package) in how initrd is handled in OM (and Linux in general). Maybe the 2 are related but maybe they aren’t. Again I don’t know.
We are all still in the learning phase in Linux. But I understand what you are saying.
You could try for support on this issue at PCLinuxOS either in their forum or in a bug report. We will also keep trying to help here.
The command is grub2-install, however you have to specify to grub where to install configuration files or these will be installed into /boot/grub. So let’s say you mounted OMV root partition into /mnt you may use the option --boot-directory=/mnt/boot. Here is an example of the commands you may use:
mount /dev/sdc2 /mnt
grub2-install --boot-directory=/mnt/boot /dev/sdc2
umount /mnt
Found an old file from when I used grub legacy and chainloading. I used a simpler entry, might be worth a try? (It was a long time ago before there was Grub2).
title OM Lx 3 experimental entry
root (hd2,1)
chainloader +1After having modified GRUB this way I again rebooted into grub. 
Because I was worried about the consequences I first did an experiment using my Oracle-Vbox.
Installed a multi distro setup there with PCLinuxOS as first distro and then installing OM next to it with the OM bootloader in its / . Did not install the OM distro updates but first booted into PCLinuxOS and modified its GRUB for chainloading OM. Rebooted and choose OM to boot facing no problems.
Then I did that large OM distro update (which took by the way a long time) and after those updates were finished I rebooted and guess what… It is now impossible to boot into PCLinuxOS and I can only boot into OM. Tried to install GRUB using your lines above (changing the sdx into the the partition where PCLOS was installed and after reboot Oracle-Vbox booted right into “rescue grub”.
So I will not execute those lines in my real setup.
The .iso which I used was
OpenMandrivaLx.3.02-PLASMA.x86_64.iso
The same I used for installing this on my computer before running into problems.
I think I will leave it by this and will no longer occupying your and ben79 's time. Sorry.
Anyway thanks for all your help sofar.
Update: I managed to get things running again in OracleVbox by doing a MBR repair using the PCLinuxOS live .iso and from there repairing the MBR.
After that everything went OK. (Removed OM).
You did all that but did you ever try it with the package ‘microcode-intel’ removed. Remember after removing that package you have to also run ‘update-grub2’.
# urpme microcode-intel
# update-grub2
Edit: You do the above in you OpenMandriva partition.
I remember to try to remove microcode-intel in one of my earlier replies:
"Did the following: booted from another distro, mounted the OM-root and after activated Konsole there, I executed “rpm -qa microcode-intel” (after having installed rpm). It responded with just the cursor."
I had to write more accurately: It responded with just the cursor coming back.
But I will start all over again in my Oracle-Vbox and after getting again at the point where in only boots into OM, will execute those two lines. See what happens then.
Um… I’m confused ‘rpm -qa microcode-intel’ is not a command to remove anything it is only a command to question if you have the package. rpm is a package manager and the options -qa mean simply ‘query’ ‘all’. To remove a package you would run ‘rpm -e [package_name]’ or ’ urpme [package_name]’. That’s without the brackets [ ]. FWIW: The ‘e’ is stands for ‘erase’.
And again it responds with just the cursor because you only mounted a parition and ran a command. That does not work. Will not work. Can not work. At great risk I’m going to post a sequence of commands for how to chroot into a system so someone can run some commands.
# mount -t ext4 /dev/sdxx /mnt
# mount -o bind /sys /mnt/sys
# mount -o bind /run /mnt/run
# mount -o bind /dev /mnt/dev
# mount -o bind /proc /mnt/proc
# chroot /mnt
Where ‘ext4’ is your file system type change if you aren’t using ext4 file system to what you are using. ‘/dev/sdxx’ represents you partition location do not copy and paste this exactly it won’t work. You change ‘/dev/sdxx’ to what your OM / partition is. If you didn’t do all of the above then issuing commands like I posted will return an empty dialog. Before doing this read and understand all of this.
So any and all commands you ran earlier while simply mounting a partition are irrelevant. They don’t belong in the discussion.
Edit: I was hoping you would find all this when I suggested to google how to chroot in to a system. That was in retrospect a mistake on my part and I wish I had handled it differently.
OK. ben79, you must give me some time to “digest” all this information.
I will come back on it as soon as I can.
A.
Sure, that is fine and understandable. I hope I’m being educational, that is the intent anyway.
Also it is perfectly reasonable for you to decide to discontinue using OM in view of all the problems you’ve been having. Or discontinue for a period of time and try again in the future. That’s up to you.
Recent posts have been in the spirit of hoping to train and educate a Linux user or users regardless of choice of distribution. I am being trained and educated by some other folks myself at the same time. We never stop learning.
It still keep me puzzled what that last big update does with the GRUB/GRUB2.
Does it modify in some way the MBR? I cannot understand what possibly could be the cause.
That depends if you have not changed anything then it might. If you have already installed boot loader to / partition then it should not have. As far as what happened. There was an updated grub2, dracut, kernel, maybe more, and the addition of the microcode-intel package. So a lot changed.
The one thing that changed that probably is causing your booting problem is very likely microcode-intel. microcode-intel brings about fundamental changes in how things are handled. All the other changes are fairly standard and unlikely (not impossible) to have caused this issue. And as I keep saying it is known that this package and the changes it brings are causing some issues elsewhere as well. Boot issues.
The microcode-intel package is a game changer. And your problems seem to coincide with when it is installed. All of you now think about this. You install OM and it works you update and it doesn’t. This happens every time doesn’t it?
Meanwhile some old fart going by ben79 keeps saying look at microcode-intel. That is the big fundamental change that is happening. The package microcode-intel is a big change. All of the other stuff is ordinary package updates. There is one thing that changes how the boot process works. microcode-intel package.