[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 <dreisner@archlinux.org> --- shutdown | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/shutdown b/shutdown index 39bcb97..aad0198 100755 --- a/shutdown +++ b/shutdown @@ -3,24 +3,26 @@ findmnt -Rruno TARGET /oldroot | awk ' BEGIN { i = 0 } ! /^\/(proc|dev|sys)/ { - i++ - mounts[i] = $0 + i++ + mounts[i] = $0 } END { - for (j = i; j > 0; j--) { - print mounts[j] - } + for (j = i; j > 0; j--) { + print mounts[j] + } } ' | while read -r mount; do - umount -l "$mount" + umount -l "$mount" done case $1 in - poweroff|shutdown|halt) - "$1" -f - ;; - *) - type kexec >/dev/null && kexec -e - reboot -f - ;; + poweroff|shutdown|halt) + "$1" -f + ;; + *) + type kexec >/dev/null && kexec -e + reboot -f + ;; esac + +# vim: ft=sh ts=4 sw=4 -- 1.7.9.4
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 <dreisner@archlinux.org> --- This was fun... so far, I've tested this with the following root configurations: * lvm+crypt+lvm (don't ask) * raid0 * lvm * crypt (this setup has encrypted home as well) * lvm+raid And it works well for all 5. The idea is that it supports any given number of stacked devices so we don't need to worry about specifically naming what we're willing to support. dmraid isn't tested because i lack the hardware (and im not sure its possible to test in qemu), but it should "just work". The only unresolved issue thus far is with the mdadm hook (rather than mdadm_udev). Since we don't include /sbin/mdadm, there's no way to disassemble devices via mdassemble. I'm inclined to believe that the lifespan of the mdadm hook is limited (as upstream really encourages you to use udev assembly these days), so I think it's okay to just call this setup unsupported. install/shutdown | 2 +- shutdown | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 95 insertions(+), 1 deletion(-) diff --git a/install/shutdown b/install/shutdown index 5b56f17..600209e 100644 --- a/install/shutdown +++ b/install/shutdown @@ -1,7 +1,7 @@ #!/bin/bash build() { - BINARIES='cp' + BINARIES='cp lsblk' SCRIPT='shutdown' add_file "/usr/lib/initcpio/shutdown" "/shutdown" diff --git a/shutdown b/shutdown index aad0198..6c34ff2 100755 --- a/shutdown +++ b/shutdown @@ -1,5 +1,80 @@ #!/usr/bin/ash +# disassemble a device, $1. +# returns 0 on disassembling a device +# returns 1 when the nothing is done (caller should stop) +disassemble_dev() { + local devtype= + + [ -n "$1" ] || return 0 + + devtype=$(lsblk -drno TYPE "$1") + case $devtype in + disk|part) + return 1 + ;; + crypt) + read devname <"${1##*/}/dm/name" + cryptsetup luksClose "$devname" + return 0 + ;; + dm|lvm) + # rip apart a specific VG. it needs to be translated from the LV + # that's been passed to this function. + read devname <"${1##*/}/dm/name" + devname=$(lvm lvs --noheadings -o vg_name "/dev/mapper/$devname") + + # $devname can't be quoted because lvs will put leading and + # trailing whitespace in the vgname output. "fortunately", + # whitespace is invalid in a vgname, so this is "safe". + lvm vgchange -an $devname + return 0 + ;; + raid*) + mdadm --stop "$1" + return 0 + ;; + dmraid) + # XXX: i have no idea how dmraid works. + dmraid -an + return 0 + ;; + *) + # unexpected device + return 1 + ;; + esac +} + +# get the parent of device $1 from /sys +# return 0 on success (and write device to stdout) +# return 1 on failure +get_parent_dev() { + local parent=$(printf '%s\n' */holders/${1##*/}) + + [ -e "$parent" ] && printf '/dev/%s' "${parent%%/*}" +} + +# get the most descendant device in a device chain +get_child_dev() { + local child= parent=$1 + + while :; do + for child in "$parent"/holders/*; do + if [ -e "$child" ]; then + # found a descendant, check for more children below it + parent=${child##*/} + break + else + # end of a chain + printf '/dev/%s' "$parent" + return + fi + done + done +} + +# unmount everything findmnt -Rruno TARGET /oldroot | awk ' BEGIN { i = 0 } ! /^\/(proc|dev|sys)/ { @@ -15,6 +90,25 @@ END { umount -l "$mount" done +# chdir, so that we can avoid a lot of path chopping +cd /sys/class/block + +# find stacked devices and disassemble them +for holder in */holders/*; do + device=${holder%%/*} + + # walk down the device chain to find the most descendant child + nextdev=$(get_child_dev "$device") + + # check to see that the device still exists in /sys. it may have been taken apart already + [ -e "${nextdev##*/}" ] || continue + + # now walk back up the chain, disassembling each device + while disassemble_dev "$nextdev"; do + nextdev=$(get_parent_dev "$nextdev") || break + done +done + case $1 in poweroff|shutdown|halt) "$1" -f -- 1.7.9.4
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 <dreisner@archlinux.org> --- 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 <bluewind@xinu.at> Thanks-To: Tom Gundersen <teg@jklm.no> Signed-off-by: Dave Reisner <dreisner@archlinux.org> --- v2 changes: This gets rid of the get_child and get_parent logic and replaces it with a recursive function which walks down the device chain. When it gets to the bottom, it unwinds, and disassembles as it walks back up -- much simpler, and much easier to maintain. Thanks to Florian for pointing out a better way of getting the containing vgname of an LV, and to Tom for telling me my initial implementation sucked. You can stop reading here you don't care about some editorial remarks. Re-tested on all the root configs I mentioned in v1 with a new intentionally absurd addition which splits a raid10 array into 2 partitions, each of which is labelled as a PV and VG. Each VG has a single LV, one of which is encrypted. lsblk shows one of the raid10 members as... NAME TYPE MOUNTPOINT vde disk └─md127 raid10 ├─md127p1 md │ └─VolGroup01-volroot (dm-1) lvm / └─md127p2 md └─VolGroup02-volhome (dm-0) lvm └─home (dm-2) crypt /home And we correctly tear this down as: lvm vgchange -an VolGroup01 lvm vgchange -an VolGroup02 mdadm --stop md127 init takes care of teardown for the encrypted home since it was responsible for the setup, but the logic is indeed robust enough to handle this extra step. I still have no idea how dmraid works. install/shutdown | 2 +- shutdown | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 1 deletion(-) diff --git a/install/shutdown b/install/shutdown index 5b56f17..600209e 100644 --- a/install/shutdown +++ b/install/shutdown @@ -1,7 +1,7 @@ #!/bin/bash build() { - BINARIES='cp' + BINARIES='cp lsblk' SCRIPT='shutdown' add_file "/usr/lib/initcpio/shutdown" "/shutdown" diff --git a/shutdown b/shutdown index aad0198..2ed9f7f 100755 --- a/shutdown +++ b/shutdown @@ -1,5 +1,57 @@ #!/usr/bin/ash +# teardown a single device by node name +# $1: device node name, e.g. md0, dm-2 +stop_device() { + local devtype= devname= + + # the device must still be active + [ -e "/sys/class/block/$1" ] || return 1 + + # 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" + ;; + dm|lvm) + # disassemble the parent VG + read devname <"$1/dm/name" + lvm lvdisplay -c "/dev/mapper/$devname" | { + IFS=: read _ vgname _ + lvm vgchange -an "$vgname" + } + ;; + raid*) + mdadm --stop "/dev/$1" + ;; + dmraid) + # XXX: i have no idea how dmraid works + dmraid -an + ;; + # silently ignore unstacked devices + esac +} + +# recursely disassemble a device chain +# $1: device node name, e.g. md0, dm-2 +disassemble() { + for holder in "$1"/holders/*; do + if [ ! -e "$holder" ]; then + # end of the chain, recurse back up + stop_device "$1" + return + fi + disassemble "${holder##*/}" + stop_device "$1" + done +} + +printf '%s\n' "Unmounting all devices." + +# unmount everything findmnt -Rruno TARGET /oldroot | awk ' BEGIN { i = 0 } ! /^\/(proc|dev|sys)/ { @@ -15,6 +67,16 @@ END { umount -l "$mount" done +printf '%s\n' "Disassembling stacked devices." + +# chdir, so that we can avoid a lot of path chopping +cd /sys/class/block + +# iterate over devices with holders +for part in */holders/*; do + [ -e "$part" ] && disassemble "${part%%/*}" +done + case $1 in poweroff|shutdown|halt) "$1" -f -- 1.7.9.4
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 <thomas@archlinux.org> 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.
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" <d@falconindy.com> 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? 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" <thomas@archlinux.org> 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?
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