Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

lilsirecho · 2011-10-08 20:20:21

The following is mdadm.conf array data:

 ARRAY /dev/md0 metadata=1.2 name=(none):0 UUID=f72d161a:5ae1e852:d6b20ecf:8399b027
ARRAY /dev/md/0 metadata=1.2 name=(none):0 UUID=f72d161a:5ae1e852:d6b20ecf:8399b027

As can be seen, the data is not the same as md0 uuid.......

EDIT: Added info on chroot:

 sh-4.2# mount /dev/md0 /mnt/md
sh-4.2# cd /mnt/md
sh-4.2# mount -t proc proc proc/
sh-4.2# mount -t sysfs sys sys/
sh-4.2# mount -o bind /dev dev/
sh-4.2# chroot . /bin/bash
[root@n6re /]# cat /proc/mdstat
Personalities : [raid0] 
md0 : active raid0 sdg2[1] sde2[4] sda2[2] sdf2[0] sdd2[3]
      77644288 blocks super 1.2 512k chunks
      
unused devices: <none>
[root@n6re /]#

Perhaps this /proc listing is not correct for my raid0 using partition of 100mb for boot on one of the 5 active devices.....

Last edited by lilsirecho (2011-10-08 21:52:00)

lilsirecho · 2011-10-09 03:11:08

Further info regarding the grub setup in my raid0 array while in chroot:

 [root@n6re boot]# pacman -S grub2-bios
warning: grub2-bios-1:1.99-5 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...

Targets (1): grub2-bios-1:1.99-5

Total Download Size:    0.00 MB
Total Installed Size:   2.41 MB

Proceed with installation? [Y/n] y
(1/1) checking package integrity                   [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) upgrading grub2-bios                         [######################] 100%
ldconfig: /usr/lib/libmpeg2convert.so.0.0.0 is not an ELF file - it has the wrong magic bytes at the start.

ldconfig: /usr/lib/librecode.so.0.0.0 is not an ELF file - it has the wrong magic bytes at the start.

[root@n6re boot]# insmod raid
insmod: can't read 'raid': No such file or directory
[root@n6re boot]# cd
bash: cd: HOME not set
[root@n6re boot]# cd /mnt/md
[root@n6re md]# search grub2
bash: search: command not found
[root@n6re md]# find grub2
find: `grub2': No such file or directory
[root@n6re md]# find /boot/grub/grub.cfg
find: `/boot/grub/grub.cfg': No such file or directory
[root@n6re md]# find rub
find: `rub': No such file or directory
[root@n6re md]# find grub
find: `grub': No such file or directory
[root@n6re md]#

It seems there is no grub file in /boot.

How did I boot before upgrading to linux-3.0.6-1?

Where did my grub go? How did it get deleted?

Cannot find grub with find command.

[root@n6re md]# uname -a
Linux n6re 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 x86_64 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
[root@n6re md]#

Linux is installed!

How do I correct the raid0 array grub details so it can boot?

The wiki addresses install procedures not corrective actions.

Attempted to run in chroot.....insmod raid.... error "can't read raid".

The grub2 wiki is extremely difficult to utilize IMHO.

Why is my raid0 uuid not present in /etc/proc/mdstat?

I cannot boot on the md0 uuid if it is not validated in that file..........

Is it possible to upgrade a raid0 system in linux kernel? Or any other raid array?

lilsirecho · 2011-10-09 14:44:09

The following is blkid for md0:

/dev/md0: UUID="6a4f9666-9f07-4792-b4cb-94033b2526f9" TYPE="ext3" SEC_TYPE="ext2"

As shown in previous post, this uuid is not in /etc/proc/mdstat for md0.

It was installed as root partition using 5 devices as partition#2 on each device.

After upgrade to linux-3.0.6-1, proc became corrupted.

Using mdadm command to populate /etc/mdadm.conf also corrupted that file. This occurred a second time when I re-performed the mdadm command so there are two instances of corrupted arrays in that file.

What corrective action must be taken? Can I not use partitioned /boot in linux or grub2? Why is md0 uuid ignored except in the boot grub sequence?

Is the identical blkid assigned to five separate devices partitions an allowed assign?

What caused this mess?

EDIT: Now noting fstab:

# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
devpts                 /dev/pts      devpts    defaults            0      0
shm                    /dev/shm      tmpfs     nodev,nosuid        0      0
UUID=6a4f9666-9f07-4792-b4cb-94033b2526f9 / ext3 defaults 0 1
UUID=71ebdefd-5418-4d1c-a508-758bb1dcd7a3 /boot ext2 defaults 0 1
UUID=7bd63c08-a9d6-414e-b612-3c0590ac79fa swap swap defaults 0 0

EDIT: Now noting ...mdadm --detail /dev/md0.....as follows:

[root@n6re proc]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Jul 20 00:54:49 2011
     Raid Level : raid0
     Array Size : 77644288 (74.05 GiB 79.51 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Wed Jul 20 00:54:49 2011
          State : clean
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : (none):0
           UUID : f72d161a:5ae1e852:d6b20ecf:8399b027
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2
       2       8       66        2      active sync   /dev/sde2
       3       8       98        3      active sync   /dev/sdg2
       4       8      114        4      active sync   /dev/sdh2
[root@n6re proc]#

Thus the blkid obtained from the query in previous post seems not to be correct.

EDIT: Running blkid in chroot to the raid array:

 [root@n6re proc]# blkid
/dev/sda1: UUID="71ebdefd-5418-4d1c-a508-758bb1dcd7a3" TYPE="ext2" 
/dev/sdb1: UUID="7bd63c08-a9d6-414e-b612-3c0590ac79fa" TYPE="swap" 
/dev/sdb2: UUID="f72d161a-5ae1-e852-d6b2-0ecf8399b027" UUID_SUB="1ef49e97-93ca-108d-3a06-7dbe6b036b74" LABEL="(none):0" TYPE="linux_raid_member" 
/dev/sdc2: UUID="4a16e80d-1cdf-4461-aed4-689350c2c0b4" TYPE="swap" 
/dev/sdd2: UUID="4a16e80d-1cdf-4461-aed4-689350c2c0b4" TYPE="swap" 
/dev/sde2: UUID="f72d161a-5ae1-e852-d6b2-0ecf8399b027" UUID_SUB="3c7d48c9-e8d2-26a1-c5ea-0fe2437a8413" LABEL="(none):0" TYPE="linux_raid_member" 
/dev/md0: UUID="6a4f9666-9f07-4792-b4cb-94033b2526f9" TYPE="ext3" 
/dev/sdc1: UUID="909993fb-bc95-4b3b-999e-15e6953a564a" TYPE="ext2" 
/dev/sdd1: UUID="909993fb-bc95-4b3b-999e-15e6953a564a" TYPE="ext2" 
/dev/sdd3: UUID="d4df3e26-4890-4cbc-ac71-4919c9e54dfc" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdd4: UUID="5b9804e6-0076-47d4-abd4-dfd300907013" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdf1: UUID="859cd38b-3a8a-449b-9989-4467bedacefd" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdg2: UUID="f72d161a-5ae1-e852-d6b2-0ecf8399b027" UUID_SUB="6811e367-aa82-8e8e-ae21-95f8b6cab0b7" LABEL="(none):0" TYPE="linux_raid_member" 
/dev/sdh2: UUID="f72d161a-5ae1-e852-d6b2-0ecf8399b027" UUID_SUB="3a214c95-e3ac-20e3-78ca-16916f66a0a8" LABEL="(none):0" TYPE="linux_raid_member" 
/dev/sda2: UUID="f72d161a-5ae1-e852-d6b2-0ecf8399b027" UUID_SUB="342e0f07-de13-6456-f66c-dd640d483f63" LABEL="(none):0" TYPE="linux_raid_member" 
/dev/sdc3: UUID="0e55cd32-ad2e-44a9-92d2-6f089176bf1a" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdc4: UUID="5b9804e6-0076-47d4-abd4-dfd300907013" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdg1: UUID="C4B8-1FAD" TYPE="vfat" 
[root@n6re proc]#

The ID seems to be the same for md0 as is provided in the grub at boot and in fstab.

Why is the ID different in mdadm --detail /dev/md0....?

Last edited by lilsirecho (2011-10-09 18:27:47)

lilsirecho · 2011-10-09 18:33:43

From the data listed in the previous post it seems that mdadm has generated the difficulty in booting the raid0 array.

Perhaps fstab and grub need to reference the md0 uuid as posted by mdadm?

EDIT Why does the mdadm listing of /dev/md0 display the uuid in such a different manner than the posting in blkid for the same uuid. Is this significant?

Last edited by lilsirecho (2011-10-09 18:37:31)

lilsirecho · 2011-10-09 23:43:59

Performed more searches as follows:

sh-4.2# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Jul 20 00:54:49 2011
     Raid Level : raid0
     Array Size : 77644288 (74.05 GiB 79.51 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Wed Jul 20 00:54:49 2011
          State : clean
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : (none):0
           UUID : f72d161a:5ae1e852:d6b20ecf:8399b027
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       66        0      active sync   /dev/sde2
       1       8       82        1      active sync   /dev/sdf2
       2       8       18        2      active sync   /dev/sdb2
       3       8       34        3      active sync   /dev/sdc2
       4       8       50        4      active sync   /dev/sdd2
sh-4.2#

As can be seen from the details given for the component devices in previous posts, the uuid for md0 is identical to all five of the component devices.

All md devices must have 9 as the major number....all of the component devices have major number 8 for scsi devices. Therefore the uuid for md0 cannot be the same unless such a case is allowed under the raid rules in udev or whatever. It seems strange that md0 has the same uuid but should have a different major number.

Attempts to determine the major-minor number of the md0 array result in unsuccessful outcomes.

The error message when trying to boot the array indicates the system is not able to determine the major-minor number of the uuid assigned in grub for md0.

How can the desired numbers be established to enable boot?

lilsirecho · 2011-10-11 05:21:52

Googling has revealed an impasse regarding raid and metadata 1.2.

It seems that grub2 doesn't like metadata 1.2 so cannot boot because /dev/md0 is not provided in the uuid in grub.

Haven't found a solution for this dilemma.......

lilsirecho · 2011-10-11 15:17:55

This googled info may have some clues to the solution to the grub fail to find md0:

Grub2 and metadata 1.2
Submitted by ecellingsworth (not registered) on Thu, 2011-09-15 22:01.

Let me first say that this is the only "how-to" guide I've been able to find that has up-to-date information for getting grub2 to work with mdraid. Thank you for that. I've been banging my head against the wall trying to get a boot manager installed on an array.

I had both of the problems described by the commentors above. First, after finishing the steps on this page and rebooting, grub threw a few errors: file not found, no such disk, you must load the kernel first. Through some trial and error I was able to determine the cause of each error.

For me, grub was unable to find the mdraid module, so the line "insmod mdraid" was returning the "no such file" error. I was able to remove this line without problems. I'm not sure of the difference between this module and the "raid" module, but it doesn't appear necessary (hopefully I don't find this to be untrue after a drive failure!).

Grub was unable to "set root = '(md0)'". I entered the command console to find it had a device called (md/0) listed instead. After googling around a bit (see links below comment), I've come to the conclusion that this is how grub labels raid devices with metadata 1.x (e.g. 1.2, as opposed to 0.90). After changing the reference to (md/0), grub was able to find the disk. The kernel option stays "/dev/md0".

Finally, I had to fix the location of the kernel and initrd which are found in the /boot directory, as suggested by the second commentor. Once the kernel was found, grub was able to load initrd and no longer complained that the kernel had to be loaded first. Voila! Grub was able to boot linux....or at least try to. At this point I ran into the problem that my mdadm was configured to prohibit booting degraded arrays. I followed the Steve M's advice and reconfigured my mdadm package to permit this (after which I reconfigured and installed grub on the partitions).

I hope this information is useful. I'm not experienced with raid or grub. One final quick note about testing your array. If you unplug a drive and boot ok, then shutdown and reboot, you have to manually re-add the drive to the array using something like "mdadm /dev/md0 -a /dev/sda1". Beware that doing so requires a complete rebuild. So if it took you 3 hours to sync the two drives the first time (as it did me), expect to spend another 3 hours rebuilding every drive you test by unpluggi

Perhaps the ID for the md0 device can be made.....set root=(md/0,1)....or not.......

EDIT: Use of (md/0,1) generates a new error....you must start the kernel first....(this occurs with set-root=(md0,1) as well.......

At this point I am not certain that the procedure above applies to a raid0 system with a separate boot partition...not an MBR arrangement.

Perhaps doing something with the kernel location will get the kernel started first....

Probable that archlinux has a different arrangement than that referenced in googled data. The initramfs appears in /boot for the new linux arrangement.

Perhaps more than initramfs is required in the /boot directory....

EDIT: Mounted /dev/md0 in /mnt/md.....opened /boot directory and found:

initramfs-linux-fallback.img
vmlinuz-linux
initramfs-linux.img

Don't have a clue as to what to do with this to enable start kernel first.....

EDIT: Mounted boot partition of the raid array in /mnt/md1......contains:

grub
lost and found
initramfs-linux-fallback.img
initramfs-linux.img
kernel26-fallback.img
kernel26.img
vmlinuz-linux
vmlinuz26

The kernel26 items are highlighted......

Last edited by lilsirecho (2011-10-11 16:24:17)

lilsirecho · 2011-10-11 18:03:35

Further info regarding the failure to boot:

The initial ...set root=(hd0,1).... existing in the unmodified grub2 edit display allows the install to proceed as follows;

Decompressing Linux ..Parsing ELF...done
Booting the kernel..
...Starting udevd
done
....Running Hook [udev]
...Triggering uevents...done
....Running Hook [mdadm]
mdadm.../dev/md0 has been started with 5 drives
Waiting 10 seconds for /dev/disk/bu-uuid/xxxxxx
Root device /dev/disk/by-uuid/xxxx doesn't exist...attempting to create it
Error unable to determine major-minor number of root device /dev/disk/by-uuid/xxxxx
Dropped to recovery shell.....

The trouble begins while the kernel is booting even though /dev/md0 has performed the start of the mdadm array of 5 devices...and the md0 device is the root device!!!

lilsirecho · 2011-10-11 18:28:19

It seems to this user that the nomenclature reference in the googling data indicates that grub2 needs a different ID for the raid device used for boot.

Thus (md/0,1) could mean raid0 md device 0 and the first partition of that device. This is consistent with the assigned md notations of the five devices, the device containing boot partition is noted as md...0, the remaining devices are 1,2,3,4....total 5.

If I use (md/0,1} as set root I am told I must load the kernel first.....................

HOW?

Last edited by lilsirecho (2011-10-11 22:04:00)

steve_v · 2011-10-12 05:32:48

Looks like the same issue here.
System booting ok prior to kernel 3.0.6 update.

Failed boot:

Decompressing Linux ..Parsing ELF...done
Booting the kernel..
...Starting udevd
done
....Running Hook [udev]
...Triggering uevents...done
....Running Hook [mdadm]
mdadm.../dev/md/1 has been started with 2 drives
mdadm.../dev/md/3 has been started with 5 drives
Waiting 10 seconds for /dev/disk/by-label/Root
Root device /dev/disk/by-label/Root doesn't exist...attempting to create it
Error unable to determine major-minor number of root device /dev/disk/by-label/Root

The md devices are being assembled correctly, but no uuid or label symlinks are created:

ramfs#: ls -l /dev/disk/by-label

lrwxrwxrwx 1 root root 10 Oct 13  2011 Boot -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Boot_Backup -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Games -> ../../sdd1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Swap -> ../../sdd2
lrwxrwxrwx 1 root root 10 Oct 13  2011 System\x20Reserved -> ../../sdc1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Win7 -> ../../sdc2

ramfs#: ls -l /dev/md

lrwxrwxrwx 1 root root 6 Oct 13  2011 1 -> ../md1
lrwxrwxrwx 1 root root 6 Oct 13  2011 3 -> ../md3

Changing the 'root=' boot parameter from '/dev/disk/by-label/Root' to '/dev/md/1' enables a normal boot.

After the system has booted all appears normal.

steve@Damnation ~> ls -l /dev/disk/by-label/

lrwxrwxrwx 1 root root  9 Oct 13  2011 Archive -> ../../md3
lrwxrwxrwx 1 root root 10 Oct 13  2011 Boot -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Boot_Backup -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Games -> ../../sdd1
lrwxrwxrwx 1 root root  9 Oct 13  2011 Root -> ../../md1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Swap -> ../../sdd2
lrwxrwxrwx 1 root root 10 Oct 13  2011 System\x20Reserved -> ../../sdc1
lrwxrwxrwx 1 root root 10 Oct 13  2011 Win7 -> ../../sdc2

It occurs to me there has also been a mkinitcpio update recently: http://projects.archlinux.org/svntogit/ … bd96acd075

Nope, rollback to 0.7.2 does not resolve, must be the kernel update?

Any ideas?

Last edited by steve_v (2011-10-12 06:10:20)

lilsirecho · 2011-10-12 15:34:50

My latest effort fails to reach desktop but reaches prompt. Trying to enter login data but have no passwd assigned to my system, using xfce4 and start it in /etc/rc.local.

I added ...root=/dev/md0 to the linux line in grub2 to get this far although some error messages occured during the boot sequence. They ran by so fast couldn't read them.

Perhaps I will determine if a password is available somehow!!!

Perhaps I can add a new one?

Seems I may have to use label since uuid gives no response in grub2 metdata1.2.

lilsirecho · 2011-10-12 16:27:36

Ran e2fsck and /dev/md0 is clean....

steve_v · 2011-10-13 05:41:19

Sounds like mdadm has changed, symlinks are no longer created my the mdadm initcpio hook. Ergo using uuid or label for the boot device no longer works.
Apparently replacing mdadm with mdadm_udev in mkinitcpio.conf should work, I have yet to test.

lilsirecho · 2011-10-13 22:22:57

Performed the following in chroot:

[root@n6re /]# mkinitcpio -b /mnt -p linux
==> Building image from preset: 'default'
  -> -b /mnt -k /boot/vmlinuz-linux -c /mnt/etc/mkinitcpio.conf -g /mnt/boot/initramfs-linux.img
==> ERROR: invalid kernel specifier: `/mnt/boot/vmlinuz-linux'
==> Building image from preset: 'fallback'
  -> -b /mnt -k /boot/vmlinuz-linux -c /mnt/etc/mkinitcpio.conf -g /mnt/boot/initramfs-linux-fallback.img -S autodetect
==> ERROR: invalid kernel specifier: `/mnt/boot/vmlinuz-linux'
[root@n6re /]#

Perhaps this is significant.................

Dunno how "default" can handle either or both of MBR grub or partitioned grub.

I assume it covers the MBR mode for grub.

So how to fix for partitioned grub?

lilsirecho · 2011-10-16 16:32:24

I conclude from reading all that I care to research this problem that mdadm and udev are at odds.

I cannot control either of those elements either by sym links or mdadm controls.

The Arch KISS has really disappeared ......in spades.

Tried making a new raid0 from the latest .iso to no avail,,,same failure to find major-minor number of root device. Can't even install Arch anymore........................Catch22!!

EDIT: Many posts with this problem and mine is no different, caused by the same udev/mdadm conflict....
The new install of raid0 with the new arch.iso gives the following: (instead of /dev/md0)

h-4.2# ls /dev/|grep md
md
md127
sh-4.2#

This is a major mistrake not a typo but a design goof-up......................

Last edited by lilsirecho (2011-10-16 16:54:50)

lilsirecho · 2011-10-20 16:41:45

Performed /arch/setup establishing sdb1 as boot partition, sdc1 as swap partition and md127 raid0 using sdb2 and sdc2 as /root partition.

Attempting to reboot gives the same error as previous attempts to boot a raid partition.

This arrangement was utilized realizing that udev seems to assign md127 to all raid devices . It might then allow the system to recognize md127 as setup...but no go again!

-----------------------------------------------------------------

Chrooted into md127 in an arch hdd boot-up.

Purpose: to run mkinitcpio -p linux.................

The following is the result of running mkinitcpio -p linux in md127 chroot::::

sh-4.2# mount /dev/md127 /mnt/md
sh-4.2# cd /mnt/md
sh-4.2# mount -t proc proc proc/
sh-4.2# mount -t sysfs sys sys/
sh-4.2# mount -o bind /dev dev/
sh-4.2# chroot . /bin/bash
[root@n6re /]# mkinitcpio -p linux
==> Building image from preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
==> Building image from preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
[root@n6re /]#

As can be seen in the results, the default mkinitcpio procedure is applied, Hopefully that is useful in this raid0 dev md127 .

The kernel installed is linux kernel obtained from FTP download during /arch/setup.

[root@n6re /]# uname -a
Linux n6re 3.0-ARCH #1 SMP PREEMPT Fri Oct 7 11:35:34 CEST 2011 x86_64 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
[root@n6re /]#

Why the error? Cannot understand why one default fits all..........

Additionally, this setup of raid0 was made using device naming rather than uuid but the error given in the failed boot was the same as that obtained by previous attempts using uuid naming.

What can be done with udev to eliminate the ignore of mdadm start-up in the boot sequence? If it does start up, does udev eliminate the ID for the root md127 even though it is identified as the device udev substitutes for raid devices.?

AFAICT all raid devices are ignored...............

EDIT: Ran blkid in arch boot-up with the following result:

sh-4.2# blkid
/dev/sdd2: UUID="4a16e80d-1cdf-4461-aed4-689350c2c0b4" TYPE="swap" 
/dev/sdc2: UUID="a34c5ae0-b8f4-05bd-5241-990451489ef3" UUID_SUB="9bcc34b0-8a34-9763-2dbe-73bcce1262c4" LABEL="archiso:0" TYPE="linux_raid_member" 
/dev/sdb2: UUID="a34c5ae0-b8f4-05bd-5241-990451489ef3" UUID_SUB="e9e16095-ba1b-fe5a-a7c0-e1493be2f11b" LABEL="archiso:0" TYPE="linux_raid_member" 
/dev/sda1: LABEL="ARCH_201108" TYPE="udf" 
/dev/sdc1: UUID="74d1b23a-1220-4bef-8ede-0debd7f64bcc" TYPE="swap" 
/dev/sdb1: UUID="df84ff39-d8da-4804-812b-8a9fe138f616" TYPE="ext2" 
/dev/sdd1: UUID="909993fb-bc95-4b3b-999e-15e6953a564a" TYPE="ext2" 
/dev/sdd3: UUID="d4df3e26-4890-4cbc-ac71-4919c9e54dfc" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdd4: UUID="5b9804e6-0076-47d4-abd4-dfd300907013" SEC_TYPE="ext2" TYPE="ext3" 
/dev/md127: UUID="2b98adab-2d13-47ef-a235-789203bf6eeb" SEC_TYPE="ext2" TYPE="ext3"

When attempting to run the same command in..... ramfs# blkid when attempting to install the new raid0 boot as installed from FTP does not list the blockid for /dev/md127. Since the mkinitcpio command resulted in the posted error, this result is very likely although the blkid data was present for all other devices in the raid0 setup while in ramfs#blkid display.
It seems that mkinitcpio is now the culprit in not recognizing the mdadm boot step necessary to boot from the sdb1 partition.Edit: And the root partitions of sdb and sdc.

Last edited by lilsirecho (2011-10-20 19:18:53)

lilsirecho · 2011-10-21 00:40:07

Added mdadm to Hooks and ran..... mkinitcpio -p linux.... in chroot for md127 and received the following error:

[root@n6re /]# mkinitcpio -p linux
==> Building image from preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
==> Building image from preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
[root@n6re /]#

Why?

falconindy · 2011-10-21 01:03:24

lilsirecho wrote:

Why?

Because /boot is a separate partition which you did not mount. The error message is vague (and fixed in the next release).

lilsirecho · 2011-10-21 02:10:59

falconindy:
Thank you for the reminder which makes the option in the wiki more than an option.

Also appreciate the promise for a fix of the vagueness.

I will try the mount of the /boot/partition which I neglected so many times!!!

Judging from the experience of the past, it may fail as well....

I am off to try it now!

lilsirecho · 2011-10-21 05:06:34

Performed the ....mount /dev/sdb1 boot/.... in the chroot setup.

Changed mkinitcpio.conf to have mdadm entered five times during the boot sequence.

In chroot, cd to boot and ran mkinitcpio successfully.

Exited chroot and rebooted into the /dev/sdb as the boot device.

Failed to obtain access to root /dev /md127 with the same error message as before.

Mdadm hook was addressed after udev.

The message that md127 was started with two drives did not appear.

Examined /etc/mdadm.conf in chroot and found that the array was identified as md127_0 which disagrees with /proc/mdstat which states md127.

Mkinitcpio ran mdadm five times during its execution for both boot options.

Still cannot establish a bootable raid array in linux 3.0.

One further thing appeared out of the blue. The notation for initramfs-linux was appended in the boot sequence with a reference that I have to monitor in order to get it correctly and report same in another post.

Woe!

falconindy · 2011-10-21 10:10:14

Use the mdadm_udev hook rather than mdadm if you're expecting your array to be given a label (and it looks like you are).

lilsirecho · 2011-10-21 16:31:46

Falconindy:

Removed the mdadm entries from the conf file and entered mdadm_udev before the udev entry in Hooks. This performed in chroot and mkinicpio -p linux re-entered successfully.

Rebooted and received the same error as before.

The mdadm hook is referenced in the boot sequence after udev has been entered. No mention of starting md127 raid array.

This experiment follows the original install attempt for md0. It repeatedly failed and device md127 was substituted for md0 in /proc/mdstat in the boot attempt by some automatic activity during the sequence. Md0 was not then recognized...does not exist. Md127 was substituted automatically.

I reasoned that using md127 might solve the discrepant condition but so far it hasn't.

It seems that md127 as entered into the install also gets modified or nullified during the procedure. Some users report it as udev causing the change. That seems very likely.

It may be a null response under my present arrangement.

Perhaps changing the location of mdadm_udev in Hooks will be fruitful?

EDIT: After many tries to get the 5 drives to boot into Linux3.0, I have concluded that the new kernel does not permit the use of partitioned boot devices. Thus the upgrade has ruined my expensive 5 device CF card raid0 arch system and attempts to download and re-build it are stymied by the design of the .iso which prevents using grub on a partition.. This thread has been open long enough for suggestions to aid in restoring the raid and it will now be closed.

Last edited by lilsirecho (2011-10-22 15:32:35)

lilsirecho · 2011-10-23 19:27:17

Falconindy:

Tried the mdadm_udev in Hooks but received command not recognized.

I am confused with the grub2 desciption of partitioned grub which is reproduced below....I wish to try that in order to get grub loaded into a partition while installing from the downloaded.iso.

Basically, the download doesn't provide for any grub variables so how does the install to partition come about?

Install to Partition or Partitionless Disk
Note: grub2-bios (any version - including upstream bzr repo) does not encourage installation to a partition boot sector or a partitionless disk like grub-legacy or syslinux does. Neither do the Arch devs.

To setup grub2-bios to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example /dev/sda1 as the /boot partition)

# chattr -i /boot/grub/core.img
# grub_bios-install --boot-directory=/boot --no-floppy --recheck --force /dev/sda1
# chattr +i /boot/grub/core.img

You need to use the --force option to allow usage of blocklists and should not use --grub-setup=/bin/true (which is similar to simply generating core.img).

grub_bios-install will give out warnings like which should give you the idea of what might go wrong with this approach.

/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition.  This is a BAD idea.
/sbin/grub-setup: warn: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  
                        However, blocklists are UNRELIABLE and their use is discouraged.

Without --force you may get the below error and grub-setup will not setup its boot code in the partition boot sector.

/sbin/grub-setup: error: will not proceed with blocklists

With --force you should get

Installation finished. No error reported.

The reason why grub-setup does not by default allow this is because in case of partition or a partitionless disk is that grub2-bios relies on embedded blocklists in the partition bootsector to locate the /boot/grub/core.img file and the prefix dir /boot/grub . The sector locations of core.img may change whenever the filesystem in the partition is being altered (files copied, deleted etc.). For more info see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915

megajosh2 · 2011-10-23 22:19:04

I have the same problem as you. The reason I can't boot is because I messed up my mkinitcpio.conf. I have "usbinput" listed instead of "usb" when my root is on a USB hard drive...

lilsirecho · 2011-10-25 15:00:40

After many weeks with this posting I have concluded that the mdadm system has been compromised and any raid entered via mdadm such as /dev/md0 will be rejected by the Linux3.0 boot system.

The error obtained reports that /dev/md0 does not exist but it appears in another Linux boot from HDD as /dev/md0 and is correctly identified in cat /proc/mdstst.

Thus, when installing from FTP with the latest .iso grub is an option for bootloader but it has no provision for partitioned boot.

Setting up a partition for booting is allowed during the arch setup procedure and /dev/md0 is successfully arranged.

After finishing the install and rebooting, the kernel is loaded, udev runs but /dev/md0 is not found so the install aborts to ramfs.

Some of the time, the ID for the raid0 is changed in the /proc/mdstat to md127 by the boot sequence.

Therefore udev seems to improperly respond to mdadm.conf as it has in past kernels.

Perhaps some expert on udev can advise as to what can be done to restore mdadm activity in the latest linux kernel boot sequence.

Or is it the fault of mdadm?

EDIT: Even though I select uuid for the install parameter in arch setup, the ID posted during boot sequence is root=/dev/md0.

Last edited by lilsirecho (2011-10-25 15:05:48)

Arch Linux

#26 2011-10-08 20:20:21

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#27 2011-10-09 03:11:08

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#28 2011-10-09 14:44:09

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#29 2011-10-09 18:33:43

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#30 2011-10-09 23:43:59

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#31 2011-10-11 05:21:52

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#32 2011-10-11 15:17:55

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#33 2011-10-11 18:03:35

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#34 2011-10-11 18:28:19

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#35 2011-10-12 05:32:48

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#36 2011-10-12 15:34:50

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#37 2011-10-12 16:27:36

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#38 2011-10-13 05:41:19

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#39 2011-10-13 22:22:57

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#40 2011-10-16 16:32:24

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#41 2011-10-20 16:41:45

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#42 2011-10-21 00:40:07

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#43 2011-10-21 01:03:24

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#44 2011-10-21 02:10:59

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#45 2011-10-21 05:06:34

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#46 2011-10-21 10:10:14

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#47 2011-10-21 16:31:46

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#48 2011-10-23 19:27:17

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#49 2011-10-23 22:19:04

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

#50 2011-10-25 15:00:40

Re: Upgrade to linux-3.0.6-1 causes no boot(Success with fewer devices in

Board footer