[arch-projects] [mkinitcpio][PATCH 1/2] shutdown: add vim modeline, fix whitespacing
Make this consistent with the rest of the codebase.
Signed-off-by: Dave Reisner
sysfs contains enough information about block devices to be able to
determine the order of stacked devices such as lvm, raid, or crypto. By
looking at the device symlinks from the holders/ attributes of a block
device, we can walk down each device chain until we reach the most
descendant device.
For each of these devices at the end of a chain, detect its type and
perform the appropriate action to disassemble it. Then, walk back up the
device chain, disassembling each parent device.
To save ourselves some pain and make sure we're fairly accurate, lsblk
is brought in for detection of device types.
Signed-off-by: Dave Reisner
On Sat, Mar 24, 2012 at 10:20:05PM -0400, Dave Reisner wrote:
sysfs contains enough information about block devices to be able to determine the order of stacked devices such as lvm, raid, or crypto. By looking at the device symlinks from the holders/ attributes of a block device, we can walk down each device chain until we reach the most descendant device.
For each of these devices at the end of a chain, detect its type and perform the appropriate action to disassemble it. Then, walk back up the device chain, disassembling each parent device.
To save ourselves some pain and make sure we're fairly accurate, lsblk is brought in for detection of device types.
Signed-off-by: Dave Reisner
--- This was fun... so far, I've tested this with the following root configurations:
<snip> and despite being fun, it turns out it's way more complicated than it needs to be, thanks to tom pointing out that we can safely use recursion to disassemble. working on a v2...
sysfs contains enough information about block devices to be able to
determine the order of stacked devices such as lvm, raid, or crypto. By
looking at the device symlinks from the holders/ attributes of a block
device, we can walk down each device chain until we reach the most
descendant device.
For each of these devices at the end of a chain, detect its type and
perform the appropriate action to disassemble it. Then, walk back up the
device chain, disassembling each parent device.
To save ourselves some pain and make sure we're fairly accurate, lsblk
is brought in for detection of device types.
Thanks-To: Florian Pritz
Okay, I am late to this party. Am 25.03.2012 21:11, schrieb Dave Reisner:
+ # this can sometimes fail on stopped md devices, when the + # sysfs node doesn't go away as quickly as i'd like it to. + devtype=$(lsblk -drno TYPE "/dev/$1" 2>/dev/null) || return 1 + case $devtype in + crypt) + read devname <"$1/dm/name" + cryptsetup luksClose "$devname" + ;;
This should be "cryptsetup remove". Although the two are identical operations, the "luksClose" keyword seems to indicate that something LUKS-specific is happening here, which it isn't.
+ dmraid) + # XXX: i have no idea how dmraid works + dmraid -an + ;;
According to the manpage, you can use the name of the dmraid set to only deactivate this specific dmraid set only. Determining this name from the device name seems to be harder than with LVM, but I don't have any dmraid-capable hardware to give you specifics. Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
On Wed, Mar 28, 2012 at 11:48 AM, Thomas Bächler
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
I was thinking the same. It would be nice if we could deal with unmounting using the same logic, and then detect loop devices, or swap files as children of filesystems and continue disassembling them recursively Not sure how easy that is though. -t
On Wed, Mar 28, 2012 at 11:48:48AM +0200, Thomas Bächler wrote:
Okay, I am late to this party.
You missed all the beer and the strippers, but I sweeped up some broken pretzels that you're welcome to.
Am 25.03.2012 21:11, schrieb Dave Reisner:
+ # this can sometimes fail on stopped md devices, when the + # sysfs node doesn't go away as quickly as i'd like it to. + devtype=$(lsblk -drno TYPE "/dev/$1" 2>/dev/null) || return 1 + case $devtype in + crypt) + read devname <"$1/dm/name" + cryptsetup luksClose "$devname" + ;;
This should be "cryptsetup remove". Although the two are identical operations, the "luksClose" keyword seems to indicate that something LUKS-specific is happening here, which it isn't.
Yup, good call.
+ dmraid) + # XXX: i have no idea how dmraid works + dmraid -an + ;;
According to the manpage, you can use the name of the dmraid set to only deactivate this specific dmraid set only. Determining this name from the device name seems to be harder than with LVM, but I don't have any dmraid-capable hardware to give you specifics.
That's as far as I got... I would love to see the hierarchy under /sys/class/block/dm* and the contents of some choice nodes from someone who actually has this hardware.
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
sure, lsblk loudly declares loop devices to be type loop. Hrmmm, archiso does a lot of weird stuff... in particular, the squashfs mounts are confusing me and/or lsblk. I'll get myself a newer image and poke around at what Gerardo is doing on setup... I'm sure it's possible, I just need to understand what's happening. d
Am 28.03.2012 15:44, schrieb Dave Reisner:
On Wed, Mar 28, 2012 at 11:48:48AM +0200, Thomas Bächler wrote:
According to the manpage, you can use the name of the dmraid set to only deactivate this specific dmraid set only. Determining this name from the device name seems to be harder than with LVM, but I don't have any dmraid-capable hardware to give you specifics.
That's as far as I got... I would love to see the hierarchy under /sys/class/block/dm* and the contents of some choice nodes from someone who actually has this hardware.
Ask Pierre.
On 03/28/2012 10:44 AM, Dave Reisner wrote:
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
sure, lsblk loudly declares loop devices to be type loop. Hrmmm, archiso does a lot of weird stuff... in particular, the squashfs mounts are confusing me and/or lsblk. I'll get myself a newer image and poke around at what Gerardo is doing on setup...
I'm sure it's possible, I just need to understand what's happening.
d
Hello, The first step on "shutdown" for archiso is a mount --move, since /oldroot depends on things from /oldroot/run/archiso. This make it a bit special. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 28.03.2012 16:30, schrieb Gerardo Exequiel Pozzi:
On 03/28/2012 10:44 AM, Dave Reisner wrote:
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
sure, lsblk loudly declares loop devices to be type loop. Hrmmm, archiso does a lot of weird stuff... in particular, the squashfs mounts are confusing me and/or lsblk. I'll get myself a newer image and poke around at what Gerardo is doing on setup...
I'm sure it's possible, I just need to understand what's happening.
d
Hello,
The first step on "shutdown" for archiso is a mount --move, since /oldroot depends on things from /oldroot/run/archiso. This make it a bit special.
It would be a good idea anyway to do that unconditionally: Just move all mount points into separate paths before umounting and closing devices.
On Wed, Mar 28, 2012 at 11:30:08AM -0300, Gerardo Exequiel Pozzi wrote:
On 03/28/2012 10:44 AM, Dave Reisner wrote:
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
sure, lsblk loudly declares loop devices to be type loop. Hrmmm, archiso does a lot of weird stuff... in particular, the squashfs mounts are confusing me and/or lsblk. I'll get myself a newer image and poke around at what Gerardo is doing on setup...
I'm sure it's possible, I just need to understand what's happening.
d
Hello,
The first step on "shutdown" for archiso is a mount --move, since /oldroot depends on things from /oldroot/run/archiso. This make it a bit special.
So, I need to understand more about this... why is this done? The current shutdown hook that I have in my tree gets archiso's wacky setup torn down properly sans loop devs. Add in a quick loop: # assume starting in /sys/class/block for loop in loop*/loop; do losetup -d "${loop%/loop}" done And everything seems to be torn down properly because I'm lazily unmounting everything. Unmounting all devices. Disassembling stacked devices. losetup: /dev/loop0: detach failed: Device or resource busy losetup: /dev/loop3: detach failed: Device or resource busy losetup: /dev/loop6: detach failed: Device or resource busy # findmnt TARGET SOURCE FSTYPE OPTIONS / run[/initramfs] tmpfs rw,nosuid,nodev,relatime,mode=755 |-/sys sys sysfs rw,nosuid,nodev,noexec,relatime |-/proc proc proc rw,nosuid,nodev,noexec,relatime |-/dev /dev devtmpfs rw,nosuid,relatime,size=503104k,nr_inodes=125776,mode=75 `-/run run tmpfs rw,nosuid,nodev,relatime,mode=755 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 5G 0 disk |-vda1 254:1 0 100M 0 part `-vda2 254:2 0 4.9G 0 part sr0 11:0 1 200M 0 rom loop0 7:0 0 92.9M 1 loop loop3 7:3 0 34.3M 1 loop loop6 7:6 0 53M 1 loop # losetup -a /dev/loop0: [2816]:1930 (/arch/x86_64/root-image.fs.sfs) /dev/loop3: [2816]:1926 (/arch/x86_64/lib-modules.fs.sfs) /dev/loop6: [2816]:1414 (/arch/any/usr-share.fs.sfs) Those three errors are something that archiso hides. So, as far as I can tell, my hook is equivalent. Is there some serious problem with using lazy unmounting that makes this non-desirable? I can't really find any evidence of negative effects here. d
On Mar 30, 2012 3:38 AM, "Dave Reisner"
On Wed, Mar 28, 2012 at 11:30:08AM -0300, Gerardo Exequiel Pozzi wrote:
On 03/28/2012 10:44 AM, Dave Reisner wrote:
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
sure, lsblk loudly declares loop devices to be type loop. Hrmmm,
archiso
does a lot of weird stuff... in particular, the squashfs mounts are confusing me and/or lsblk. I'll get myself a newer image and poke around at what Gerardo is doing on setup...
I'm sure it's possible, I just need to understand what's happening.
d
Hello,
The first step on "shutdown" for archiso is a mount --move, since /oldroot depends on things from /oldroot/run/archiso. This make it a bit special.
So, I need to understand more about this... why is this done? The current shutdown hook that I have in my tree gets archiso's wacky setup torn down properly sans loop devs. Add in a quick loop:
# assume starting in /sys/class/block for loop in loop*/loop; do losetup -d "${loop%/loop}" done
And everything seems to be torn down properly because I'm lazily unmounting everything.
Unmounting all devices. Disassembling stacked devices.
losetup: /dev/loop0: detach failed: Device or resource busy losetup: /dev/loop3: detach failed: Device or resource busy losetup: /dev/loop6: detach failed: Device or resource busy
# findmnt TARGET SOURCE FSTYPE OPTIONS / run[/initramfs] tmpfs rw,nosuid,nodev,relatime,mode=755 |-/sys sys sysfs rw,nosuid,nodev,noexec,relatime |-/proc proc proc rw,nosuid,nodev,noexec,relatime |-/dev /dev devtmpfs rw,nosuid,relatime,size=503104k,nr_inodes=125776,mode=75 `-/run run tmpfs rw,nosuid,nodev,relatime,mode=755
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 5G 0 disk |-vda1 254:1 0 100M 0 part `-vda2 254:2 0 4.9G 0 part sr0 11:0 1 200M 0 rom loop0 7:0 0 92.9M 1 loop loop3 7:3 0 34.3M 1 loop loop6 7:6 0 53M 1 loop
# losetup -a /dev/loop0: [2816]:1930 (/arch/x86_64/root-image.fs.sfs) /dev/loop3: [2816]:1926 (/arch/x86_64/lib-modules.fs.sfs) /dev/loop6: [2816]:1414 (/arch/any/usr-share.fs.sfs)
Those three errors are something that archiso hides. So, as far as I can tell, my hook is equivalent. Is there some serious problem with using lazy unmounting that makes this non-desirable? I can't really find any evidence of negative effects here.
Wouldnt this lead to races in case the lazy umount is not finished when you need it to be (either because the parent cant be dissssembled lazily, or because we switch the power off). For once sceptical of lazines, Tom
Am 30.03.2012 09:12, schrieb Tom Gundersen:
Wouldnt this lead to races in case the lazy umount is not finished when you need it to be (either because the parent cant be dissssembled lazily, or because we switch the power off).
For once sceptical of lazines,
Exactly. How do you make sure the lazy umount finished before you power off?
On 03/29/2012 10:38 PM, Dave Reisner wrote:
On Wed, Mar 28, 2012 at 11:30:08AM -0300, Gerardo Exequiel Pozzi wrote:
On 03/28/2012 10:44 AM, Dave Reisner wrote:
Is there any way to make something similar work with loop devices? You would need to disable the loop device before umounting the underlying file system. If we could solve this as well, then archiso probably wouldn't need its special shutdown hook anymore.
sure, lsblk loudly declares loop devices to be type loop. Hrmmm, archiso does a lot of weird stuff... in particular, the squashfs mounts are confusing me and/or lsblk. I'll get myself a newer image and poke around at what Gerardo is doing on setup...
I'm sure it's possible, I just need to understand what's happening.
d
Hello,
The first step on "shutdown" for archiso is a mount --move, since /oldroot depends on things from /oldroot/run/archiso. This make it a bit special.
So, I need to understand more about this... why is this done? Are you talk about this "mount --move" ? Because all things needed for /new_root/ are mounted on /run/archiso on initramfs. So all things are visible outside initramfs, nothing is hide to user (Thomas wants this some long time ago since AUFS-age). The current shutdown hook that I have in my tree gets archiso's wacky setup torn down properly sans loop devs. Add in a quick loop:
# assume starting in /sys/class/block for loop in loop*/loop; do losetup -d "${loop%/loop}" done This can be done in one step: losetup -D Anyway I am done in a special way because some loops are in used, then if ! losetup -d ${_lup} 2> /dev/null; then umount -d ${_lup} fi
Anyway there are special cases if copytoram is used, or cowdevice for persistent data, or iso-loopback mount, and iso via NBD. http://projects.archlinux.org/archiso.git/tree/archiso/archiso_shutdown
And everything seems to be torn down properly because I'm lazily unmounting everything.
Unmounting all devices. Disassembling stacked devices.
losetup: /dev/loop0: detach failed: Device or resource busy losetup: /dev/loop3: detach failed: Device or resource busy losetup: /dev/loop6: detach failed: Device or resource busy
# findmnt TARGET SOURCE FSTYPE OPTIONS / run[/initramfs] tmpfs rw,nosuid,nodev,relatime,mode=755 |-/sys sys sysfs rw,nosuid,nodev,noexec,relatime |-/proc proc proc rw,nosuid,nodev,noexec,relatime |-/dev /dev devtmpfs rw,nosuid,relatime,size=503104k,nr_inodes=125776,mode=75 `-/run run tmpfs rw,nosuid,nodev,relatime,mode=755
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 5G 0 disk |-vda1 254:1 0 100M 0 part `-vda2 254:2 0 4.9G 0 part sr0 11:0 1 200M 0 rom loop0 7:0 0 92.9M 1 loop loop3 7:3 0 34.3M 1 loop loop6 7:6 0 53M 1 loop
# losetup -a /dev/loop0: [2816]:1930 (/arch/x86_64/root-image.fs.sfs) /dev/loop3: [2816]:1926 (/arch/x86_64/lib-modules.fs.sfs) /dev/loop6: [2816]:1414 (/arch/any/usr-share.fs.sfs)
Those three errors are something that archiso hides. So, as far as I can tell, my hook is equivalent. Is there some serious problem with using lazy unmounting that makes this non-desirable? I can't really find any evidence of negative effects here.
d
Anyway using shutdown hook provided by mkinitcpio in archiso can not be a good idea archiso initramfs has a looots of kernel modules, shutdown hooks will copy all them to ram. (Yes, of course we can just still use our install/archiso_shutdown and using initcpio/shutdown script instead of initcpio/archiso_shutdown) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 30.03.2012 15:01, schrieb Gerardo Exequiel Pozzi:
Anyway using shutdown hook provided by mkinitcpio in archiso can not be a good idea archiso initramfs has a looots of kernel modules, shutdown hooks will copy all them to ram.
Ehm what? This is a bad idea regardless. Usual initramfs can also have lots of modules. You don't need to load additional modules on shutdown, so why copy them at all?
On 03/30/2012 10:11 AM, Thomas Bächler wrote:
Am 30.03.2012 15:01, schrieb Gerardo Exequiel Pozzi:
Anyway using shutdown hook provided by mkinitcpio in archiso can not be a good idea archiso initramfs has a looots of kernel modules, shutdown hooks will copy all them to ram. Ehm what? This is a bad idea regardless. Usual initramfs can also have lots of modules. You don't need to load additional modules on shutdown, so why copy them at all?
I am not doing this, archiso_shutdown just copies what files are needed only [#1] This is done by mkinitcpio-shutdown [#2] [#1] http://projects.archlinux.org/archiso.git/tree/archiso/hooks/archiso_shutdow... [#2] http://projects.archlinux.org/mkinitcpio.git/tree/hooks/shutdown -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Mar 30, 2012 3:11 PM, "Thomas Bächler"
Am 30.03.2012 15:01, schrieb Gerardo Exequiel Pozzi:
Anyway using shutdown hook provided by mkinitcpio in archiso can not be a good idea archiso initramfs has a looots of kernel modules, shutdown hooks will copy all them to ram.
Ehm what? This is a bad idea regardless. Usual initramfs can also have lots of modules. You don't need to load additional modules on shutdown, so why copy them at all?
If the shutdown stuff had not been a hook, but built in, we could avoid this easily: Just delete the modules and copy the rest to /run as the last thing in ./init before switching to the new root. T
Am 30.03.2012 17:19, schrieb Tom Gundersen:
Am 30.03.2012 15:01, schrieb Gerardo Exequiel Pozzi:
Anyway using shutdown hook provided by mkinitcpio in archiso can not be a good idea archiso initramfs has a looots of kernel modules, shutdown hooks will copy all them to ram.
Ehm what? This is a bad idea regardless. Usual initramfs can also have lots of modules. You don't need to load additional modules on shutdown, so why copy them at all?
If the shutdown stuff had not been a hook, but built in, we could avoid this easily:
Just delete the modules and copy the rest to /run as the last thing in ./init before switching to the new root.
It's not like this is unsolvable as a hook.
participants (4)
-
Dave Reisner
-
Gerardo Exequiel Pozzi
-
Thomas Bächler
-
Tom Gundersen