Bug 720684 - Booting with snapshot of / requires non user-friendly config
Booting with snapshot of / requires non user-friendly config
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dracut (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Harald Hoyer
Release Test Team
Depends On:
  Show dependency treegraph
Reported: 2011-07-12 09:32 EDT by David Kovalsky
Modified: 2014-03-31 19:46 EDT (History)
14 users (show)

See Also:
Fixed In Version: dracut-004-322.el6
Doc Type: Bug Fix
Doc Text:
Cause: dracut does not call "lvchange" with the "--yes" option. Consequence: Booting an LVM snapshot required adding rd_LVM_LV of the original volume, which is counter intuitive. Fix: dracut calls "lvchange" with the "--yes" option. Result: Booting an LVM snapshot does not require adding rd_LVM_LV of the original volume anymore.
Story Points: ---
Clone Of:
Last Closed: 2013-11-21 16:53:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Kovalsky 2011-07-12 09:32:13 EDT
Bug 602793 suggests that it's possible to boot with snapshot of / (root) mounted as / (root).

So I have:
[root@hogofogo ~]# lvs
  LV             VG          Attr   LSize  Origin     Snap%
  root_rhel6     vg_hogofogo owi-a- 10.00g
  root_rhel6_ati vg_hogofogo swi-ao  5.00g root_rhel6   0.21
  swap           vg_hogofogo -wi-ao  2.00g

I did the change in grub, to point to the snapshot:
kernel /vmlinuz-2.6.32-166.el6.x86_64 ro root=/dev/mapper/vg_hogofogo-root_rhel6_ati rd_LVM_LV=vg_hogofogo/root_rhel6_ati rd_LVM_LV=vg_hogofogo/swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us

But that doesn't work. Root is not found. Reading more in bug 602793 I tried settings rd_LVM_LV to the original volume, not the snapshot. That did the trick. But it's not something user friendly that I could have just edited.

I suggest dracut tries to activate the original volume when it attemps to activate the snapshot (which doesn't work). Or perhaps this would be better done in LVM? Or in the worst case (least preferred) at least print a proper error message. 

[root@hogofogo ~]# rpm -q kernel dracut
Comment 1 Harald Hoyer 2011-07-15 04:00:43 EDT
bug 602793 ???
Comment 2 David Kovalsky 2011-07-18 05:26:35 EDT
Ooops, temporary brain outage / finger malfunction.

I meant bug 602723 / bug 602649. Sorry for the confusion.
Comment 3 Harald Hoyer 2011-07-18 06:03:08 EDT

According to prajnoha@redhat.com, the 'lvchange' command does not support a
snapshot as an argument.  

"Instead, you need to run lvchange -ay /dev/vg/origin_lv which will activate
*both* origin_lv and snap_lv.  Because of the way snapshots work, it is
necessary always to have all snapshots+origin active together, or none of them
active.  You can't pick and choose which"

nothing I can do about...
Comment 4 David Kovalsky 2011-07-18 07:09:45 EDT
Could perhaps dracut query LVM and figure out that we're trying to boot from snapshot, and request activating the original volume (+all snapshots)?

Or could this logic be pushed to LVM?

Are there any downsides to activating the original volume + all snapshots during boot?
Comment 5 Suzanne Yeghiayan 2011-10-06 14:42:09 EDT
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 6 Harald Hoyer 2012-07-04 08:18:17 EDT
reassigning to lvm2 to get some comments here.
Comment 7 Zdenek Kabelac 2012-10-19 03:56:17 EDT
Since version 2.02.89 lvm2 is able to activate snapshots automatically with its origin (giving you a question). If you want proceed with [y] answer - use command like this:

lvchange -ay --yes  vg/snapshot_lv
Comment 8 Peter Rajnoha 2012-11-28 05:20:08 EST
So I think this is just about adding the "--yes" option to the lvchange command in dracut, reassigning back... Harald, would you add the "--yes" to the lvchange you use in dracut, please?

Note that this will activate the origin as well as all other existing snapshots, but I don't see any problem with that except if there are numerous volumes/snapshots, it'll take a bit more time to activate of course.
Comment 9 Harald Hoyer 2012-11-28 05:52:54 EST
will do
Comment 15 Harald Hoyer 2013-07-18 09:54:28 EDT
First alpha build for testing:

Would be nice, if you could test it.
Comment 17 Jan Stodola 2013-10-18 06:18:56 EDT
[root@rhevh-x3650-01-g1 ~]# lvs
  LV      VG      Attr       LSize Pool Origin Data%  Move Log Cpy%Sync Convert
  lv_root vg_test -wi-ao---- 9.78g                                             
[root@rhevh-x3650-01-g1 ~]# lvcreate -s /dev/mapper/vg_test-lv_root -l 100%ORIGIN -n lv_root_snapshot
  Logical volume "lv_root_snapshot" created
[root@rhevh-x3650-01-g1 ~]# sed s/lv_root/lv_root_snapshot/g -i /boot/grub/grub.conf 
[root@rhevh-x3650-01-g1 ~]# sed s/lv_root/lv_root_snapshot/g -i /etc/fstab
[root@rhevh-x3650-01-g1 ~]# reboot

During boot:
dracut: inactive Original '/dev/vg_test/lv_root' [9.78 GiB] inherit
dracut: inactive Snapshot '/dev/vg_test/lv_root_snapshot' [9.78 GiB] inherit
EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
dracut: Mounted root filesystem /dev/mapper/vg_test-lv_root_snapshot

After login:
[root@rhevh-x3650-01-g1 ~]# mount | grep ' / '
/dev/mapper/vg_test-lv_root_snapshot on / type ext4 (rw)
[root@rhevh-x3650-01-g1 ~]# lvs
  LV               VG      Attr       LSize Pool Origin  Data%  Move Log Cpy%Sync Convert
  lv_root          vg_test owi-a-s--- 9.78g                                              
  lv_root_snapshot vg_test swi-aos--- 9.78g      lv_root   0.03                          
[root@rhevh-x3650-01-g1 ~]# rpm -q dracut
[root@rhevh-x3650-01-g1 ~]#

Moving to VERIFIED.
Comment 18 errata-xmlrpc 2013-11-21 16:53:44 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.