Bug 720684

Summary: Booting with snapshot of / requires non user-friendly config
Product: Red Hat Enterprise Linux 6 Reporter: David Kovalsky <dkovalsk>
Component: dracutAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact:
Priority: high    
Version: 6.1CC: agk, benl, dracut-maint-list, dwysocha, heinzm, jbrassow, jstodola, lnovich, msnitzer, pknirsch, prajnoha, prockai, thornber, zkabelac
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
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: Environment:
Last Closed: 2013-11-21 21:53:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description David Kovalsky 2011-07-12 13:32:13 UTC
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 08:00:43 UTC
bug 602793 ???

Comment 2 David Kovalsky 2011-07-18 09:26:35 UTC
Ooops, temporary brain outage / finger malfunction.

I meant bug 602723 / bug 602649. Sorry for the confusion.

Comment 3 Harald Hoyer 2011-07-18 10:03:08 UTC

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 11:09:45 UTC
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 18:42:09 UTC
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 12:18:17 UTC
reassigning to lvm2 to get some comments here.

Comment 7 Zdenek Kabelac 2012-10-19 07:56:17 UTC
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 10:20:08 UTC
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 10:52:54 UTC
will do

Comment 15 Harald Hoyer 2013-07-18 13:54:28 UTC
First alpha build for testing:

Would be nice, if you could test it.

Comment 17 Jan Stodola 2013-10-18 10:18:56 UTC
[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 21:53:44 UTC
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.