Boot mistakes eSata drive for a RAID drive

ToddAndMargo · 11-22-2015, 10:38 PM

Hi All,

$ cat /etc/redhat-release
Scientific Linux release 7.1 (Nitrogen)

$ uname -r
3.10.0-229.20.1.el7.x86_64

My system:
Supermicro X8SAX motherboard, Bios 2.0
Raid controller LSI 9750-4i, Bios 5.08.00.008
eSata drive 2.0 GB in removable sleeve (two drives in rotation for backup)

When I build a custom Linux server for my customers, I will install removable eSata drives for them to place in rotation for backup (anywhere from 2 to 14 drives). My Office system uses two eSata drives in rotation. All drives are typically LUKS encrypted.

The eSata drive is not in the fstab purposefully. (If you put the backup drive in fstab and boot without the drive in the sleeve, the system will lock up after prompting for the RAID password.) I mount these eSata drives at backup time on /lin-bak; I label these drives "lin-bak". They are dismounted after the backup.

Problem: if the eSata drive is in the system when the system boots up, the system will ask for the RAID array's password, then run for a while and ask for the eSata drive's password. Problem: the system thinks the eSata drive is a partition on the RAID controller and seizes the system after entering the password (no keyboard or mouse and no <ctrl><alt><f2>).

The prompt states: Please enter passphrase for disk 9750-4I_DISK (lin-bak) on /lin-bak

I reported this bug over on:
https://bugzilla.redhat.com/show_bug.cgi?id=1257018

While I wait for Red Hat to fix this, is there some work around? Something I can add to boot.cfg?

Many thanks,
-T

maples · 11-23-2015, 07:46 AM

It sounds like you have the filesystem labels for all of these drives as "lin-bak". If that's correct, you can add an entry to fstab for it. To prevent it from failing when the drive isn't there, add the "nofail" option. To ignore it at boot, add "noauto".

Code:

LABEL="lin-bak"     /lin-bak/      auto     defaults,nofail,noauto     0     1

I'm not sure why it detects it as part of the RAID, though. Is the drive encrypted?

suicidaleggroll · 11-23-2015, 11:58 AM

As maples said, you should put it in fstab and add the noauto option. This lets the system know what the drive is and what to do with it, and also tells it to purposely skip it on boot so it shouldn't prompt you.

I do not believe nofail is needed when noauto is there. nofail tells the system to continue booting if the mount fails, but with noauto it won't even attempt to mount it in the first place.

ToddAndMargo · 11-25-2015, 06:03 PM

Quote:

Originally Posted by maples

It sounds like you have the filesystem labels for all of these drives as "lin-bak". If that's correct, you can add an entry to fstab for it. To prevent it from failing when the drive isn't there, add the "nofail" option. To ignore it at boot, add "noauto".

Code:

LABEL="lin-bak"     /lin-bak/      auto     defaults,nofail,noauto     0     1

I'm not sure why it detects it as part of the RAID, though. Is the drive encrypted?

Both drives are encrypted. "noauto" does not work.

The issue is that the RAID drive should be mounted as /dev/sda (it is the boot drive) and the (non-bootable) eSata drive should be mounted at /dev/sdb. The boot drive should ALWAYS be mounted as /dev/sda, NEVER as /dev/sdb.

What actually happens if the eSata drive is inserted at boot time is that the system boots off the RAID drive but when it gets to Linux, mounts the (boot in progress) RAID drive as /dev/sdb and mounts the eSata drive as /dev/sda. Then Linux lays an eggs when it can not find what it is expecting on /dev/sda as it is reading the wrong drive.

The tip off is the error message:

Please enter passphrase for disk 9750-4I_DISK (lin-bak) on /lin-bak

"9750-4I" is the part number for RAID drive. "(lin-bak) on /lin-bak" are for the eSata drive.

suicidaleggroll · 11-25-2015, 06:07 PM

Why does it matter if sda and sdb swap? You should not be using those labels in fstab anyway.

syg00 · 11-25-2015, 07:16 PM

Not fstab - that's way too late. This sounds like a udev issue in the dracut hooks. And I guess SL 7 uses systemd as well.
Open a bugzilla - that way you may get a work-around if not a real fix.

ToddAndMargo · 11-25-2015, 07:33 PM

Quote:

Originally Posted by suicidaleggroll

Why does it matter if sda and sdb swap? You should not be using those labels in fstab anyway.

It shouldn't, but it does. This is a grub.cfg issue anyway, not an fstab issue. The boot drive is mounted by UUID (which are correct for the partitions on the boot drive). When the boot drives UUID is mapped to a /dev, it is mapping it to /dev/sdb, not /dev/sda as it should. ("lin-bak" is not even bootable.) Problem is that the rest of the boot up thinks that the boot drive is sda, which is what it is suppose to be.

And yes, I have tried mounting "lin-bak" by uuid in fstab. It does work, as long as it is not in the sleeve when I boot.

Is there any way to force grub.cfg to mount the boot drive as sda?

Thank you for helping me with this,
-T

Code:

menuentry 'Scientific Linux (3.10.0-229.20.1.el7.x86_64) 7.1 (Nitrogen)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-229.el7.x86_64-advanced-105955c6-f1b1-4768-824c-9a997a487148' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod xfs
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  35f354aa-d431-4bfc-a83f-0b388900fee7
	else
	  search --no-floppy --fs-uuid --set=root 35f354aa-d431-4bfc-a83f-0b388900fee7
	fi
	linux16 /vmlinuz-3.10.0-229.20.1.el7.x86_64 root=/dev/mapper/luks-4dc5d930-f4c3-42de-80c5-274f70b944a1 ro crashkernel=auto rd.luks.uuid=luks-4dc5d930-f4c3-42de-80c5-274f70b944a1 rd.luks.uuid=luks-b8ecc95b-85fa-4111-9ef8-78a8b4934b79 rhgb quiet LANG=en_US.UTF-8 systemd.debug
	initrd16 /initramfs-3.10.0-229.20.1.el7.x86_64.img
}

ToddAndMargo · 12-11-2015, 12:51 AM

Here is an interesting clue:

I booted with my eSata drive removed. Just after I entered the boot drive's pass phrase (three partition are LUKS) I inserted my Kanguru SS3 unencrypted NTFS 32 GB flash drive. I got prompted for SS3's pass phrase. (Entering it still crashed the boot.) Boot mistook my flash drive for one of the partition on my boot drive.

I also means I can not switch to a USB3 drives for backup as a workaround