Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
Moshe Yudkowsky wrote: maximilian attems wrote: 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. 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. -- 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 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
Bill Davidsen wrote: Moshe Yudkowsky wrote: maximilian attems wrote: 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. 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... ;-) -- 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 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
On Mon, Feb 04, 2008 at 02:59:44PM -0600, Moshe Yudkowsky wrote: 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. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
On Mon Feb 04, 2008 at 02:59:44PM -0600, Moshe Yudkowsky wrote: 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 ---^^ Are you sure that's right? Looks like a typo to me. Cheers, Robin -- ___ ( ' } | Robin Hill[EMAIL PROTECTED] | / / ) | Little Jim says | // !! | He fallen in de water !! | pgpLybDJ7EGiw.pgp Description: PGP signature
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
Robin Hill wrote: 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? -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe Blessed are the peacemakers, for they shall be mowed down in the crossfire. -- Michael Flynn - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
maximilian attems wrote: 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. -- 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 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
On Mon Feb 04, 2008 at 02:59:44PM -0600, Moshe Yudkowsky wrote: 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 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 -- ___ ( ' } | Robin Hill[EMAIL PROTECTED] | / / ) | Little Jim says | // !! | He fallen in de water !! | pgpSsIYkFb4DG.pgp Description: PGP signature
using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
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! -- 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) - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using update-initramfs: how to get new mdadm.conf into the /boot? Or is it XFS?
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. -- Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe The central tenet of Buddhism is not 'Every man for himself.' -- Wanda - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
