Mageia forum

Hi,

Yesterday I upgraded Mageia 2 to Mageia 3 in my PC using mgaonline (something that I already did in my laptop without any problem). The process was very smooth, after first reboot all packages installed OK, but when I rebooted after finishing, the system does not boot anymore.
Grub loads, but then I get the following message:

RAMDISK: EOF while reading compressed data
uncompression error
Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)
CPU:0 PID: 1 Comm: swapper/0 Not tainted 3.10.24-desktop-2.mga3
...(more lines)....

This happens when in Grub I select either Mageia 3 kernel (3.10.24-2.mga3) or the older from Mageia 2 (3.4.69-1.mga2).

I must say that Mageia boots from sbd (selected in the bios menu).

Is there anything I can do to rescue the system?

Thanks a lot,
Pablo

Zamu wrote:Is there anything I can do to rescue the system?

Can you boot via some livecd, and check the Mageia filesystems whether your files are still there?

Thanks for your answer, doktor5000.
Yes, the Mageia filesystems are there. I guess I need to edit grub files and save, but I don't know how to do it from a livecd or rescue system...

You can do that via grub prompt interactively and pretty easy.
In grube menu, press Esc to continue to text mode, and press c
to get a command line.

Then search for grub installations, simply search for the path to a file that is contained in grub installation. E.g. find /boot/grub/menu.lst would also work for grub1 systems.

Code: Select all

grub> find /boot/grub/stage1
find /boot/grub/stage1
 (hd0,4)
 (hd0,7)

Then change to that root:

Code: Select all

grub> root (hd0,4)
root (hd0,4)
 Filesystem type is ext2fs, partition type 0x83

Then specify the kernel you want to boot and additional options, press the TAB key to see possible kernel choices and select one and press enter (can't show this from terminal, but it will show you the filenames inside the /boot folder of that partition)

Code: Select all

grub> kernel (hd0,4)/boot/

Then enter boot. Quite a long time since I've used this the last time, maybe you also need to select the initrd after the kernel.

Grub can also be reinstalled that way, but then you use the setup command instead of selecting a kernel and booting it:
http://www.gnu.org/software/grub/manual ... ively.html

But I guess that grub-editing will work only if I run it from inside my system, which I can't do since it does not boot.

I have been checking the grub configuration files, and I think I know what the problem is:
device.map

Code: Select all

(hd0) /dev/sdb
(hd1) /dev/sda

menu.lst (first instance only)

Code: Select all

title linux
kernel (hd0,0)/vmlinuz BOOT_IMAGE=linux root=UUID=01da458c-7bea-41af-b30c-ab8db9561414 splash quiet nokmsboot resume=UUID=6c648442-4ebf-4acc-8d58-435f423b3a33 vga=794
root (hd0,0)
initrd /initrd.img

I must explain that my system has a dedicated /boot partition (sdb1) separated from / (sdb6). Then, the root UUID in the above instance should be /boot UUID, but instead is /. Am I right?

Zamu wrote:I must explain that my system has a dedicated /boot partition (sdb1) separated from / (sdb6). Then, the root UUID in the above instance should be /boot UUID, but instead is /. Am I right?

As far as grub is concerned your /boot partition is /
It's only after the system boots that it's mounted as /boot.

Zamu wrote:But I guess that grub-editing will work only if I run it from inside my system, which I can't do since it does not boot.

Nope, as long as grub still loads it will work,

Zamu wrote:I have been checking the grub configuration files, and I think I know what the problem is:
device.map

Code: Select all

(hd0) /dev/sdb
(hd1) /dev/sda

menu.lst (first instance only)

Code: Select all

title linux
kernel (hd0,0)/vmlinuz BOOT_IMAGE=linux root=UUID=01da458c-7bea-41af-b30c-ab8db9561414 splash quiet nokmsboot resume=UUID=6c648442-4ebf-4acc-8d58-435f423b3a33 vga=794
root (hd0,0)
initrd /initrd.img

I must explain that my system has a dedicated /boot partition (sdb1) separated from / (sdb6). Then, the root UUID in the above instance should be /boot UUID, but instead is /. Am I right?

If sdb1 is where your boot partition is, the grub part looks correct.
But if the UUID of the root filesystem on sdb6 is not 01da458c-7bea-41af-b30c-ab8db9561414 then you have to change the UUID to match your sdb6.
UUID can be seen from installed system with

Code: Select all

blkid

or

Code: Select all

lsblk -f

as root

First, 3 points.
o root line must indicate the partition for /boot, not the partition for /.
o kernel line must indicate the partition for / not /boot; assuming that the kernel (vmlinuz) is in /, not in /boot.
o initrd line must assume that the initial ramdisk (initrd) is in /, not in /boot.

But you said...

I must explain that my system has a dedicated /boot partition (sdb1) separated from / (sdb6). Then, the root UUID in the above instance should be /boot UUID, but instead is /. Am I right?

A dedicated boot implies you use this to boot every OS in your computer (so I understand you do not wish to follow docktor5000's instructions setting up Mageia's boot as 'root') and which will work.
I am not sure if (talking only of Mageia, and not other OS or any dedicated boot partition) you have a separate /boot Mageia partition. If you do, then follow the above 3 points (taking care the sdax/(hd0,x-1) naming).
If you dont', and have only 1 partition for Mageia or that /boot is in /, than everything (UUID, sdax,(hd0,x-1)) must refer to that Mageia partition.

However, and I think this is the case, assuming the 3 points are handled and/or you have only 1 partition for Mageia, and you have a truly dedicated partition, the reason it is not booting is that your BIOS has set up your sda and hd0,x as sdb and hd1,x or vice versa [see note later]. You can try to boot rearranging the sequence, meaning changing sdax to sdbx and hd0,x to hd1,x or the other way round (sdb to sda...) at grub menu (press 'e'?).

[see note later] - BIOS sometimes change the ordering at boot time. so the drive may be sda or sdb at different boots, and it may change even later on. You can mitigate this by properly setting up slave/master through cabling or jumpers. If you set both drives to master (most likely) or both to slave, then you will have this problem even later on.

[gratutious note] - you will not have this problem if you use grub2 for your dedicated boot. Or for that matter, a simple 'update-grub' will straighten things out for an OS grub.

Thank you again, doktor5000 and Ken-Bergen.

I made a mistake in my previous posts, since I was confused about the two root entries in menu.lst, but now I read more about grub configuration and booting, and know that: root in the kernel line points to the root filesystem (sdb6 in my case); and the one in a separate line points to where grub configuration files are located (sdb1 in my case). So the menu.lst seems to be OK, I checked the UUID from a Mageia3 LiveDVD.

I also understood that, since grub runs, I can go into console mode (as doktor5000 wrote) and boot from there. I tried with both kernels, and I get the same error message. But I could see more details in the console errors, and the problem seems to be reading the initrd file (un compression error). How can I create the initrd again from a LiveDVD or any other way?
Any ideas?

When I wrote the previous post I had not read yours, gohlip.

I have a separare /boot Mageia partition (sdb1), where all grub files, vmzlinux, initrd,... are. And the / Mageia partition is at sdb6. Grub is loaded from the MBR in sdb, which I slect from the BIOS when I start the PC. So I tried this from the grub console:

root (hd0,0)
kernel (hd0,0)/kernel-... root=/dev/sdb6 vga=794
initrd (hd0,0)/initrd-...
boot

But it did not boot with an uncompression error and unable to load the root filesystem.

I use (hd0,0) because in my device.map (hd0) is /dev/sdb and (hd1) is /dev/sda (where Windows and other partitions are installed).

As for the BIOS setting up the drives incorrectly, I don't think tha is the case, since the initrd and vmzlinux files are found during booting. What do you think?

Zamu wrote:
root (hd0,0)
kernel (hd0,0)/kernel-... root=/dev/sdb6 vga=794
initrd (hd0,0)/initrd-...
boot

kernel (hd0,0)/kernel-... root=/dev/sdb6 vga=794
should be

Code: Select all

kernel (hd0,0)/kernel-... root=/dev/sda6 vga=794

and if it fact, it is (hd1,0), then it should be
kernel (hd1,0)/kernel-... root=/dev/sdb6 vga=794
as both partitions reside in the same drive

ps: don't forget your 'nokmsboot'

[edit] - emphasis -
kernel (hd0,0)/kernel-... root=/dev/sda6 vga=794
kernel (hd1,0)/kernel-... root=/dev/sdb6 vga=794
don't forget that goes for the other lines.

when you mean/use "sda", it is always (hd0).
- when you use "sdb", it is always (hd1).
- even when we know the windows as in sda, the mapping as mentioned by you, put your mageia as (hd0) meaning sda, and therefore your windows is in sdb, then.
- partitcularly, when you ask your bios to boot "sdb", it becomes sda.
Hope this is not confusing enough.

Thanks again for all your help, gohlip.

I tried:
kernel (hd0,0)/kernel-... root=/dev/sda6 vga=794
but it does not work, same error message.

As for the other option:
kernel (hd1,0)/kernel-... root=/dev/sdb6 vga=794

It does not work because no kernel or initrd can be located in hd1.

I am ver confused now, I never had so many problems before. In fact, I have been running Linux in this PC (first Mandriva, then Mageia) for years without such problems. I know I can reinstall Mageia 3 keeping my /home and /opt partitions untouched, but I'd rather solve the issue without reinstalling.

Sorry to hear it didn't work, but I am very sure that the naming convention for the same drive should be kept.
Anyway, you can try to boot the kernel directly; ie. use vmlinuz-3.xx.x-desktop-x.mgax and initrd-3.xx.x-desktop-x-mgax.img
This can check whether the .....er,.initramfs..,(different distro use diff names) and the sym-link is done correctly. I recall sometime back Mageia had some issue with it.
Other than that, sorry. But repeat, I am very sure the naming convention (sda hd0 - sdb hd1) must be kept.

Good luck.

[edit] - after writing above, noticed you use vmlinuz and initrd.img. Shouldn't it be vmlinuz-desktop and initrd-desktop.img?
Try it out first, okay?

To check the linux kernel 3.xx.x-desktop-x.mga3, at grub prompt,
<code>grub> ls (hd0,0)/</code>
edit

Code: Select all

grub>  ls (hd0,0)/

ps: I am not too sure this works in grub-legacy, but I think so. Confidence level 70% (had not used grub-legacy for more than 5 years)
If I get this wrong, can somebody please write the correct command. Thanks.

No need to use ls, grub legacy supports tab completion with all commands so just press TAB and all possible choices will be shown.
That way you can also navigate through your filesystem.

Thanks a lot everyone! I am writing this in Mageia 3, so as you can imagine I solved the issue!

Thanks to all your help I guessed that the initrd files were corrupted, so I booted a Mageia3 LiveDVD on USB in order to try to create a new one using 'chroot' and 'dracut' (after reading instructtions for these). But 'dracut' complained that /boot was full and could not write the .img file. And it was full indeed! (It is only 38Mb, which I guess it is a bad idea...) So I deleted the old initrd images, and created a new one, which I finally did not use, since I saw 'initrd.img.old' file in /boot, guessed it was the old initrd of Mageia2 kernel (3.4), renamed it so, and rebooted. When grub loaded, I used the console to boot with the old kernel and newly renamed initrd... and it worked! Back in Mageia 3, I created a new initrd for kernel 3.10 [Note], uninstalled the old 3.4 kernel, wrote GRUB to MBR, rebooted and everything is working now.

Thanks again, you have been so helpful! As always, when something goes wrong I end up learning a lot of stuff, in this case about grub, initrd images, dracut,...
Cheers,
Pablo

[Note] I used 'dracut --kver 3.10.24-desktop-2.mga3' with no options from the console to create it. Is there a better way?

PS How can I mark the issue as solved? I changed the subject line in the reply but it did not work...

This is the second time I have written this post. The first time I got distracted after completing the post and before submitting it and I forgot to copy it to the clipboard. By the time I hit submit, the site had logged me out and the post was lost . Fortunately I have a bit of time today and elected to rewrite the post...I don't always...

But I guess that grub-editing will work only if I run it from inside my system, which I can't do since it does not boot.

To boot from a live cd then use your desired / partition, you need to set up the environment then use the chroot command.

Start by mounting your / filesystem someplace, let us say on /mnt. After mounting your / filesystem, mount your /boot filesystem under it on /mnt/boot.

Now set up your environment:

Code: Select all

mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc


After doing this, chroot to the desired / filesystem:

Code: Select all

chroot /mnt


Now, this set of commands works on OpenSUSE, but I am not sure it works on Mageia; in the past, when I have had to fix initrds on Mandriva systems, I have had to do it this way:

Code: Select all

mount -o bind /dev /mnt/dev
chroot /mnt
mount sysfs -t sysfs /sys
mount proc -t proc /proc


Regardless, after you have your system running properly in the chroot environment, then you cd to your boot partition (cd /boot) and fix your initrd.

Remember you use the dracut command to work on a Mageia initrd.