Mailinglist Archive: opensuse (1420 mails)

< Previous Next >
Re: [opensuse] problem with raid number on 13.1 install
On 2014-01-09 15:29 (GMT+0800) G.O. composed:

ISTR 13.1 RAID1 boot trouble reported on this or opensuse-testing or opensuse-factory list at least once before or after 13.1 was released, making yours at least the second.

I just repaired manually a fresh 64 bit 13.1 RAID1 non-GPT installation that would not boot as far as to display a Grub prompt let alone a Grub menu. 13.1 had been installed to the #1 HD normally a week or so before, but we wiped all but the first two partitions on sda, then cloned them to sdb before beginning a new 13.1 installation. sda1/sdb1 were size clones of 1G to be used for booting. sda2/sdb2 were created as two swaps. Neither of the 4 were intended to become components of RAID devices. Also before starting we created the identical unassembled unformatted pairs sda5/sdb5, sda6/sdb6, sda7/sdb7, sda8/sdb8, sda9/sdb9 & sda10/sdb10. From these 6 pairs we used the 13.1 YaST partitioner to create 6 RAID1 devices, assigning names md0-md5, all to be mounted by volume label. The disappointing result (IIRC, since the machine went to its home after we got done):

md0=md127 (sda5/sdb5) (/ 12G)
md1=md126 (sda6/sdb6) (reserved for future / 12G)
md2=md125 (sda7/sdb7) (reserved for future / 12G)
md3=md124 (sda8/sdb8) (/srv 1G)
md4=md123 (sda9/sdb9) (/home 7##G)
md5=md122 (sda10/sdb10) (/bigfiles 1T)

Installation seemed easy enough, almost until bootloader installation time. Several packages were reported as installation failures, including only glamor that I could remember afterward. We had specified Grub (Legacy) be installed to sda & sdb. YaST reported bootloader installation failed and allowed us to try again. Second try we asked it to be installed to sda1 to be mounted as /boot. That produced no error messages, but the system nevertheless failed to "boot" a second time. As I had neglected to disable kexec reboot, the first system "boot" worked, from which we proceeded to do 'zypper ref; zypper in glamor; zypper up' before allowing the GUI to start.

This configuration required sda1 have the active flag set, but we found it set to the swap partition on sda2, hence the machine hung (with no error message) when the BIOS gave control to the MBR. Once fixed, it booted right up from Grub's menu.lst on sda1.

One possible fly in the ointment was that it was necessary to disable AHCI to get the machine to boot the DVD past loading 11% of the installation system. Whether there was any actual impact from doing that and afterward switching BIOS back from legacy to AHCI we weren't able to figure out. IIRC, the chipset was ICH9R with BIOS RAID disabled.

First boot actually refused to quit. I don't remember whether we tried shutdown or reboot, but whichever we tried never happened. After waiting more than 5 minutes after last new shutting down message appeared, we pulled the plug.

On restart, mdstat looked pitiful. The 1T md5 would resync (with up to 20 hour ETA for completion) on every subsequent boot, with the md0 / partition running on just sda5. I tried rebooting with the 1T md5 removed from fstab, but that just left it with md0 degraded and md4 (/home) resyncing with several hour ETA for completion. I removed md4 from fstab and rebooted again. This left nothing resyncing, with / still degraded. I failed, removed, then added sdb5 to md0. After resyncing finished, we rebooted with md4 & md5 restored to fstab to find all in mdstat looking good, nothing resyncing or degraded, but also no /etc/mdadm.conf.
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata ***
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >