Init unable to mount root if it on lvm device, which is over mdadm

Bug #1269688 reported by Vladimir Skubriev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
New
Undecided
Unassigned

Bug Description

This bug appears follows:

Sometimes on linux-image-3.2.0-58-generic.
Always on linux-image-3.5.0-41-generic
Always on linux-image-3.8.0-35-generic

I tried to interrupt init by inserting the following code:

/bin/sh

in '/usr/share/initramfs-tools/scripts/local'

        # FIXME This has no error checking
        # Mount root
        mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
        mountroot_status="$?"
        /bin/sh #I added this code here
        if [ "$LOOP" ]; then
                if [ "$mountroot_status" != 0 ]; then
                        if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then

and of course update initramfs after this.

dmsetup is correctly show logical volumes, by command `dmsetup ls`

sysraid-winxp (252, 5)
sysraid-lxc_redmine_aptarchives (252, 12)
sysraid-zeus--datafs (252, 11)
sysraid-lxc_redmine--dev_aptarchives (252, 14)
sysraid-lxc_redmine_datafs (252, 10)
sysraid-lxc_redmine--dev_datafs (252, 13)
sysraid-zeus--home (252, 8)
sysraid-zeus--tmp (252, 2)
sysraid-squiddebproxy (252, 6)
sysraid-zeus--swap (252, 1)
sysraid-zeus--rootfs (252, 0)
sysraid-backups (252, 7)
sysraid-lxc_redmine_rootfs (252, 9)
sysraid-zeus--var--log (252, 3)
sysraid-zeus--iso--images (252, 4)
sysraid-lxc_poseidon (252, 15)
sysraid-lxc_pdc (252, 16)

But manual mount of root to /root of initram filesystem is break down by error that fs driver cannot find superblock.

I tried to mount all other existing partitions from volume group sysraid, but they also could not be mounted because of `bad superblock`

Then I tried to mount existing (/boot) partition from mdadm device (md0) and it was succesful.

After that i tried to refresh logical volume's by a command `/sbin/lvm vgchange --refresh` and then mount root succefull.

I decided to improve init script by following code in mountroot function in file
`/usr/share/initramfs-tools/scripts/local`:

# Refresh volume group's if prev attempt failed
#
dmsetup -v info $ROOT | grep -q 'UUID: LVM'
        if [ "$?" != "1" ] && [ "$mountroot_status" != 0 ] && [ -x /sbin/lvm ]
        then
                /sbin/lvm vgchange --refresh && mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
        fi

It must be inserted after:
...
        # FIXME This has no error checking
        # Mount root
        mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
        mountroot_status="$?"

       #INSERT CODE HERE

        if [ "$LOOP" ]; then
                if [ "$mountroot_status" != 0 ]; then
...

What do you think about this hook?

Can I rely on the adoption of this patch in upstream?
---
ApportVersion: 2.0.1-0ubuntu17.6
Architecture: amd64
DistroRelease: Ubuntu 12.04
InstallationMedia: Ubuntu-Server 12.04.2 LTS "Precise Pangolin" - Release amd64 (20130214)
MarkForUpload: True
Package: initramfs-tools 0.99ubuntu13.4
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.8.0-35.50~precise1-generic 3.8.13.13
Tags: precise
Uname: Linux 3.8.0-35-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

Revision history for this message
Vladimir Skubriev (v-skubriev) wrote : Dependencies.txt

apport information

tags: added: apport-collected precise
description: updated
Revision history for this message
Vladimir Skubriev (v-skubriev) wrote :
description: updated
Revision history for this message
Vladimir Skubriev (v-skubriev) wrote :
Revision history for this message
Vladimir Skubriev (v-skubriev) wrote :
Revision history for this message
Vladimir Skubriev (v-skubriev) wrote :

Interesting Situation!

I have a server with 3 disks in mdadm raid 1.

Third disk only for backup purposes only.

I shutdown server once a week and removing third disk to put in a safe place.

In any case we need to test boot from this third disk, for future confidence.

But it doesn't start with latest 3.5 kernel.

I upgrade kernel to 3.8, made a copy.

Tried to start system with 3.8 kernel but it did not help too.

Next I tried to start system on multiple computers but it did not help too.

3.2 Kernel is working )

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.