Dumb thought: I don't remember how, other than from a grub menu, but I'm
pretty sure there's a way to default boot into a grub shell. Once there,
you can see, using file completion, the drives, and where your initrd is.
mark
On Wed, Aug 5, 2015 at 1:59 PM, <m.roth at 5-cent.us> wrote:> Dumb thought: I don't remember how, other than from a grub menu, but I'm > pretty sure there's a way to default boot into a grub shell. Once there, > you can see, using file completion, the drives, and where your initrd is.It's definitely not an initrd problem. a.) the failure happens before the GRUB menu appears so it hasn't even gone looking for an initrd, b.) the initrd is technically on an array not a device, and as long as the array is sync'd on both devices, it's the same, and since it works on one device, it should work on the other and c.) it's v0.9 mdadm metadata which is kernel autodetect so the initrd doesn't do the assembly. I think once the partition stuff is fixed, and synced, then it will be more reliable to do this because GRUB is after all being pointed to member devices, not the array. There might be more luck using this command at command prompt: grub-install --recheck /dev/hdg See if that repopulates the device.map correctly. It should use /boot (/dev/md0) automatically for stage2. -- Chris Murphy
On 8/5/2015 3:59 PM, m.roth at 5-cent.us wrote:> Dumb thought: I don't remember how, other than from a grub menu, but I'm > pretty sure there's a way to default boot into a grub shell. Once there, > you can see, using file completion, the drives, and where your initrd is.Good thought. I went into the grub.conf, commented out the "hiddenmenu" option and increased the timeout to 10 seconds. This works if I boot from the original drive, but it doesn't help with the new drive. It's not getting that far. -- Bowie
On 8/5/2015 4:40 PM, Chris Murphy wrote:> On Wed, Aug 5, 2015 at 1:59 PM, <m.roth at 5-cent.us> wrote: >> Dumb thought: I don't remember how, other than from a grub menu, but I'm >> pretty sure there's a way to default boot into a grub shell. Once there, >> you can see, using file completion, the drives, and where your initrd is. > It's definitely not an initrd problem. a.) the failure happens before > the GRUB menu appears so it hasn't even gone looking for an initrd, > b.) the initrd is technically on an array not a device, and as long as > the array is sync'd on both devices, it's the same, and since it works > on one device, it should work on the other and c.) it's v0.9 mdadm > metadata which is kernel autodetect so the initrd doesn't do the > assembly. > > I think once the partition stuff is fixed, and synced, then it will be > more reliable to do this because GRUB is after all being pointed to > member devices, not the array. > > There might be more luck using this command at command prompt: > > grub-install --recheck /dev/hdg > > See if that repopulates the device.map correctly. It should use /boot > (/dev/md0) automatically for stage2.Can't risk killing the system at the moment. I'll give it a try tomorrow. However, I do note that the man page for grub-install has a comment about --recheck stating "This option is unreliable and its use is strongly discouraged." -- Bowie
Bowie Bailey wrote:> On 8/5/2015 3:59 PM, m.roth at 5-cent.us wrote: >> Dumb thought: I don't remember how, other than from a grub menu, but I'm >> pretty sure there's a way to default boot into a grub shell. Once there, >> you can see, using file completion, the drives, and where your initrd >> is. > > Good thought. I went into the grub.conf, commented out the "hiddenmenu" > option and increased the timeout to 10 seconds. This works if I boot > from the original drive, but it doesn't help with the new drive. It's > not getting that far. >I *think* what you may have to do is: 1. use mdadm to remove the new drive from the RAID. 2. use it to create a new md drive with *just* the new drive. 3. copy from the remaining old RAID drive to the new. 4. remove the old RAID drive, then put in a new large drive. 5. add the new drive to the new array. mark