Subject: [alpine-user] alpinelinux 3.3.1 can not boot, when root is on lvm, which is on raid1

From: Dieter Bloms <[email-masked]>
Date: Fri, 8 Jan 2016 21:56:34 +0100

Hi,

I installed alpinelinux 3.3.1 with manual disc mode.
My root is a logical volume in a volume group on a raid1 system.
During boot the raid is activated, but the logical volumes are not.
So I have to activate it manually and mount it to /sysroot.
After that I can boot into alpinelinux.

Is it a known problem, that lvm on a raid is not activated in the
initramfs during boot ?

My /boot is on a usbstick and sdc is a backup disc.

Here some data from my setup:

--snip--
docker:~# lsscsi 
[0:0:0:0]    disk    ATA      ST4000VN000-1H41 SC44  /dev/sda 
[1:0:0:0]    disk    ATA      ST4000VN000-1H41 SC43  /dev/sdb 
[3:0:0:0]    disk    ATA      Hitachi HDS72202 A3MA  /dev/sdc 
[6:0:0:0]    disk    Generic  Flash Disk       8.07  /dev/sdd 

docker:~# cat /proc/mdstat 
Personalities : [raid1] 
md1 : active raid1 sdb1[2] sda1[0]
      3906886464 blocks super 1.2 [2/2] [UU]
      bitmap: 2/30 pages [8KB], 65536KB chunk

unused devices: <none>

docker:~# pvs
  PV         VG     Fmt  Attr PSize PFree  
  /dev/md1   space  lvm2 a--  3.64t 293.89g
  /dev/sdc1  backup lvm2 a--  1.82t      0 

docker:~# lvdisplay /dev/space/alpine
  --- Logical volume ---
  LV Path                /dev/space/alpine
  LV Name                alpine
  VG Name                space
  LV UUID                RU7k0a-NTdS-MUiG-tI1K-79Ub-66OQ-HwGQ0T
  LV Write Access        read/write
  LV Creation host, time docker, 2015-12-28 15:37:56 +0100
  LV Status              available
  # open                 1
  LV Size                2.00 GiB
  Current LE             512
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:16

docker:~# blkid /dev/space/alpine
/dev/space/alpine: UUID="1158e9c8-5e60-4318-99ef-67b617ef0f17" TYPE="xfs"

docker:~# cat /proc/cmdline 
BOOT_IMAGE=vmlinuz-grsec root=UUID=1158e9c8-5e60-4318-99ef-67b617ef0f17 modules=loop,sd-mod,usb-storage,raid,lvm,xfs quiet initrd=initramfs-grsec

docker:~# df
Filesystem                     1K-blocks       Used Available Use% Mounted on
devtmpfs                           10240          0     10240   0% /dev
shm                              4059628          0   4059628   0% /dev/shm
/dev/space/alpine                2086912     603096   1483816  29% /
tmpfs                             811928        328    811600   1% /run
cgroup_root                        10240          0     10240   0% /sys/fs/cgroup
/dev/sdd2                         999320      26288    904220   3% /boot

docker:~# cat /etc/mkinitfs/mkinitfs.conf
features="ata base ide scsi usb raid lvm xfs"

Can anybody see where I did a mistake ?

-- 
Regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 11 Jan 2016 08:59:19 +0100

On Fri, 8 Jan 2016 21:56:34 +0100

> Is it a known problem, that lvm on a raid is not activated in the

It is a known problem. I have the same on my workstation. Sometimes it
works and sometimes it fails so I think it is a timing issue.

Today I looked at it a bit and it seems that /sbin/lvm is never
executed from initramfs. It means that the nlplug-findfs times out
before it gets the hotplug event for mdadm devices.

I think we have a few options for fixing it:

1) when mdadm is run, make it wait til all mdadm devices are run before
   exit. I don't know if this is possible, but nlplug-finds will not
   exit til all forked children has exited. This means that mdadm
   executes, initalizes the raid devices, and exits long before the
   kernel generates the uevent for the raid device. If we could make
   mdadm not exit til the uevent is generated, then we should be fine.
   I don't know if there is any option for that. (probably not)

2) When mdadm is started, increase the default nlplug-findfs timeout
   (250ms) so kernel gets enough time to generate the raid device
   uevent before nlplug-findfs times out. We could increase it with 1
   sec for example? The problem is that I don't know what is a good
   value since it may depend on the hardware. It will also make boot
   slower when you boot to tmpfs root but does not have any apkovl. I
   doubt there will ever exist any such setup so the slowdown here is
   acceptable.

3) When boot option `root=...` is specified, increase the default
   nlplug-findfs timeout (250ms) to something significantly longer.
   Maybe 2 seconds? 5 seconds? If we actually timeout, it means that we
   will failed to find the rootfs and the boot will fail. So it makes
   sense to increase the timeout for making it not give up that fast.

> Can anybody see where I did a mistake ?

You did not any mistake. This is a bug in nlplug-findfs.

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 11 Jan 2016 11:02:33 +0100

On Mon, 11 Jan 2016 08:59:19 +0100

>    sense to increase the timeout for making it not give up that fast.

I tested this. it didnt help. must be mdadm that mdadm delete/recreate
the /dev/md* device node so that when the uevent trigger happens,
the /dev/md* device node temporarily does not exist.

I think we might need block event handling while mdadm executes. We do
the same for cryptsetup.

-nc

---

---

From: Dieter Bloms <[email-masked]>
Date: Thu, 21 Jan 2016 16:31:54 +0100

Hello Natanael,

> I think we might need block event handling while mdadm executes. We do

did you have any success on this topic ?

-- 
Regards

  Dieter

---