I'm looking for a way to have a system with disposable storage that can be
rebooted and all filesystem changes are thrown away. After reboot, the system
starts with a fresh root volume again. The use case is for automated testing.
We run test scripts that could potentially not clean up after themselves.
This is almost like stateless, but the storage is local to the system (not
iSCSI, NFS or NBB).
1. Install Fedora 13 using default partition layout
NOTE: modify the layout to leave extra room in the LVM volume group
2. Apply attached patch
3. Update grub.conf to enable dracut LVM snapshot support. Add the following
boot arguments
rd_LVM_SNAPSHOT=vg_test1055/lv_snap (note the VG name will depend on your
system).
rd_LVM_SNAPSIZE= (optional, defaults to size of volume specified with by
rd_LVM_SNAPSHOT)
4. Adjust grub.conf and fstab to use LVM snapshot
$ sed -i -e 's|lv_root|lv_snap|' /boot/grub/grub.conf
$ sed -i -e 's|lv_root|lv_snap|' /etc/fstab
5. Reboot system
Expected results (no value provided for rd_LVM_SNAPSIZE):
dracut: Starting plymouth daemon
dracut: rd_NO_DM: removing DM RAID activation
dracut: rd_NO_MD: removing MD RAID activation
dracut: Removing existing LVM snapshot vg_test1055/lv_snap
dracut: Logical volume "lv_snap" successfully removed
dracut: No LVM snapshot size provided, using size of vg_test1055/lv_root (
9024.00m)
dracut: Creating LVM snapshot vg_test1055/lv_snap ( 9024.00m)
dracut: Logical volume "lv_snap" created
dracut: Scanning devices sda2 for LVM logical volumes vg_test1055/lv_root
vg_test1055/lv_swap
dracut: inactive Original '/dev/vg_test1055/lv_root' [8.81 GiB] inherit
dracut: inactive '/dev/vg_test1055/lv_swap' [1.00 GiB] inherit
dracut: inactive Snapshot '/dev/vg_test1055/lv_snap' [8.81 GiB] inherit
dracut: Mounted root filesystem /dev/mapper/vg_test1055-lv_snap
dracut: Loading SELinux policy
dracut: Switching root
Expected results (rd_LVM_SNAPSIZE=100m):
dracut: Starting plymouth daemon
dracut: rd_NO_DM: removing DM RAID activation
dracut: rd_NO_MD: removing MD RAID activation
dracut: Removing existing LVM snapshot vg_test1055/lv_snap
dracut: Logical volume "lv_snap" successfully removed
dracut: Creating LVM snapshot vg_test1055/lv_snap (100m )
dracut: Rounding up size to full physical extent 128.00 MiB
dracut: Logical volume "lv_snap" created
dracut: Scanning devices sda2 for LVM logical volumes vg_test1055/lv_root
vg_test1055/lv_swap
dracut: inactive Original '/dev/vg_test1055/lv_root' [8.81 GiB] inherit
dracut: inactive '/dev/vg_test1055/lv_swap' [1.00 GiB] inherit
dracut: inactive Snapshot '/dev/vg_test1055/lv_snap' [128.00 MiB] inherit
dracut: Mounted root filesystem /dev/mapper/vg_test1055-lv_snap
dracut: Loading SELinux policy
dracut: Switching root
lvchange and vgchange '--monitor n' will not prevent lvm from
attempting to dlopen the libdevmapper-event library.
dracut git commit 47ab3b6c5e introduced the use of '--monitor n' but
'--ignoremonitoring' is needed now that the libdevmapper-event library
isn't copied into the initramfs (ever since 0fae59d6eb)
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
- the use of sed is placeholder "hack" until lvm2 provides a proper
tool for changing lvm.conf
- lvm_scan.sh should run lvm commands with --ignorelockingfailure to
re-use lvm's existing initrd-specific logic; future lvm2 changes
will split this flag out into various new command-line switches
- no monitoring should be started from within initramfs
- NOTE: the same should apply to 90dmraid/install
- the correct types would be: '[ "blkext", 1 , "cciss0", 16 ]'
but lvm2 (>= 2.02.52) already properly supports both 'blkext' and
'cciss' (including cciss0 -> cciss7)
This is a more sane solution, than ignoring subsequent "change" events.
The only danger is that we could loop, if a lvm scan triggers a broken
md partition, which triggers a broken PV and so on.
Better fix the scanning tools, not to emit change events for devices,
if no action was taken.
I've looked at the LVM rules used in dracut just recently
and it needs fixing - we should react to change events only
for DM devices, so we have to skip vol_id/blkid call on ADD:
KERNEL=="dm-[0-9]*", ACTION=="add", GOTO="lvm_end"
Also, MD devices have their own rules, where vol_id/blkid
is called and where the symlinks are created (when looking
into raw initrd, this is in 64-md-raid.rules).
Also, if those rules are meant to be for DM devices only,
maybe we should skip symlink creation for the other devices
there, to keep the rules clean and straightforward. I think
we shouldn't create/recreate symlinks for non-dm devices in
LVM/DM rules (..should be in appropriate rules for that type
of device):
KERNEL!="dm-[0-9]*", GOTO="lvm_end"
Since different distros may or may not use vol_id in udev, and blkid
is generally replacing vol_id, abstract them out into a function which
tries to use vol_id first and blkid second, on the assumption that
blkid can take over for vol_id if vol_id is no longer there.
Harald Hoyer