On Tue, 18 Jan 2011 17:31:29 -0700 Bob Proulx <b...@proulx.com> wrote:
> Jack Schneider wrote: > > It booted to the correct grub menu then to Busy Box. I am thinking > > it goes to BB because it can't find /var and or /usr on the > > md1/sda5 LVM partition. > > Very likely. > > > I checked /proc/mdstat and lo & behold there was md1:active > > with correct partitions and md0: active also correct partitions... > > That is good news to hear. Becuase it should mean that all of your > data is okay on those disks. That is always a comfort to know. > > > So here I sit with a root prompt from Busy Box.... I checked mdadm > > --examine for all known partitions and mdadm --detail /mdo & /md1 > > and all seems normal and correct. No Errors. > > Yeah! :-) > > > Both /etc/fstab and /etc/mtab show entries for /dev/md126.. > > What the ... ? > > That does seem strange. Could the tool you used previously have > edited that file? > > You said you were using /dev/md1 as an lvm volume for /var, /home, > swap and other. As I read this it means you would only have /dev/md0 > for /boot in your /etc/fstab. Right? Something like this from my > system: > > /dev/md0 /boot ext2 defaults 0 2 > > You /var, /home and swap would use the lvm, right? So from my system > I have the following: > > /dev/mapper/v1-var /var ext3 defaults 0 2 > /dev/mapper/v1-home /home ext3 defaults 0 2 > > Those don't mention /dev/md1 (which showed up for you as /dev/md126) > at all. They would only show up in the volume group display. > > If you are seeing /dev/md126 in /etc/fstab then it is conflicting > information. You will have to sort out the information conflict. Do > you really have LVM in there? > > Certainly if the "/dev/md0 /boot" boot line is incorrect then you > should correct it. Edit the file and fix it. If your filesystem is > mounted read-only at that point you will need to remount it > read-write. > > mount -n -o remount,rw / > > Bob Hi, Bob Back at it...8-( I think I found a significant glitch.. I appears that mdadm is confused. I think it happened when I created the /dev/md2 array from the new disks. It looks like the metadata 1.2 vs 0.90 configs is the culprit... Here's the output of: mdadm --detail --scan: ARRAY /dev/md0 metadata=0.90 UUID=e45b34d8:50614884:1f1d6a6a:d9c6914c ARRAY /dev/md1 metadata=0.90 UUID=c06c0ea6:5780b170:ea2fd86a:09558bd1 Here's the output of /etc/mdadm/mdadm.conf: # mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=f6de5584:d9dbce39:090f16ff:f795e54c name=hetzner:0 ARRAY /dev/md/1 metadata=1.2 UUID=0e065fee:15dea43e:f4ed7183:70d519bd name=hetzner:1 ARRAY /dev/md/2 metadata=1.2 UUID=ce4dd5a8:d8c2fdf4:4612713e:06047473 name=hetzner:2 # This file was auto-generated on Mon, 10 Jan 2011 00:32:59 +0000 # by mkconf 3.1.4-1+8efb9d1 Given that the metadata from 0.90 & 1.2 cannot be on each md0 and md1 at the same time. Although they are on different places on the disks IIRC. Something needs to change... I am thinking of an mdadm.conf edit. But there maybe an alternative tool or approach... ???? This was obtained using my Debian-live amd64 rescue disk. TIA 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/20110121195115.3e62f...@torrid.volunteerwireless.net
