8.10 on RAID1 (fakeRAID) array doesn't boot

[Trippytiger]

I've been trying to get Ubuntu up and running on the computer I put together recently, but even with 8.10 I haven't had any luck. The alternate installer detects my array just fine and has no apparent problems installing to it. GRUB also seems to install properly, and has no issue loading my Windows install.

However, when I try to load Ubuntu, I'm greeted with a blinking cursor. There are no error messages or any indication of why the OS isn't booting. I've had similar problems with openSUSE 11 and Fedora 9. I am really perplexed by this and I've no idea what the problem is.

Can anyone help me get Ubuntu up and running? I really prefer it to Windows and I'd love to be able to use it on this machine.

[Trippytiger]

Nobody has any suggestions for fixing this?

And since I neglected to mention this in my first post and it's probably relevant, my motherboard is an Asus M3A78-EM, with the AMD 780G chipset and SB700 southbridge that uses a Promise RAID controller.

[psusi]

Did you try booting into rescue mode?

[Trippytiger]

Thanks for the reply! I have tried booting into the recovery mode, but the same thing happens. Even trying to load memtest doesn't work; I get "Error 28: Selected item cannot fit into memory."

[psusi]

Wow, that is really strange. Boot the livecd and post the output of the following:

sudo fdisk -lu
sudo mount /dev/sda1 /mnt
sudo cat /mnt/boot/grub/menu.lst

Replace sda1 with whatever partition you have Ubuntu installed on. sda1 is probably your windows ntfs partition. You should have one for linux and one for swap as well in the fdisk listing.

[Trippytiger]

Thanks again! Here is the output for sudo fdisk -lu:



Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x3dc43dc4

Device Boot Start End Blocks Id System
/dev/sda1 * 63 83891429 41945683+ 7 HPFS/NTFS
/dev/sda2 83891430 167782859 41945715 5 Extended
/dev/sda3 167782860 1250130104 541173622+ 7 HPFS/NTFS
/dev/sda5 83891493 164248559 40178533+ 83 Linux
/dev/sda6 164248623 167782859 1767118+ 82 Linux swap / Solaris

Disk /dev/sdb: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x3dc43dc4

Device Boot Start End Blocks Id System
/dev/sdb1 * 63 83891429 41945683+ 7 HPFS/NTFS
/dev/sdb2 83891430 167782859 41945715 5 Extended
/dev/sdb3 167782860 1250130104 541173622+ 7 HPFS/NTFS
/dev/sdb5 83891493 164248559 40178533+ 83 Linux
/dev/sdb6 164248623 167782859 1767118+ 82 Linux swap / Solaris


I used the 8.04 live cd because I don't have an 8.10 live cd handy, so of course it didn't pick up the RAID array... but I gather that the 8.10 live cd doesn't support fakeRAID out of the box either, so it shouldn't make a difference, right?

I wasn't able to mount sda2; whenever I tried I got an error: "mount: special device /dev/sda2 does not exist." I'm not really sure why that happened. However, I was able to mount the partition Ubuntu is installed on through the places menu. The contents of /boot/grub/menu.lst are:



title Ubuntu 8.10, kernel 2.6.27-7-generic
root (hd0,4)
kernel /boot/vmlinuz-2.6.27-7-generic root=/dev/mapper/pdc_bgcfbgdhjj5 ro quiet splash
initrd /boot/initrd.img-2.6.27-7-generic

title Ubuntu 8.10, kernel 2.6.27-7-generic (recovery mode)
root (hd0,4)
kernel /boot/vmlinuz-2.6.27-7-generic root=/dev/mapper/pdc_bgcfbgdhjj5 ro single
initrd /boot/initrd.img-2.6.27-7-generic

title Ubuntu 8.10, memtest86+
root (hd0,4)
kernel /boot/memtest86+.bin

### 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/mapper/pdc_bgcfbgdhjj1
title Microsoft Windows XP Professional
root (hd0,0)
savedefault
makeactive
chainloader +1


I'm not sure how much that can actually help, though, since GRUB refers to the actual RAID partition... things. Let me know if there's any other info that might be helpful!

[psusi]

Did you post the entire menu.lst? There should be more in it.

Also you do not want to use the places menu to mount the drive because it makes the same mistake I did in my last post: it mounts one of the drives directly, rather than the mirror. This can cause one side of the mirror to be modified without the other resulting in odd corruption down the road. In fact, that may have happened already so see if you can go into the bios setup utility and either scrub the array or remove the second disk and then add it back to force everything to be copied over again from the first disk.

[Trippytiger]

That's the functional section of menu.lst. Everything else in there was just commented-out information and I didn't think it was important. I can post the rest if it matters.

And thanks for the heads up about mounting partitions through the Places menu. I guess I'll reboot and see how everything goes.

I don't know how I would go about mounting the actual mirror partitions, though. I played around with installing and running dmraid, but I don't really know what to do with it once its activated.

[psusi]

Once you install dmraid it should create devices in /dev/mapper/ that correspond to the array and the partitions in it. All disk access needs to go through those to update both underlying disks.

[ramuk]

(Bug reported copied from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;bug=319837)

Message #21 received at 319837@bugs.debian.org (full text, mbox):

From: Paolo Ornati <ornati@fastwebnet.it>
To: 319837@bugs.debian.org
Subject: Not really a BUG...
Date: Mon, 1 Jan 2007 13:55:05 +0100

This is not really a BUG of GRUB... it's just that BIOS tables are
getting bigger!

Memtest86(+) uses the "standard" linux kernel image format, so it it can
be loaded easily by boot loaders such as Lilo and Grub...

The format is:
512 byte of boot sector
512 * X bytes of setup (where X is usually 4)
Y bytes of kernel image

A zImage kernel will be loaded at address 0x10000 (64k) while a bzImage
will be loaded at 0x10000 (1MB).

Memtest uses the old format.

The boot loader also loads a copy of boot sector and setup sectors at
0x90000 (and then execute the setup code):

| |
0A0000 +------------------------+
| Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
09A000 +------------------------+
| Stack/heap/cmdline | For use by the kernel real-mode code.
098000 +------------------------+
| Kernel setup | The kernel real-mode code.
090200 +------------------------+
| Kernel boot sector | The kernel legacy boot sector.
090000 +------------------------+
| Protected-mode kernel | The bulk of the kernel image.
010000 +------------------------+
| Boot loader | <- Boot sector entry point 0000:7C00
001000 +------------------------+
| Reserved for MBR/BIOS |
000800 +------------------------+
| Typically used by MBR |
000600 +------------------------+
| BIOS use only |
000000 +------------------------+

For the details read this:
http://lxr.linux.no/source/Documentation/i386/boot.txt

So, basically, this layout assumes that memory up to address 0x9A000 can be used.


The problem is that the newer BIOSes are reserving more and more space
in the top addresses below 640k (low memory), so this layout got
broken... and GRUB cannot do anything about it.

I hit this problem a few days ago switching from an "old" Athlon64
based system to a Core2Duo base one.


If you have an x86_64 system you shold have something like this in the
"dmesg" (it's not printed on x86 if I rember correctly, you can look at
"/proc/iomem" anyway):

[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[ 0.000000] BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003e599000 (usable)
[ 0.000000] BIOS-e820: 000000003e599000 - 000000003e5a6000 (reserved)
[ 0.000000] BIOS-e820: 000000003e5a6000 - 000000003e655000 (usable)
[ 0.000000] BIOS-e820: 000000003e655000 - 000000003e6a6000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003e6a6000 - 000000003e6ab000 (ACPI data)
[ 0.000000] BIOS-e820: 000000003e6ab000 - 000000003e6ac000 (usable)
[ 0.000000] BIOS-e820: 000000003e6ac000 - 000000003e6f2000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003e6f2000 - 000000003e6ff000 (ACPI data)
[ 0.000000] BIOS-e820: 000000003e6ff000 - 000000003e700000 (usable)
[ 0.000000] BIOS-e820: 000000003e700000 - 000000003f000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)


This table is provided by the BIOS and basically tells what memory
regions can or can't be used by the system (because reserved by BIOS,
for example).

The first line tells that, on my system, the limit of usable low memory
is 8f000, which breaks the above layout assumption...

On my Athlon64 based machine (ASUS K8VSE Deluxe) it was 9FC00, and in
fact it worked.


Conclusion: memtest86 should use some other method of loading...


PS: it's a bit odd to have 1GB of memory and read that a <100k thing
"cannot fit into memory" ;)

--
Paolo Ornati
Linux 2.6.20-rc2 on x86_64

(Bug reported copied from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;bug=319837)

[ramuk]

I've the same Problem and there was the Explanation. waiting for some sort of Patch soon.:popcorn:

[ramuk]

I've the same Problem and there was the Explanation. waiting for some sort of Patch soon.:popcorn: