Bug#616689: The bug now reaches the "separate /usr on lvm" case

[Raphael Plasson <rplasson@gmail.com>]

Hello,

This bug is now also a problem with the new version of initramfs-tools
in the case of a separate /usr partition on a lvm, as /usr is also being
mounting early in the boot sequence by initramfs (this problem wasn't
hitting me beforehand as I did put a small root partition on a non-lvm
partition for "avoiding such problems" ... :/)

Actually, the solutions proposed there were not working for me, I still
had to "vgchange -ay" on the initramfs prompt. My working solution ended
up to add the scsi_mod.scan=sync option to be passed by grub, and forced
the lvm scanning by adding to
/usr/share/initramfs-tools/scripts/local-top/lvm2 the lines:
  lvm pvscan
  lvm vgscan
  lvm vgchange -ay
before the "activate_vg" lines. Note that I added the "lvm vgchange -ay"
line on top of the other one, as suggested previously.

It seemed that the volume /groups/ were correctly scanned and identified
during the initial boot-up, as I could read the following lines:
  PV /dev/sdb1   VG lv_data     lvm2 [1.82 TiB / 0    free]
  PV /dev/sda3   VG lv_system   lvm2 [235.68 GiB / 0    free]
  Total: 2 [2.05 TiB] / in use: 2 [2.05 TiB] / in no VG: 0 [0   ]
  Reading all physical volumes.  This may take a while...
  Found volume group "lv_data" using metadata type lvm2
  Found volume group "lv_system" using metadata type lvm2
But the lvm /volumes/ were not activated, as initramfs was waiting for
the /usr partition, until complaing and falling back to the prompt were
the vgchange command had to be performed... so that I ended up adding
the vgchange command in a "why not" mood, that ended up to work for me.

I do not know if this is a solution or a dirty hack, but at least it is
working for me. I don't know neither if /all/ the modifications are
indeed necessary, as I added them incrementally until it worked.

I hope that I could help...

-- Raphaël