Skip to contentSkip to conversation

using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?

DISCUSSION Moshe Yudkowsky 4 participants 9 messages Feb 4, 2008 – Feb 7, 2008 MD RAID

lore
Share & tools
lore
#0 lore raw

I've managed to get myself into a little problem.

Since power hits were taking out the /boot partition, I decided to split /boot out of root. Working from my emergency partition, I copied all files from /root, re-partitioned what had been /root into room for /boot and /root, and then created the drives. This left me with /dev/md/boot, /dev/md/root, and /dev/md/base (everything else).

I modified mdadm.conf on the emergency partition, used update-initramfs to make certain that the new md drives would be recognized, and rebooted. This worked as expected.

I then mounted all the entire new file system on a mount point, copied the mdadm.conf to that point, did a chroot to that point, and did an update-initramfs so that the non-emergency partition would have the updated mdadm.conf. This worked -- but with complaints about missing the file /proc/modules (which is not present under chroot). If I use the -v option I can see the raid456, raid1, etc. modules loading.

I modified menu.lst to make certain that boot=/dev/md/boot, ran grub (thanks, Robin!) successfully.

Problem: on reboot, the I get an error message:

root (hd0,1) (Moshe comment: as expected)
Filesystem type is xfs, partition type 0xfd (Moshe comment: as expected) kernel /boot/vmliuz-etc.-amd64 root=/dev/md/boot ro

Error 15: File not found

Did I miss something? I'm pretty certain this is the procedure I used before. The XFS module is being loaded by update-initramfs, so unless there's a reason that I can't boot md from a boot partition with the XFS file system, then I don't understand what the problem is.

Comments welcome -- I'm wedged!

Signature · 5 lines
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
"Many that live deserve death. And some that die deserve life. Can you give it to
them? Then do not be too eager to deal out death in judgement. For even the
wise cannot see all ends."
				-- Gandalf (J.R.R. Tolkien)
#1 lore raw
Quoted 19 lines · Moshe Yudkowsky

I've managed to get myself into a little problem.

Since power hits were taking out the /boot partition, I decided to split /boot out of root. Working from my emergency partition, I copied all files from /root, re-partitioned what had been /root into room for /boot and /root, and then created the drives. This left me with /dev/md/boot, /dev/md/root, and /dev/md/base (everything else).

I modified mdadm.conf on the emergency partition, used update-initramfs to make certain that the new md drives would be recognized, and rebooted. This worked as expected.

I then mounted all the entire new file system on a mount point, copied the mdadm.conf to that point, did a chroot to that point, and did an update-initramfs so that the non-emergency partition would have the updated mdadm.conf. This worked -- but with complaints about missing the file /proc/modules (which is not present under chroot). If I use the -v option I can see the raid456, raid1, etc. modules loading.

Quoted 8 lines

I modified menu.lst to make certain that boot=/dev/md/boot, ran grub (thanks, Robin!) successfully.

Problem: on reboot, the I get an error message:

root (hd0,1) (Moshe comment: as expected)
Filesystem type is xfs, partition type 0xfd (Moshe comment: as expected) kernel /boot/vmliuz-etc.-amd64 root=/dev/md/boot ro

---------------^^^^^^

Are you sure that's right? Looks like a typo to me.

Cheers,
Robin

Signature · 4 lines
     ___        
    ( ' }     |       Robin Hill        <[email protected]> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |
#2 lore raw
In reply to Moshe Yudkowsky
Quoted 8 lines · Moshe Yudkowsky

Problem: on reboot, the I get an error message:

root (hd0,1) (Moshe comment: as expected)
Filesystem type is xfs, partition type 0xfd (Moshe comment: as expected) kernel /boot/vmliuz-etc.-amd64 root=/dev/md/boot ro

Error 15: File not found

error 15 is an *grub* error.

grub is known for it's dislike of xfs, so with this whole setup use ext3 rerun grub-install and you should be fine.

#3 lore raw
Quoted 4 lines · maximilian attems

error 15 is an *grub* error.

grub is known for it's dislike of xfs, so with this whole setup use ext3 rerun grub-install and you should be fine.

I should mention that something *did* change. When attempting to use XFS, grub would give me a note about "18 partitions used" (I forget the exact language). This was different than I'd remembered; when I switched back to using reiserfs, grub reports using 19 partitions.

So there's something definitely interesting about XFS and booting.

As an additional note, if I use the grub boot-time commands to edit root to read, e.g., root=/dev/sda2 or root=/dev/sdb2, I get the same Error 15 error message.

It may be that grub is complaining about grub and resiserfs, but I suspect that it has a true complain about the file system and what's on the partitions.

Signature · 4 lines
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
 "If, after hearing my songs, just one human being is inspired to
  say something nasty to a friend, it will all have been worthwhile."
    			-- Tom Lehrer
#4 lore raw
Quoted 7 lines · Moshe Yudkowsky
Quoted 4 lines · maximilian attems

error 15 is an *grub* error.

grub is known for it's dislike of xfs, so with this whole setup use ext3 rerun grub-install and you should be fine.

Quoted 8 lines

I should mention that something *did* change. When attempting to use XFS, grub would give me a note about "18 partitions used" (I forget the exact language). This was different than I'd remembered; when I switched back to using reiserfs, grub reports using 19 partitions.

So there's something definitely interesting about XFS and booting.

As an additional note, if I use the grub boot-time commands to edit root to read, e.g., root=/dev/sda2 or root=/dev/sdb2, I get the same Error 15 error message.

It may be that grub is complaining about grub and resiserfs, but I suspect that it has a true complain about the file system and what's on the partitions.

I think you have two choices, convert /boot to ext2 and be sure you are going down the best-tested code path, or fight and debug, read code, learn grub source, play with the init parts of the boot sequence, and then convert /boot to ext2 anyway. No matter how "better" something else might be, /boot has nothing I use except at boot, I don't need features or performance, I just want it to work.

Unless you are so frustrated you have entered "I am going to make this *work* if it takes forever" mode, I would try the easy solution first. Just my take on it.

Signature · 3 lines
Bill Davidsen <[email protected]>
 "Woe unto the statesman who makes war without a reason that will still
 be valid when the war is over..." Otto von Bismark 
#5 lore raw
Quoted 12 lines · Bill Davidsen
Quoted 11 lines · Moshe Yudkowsky
Quoted 4 lines · maximilian attems

error 15 is an *grub* error.

grub is known for it's dislike of xfs, so with this whole setup use ext3 rerun grub-install and you should be fine.

I should mention that something *did* change. When attempting to use XFS, grub would give me a note about "18 partitions used" (I forget the exact language). This was different than I'd remembered; when I switched back to using reiserfs, grub reports using 19 partitions.

So there's something definitely interesting about XFS and booting.

Quoted 8 lines
Quoted 4 lines

As an additional note, if I use the grub boot-time commands to edit root to read, e.g., root=/dev/sda2 or root=/dev/sdb2, I get the same Error 15 error message.

It may be that grub is complaining about grub and resiserfs, but I suspect that it has a true complain about the file system and what's on the partitions.

I think you have two choices, convert /boot to ext2 and be sure you are going down the best-tested code path, or fight and debug, read code, learn grub source, play with the init parts of the boot sequence, and then convert /boot to ext2 anyway. No matter how "better" something else might be, /boot has nothing I use except at boot, I don't need features or performance, I just want it to work.

Unless you are so frustrated you have entered "I am going to make this *work* if it takes forever" mode, I would try the easy solution first. Just my take on it.

Or you can get lucky and someone will have seen this before and hand you a solution... ;-)

Signature · 3 lines
Bill Davidsen <[email protected]>
 "Woe unto the statesman who makes war without a reason that will still
 be valid when the war is over..." Otto von Bismark 
#6 lore raw
In reply to Moshe Yudkowsky
Quoted 22 lines · Moshe Yudkowsky

I've managed to get myself into a little problem.

Since power hits were taking out the /boot partition, I decided to split /boot out of root. Working from my emergency partition, I copied all files from /root, re-partitioned what had been /root into room for /boot and /root, and then created the drives. This left me with /dev/md/boot, /dev/md/root, and /dev/md/base (everything else).

I modified mdadm.conf on the emergency partition, used update-initramfs to make certain that the new md drives would be recognized, and rebooted. This worked as expected.

I then mounted all the entire new file system on a mount point, copied the mdadm.conf to that point, did a chroot to that point, and did an update-initramfs so that the non-emergency partition would have the updated mdadm.conf. This worked -- but with complaints about missing the file /proc/modules (which is not present under chroot). If I use the -v option I can see the raid456, raid1, etc. modules loading.

I modified menu.lst to make certain that boot=/dev/md/boot, ran grub (thanks, Robin!) successfully.

Quoted 8 lines

Problem: on reboot, the I get an error message:

root (hd0,1) (Moshe comment: as expected)
Filesystem type is xfs, partition type 0xfd (Moshe comment: as expected) kernel /boot/vmliuz-etc.-amd64 root=/dev/md/boot ro

Error 15: File not found

"File not found" at that point would suggest it can't find the kernel file. The path here should be relative to the root of the partition /boot is on, so if your /boot is its own partition then you should either use "kernel /vmlinuz...." or (the more usual solution from what I've seen) make sure there's a symlink:
ln -s . /boot/boot

HTH,
Robin

Signature · 4 lines
     ___        
    ( ' }     |       Robin Hill        <[email protected]> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |
#7 lore raw
Quoted 6 lines · Robin Hill

"File not found" at that point would suggest it can't find the kernel file. The path here should be relative to the root of the partition /boot is on, so if your /boot is its own partition then you should either use "kernel /vmlinuz...." or (the more usual solution from what I've seen) make sure there's a symlink:
ln -s . /boot/boot

Robin,

Thanks very much! ln -s . /boot/boot works to get past this problem.

Now it's failed in a different section and complains that it can't find /sbin/init. I'm at the (initramfs) prompt, which I don't ever recall seeing before. I can't mount /dev/md/root on any mount points ("invalid arguments" even though I'm not supplying any). I've checked /dev/md/root and it does work as expected when I try mounting it while in my emergency partition, and it does contain /sbin/init and the other files and mount points for /var, /boot, /tmp, etc.

So this leads me to the question of why /sbin isn't being seen. /sbin is on the device /dev/md/root, and /etc/fstab specifically mounts it at /.
I would think /boot would look at an internal copy of /etc/fstab. Is
this another side effect of using /boot on its own partition?

Signature · 4 lines
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
 "Blessed are the peacemakers,
  for they shall be mowed down in the crossfire."
   				-- Michael Flynn
#8 lore raw
Quoted 5 lines · I wrote:

Now it's failed in a different section and complains that it can't find /sbin/init. I'm at the (initramfs) prompt, which I don't ever recall seeing before. I can't mount /dev/md/root on any mount points ("invalid arguments" even though I'm not supplying any). I've checked /dev/md/root and it does work as expected when I try mounting it while in my emergency partition, and it does contain /sbin/init and the other files and mount points for /var, /boot, /tmp, etc.

So this leads me to the question of why /sbin isn't being seen. /sbin is on the device /dev/md/root, and /etc/fstab specifically mounts it at /.
I would think /boot would look at an internal copy of /etc/fstab. Is
this another side effect of using /boot on its own partition?

The answer: I managed to make a mistake in the configuration of grub, in
/boot/grub/menu.lst. I'd changed root= from /dev/md/root to
/dev/md/boot -- but I really need to include the *root* location, which does not change, vs. the boot location, which is not relevant.

Signature · 3 lines
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
"The central tenet of Buddhism is not 'Every man for himself.'"
                                        -- Wanda