"ALERT! does not exist" at boot with ICH7

[Linoleum]

on an intel ich7 fakeraid0, following different howtos, with the last dmraid (ubuntu3), I've got a "waiting for root filesystem"
After a few minutes, I'm droped to the busybox, giving me those informations :

check root= bootarg cat /proc/cmdline or missing modules, device : cat /prc/modules ls /dev ALERT! does not exist. Dropping to shell.

I do an ls /dev/mapper, and I have all my raid device detected ...
the odd thing is that there is nothing between "ALERT!" and "does not exist"
so the problem seems that there is no root specified to be as asked to continu the boot after the initramfs. But I followed exactly the howtos, I have try all of them, and have the same problem.

I have try to install feisty without the fakeraid, and it works well. So the problem is dmraid related

[Tormod Volden (tormodvolden)]

Thanks for your bug report. Please attach your /boot/grub/menu.lst

[Linoleum (114thw)]

here is my /boot/grub/menu.lst
I've got 4 primary partition :

device Volume0
--Volume01 /boot
--Volume02 /ntfs (win)
--Volume03 /
--Volume04 swap

I have removed 'savedefault'

[Tormod Volden (tormodvolden)]

Your menu.lst looks fine AFAICS. But I wonder if grub is reading it correctly when you boot. In the grub menu, please press 'e' to edit the entry, and verify that the root= is filled out. Please also do as suggested by the error message: type "cat /proc/cmdline" and tell us what it is.

Try also to add "break=mount" to the grub kernel line, and then wait 10 seconds before you press ctrl-D to continue booting,

[Linoleum (114thw)]

I forgot to mention that I have also a lot of line like this :

sda: rw=o, want=582163478, limit=29304678, attempt to access beyond end of device

before the error with the "waiting for root filesystem"

[Linoleum (114thw)]

I have checked
-in the grub menu, with e : root= is right filled, same as in the meu.lst
-with break=mount : make no difference
-if I do "cat /proc/cmdline , after that all the caracters and line are made of cube, triangle and losange. I can only do ctrl-alt-del to restart the computer because nothing is readable.

[Arno Fiva (fivaa)]

Hi

I get a similar error on the an intel ich7 as well. In my case though the raid partition appears after the ALERT! message, saying something like

check root= bootarg cat /proc/cmdline or missing modules, device : cat /prc/modules ls /dev ALERT! /dev/mapper/ /dev/mapper/isw_bbfdjggjhj_HDDRAID6 does not exist. Dropping to shell.

When I then type dmraid -ay followed by Ctrl-D into the shell, the systems boots normally. I got rid of this error adding a 'udevsettle --timeout=10' at the end of /usr/share/initramfs-tools/scripts/init-premount/udev as proposed in Bug #83231. Unfortunatly it takes about 5min for the system to boot now. During the boot process it says something about doing a SOFTRESET. After initializing all devices again it does find the raid drives and boots normally (i guess...). So now I am not sure if this problem concerns dmraid itself or maybe even the SATA drivers.

Did anyone else encounter this problem? Let me know if you need more detailed information!

[Tormod Volden (tormodvolden)]

Arno, you have a different problem -> please file a new bug. The udevsettle line has been included in the Feisty version. I experienced myself a slow boot in Edgy, even when including udevsettle, but I upgraded to Feisty and everything was fine (I was just stepping through Edgy on an upgrade from Dapper to Feisty).

[mpwalter (mpwalter)]

Hi,

had the same problem (SATA2 HDD on ICH7 - 82801). I have this discuss here: http://forum.ubuntuusers.de/viewtopic.php?p=744986 (german only, sorry). With Ubuntu 6.06 - 7.04 it doesn't work - same error(s). The I have installed - for testing - Mandriva 2007 Spring Power Pack, which use also GRUB (v0.97 / Stage 1.5) to boot. There I try to boot Ubuntu with the same setting (menu.lst) from Ubuntu-Installation and it works !

The problem is not on all ICH7 chipsets with SATA because on an Fujitsu Siemens Notebook there is the 82801FBM and there it works well!

[Tormod Volden (tormodvolden)]

The corrupted /proc/cmdline output indicates some serious trouble. Either there's a grave bug in grub or in the kernel (fakeraid modules?) or the BIOS corrupts the kernel and initrd when it reads them from disk. That the Mandriva grub works fine would point to grub.

Do you have raid-1 (mirror)? Can you verify with BIOS tools or another operating system that the raid is fine and in sync?

Can you boot with break=top and cat /proc/cmdline at this stage?

[mpwalter (mpwalter)]

I don't use any raid , so I don't check it. But I can set up one to test , if Mandriva Grub works.

[Tormod Volden (tormodvolden)]

mpwalter, so you get the broken /proc/cmdline, and you've not even installed dmraid? This might be a more general problem then.

[Tormod Volden (tormodvolden)]

mpwalter, it would be very interesting to know if it works with the Mandriva grub, for instance doing something like this:
1. Try installing only the boot loader from Mandriva, by booting the Mandriva grub, go in command mode and run "root" to choose the Ubuntu partition and run "setup" to install the boot loader.
2. Use the Mandriva stage1.5 as well, by running "setup" after choosing Mandriva "root" partition again, and then boot into command mode and pick the "configfile" from the Ubuntu partition while keeping Mandriva as "root".

Please don't set up any raid if you haven't yet, because it would be good to figure out this problem separately and confirm that dmraid is not to blaim.

[Tormod Volden (tormodvolden)]

Sorry, I was too fast there. In (1) it would install the Ubuntu boot loader to MBR, even when running the Mandriva grub. You have to do it more manually, copying the Mandriva stage1 file to the Ubuntu /boot/grub directory for instance. It might be the "setup" command can specify the "stage1" to use as well. You get the idea :)

[mpwalter (mpwalter)]

tormon, some question: You mean, I will "start" with Mandriva GRUB, go to the command line and install then the Ubuntu-Grub - right?

So at the cmd line I try to handle with "setup" ... hmm, I don't really know to do ... for my understanding: with "setup" I can copy/Install the "stage"-Files from Mandriva-Grub to Ubuntu-Grub ?

Ok, this is what I do:

> root (hd0,2) this will change to my Ubuntu Partition (Mandriva is on hd0,4)
> setup (hd0,0) or setup /dev/sda this will install Ubuntu-Grub to MBR - right? Or must I specific here the Mandriva-Stage files ?
> root (hd0,4) change back to Mandriva-Partition

at last how to "pick-up" the Ubuntu-Conffile?

Sorry, I will help, but I'm not a real linux expert, yet!

[Tormod Volden (tormodvolden)]

mpwalter, I hope you have a good boot floppy/cd and a backup, because this can get messy :) Actually it shouldn't be any risk at all, only boot sectors will be changed, and if you can boot a grub floppy you can always recover.

- I am not sure if it's possible to use stage1 from Mandriva and stage1.5 from Ubuntu, but you can try.
- the grub command "install" allows to choose any stage1 file. Try "help install"
- the MBR is (hd0)
- you can specify "full path" to a file, for instance if your have set root to Mandriva and needs Ubuntu menu.lst:
 root (hd0,4)
 configfile (hd0,2)/boot/grub/menu.lst
This would be what I asked for in (2) in my previous post, and I suggest you try this first, since it doesn't change anything on the disk. Of course, boot into the Mandriva grub before running these commands.

Then I was thinking something like this for experiment (1).
 root (hd0,2)
 install hd(0,4)/boot/grub/stage1 (hd0) (hd0,2)/boot/grub/stage2 p (hd0,2)/boot/grub/menu.lst
This should install the Mandriva stage1 to MBR and link to the Ubuntu stage2 and menu.lst

I am new to the "install" command myself, and still find the stage1.5 vs stage2 a little unclear, but if you run setup (hd0) you can see what the default install command is, to get an idea.

To reinstall clean Mandriva:
 root (hd0,4)
 setup (hd0)

To reinstall clean Ubuntu:
 root (hd0,2)
 setup (hd0)

[mpwalter (mpwalter)]

tormod, I don't need to backup my data - the system is alway clear "a fresh new installation" ;-)

ok, but now here the results:

(1) changing menu.lst --> with the Ubuntu menu.lst i can normal booting Ubuntu (ok, this is what we expected)
(2) changing stage-files --> crash ! can't boot any system (expect Win)

So I have to try to boot Mandriva from Ubuntu GRUB --> this didn't work, that meas ist must me GRUB.

Some more: I have checked the files (all sizes are different ..,):
Ubuntu e2fs_stage1.5 7584Bytes / Mandriva 8660 Bytes
Ubuntu stage2 110132 Bytes / Mandriva 102890 Bytes

The output of setup(hd0) is also different from Ubuntu and Mdv GRUB:

...
running "embed /boot/grub/e2fs_Stage15 (hd0)" 17 sectors are embedded (@mdv only 15 written, I think that will be occour of the filesize ?!)
...

So any more Idea ? When I start with Ubuntu Grub I will see for a little moment some "wrong" letters, chars etc. on the screen (maybe the wrong cmdline?) is threre any way to stop this, or to see this log in the busybox ?

[Tormod Volden (tormodvolden)]

Thanks for testing this out! You have narrowed it down to the grub loader. Now for the critical difference between the two grubs... The Ubuntu grub has a lot of Ubuntu changes patched in, I don't know about the Mandriva one. No surprise they have different file size, they are compiled in different environments anyway. The Ubuntu patches deal with both stage1 and stage2, so I guess that's why you can not mix stage files. And yes, the 17 vs 15 sectors is just the filesize/512 rounded up.

Since both of you have ICH7, it's tempting to believe that the corruption is due to the way grub accesses the disk and that something in that chipset triggers the problem. However AFAIK grub just uses BIOS calls and doesn't care about hardware details, unless there is something with disk geometry - which should be only disk-specific. I've got ICH7 myself, without problems.

Can you all please post lspci output and your menu.lst?

[mpwalter (mpwalter)]

The lspci output is at the attachment. I think this bug is not on all ICH7 Systems on a Laptop (see above) with ICH7 ans SATA but 915GM Chipset and 82801FB SATA Controller I don not have this trouble. On my "buggy" system there is a 320GB drive at the working laptop only 40GB drive.

This is my menu.lst:

title Ubuntu, kernel 2.6.20-15-generic
root (hd0,1)
kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=649f8650-f70b-4753-bac5-3dbbaff38ef7 ro quiet splash
initrd /boot/initrd.img-2.6.20-15-generic
quiet
savedefault

title Ubuntu, kernel 2.6.20-15-generic (recovery mode)
root (hd0,1)
kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=649f8650-f70b-4753-bac5-3dbbaff38ef7 ro single
initrd /boot/initrd.img-2.6.20-15-generic

title Ubuntu, memtest86+
root (hd0,1)
kernel /boot/memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title Other operating systems:
root

# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda1
title Microsoft Windows XP Professional
root (hd0,0)
savedefault
makeactive
chainloader +1

[Tormod Volden (tormodvolden)]

Someone intimate with grub and kernel-loading has to chime in here. The only thing I can suggest is to try different versions of grub in order to isolate the issue. I built the old 0.97-20 Debian version, please try it. It has no Ubuntu patches like for instance for usplash support. It should tell us if Ubuntu is to blame or if it would be the same in Debian.

[Tormod Volden (tormodvolden)]

Could you also try to capture and attach the corrupted cmdline entry, in case it could have some hints? Boot with break=mount
mount -t ext3 /dev/sda2 /mnt
cp /proc/cmdline /mnt/var/tmp/proc-cmdline.dat
umount /mnt
(Or to any other partition, or memory stick, which would be convenient for you)

[mpwalter (mpwalter)]

I have captured the cmdline , I hope it will help - I think there are no infos :-(.

I could not install the package , because I have installed the amd64 version - sorry. But the problem will also on the i386 , because this was the first version who I have tried. Is there any way to compile or give me the amd64 version , for testing ?

The problem might be at Debian , too, because at first I have searched the web for similar problems ...

At first I have copied all MDV Stage Files to Ubuntu GRub to boot the system.

[Tormod Volden (tormodvolden)]

You can easily compile the package yourself: From http://merges.ubuntu.com/g/grub/ get grub_0.97.orig.tar.gz and grub_0.97-20.diff.gz and grub_0.97-20.dsc
sudo apt-get build-dep grub
dpkg-source -x grub_0.97-20.dsc
cd grub-0.97
debuild -b -us -uc

I have looked at the cmdline contents, it's certainly not data or code, I would have guessed some graphics. It doesn't seem like random bit patterns, so it could maybe provide a hint for someone.

Did you find anything on the web with regards to similar problems? I googled, but didn't find anything.

[Tormod Volden (tormodvolden)]

Linoleum, it would be nice if you could provide lspci output and menu.lst as well as your /proc/cmdline contents.

[mpwalter (mpwalter)]

Ok, back again.

I have reinstalled my system with the i386 Version and the I replace the installed Ubuntu Grub, with your Grub Version: same result, same error!

Now I will try the gfxBoot Grub an later I will change the drive settings in my BIOS from AUTO to LARGE maybe it help !?

[mpwalter (mpwalter)]

Some note: The error is maybe only in the Stage-Files so I can install the Ubuntu Grub and use only the Mandrive Stage 1,2 and 1.5 files.

[Tormod Volden (tormodvolden)]

Could you also try these files, from the current Debian version?

[mpwalter (mpwalter)]

Tormod, I have tried the files you have attached: same result, same error!. At the next step I have mixed the MDV and your files. Here is the result:

Stage1 Stage2 e2fs_stage15 work
---------------------------------------------
deb mdv deb yes
deb deb mdv no
mdv deb deb no
deb deb deb no
deb mdv mdv yes
mdv deb mdv no
mdv mdv deb yes
mdv mdv mdv yes
---------------------------------------------

This looks like a problem with Stage2 ?!
Stage1 and 2 are installed by: install command. e2f file by embed command.

[Tormod Volden (tormodvolden)]

You seem to be on the right track here. Is it Mandriva grub-0.97-17mdk?

[Tormod Volden (tormodvolden)]

These stage files are from compiling the upstream 0.97 (the common ancestor of Mandriva's and Ubuntu's grub) on Feisty. Can you try them as well?

[mpwalter (mpwalter)]

Curretly I have no installed MDV I using only the Stage files, but the official pakage list tell me that Mandriva (2077 Spring) using grub-0.97-20mdv2007.1.i586. At the weekend I will checked your attached files and report then.

[Tormod Volden (tormodvolden)]

mpwalter, did you open the "dmraid" task? I thought you were experiencing this bug without having dmraid installed?

[mpwalter (mpwalter)]

Sorry, was my mistake, how can I remove it? I don't experiencing whith dmraid!

[Tormod Volden (tormodvolden)]

(Yes, rejecting the dmraid task was fine, because there's no way to remove it again.)

Here is the Mandriva version of the stage files, built on Feisty. It should tell us if any of the Mandriva patches helps, or if it's a compiler environment issue.

[mpwalter (mpwalter)]

Tormod, I have tested both packages you have posted (only all three files together , I don't have mixed the files). The first set (grub-0.97) don't work. The second one (mandriva stage files) works very fine (no trouble or anything else)

[Tormod Volden (tormodvolden)]

There are 29 Mandriva patches, 11 of them touch stage2 (grep /stage2/ *.patch). When applying on top the Ubuntu patches, only 4 apply cleanly. 4 others would apply without Ubuntu patches and one touches only reiserfs_stage1_5. I did not verify the order of the patches, which could help for the last 2, or else they would need more tweaking.

In the first place, without too much effort, I compiled stage files using Feisty grub + the 4 easy Mandriva patches:
grub-0.5.96.1-ezd.patch
grub-0.91-nice-magic.patch
grub-0.95-eltorito.patch
grub-0.95-mem_lower.patch

Let's see how lucky we are. BTW, do you guys have 4GB RAM?

[Tormod Volden (tormodvolden)]

While I am at it, I compiled again without Ubuntu patches, but with the 4 other Mandriva patches:
grub-0.94-initrdmax.patch
grub-0.97-mactel-kbd.patch
grub-0.97-nxstack.patch
grub-0.97-once.patch

If neither if these two sets work, it must be in the last 2 patches...

[mpwalter (mpwalter)]

At first, I have only 2 GB RAM in my system.

The first set of files (incl. MDV patches) works without any problem. The second package (no Ubuntu, other MDV patches) don't work.

Hope this result is helpful for you.

[Tormod Volden (tormodvolden)]

Thanks for all the testing! Yes, that's very good news, then the fix is inside one of these four patches. It's probably not the "eltorito" patch, and from quickly looking at the others (ezd, nice-magic, mem_lower) I would guess the last. Here are Feisty stage files built with the grub-0.95-mem_lower.patch.

[mpwalter (mpwalter)]

The mem_lower files working, very good without any trouble!

[Tormod Volden (tormodvolden)]

Can you verify that this new package fixes the issue? Note that you have to run "sudo grub-install (hd0)" (use hd0 if you want grub on the MBR) after that you have installed the new package. This is because the package contains the stage files only under /usr/lib/grub but they are copied to /boot/grub by grub-install.

[mpwalter (mpwalter)]

The last deb-Packege you have posted will work.

I have do these things to install:

sudo apt-get remove grub (to remove old grub)
sudo dpkg -i <your last package> (to install the new one)
sudo grub-install hd0 (install grub in mbr)

reboot system and test!

in /boot/grub the files are dated today and installed-version tell me: 0.97-20ubuntu7

[Tormod Volden (tormodvolden)]

Linoleum, it would be nice if you could test the package too.

[Tormod Volden (tormodvolden)]

Here is a debdiff for the new grub package. The mem_lower patch is used by Mandriva and Red Hat. I found it mentioned on the grub mailing list (http://<email address hidden>/msg06526.html)

"One that I think is very useful is the grub-0.92-mem_lower.patch, it is
relatively simple, and will allow grub to boot some computers where only
lilo and syslinux were booting, basically, this patch checks early if
grub will fail, and in that case, use a memory detection code almost
indentical to syslinux."

[Tormod Volden (tormodvolden)]

Request sponsoring for upload.

[Kees Cook (kees)]

Great work tracking down a fix for this bug! Tormod, can you adjust your changelog to describe the "why" of the patch? This will be handy for doing future Debian merges. In other words, the changelog should try to summarize what the patch fixes, rather than just saying that a patch was added. That way the merger has some idea of its purpose without having to read through this entire bug report. (For example, see the entries for 0.97-20ubuntu6 and 0.97-20ubuntu3, which give a short summary of what the patch is for). After that, I'd like to get cjwatson's ACK for this patch since I'm not a grub expert, but AFAICT, it looks fine. :)

[Tormod Volden (tormodvolden)]

Here is a longer changelog, with a summary of the quote above. There is not any more information to be found in the Mandriva sources. Apparently it came into the Conectiva version of grub 0.92. It is also in Red Hat's grub. I must honestly say I don't understand every line of that patch myself :)

[Goodwin (al-linux)]

Will be there also the version of the new GRUB package for amd64?

I have the error with the similar message, but I do not know, if it is the same problem, so I would like to try the new grub if it could have some influence...

My problem is related to Xen - I get this error if booting the Xen over Ubuntu 7.04 server as Dom0. Maybe it could be also some problem of Xen, but the problem occurs first, if the boot of the Xen part is already done and the Ubunt boot runs. Below is my error description, whcih I posted to Xen users conference.
Do You think, this can be the error of GRUB in Ubuntu, is it the same error like here described, or is it some other error or is it no problem of Ubuntu? Should I open the new thread here?
  Thank You, Archie.
*************************
Hello,

             I have problems with booting with the new Xen (used the binary tarball) v. 3.1.0.

I have installed following system:
One small raid partition with Ext3 fs with the boot directory and grub installed
Two large and one small mirrored raid1 partitions managed by mdadm and used as 3 physical volumes for LVM, all 3 joined into one volume group.
Planned dom0 system is installed on the logical volume, which is striped over md1 and md3 raid phzsical volumes. It is Ubuntu server 7.04.

The Ubuntu system self boots ad behaves normally.

If booting Xen, the boot process comes to the point where the raid arrays are beeing initialized. The RAID arrays itself are initialized and activated correctly. After it happens, the system hangs for some minutes and then the message comes:

Check root= bootarg cat /proc/cmdline
or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/mapper/VG_HIGHLAND_SYSTEM-LV_DOM0 does not exist. Dropping to shell!

... and the sh is invoked, the tty cannot be accessed, so the job control is turned off.

I looked into /dev/mapper and really, thre is no VG_HIGHLAND_SYSTEM volume group, which appears there if booting the Ubuntu server.

I am not very skilled in the work with LVM, so the only thing what came into my mind was - it looks like if the default binary tarball of Xen 3.1.0 has not turned on the LVM support in the kernel, but I think this is not possible, because LVM is normally used.

Or would it be the solution to configure and compile the xen kernel from source?

Does somebody some other idea, why the volume group is not recogized and cannot be found in /dev/mapper ?
The logical partitions also are invisible in the result of cat /proc/partitions

                        Thank You very much in advance for any advice or help...

                                   With best regards, Archie

            P.S. In http://groups.google.cz/group/linux.debian.bugs.dist/browse_thread/thread/eafa7a66782c206e/630c5180caa580dd?lnk=st&q=ALERT!+%2Fdev%2Fmapper%2FVG+does+not+exist.+Dropping+to+shell!&rnum=1&hl=cs#630c5180caa580dd

I found the idea this is some error in GRUB script, but I do not know if it is my case - GRUB configuration file „menu.lst“ looks like:

title Xen 3.1.0, kernel 2.6.18-xen /dev/sda1
root (hd0,0)
kernel /xen-3.1.0.gz dom0_mem=192M
module /vmlinuz-2.6.18-xen root=/dev/mapper/VG_HIGHLAND_SYSTEM-LV_DOM...

[Tormod Volden (tormodvolden)]

Goodwin, that has nothing to do with this bug. The essential thing here is the exact error message in the bug title. You don't have a corrupted /proc/cmdline.

[Goodwin (al-linux)]

OK, You are right, sorry for the off-topic...

[Kees Cook (kees)]

I've sponsored the upload. :) Thanks again for tracking this down.

grub (0.97-20ubuntu7) gutsy; urgency=low

  * Add patch from Mandriva grub-0.95-mem_lower.patch (Ubuntu bug #106887)
    Allows grub to boot on some computer where only lilo and syslinux
    would work. Uses memory detection similar to syslinux.
    http://<email address hidden>/msg06526.html

 -- Tormod Volden <email address hidden> Sat, 26 May 2007 11:15:23 +0200

[cs224 (cs224)]

I just wanted to say that I had the same problem and your (feisty_mem_lower.tgz) solved the problem for me, too. I did not install ubuntu, but a debian lenny and I just put the files in the tgz in the /boot/grub directory. Thanks for the fix.

[Tormod Volden (tormodvolden)]

cs224, I was just filing the bug upstream in Debian when your comment came in :) Maybe you can confirm/comment on the Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428094

[Jonah (jonah)]

i have the same problem with m3n8200 motherboard. i'm stuck at initramfs with ALERT! /dev/mapper/nvidia_fgadbadj2 does not exist. Dropping to shell!.

I don't understand why, installation from livecd goes fine, then on reboot i get stuck here... please help.

[Luke Yelavich (themuso)]

Jonah, you are using a different chipset to the bug reporter. Please report a separate bug so we can track your issue individually.