[pkg-cryptsetup-devel] Bug#511840: - new revised patch

[Pyotr Berezhkov]

Well, here you have it.  With this revision of the patch, the code only
runs if the user explicitly asks it to by specifying 'cryptsetroot' on
the kernel command line.  Otherwise nothing happens.  This was done in
response to maximilian attems' objection:

>  anyway the way you tried to solve it is out of question:
>  random script deleting the root device node.

--------------------------------- SNIP ------------------------------------
diff --git a/scripts/local-top/cryptroot b/scripts/local-top/cryptroot
index 56d1d63..544b3ef 100755
--- a/scripts/local-top/cryptroot
+++ b/scripts/local-top/cryptroot
@@ -264,6 +264,16 @@ setup_mapping()
 		fi
 
 		message "cryptsetup: $crypttarget setup successfully"
+		for opt in $(cat /proc/cmdline); do
+			if [ $opt = "cryptsetroot" ]; then
+				message "cryptsetup: linking /dev/root to $NEWROOT"
+				echo "ROOT=$NEWROOT" >> /conf/param.conf
+				if [ -e "/dev/root" ]; then
+					rm -f /dev/root
+				fi
+				ln -s $NEWROOT /dev/root
+			fi
+		done;
 		break
 	done
 
--------------------------------- SNIP ------------------------------------

Now you'll see what the patch does for us.  Here's the state of the
system after booting with the patch applied:

  # cat /proc/cmdline
  BOOT_IMAGE=LinuxExp ro root=fe04 cryptsetroot

Note that Lilo thought the root device was at 254,4:

  0xfe04 => major 254, minor 4

But it's really at 254,7!

  # cat /proc/mounts
  rootfs / rootfs rw 0 0
  none /sys sysfs rw,nosuid,nodev,noexec 0 0
  none /proc proc rw,nosuid,nodev,noexec 0 0
  udev /dev tmpfs rw,size=10240k,mode=755 0 0
  /dev/mapper/lenny-root_crypt / ext3 rw,errors=remount-ro,data=ordered 0 0
  tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
  usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
  tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
  devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
  /dev/mapper/lenny-boot /boot ext2 rw,errors=continue 0 0

  # ls -l /dev/dm-7 /dev/root /dev/mapper
  brw-rw---- 1 root disk 254, 7 Янв 16 21:42 /dev/dm-7
  lrwxrwxrwx 1 root root      4 Янв 16 21:43 /dev/root -> dm-7
  
  /dev/mapper/:
  итого 0
  crw-rw---- 1 root root  10, 60 Янв 16 21:42 control
  brw-rw---- 1 root disk 254,  5 Янв 16 21:42 lenny-boot
  brw-rw---- 1 root disk 254,  6 Янв 16 21:42 lenny-root
  brw-rw---- 1 root disk 254,  7 Янв 16 21:43 lenny-root_crypt
  brw-rw---- 1 root disk 254,  0 Янв 16 21:42 sid-boot
  brw-rw---- 1 root disk 254,  2 Янв 16 21:42 sid-root
  brw-rw---- 1 root disk 254,  1 Янв 16 21:42 sid-root-real
  brw-rw---- 1 root disk 254,  4 Янв 16 21:42 sid-sid--root_snapshot
  brw-rw---- 1 root disk 254,  3 Янв 16 21:42 sid-sid--root_snapshot-cow

I added the snapshot volume 'sid-sid--root_snapshot' at my previous
uptime.  Running lilo after adding the snapshot didn't help, because the
majors and minors change _only after rebooting_.  When I ran lilo before
rebooting the root device looked like this:

  brw-rw---- 1 root disk 254,  4 Янв 16 20:36 lenny-root_crypt

So you see, with the patch we simply ignore Lilo's silly hardcoding of
the root device major/minor, letting LVM and dm-crypt set everything up
for us a boot time.  Otherwise, booting fails after adding or deleting
LVM volumes.  Your comments are welcome.

  -PGB