Do not mount LV by UUID from fstab.

I should not reference LV in fstab by UUID, because if i have snapshot of this
LV, it is unknown which one (origin or snapshot) will be mounted.

The problem is in non-unique UUID. Indeed, LV UUID is unique, but about LV
UUID knows (and uses) only lvm itself. In fstab corresponding device
referenced by _filesystem's_ UUID. LV UUID is actually device's ID (like, e.g.
serial number of hdd), not filesystem's one. And since snapshot has exactly
the same fs as origin (perhaps, in some earlier state), fs on both snapshot
and origin will have exactly the _same_ UUID. Hence, i end up with several
devices holding fs with exactly the same UUID.  I don't know for sure, which
one will be selected, perhaps, the first one found.

Example.

Let's check origin's and snapshot's LV UUID:

    # lvs -o +lv_uuid | sed -ne'1p; /usr/p;'
      LV                                 VG            Attr   LSize   Origin  Snap%  Move Log Copy%  Convert LV UUID                               
      recovery_point_usr                 shilvana_sys  sri-a-   1.12g usr       0.35                         sq3rFq-hXXL-y385-4hxe-Ha9G-i9oJ-WxM2qQ
      usr                                shilvana_sys  owi-ao  10.00g                                        JV1HvR-odwN-lXif-m4oS-UyG0-A9qP-amXPyk

and they're different. Now let's check fs's UUID:

    # tune2fs -l /dev/shilvana_sys/recovery_point_usr  | grep UUID
    Filesystem UUID:          3fe2838e-ea56-44d8-8dc3-731c84532a50
    # tune2fs -l /dev/shilvana_sys/usr  | grep UUID
    Filesystem UUID:          3fe2838e-ea56-44d8-8dc3-731c84532a50

and they're the same. Now i can ensure, that `blkid` reports fs UUID:

    # blkid -s UUID  /dev/shilvana_sys/recovery_point_usr  
    /dev/shilvana_sys/recovery_point_usr: UUID="3fe2838e-ea56-44d8-8dc3-731c84532a50" 
    # blkid -s UUID  /dev/shilvana_sys/usr  
    /dev/shilvana_sys/usr: UUID="3fe2838e-ea56-44d8-8dc3-731c84532a50" 

and try to mount using all these UUIDs:

    # grep fstab  -e'zip'
    UUID=sq3rFq-hXXL-y385-4hxe-Ha9G-i9oJ-WxM2qQ /mnt/zip ext4 defaults    0 0
    # mount  /mnt/zip/
    mount: special device UUID=sq3rFq-hXXL-y385-4hxe-Ha9G-i9oJ-WxM2qQ does not exist

    # grep fstab  -e'zip'
    UUID=JV1HvR-odwN-lXif-m4oS-UyG0-A9qP-amXPyk /mnt/zip ext4 defaults    0 0
    root@shilvana:/etc# mount  /mnt/zip/
    mount: special device UUID=JV1HvR-odwN-lXif-m4oS-UyG0-A9qP-amXPyk does not exist

    # grep fstab  -e'zip'
    UUID=3fe2838e-ea56-44d8-8dc3-731c84532a50 /mnt/zip ext4 defaults    0 0
    root@shilvana:/etc# mount  /mnt/zip/
    root@shilvana:/etc# grep /proc/mounts -e'zip'
    /dev/mapper/shilvana_sys-usr /mnt/zip ext4 rw,relatime,barrier=1,journal_checksum,data=ordered 0 0

only the last one mount (with fs UUID) succeeded.

Update 8.05.2014.

This also will cause problems with boot. Particularly, if i consider default
menuentry generated by `update-grub` (from grub2=1.99-27+deb7u2 on debian
wheezy), there is two places, where boot may break:

menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-686-pae' --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod lvm
        insmod part_msdos
        insmod part_msdos
        insmod ext2
        set root='(shilvana_sys-wheezy_root)'
        search --no-floppy --fs-uuid --set=root 1522d319-2508-40aa-815f-e07dacd7abcc
        echo    'Loading Linux 3.2.0-4-686-pae ...'
        linux   /boot/vmlinuz-3.2.0-4-686-pae root=/dev/mapper/shilvana_sys-wheezy_root ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-3.2.0-4-686-pae
}

First, is searching for root: though, first value
`root='(shilvana_sys-wheezy_root)'` is correct, it will be overwritten then by
search by fs uuid, which may result in wrong root. And, grub may load not that
kernel, which i expect.

Second - in 'root=' kernel parameter. In the example above, it uses LV path,
though.

There is variable 'GRUB_DISABLE_LINUX_UUID' in default/grub, which, as comment
explains, should control whether to pass 'root=UUID=xx' to linux kernel. But,
it seems, that with root in LVM update-grub always sets 'root=' to path
(regardless of GRUB_DISABLE_LINUX_UUID value, thus fixing second point). But i
don't know any reliable way to fix first.