On Fri, 14 Jan 2011 05:25:45 -0700 Bob Proulx <b...@proulx.com> wrote:
> Jack Schneider wrote: > > I have a raid1 based W/S running Debian Squeeze uptodate. (was > > until ~7 days ago) There are 4 drives, 2 of which had never been > > used or formatted. I configured a new array using Disk Utility from > > a live Ubuntu CD. That's where I screwed up... The end result was > > the names of the arrays were changed on the working 2 drives. > > IE: /dev/md0 to /dev/126 and /dev/md1 became md127. > > Something else must have happened too. Because normally just adding > arrays will not rename the existing arrays. I am not familiar with > the "Disk Utility" that you mention. > Hi, Bob Thanks for your encouraging advice... As I mentioned in a prior post,Grub was leaving me at a Grub rescue>prompt. I followed this procedure: http://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-shell.html#GRUB-only-offers-a-rescue-shell Booting now leaves me at a busy box: However the Grub menu is correct. With the correct kernels. So it appears that grub is now finding the root/boot partitions and files. > Next time instead you might just use mdadm directly. It really is > quite easy to create new arrays using it. Here is an example that > will create a new device /dev/md9 mirrored from two other devices > /dev/sdy5 and /dev/sdz5. > > mdadm --create /dev/md9 --level=mirror > --raid-devices=2 /dev/sdy5 /dev/sdz5 > > > Strangely the md2 array which I setup on the added drives remains as > > /dev/md2. My root partition is/was on /dev/md0. The result is that > > Grub2 fails to boot the / array. > > You may have to boot a rescue cd. I recommend booting the Debian > install disk in rescue mode. Then you can inspect and fix the > problem. But as of yet you haven't said enough to let us know what > the problem might be yet. > > > I have tried three REINSTALLING GRUB procedures from Sysresccd > > online docs and many others GNU.org, Ubuntu etc. > > This isn't encouraging. I can tell that you are grasping at straws. > You have my sympathy. But unfortunately that doesn't help diagnose > the problem. Remain calm. And repeat exactly the problem that you > are seeing and the steps you have taken to correct it. > > > The errors occur when I try to mount the partition with the /boot > > directory. 'Complains about file system type 'linux_raid_member' > > I haven't seen that error before. Maybe someone else will recognize > it. > > I don't understand why you would get an error mounting /boot that > would prevent the system from coming online. Because by the time the > system has booted enough to mount /boot it has already practically > booted completely. The system doesn't actually need /boot mounted to > boot. Grub reads the files from /boot and sets things in motion and > then /etc/fstab instructs the system to mount /boot. > > Usually when the root device cannot be assembled the error I see is > that the system is "Waiting for root filesystem" and can eventually > get to a recovery shell prompt. > > > This machine has worked for 3 years flawlessly.. Can anyone help > > with this? Or point me to a place or link to get this fixed. Google > > doesn't help... I can't find a article/posting where it ended > > successfully. I have considered a full reinstall after Squeeze goes > > stable, since this O/S is a crufty upgrade from sarge over time. But > > useless now.. > > The partitions for raid volumes should be 'autodetect' 0xFD. This > will enable mdadm to assemble then into raid at boot time. > > You can inspect the raid partitions with --detail and --examine. > > mdadm --examine /dev/sda1 > mdadm --detail /dev/md0 > mdadm --examine /dev/sda1 & /dev/sda2 gives I think a clean result I have posted the output at : http://pastebin.com/pHpKjgK3 mdadm --detail /dev/md0 --> gives mdadm: md device /dev/md0 does not appear to be active. There is no /proc/mdstat data output. > That will list information about the devices. Replace with your own > series of devices. > > I would boot a rescue image and then inspect the current configuration > using the above commands. Hopefully that will show something wrong > that can be fixed after you know what it is. > > A couple of other hints: If you are not booting a rescue system but > using something like a live boot then you may need to load the kernel > modules manually. You may need to load the dm_mod and md_mod modules. > > modprobe md_mod > > You might get useful information from looking at the /proc/mdstat > status. > > cat /proc/mdstat > > There is a configuration file /etc/mdadm/mdadm.conf that holds the > UUIDs of the configured devices. If those have become corrupted then > mdadm won't be able to assemble the /dev/md* devices. Check that file > and compare against what you see with the --detail output. > > The initrd contains a copy of the mdadm.conf file with the components > needed to assemble the root filesystem. If the UUIDs change over what > is recorded in the initrd then the initrd will need to be rebuilt. To > do that make sure that the /etc/mdadm/mdadm.conf file is correct and > then reconfigure the kernel with dpkg-reconfigure. > > dpkg-reconfigure linux-image-2.6.32-5-i686 > > Good luck! > > Bob So it appears that I must rebuild my arrays. I think I can munge thru the mdadm man pages or Debian Reference to get the tasks. Thanks for the help.. You need all the help you can get at 76yrs.. Jack -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110115162908.1d25f...@torrid.volunteerwireless.net
