[SOLVED] Mageia does not boot after adding a new system to..

[linuxero]

Hi Mageans;

I am using Mageia 2 64-bit KDE on an AMD machine with 8 GB RAM. I have Windows, Fedora, Debian as well as Mageia installed all booting through Mageia's GRUB. Grub is installed on the first hard-disk, which is IDE. The systems are installed all on the third SATA hard disk. I have two other disks for keeping data.

I should mention that I have one of the two data-store disks has 3 partitions; one with Mageia, also, for other uses , another empty one and the data partition.

I built a distro following LFS - Linux From Scratch - on the empty partition. and everything went great.

So till last night I could boot my main Mageia system, the special use Mageia - ALPHA and development releases -, Windows, Debian and Fedora with Mageia's GRUB as I mentioned before.

Last night I opened Mageia's MCC, added my newly-created LFS distro to the boot-loader and closed MCC. When shutting down KDE, I chose reboot LFS from the KDM drop-down menu.

Now the computer does not boot and GRUB gives me fatal error 22. I tried to recover GRUB using the installation DVD and choosing rescue, but there I have an error on some line telling me that the rescue system cannot find the boot-loader..! Trying once again the same error and telling me that it cannot mount the partitions, mentioning that the system is squashfs - I think it was trying to mount the Rescue System here- !!

Anyway; now I am stuck with this problem so I installed Zorin on the Mageia testing partition so that I write you.

I can mount all the partitions in Zorin. I could even boot my LFS distro as it was added to Zorins boot loader, I can boot all the other os'es..the only problem I have is when trying to boot Mageia through Zorin where I am sent to initram console!!

I even tried to double Mageia using the installation DVD to update so that I get it to reinstall GRUB..Well I does, but the same fatal error 22 appears upon booting again!!

My questions to learn;
- How does KDM tell GRUB to boot a specific OS upon rebooting or after a shut-down?
- My guess is that Mageia's GRUB went bad, is it a bug?
- Should I copy my Data through Zorin or even reinstall Mageia as I have the Home partition apart?

Thank you as always guys.

[oj]

My questions to learn;
- How does KDM tell GRUB to boot a specific OS upon rebooting or after a shut-down?

I think you may be referring to the option on the shutdown context menu. When you select reboot, if you hover the mouse over the confirmation that pops up you get a menu where you can select which OS to reboot to. (or is that a right click?? Try both)

- My guess is that Mageia's GRUB went bad, is it a bug?

Probably not a bug. Grub 1 and grub 2 are not (easily) compatible. Make sure you're using one or the other throughout.

- Should I copy my Data through Zorin or even reinstall Mageia as I have the Home partition apart?

Always back up your data, so yes. And yes to reinstalling Mageia, at least that's what I would do. I'd make sure all the other systems can boot, then install Mageia and add it's image to the menu.lst of whatever distribution installed the grub that is working. (working prior to installing Mageia) You might select to install Mageia's boot loader to the root of the Mageia install and chain load it from the working grub that whichever of your other distributions installed in the first MBR.

I'm curious: does your hardware check IDE first on boot? The machines I have that have both SATA and PATA all look to SATA drives first. If any of them have a boot loader, that's what will be used. The only way I can get these systems to boot to IDE is to make sure there is no instance of grub (or lilo) on any of the SATA disks. Your hardware may be different, but SATA vs PATA on boot is definitely something worth considering when trying to iron out a problem like this.

[linuxero]

Thank you oj;

I guess I have not been clear on my first question! Sorry..

I meant how does KDM instruct GRUB to boot a specific OS under the hood..? Sorry I was not clear..

As to your suggestion about jealousy between Grubs, 1 AND 2, I think compatibility is not the issue here because I am trying to boot my LFS through Mageia..I actually always boot through Mageia..

Now I am writing from Mageia I actually tried several possibilities with Zorin's GRUB until I was able to boot into my Mageia, but here again, I go to MCC, try to install Mageia's boot loader and it messes up everything So, for the time being I am sticking to Zorin's GRUB to boot into all my OSes..

As for your question about PATA/SATA together, I made sure that my first boot device is the IDE hard disk, and Mageia never had a problem with that..it's just this week whenever I try to install Mageia's boot-loader it loses its bearings..

I backed up all my data just in case but still I'll try to help Mageia install its boot-loader correctly..

Thank you

[filip]

As for your question about PATA/SATA together, ...

I also have such a PC with one HD IDE and (two and now one) SATA.

I learned that Grub can only boot himself from first disk that BIOS see (hd0). There is of course big influence on that of boot order setting in BIOS. Possibly also some others settings there. I also experience something very strange last week. After removal of one SATA HD Grub just gived read error no matter of setup method or setting. Long research revealed that removed HD also took it's hd0 number with it. That should not happen and is plain BIOS bug. Unfortunately not the only one on that PC (only cold boot boots USB properly, dual keypresses out of OS). I found out about that when I booted Super Grub disk from Parted Magic and used "find /boot/grub/stage1" and also "find /grub/stage1" as I have separate boot partitions as well. There were hd1 and hd2 but no hd0. So I solved that with boot order setting for now.

I would also check device.map file. It should reflect state which Grub itself see at startup not in Grub shell in operating system as they can see HD numbering differently (BIOS vs. kernel).

[linuxero]

Thank you filip;

This is probably the first time I have this problem with Mageia. Usually, as I noticed, Mageia tries to detect BIOS disk order and acts accordingly. Well, the device.map does not really reflect the order of the disks in my BIOS and that could be part of the problem..but it looks like the old version, ie. device.map.old, because I like to keep some conf files for reference

My wonder is why it just happened now..I mean I added Fedora before, then Debian, then another Mageia, it has been quite smooth then..now, however, it came up with this problem..

BTW; I tried to change the order of the disks in the BIOS but couldn't resolve the problem for Mageia..

I'll try to figure it out..in the meanwhile using Zorin's grub to boot

[filip]

Usually, as I noticed, Mageia tries to detect BIOS disk order and acts accordingly.

Let me try to explain. On boot BIOS boots MBR of HD according to BIOS setup. There is already Stage 1 of Grub if you install it there. Stage 1 then boots Stage 1,5 (or Stage 2) from address hardcoded in Stage 1 (encoded during boot loader setup) as it can't read any file system. Last step is to show boot menu from its menu.lst file. On your system it seems that Stage 1 can't find your device so it's possible that device.map file could be connected with your error. You can safely replace device.map file from another working Grub legacy copy on that PC. Then you can reinstall Grub from this working Grub legacy. Just press Esc and Enter in boot menu to go to text mode. Then you press C for command line.
Then just use the following commands:

This one will list all grub installs. Remember to use find /grub/stage1 if you have separate boot partition. If results are many you can find right one if you search for unique files.

Code: Select all

grub> find /boot/grub/stage1


Put the correct x and y returned from previous find.

Code: Select all

grub> root(hdx,y)


Finally install it to MBR like

Code: Select all

grub> setup(hdx)


or to partition boot sector:

Code: Select all

grub> setup(hdx,y)


My wonder is why it just happened now..I mean I added Fedora before, then Debian, then another Mageia, it has been quite smooth then..now, however, it came up with this problem..

Grub is reinstalled at any change in boot loader setup. So if there is any difference from HD numbering (BIOS vs. kernel) Mageia or any other distribution has to take care of it. You can edit that manually by following upper procedure.

BTW; I tried to change the order of the disks in the BIOS but couldn't resolve the problem for Mageia..

Did you reinstall Grub on every such change? It seems that your Stage 1 has wrong address hardcoded.

[linuxero]

Thanks for the follow-up filip;

Actually I cannot get to GRUB's prompt because it does not even show the menu. The first thing that pops up after BIOS has loaded the MBR is fatal error 22! Not even a chance to get to the propmt you mentioned. I tried it with ESC and TAB but no luck.

Now with this error the thing you mentioned about the hard-coded address makes sense..I mean I am only stuck with stage 1 as far as I can see. No menu that loads a mistaken partition at all..just fatal error 22 everytime.

As for your last question whether I reinstalled GRUB every time I tried to change the hard-disks boot order; the answer is yes.. I actually try to install Mageia's GRUB then try to feddle with the boot order and hard-disk partitions, but then I go back and install Zorin's Grub as I can reach no where with Mageia's.

About the find stage1 that you mentioned, I guess the system should only find Mageia's. Fedora and the rest are already using GRUB2..Does GRUB2 use stages as well?

Since I am in Mageia now, I'll try to get to Grub's promt from the console and do it manually. I'll forget about MCC for the moment just to see if I can get over it

Thanks again

[filip]

You're welcome linuxero.

Actually I cannot get to GRUB's prompt because it does not even show the menu. The first thing that pops up after BIOS has loaded the MBR is fatal error 22! Not even a chance to get to the propmt you mentioned. I tried it with ESC and TAB but no luck.

Forgot to add that you can boot from live CD or USB to do that.

About the find stage1 that you mentioned, I guess the system should only find Mageia's.

Find searches for filename only. It doesn't distinct content or owner. But you can "cat" files to distinguish them manually.

Does GRUB2 use stages as well?

Yes. IIRC they eliminated 1.5.

Since I am in Mageia now, I'll try to get to Grub's promt from the console and do it manually. I'll forget about MCC for the moment just to see if I can get over it

Just be careful on HD numbering (BIOS vs. kernel) in "device.map" file as I already explained before. Documentation in Grub also explicitly warns about that.

Good luck on your rescue and learning mission .

[linuxero]

Hi again;

Well I kept changing the order in the BIOS until I was presented with GRUB's shell, there I booted Mageia again using the commands you mentioned.

I tried to set up GRUB as you said but I didn'y get anywhere

Finally I had to change the order of the disks in the BIOS setting the one with Mageia as the fourth one, GRUB is always finding stage1 on (hd3,6), and then changed /boot/grub/menu.lst to suit my configuration..

But this is for me a pain in the neck as I won't be able to count on MCC's boot-loader set-up! Each time I have to install an alpha or anything esle I'll have to do it manuall..otherwise I'll set a permenant entry and chainload it never changing its title no matter what new distro I am trying in there

Thanks again filip

[filip]

I'm sorry you didn't succeeded. I don't have clear picture of which boot loader would you like to be "master". But in any case you could setup a separate boot partition on HD which BIOS see first. Then you just use chainload to boot all your current and future operating systems.

[gohlip]

Firstly, it had to be said that the mapping of disks is done by BIOS. OS's (and bootloaders) has no involvement in this; and numbering of multiple disks (hdx) are sometimes changed with different instances of booting, hence booting failures can occur. Grub2 circumvents this by using UUID instead of /dev/hda or (hdx,y) but unfortunately grub-legacy has to boot using device mapping set by the BIOS, resulting in your problem.
Setting up a separate 'master' boot partition will still not overcome this problem if grub-legacy is used. UEFI will not have ths problem but (unmodified) grub-legacy will not work on UEFI.

That said, it is not good practice to mix SATA and IDE disks.
Furthermore (even if disks are not mixed), the master drive has to be set properly, SATA by ensuring the main cable to it and IDE by setting jumper wires in each drive to 'master' or 'slave'.

Using grub-legacy on multiple disks is often a 'hit or miss' affair, sorry.

[gohlip]

Furthermore (even if disks are not mixed), the master drive has to be set properly, SATA by ensuring the main cable to it and IDE by setting jumper wires in each drive to 'master' or 'slave'.

Need to add......this makes 'hitting' the master (sda) more likely but as for 'slaves' sdb, sdc.......still a roll of the dice.

[filip]

Once "master" grub is workable and all operating systems use chainloading that particular PC should be bootable to at least "master" grub. Well as long as BIOS is not upgraded or changed and no hardware changes on IDE and SATA appear. Assuming also bug free BIOS which is quite unrealistic. Still in current situation (mix of SATA and IDE disks) is the best way to go for home user IMHO.

OS is involved in the mapping of disks but not directly. On kernel upgrade grub is installed again including change of device.map file. Which can and it does break booting. But technically you're right: BIOS does the mapping of disks.

[gohlip]

Once "master" grub is workable and all operating systems use chainloading that particular PC should be bootable to at least "master" grub.

only if the chainloaded to OS doe not reside in sdb,c,e......and there is more than 2 hard drives.

OS is involved in the mapping of disks but not directly. On kernel upgrade grub is installed again including change of device.map file.

At that particular point and device.map whose mapping is given by BIOS.
The next reboot may be different altogether.

But hey, no worries, we're going into grub2 in some later version, right?
Have to, otherwise newer computers with UEFI will not be able to install Mageia.
Cheers.

[filip]

You're right.

But hey, no worries, we're going into grub2 in some later version, right?

Yeah, that will be fun. Unfortunately many issues from grub-legacy will remain as BIOS is still the same on many machines.

AFAIK there are still some work to do in grub2 and usr move parts for mga3. I hope it will be more stable than mga2 on my PC. I have some issues I can live with but they are sometimes nasty. Surprisingly mga1 was really stable here. Since alpha 1 when I switched from mga and never looked back.

[linuxero]

Thanks for the ideas you are sharing. I am always using my Mageia GRUB to boot anything, any other bootloader is installed on the root partition of the corresponding installation.

I guess we'll just have to wait for GRUB2 to come