[arch-projects] [mkinitcpio PATCH 1/3] /run/initramfs: copy the whole ramfs
This is useful for the future shutdown hook, and might make debugging easier, as well as potentially opening up for other usecases (that I cannot yet imagine ;-) ). Signed-off-by: Tom Gundersen <teg@jklm.no> --- init | 2 +- install/base | 1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/init b/init index 7cc2d47..3c6fb81 100644 --- a/init +++ b/init @@ -21,7 +21,7 @@ else mknod /dev/mem c 1 1 fi mount -t tmpfs run /run -o nosuid,nodev,mode=755,size=10M -mkdir /run/initramfs +cp -ax / /run/initramfs # parse the kernel command line parse_cmdline diff --git a/install/base b/install/base index 0726fa2..84e7f02 100644 --- a/install/base +++ b/install/base @@ -10,6 +10,7 @@ build() { add_binary /sbin/blkid add_binary /bin/mount add_binary /sbin/switch_root + add_binary /bin/cp add_symlink "/etc/mtab" "/proc/self/mounts" -- 1.7.7.3
Add compat symlinks from /bin, /sbin and /usr/sbin, so nothing is lost. This will make sure that it is not possibly to install two different versions of the same binary in PATH. The main usecase of this is that we want to be able to override any symlink provided by busybox by adding a binary by the same name. With this patch we don't have to worry in case the busybox symlink and the binary we add are in different directories; the last binary to be added always takes precedence. Signed-off-by: Tom Gundersen <teg@jklm.no> --- init | 5 ++--- install/base | 6 +++++- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/init b/init index 3c6fb81..beb697c 100644 --- a/init +++ b/init @@ -1,6 +1,5 @@ -#!/bin/busybox ash -# Install busybox's applets as symlinks -PATH=/usr/sbin:/usr/bin:/sbin:/bin +#!/usr/bin/ash +PATH=/usr/bin /bin/busybox --install -s diff --git a/install/base b/install/base index 84e7f02..c0c19d2 100644 --- a/install/base +++ b/install/base @@ -1,10 +1,14 @@ #!/bin/bash build() { - for dir in new_root proc sys dev run usr/{bin,sbin}; do + for dir in new_root proc sys dev run usr/bin; do add_dir "/$dir" done + add_symlink /sbin usr/bin + add_symlink /bin usr/bin + add_symlink /usr/sbin bin + add_binary /lib/initcpio/busybox /bin/busybox add_binary /sbin/modprobe add_binary /sbin/blkid -- 1.7.7.3
This means that no "setup" of the initramfs is requried on boot, and this should make testing a lot eaiser by just chrooting into the ramfs to check if it works. Signed-off-by: Tom Gundersen <teg@jklm.no> --- init | 2 -- install/base | 5 +++++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/init b/init index beb697c..ff65905 100644 --- a/init +++ b/init @@ -1,8 +1,6 @@ #!/usr/bin/ash PATH=/usr/bin -/bin/busybox --install -s - . /init_functions mount -t proc proc /proc -o nosuid,noexec,nodev diff --git a/install/base b/install/base index c0c19d2..59c3629 100644 --- a/install/base +++ b/install/base @@ -10,6 +10,11 @@ build() { add_symlink /usr/sbin bin add_binary /lib/initcpio/busybox /bin/busybox + + for applet in `/lib/initcpio/busybox --list`; do + add_symlink "/usr/bin/$applet" busybox + done + add_binary /sbin/modprobe add_binary /sbin/blkid add_binary /bin/mount -- 1.7.7.3
Am 17.11.2011 17:08, schrieb Tom Gundersen:
This is useful for the future shutdown hook, and might make debugging easier, as well as potentially opening up for other usecases (that I cannot yet imagine ;-) ).
Unconditionally doing this seems like a bad idea, and many people will complain. Please only do this when needed/requested.
On Fri, Nov 18, 2011 at 3:52 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Unconditionally doing this seems like a bad idea, and many people will complain. Please only do this when needed/requested.
I guess I see your point, but just to be difficult: Why do you think it is a bad idea? I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference. I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem. -t
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem.
Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). Other than that, people WILL complain.
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem.
Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC).
That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing this stuff to be switched off). [untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?]
Other than that, people WILL complain.
Undoubtedly. They always do. -t
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote:
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem.
Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC).
That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?]
No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying physical mount.
Other than that, people WILL complain.
Undoubtedly. They always do.
Always. d
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem. Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d,
On 11/17/2011 10:21 PM, Dave Reisner wrote: that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;) Why no just copy the needed files? Yes needs more steps...
Other than that, people WILL complain. Undoubtedly. They always do.
Always.
d
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 10:21 PM, Dave Reisner wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem. Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d, that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;)
No, this has nothing to do with chrooting. The point is that if you're walking through a directory structure for an operation that's required to stay on a single filesystem, you're stat'ing every directory before descending into it (my example was actually backwards). Written in (probably nonworking) shell.. walk() { local pwd_dev dir_dev pwd_dev=$(stat -c %d "$1") for f in *; do if [[ -d $f ]]; then dir_dev=$(stat -c "$1/$f") if (( pwd_dev != dir_dev )); then # this is a mountpoint, skip it continue fi walk "$f" else callback "$f" fi done } walk /
Why no just copy the needed files? Yes needs more steps...
Because I don't want to have to calculate what's needed for teardown on an encrypted LVM root device. Make it optional, and everything is copasetic. d
On 11/17/2011 11:03 PM, Dave Reisner wrote:
On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 10:21 PM, Dave Reisner wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem. Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d, that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;) No, this has nothing to do with chrooting. I did nothing about chroot. misreading?
The point is that if you're walking through a directory structure for an operation that's required to stay on a single filesystem, you're stat'ing every directory before descending into it (my example was actually backwards). Written in (probably nonworking) shell..
walk() { local pwd_dev dir_dev
pwd_dev=$(stat -c %d "$1")
for f in *; do if [[ -d $f ]]; then dir_dev=$(stat -c "$1/$f") if (( pwd_dev != dir_dev )); then # this is a mountpoint, skip it continue fi walk "$f" else callback "$f" fi done }
walk / Sure, but you can not access files under lower mountpoint using the same
In shell terms Point1: * we are on rootfs (special case of tmpfs/ramfs) the HEAD of vfsmount * mkdir /a mkdir /b mount --bind /a /b <- this will not work, you can not reference a unnamed mountpoint. (for the same reason that you can not pivot_root and must use switch_root) Point2: * we are on any normal mount point * mkdir -p src/{a,b} dst touch src/a/s src/b/t mount --bind src/b src/a cp -ax src dst cp: will not create hard link `dst/src/a' to directory `dst/src/b' path. Or I am misunderstood something?
Why no just copy the needed files? Yes needs more steps... Because I don't want to have to calculate what's needed for teardown on an encrypted LVM root device. Make it optional, and everything is copasetic.
d
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Thu, Nov 17, 2011 at 11:48:27PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 11:03 PM, Dave Reisner wrote:
On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 10:21 PM, Dave Reisner wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen: >I see two potential issues: boot speed and memory use. Moving stuff >around in memory should be pretty much instantaneous, and the memory >(a couple of MB) will be swapped out quick enough so it shouldn't make >a difference. > >I'd be happy to write a new patch where this is optional, but I don't >think we should optimize for stuff unless we know it is a measurable >problem. Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d, that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;) No, this has nothing to do with chrooting. I did nothing about chroot. misreading?
I assumed you were when you mentioned files "under" a mount.
In shell terms
Point1: * we are on rootfs (special case of tmpfs/ramfs) the HEAD of vfsmount *
mkdir /a mkdir /b mount --bind /a /b <- this will not work, you can not reference a
No, that absolutely _will_ work. Binding arbitrary directories is totally kosher, and I do it fairly frequently. You can even bind mount files, i.e. echo blah > foo touch bar mount -B foo bar When you 'cat bar' it will have the same contents as 'foo'.
unnamed mountpoint. (for the same reason that you can not pivot_root and must use switch_root)
Point2: * we are on any normal mount point *
mkdir -p src/{a,b} dst touch src/a/s src/b/t mount --bind src/b src/a cp -ax src dst cp: will not create hard link `dst/src/a' to directory `dst/src/b'
Seems like its working as intended. There must be some inode comparison going on in addition to the devno check.
The point is that if you're walking through a directory structure for an operation that's required to stay on a single filesystem, you're stat'ing every directory before descending into it (my example was actually backwards). Written in (probably nonworking) shell..
walk() { local pwd_dev dir_dev
pwd_dev=$(stat -c %d "$1")
for f in *; do if [[ -d $f ]]; then dir_dev=$(stat -c "$1/$f") if (( pwd_dev != dir_dev )); then # this is a mountpoint, skip it continue fi walk "$f" else callback "$f" fi done }
walk / Sure, but you can not access files under lower mountpoint using the same path. Or I am misunderstood something?
What's under / is unimportant. We just (have to) assume that its the real root. d
On 11/18/2011 12:03 AM, Dave Reisner wrote:
On Thu, Nov 17, 2011 at 11:48:27PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 11:03 PM, Dave Reisner wrote:
On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 10:21 PM, Dave Reisner wrote:
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: > Am 17.11.2011 18:07, schrieb Tom Gundersen: >> I see two potential issues: boot speed and memory use. Moving stuff >> around in memory should be pretty much instantaneous, and the memory >> (a couple of MB) will be swapped out quick enough so it shouldn't make >> a difference. >> >> I'd be happy to write a new patch where this is optional, but I don't >> think we should optimize for stuff unless we know it is a measurable >> problem. > Depending on what's in there, it could be big. For example, I once wrote > a hook that extracted a tarfile that was stored inside initramfs (that > tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d, that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;) No, this has nothing to do with chrooting. I did nothing about chroot. misreading? I assumed you were when you mentioned files "under" a mount.
In shell terms
Point1: * we are on rootfs (special case of tmpfs/ramfs) the HEAD of vfsmount *
mkdir /a mkdir /b mount --bind /a /b<- this will not work, you can not reference a No, that absolutely _will_ work. Binding arbitrary directories is totally kosher, and I do it fairly frequently. You can even bind mount files, i.e.
echo blah> foo touch bar mount -B foo bar
When you 'cat bar' it will have the same contents as 'foo'. I know, but again, rootfs is the *HEAD* of vfsmount.
[ramfs /]# mkdir a b [ramfs /]# mount --bind a b mount: mounting a on b failed: Invalid argument [ramfs /]# mkdir coco [ramfs /]# mount -t tmpfs coco coco [ramfs /]# cd coco/ [ramfs /coco]# mkdir a b [ramfs /coco]# mount --bind a b [ramfs /coco]# -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, Nov 18, 2011 at 12:12:28AM -0300, Gerardo Exequiel Pozzi wrote:
On 11/18/2011 12:03 AM, Dave Reisner wrote:
No, that absolutely _will_ work. Binding arbitrary directories is totally kosher, and I do it fairly frequently. You can even bind mount files, i.e.
echo blah> foo touch bar mount -B foo bar
When you 'cat bar' it will have the same contents as 'foo'. I know, but again, rootfs is the *HEAD* of vfsmount.
[ramfs /]# mkdir a b [ramfs /]# mount --bind a b mount: mounting a on b failed: Invalid argument [ramfs /]# mkdir coco [ramfs /]# mount -t tmpfs coco coco [ramfs /]# cd coco/ [ramfs /coco]# mkdir a b [ramfs /coco]# mount --bind a b [ramfs /coco]#
Ahh, there's the lightbulb. More specifically, directories in the root can't be bind mounted. Seems the inverse doesn't hold true. [ramfs /]# mkdir /a [ramfs /]# mount -B /run/initramfs/ /a [ramfs /]# umount /a [ramfs /]# mount -B /a /run/initramfs/ mount: wrong fs type, bad option, bad superblock on /a, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so (oh the joys of the soul-less vacuum that is early userspace) d
On 11/18/2011 12:22 AM, Dave Reisner wrote:
On Fri, Nov 18, 2011 at 12:12:28AM -0300, Gerardo Exequiel Pozzi wrote:
On 11/18/2011 12:03 AM, Dave Reisner wrote:
No, that absolutely _will_ work. Binding arbitrary directories is totally kosher, and I do it fairly frequently. You can even bind mount files, i.e.
echo blah> foo touch bar mount -B foo bar
When you 'cat bar' it will have the same contents as 'foo'. I know, but again, rootfs is the *HEAD* of vfsmount.
[ramfs /]# mkdir a b [ramfs /]# mount --bind a b mount: mounting a on b failed: Invalid argument [ramfs /]# mkdir coco [ramfs /]# mount -t tmpfs coco coco [ramfs /]# cd coco/ [ramfs /coco]# mkdir a b [ramfs /coco]# mount --bind a b [ramfs /coco]#
Ahh, there's the lightbulb. More specifically, directories in the root can't be bind mounted. Seems the inverse doesn't hold true. Not exactly. you are mixing things. /run is on another filesystem
When I say rootfs I talk about of a type of filesystem. Do not confuse, rootfs (an special tmpfs/ramfs is the head, it does not have a name, you can not reference, this implies you can not unmount, bind, move and pivot).
[ramfs /]# mkdir /a [ramfs /]# mount -B /run/initramfs/ /a
works because you are binding a tmpfs. repeat the same with /somedir/lalala, the result is exactly as below....
[ramfs /]# umount /a
[ramfs /]# mount -B /a /run/initramfs/ mount: wrong fs type, bad option, bad superblock on /a, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so does not works because you are trying to reference an "unnamed" mountpoint. There is no "source" for such fs.
(oh the joys of the soul-less vacuum that is early userspace)
d
haha :P -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, Nov 18, 2011 at 12:44:51AM -0300, Gerardo Exequiel Pozzi wrote:
On 11/18/2011 12:22 AM, Dave Reisner wrote:
On Fri, Nov 18, 2011 at 12:12:28AM -0300, Gerardo Exequiel Pozzi wrote:
On 11/18/2011 12:03 AM, Dave Reisner wrote:
No, that absolutely _will_ work. Binding arbitrary directories is totally kosher, and I do it fairly frequently. You can even bind mount files, i.e.
echo blah> foo touch bar mount -B foo bar
When you 'cat bar' it will have the same contents as 'foo'. I know, but again, rootfs is the *HEAD* of vfsmount.
[ramfs /]# mkdir a b [ramfs /]# mount --bind a b mount: mounting a on b failed: Invalid argument [ramfs /]# mkdir coco [ramfs /]# mount -t tmpfs coco coco [ramfs /]# cd coco/ [ramfs /coco]# mkdir a b [ramfs /coco]# mount --bind a b [ramfs /coco]#
Ahh, there's the lightbulb. More specifically, directories in the root can't be bind mounted. Seems the inverse doesn't hold true. Not exactly. you are mixing things. /run is on another filesystem
When I say rootfs I talk about of a type of filesystem.
Do not confuse, rootfs (an special tmpfs/ramfs is the head, it does not have a name, you can not reference, this implies you can not unmount, bind, move and pivot).
d'oh, right. poor place to test my assumptions. time for sleep, dave. yeah, it all makes sense.
[ramfs /]# mkdir /a [ramfs /]# mount -B /run/initramfs/ /a
works because you are binding a tmpfs. repeat the same with /somedir/lalala, the result is exactly as below....
[ramfs /]# umount /a
[ramfs /]# mount -B /a /run/initramfs/ mount: wrong fs type, bad option, bad superblock on /a, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so does not works because you are trying to reference an "unnamed" mountpoint. There is no "source" for such fs.
(oh the joys of the soul-less vacuum that is early userspace)
d
haha :P
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, Nov 18, 2011 at 1:03 PM, Dave Reisner <d@falconindy.com> wrote:
On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 10:21 PM, Dave Reisner wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen:
I see two potential issues: boot speed and memory use. Moving stuff around in memory should be pretty much instantaneous, and the memory (a couple of MB) will be swapped out quick enough so it shouldn't make a difference.
I'd be happy to write a new patch where this is optional, but I don't think we should optimize for stuff unless we know it is a measurable problem. Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d, that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;)
No, this has nothing to do with chrooting. The point is that if you're walking through a directory structure for an operation that's required to stay on a single filesystem, you're stat'ing every directory before descending into it (my example was actually backwards). Written in (probably nonworking) shell..
walk() { local pwd_dev dir_dev
pwd_dev=$(stat -c %d "$1")
for f in *; do if [[ -d $f ]]; then dir_dev=$(stat -c "$1/$f") if (( pwd_dev != dir_dev )); then # this is a mountpoint, skip it continue fi walk "$f" else callback "$f" fi done }
walk /
Why no just copy the needed files? Yes needs more steps...
Because I don't want to have to calculate what's needed for teardown on an encrypted LVM root device. Make it optional, and everything is copasetic.
From the point of view of initscripts it would be very nice to know
Thanks for the explanations Dave and Gerardo. I agree that it would be best to just copy everything, which would not require us to do anything fancy. Still not sold on making it optional though. At least wait until someone can point to a use-case and some numbers that shows a real problem. If the initramfs is sufficiently huge, the time taken to copy it to /run would obviously be measurable. However, the time taken to extract the initramfs in the first place would probably dwarf this number. If we start making things optional we'd have something like this: copying /run/initramfs is required by "shutdown" and "shutdown" is required by "usr". But all users who have a separate /usr must use the "usr" hook, and all users really should use the "shutdown" hook. So unless we find a case where including a hook causes some sort of real downside I'd say just make it unconditional, and thereby reduce the number of configurations we'd have to test. that /usr is always mounted, and if the rootfs is on lvm or something like that it will always be torn down properly, without worrying about users possibly disabling these hooks in mkinitcpio. Just my two cents. -t
On 11/18/2011 03:26 AM, Tom Gundersen wrote:
On Fri, Nov 18, 2011 at 1:03 PM, Dave Reisner<d@falconindy.com> wrote:
On Thu, Nov 17, 2011 at 10:51:37PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 10:21 PM, Dave Reisner wrote:
Am 17.11.2011 18:07, schrieb Tom Gundersen: > I see two potential issues: boot speed and memory use. Moving stuff > around in memory should be pretty much instantaneous, and the memory > (a couple of MB) will be swapped out quick enough so it shouldn't make > a difference. > > I'd be happy to write a new patch where this is optional, but I don't > think we should optimize for stuff unless we know it is a measurable > problem. Depending on what's in there, it could be big. For example, I once wrote a hook that extracted a tarfile that was stored inside initramfs (that tarfile was the whole root filesystem IIRC). That's something to take into consideration. I think it would be best if we were able to optimize the cases that need it by adding some exceptions to the copying, but still keep the bits needed for shutdown++, rather than disabling it altogether. Having huge initramfs' being a corner case, any workaround should of course be unintrusive (if that is not possible then I agree on just allowing
On Fri, Nov 18, 2011 at 5:23 AM, Thomas Bächler<thomas@archlinux.org> wrote: this stuff to be switched off).
[untested: would bindmounting a directory (like say /lib/modules) to itself exclude it from "cp -ax"?] No, it won't. Generally, detection of crossing onto another mount is done by comparing the devno of '.' to the devno of '..'. Bind mounts aren't special in this regard -- they'll just expose the underlying
On Fri, Nov 18, 2011 at 11:42:43AM +1100, Tom Gundersen wrote: physical mount. Mmm no, you can not access to files in underliying mount from such path. Anyway the rootfs is the HEAD of vfsmount, so you can not bind/move/pivot. :P But supose that you can do a bindmount... -a is used that implies -d, that implies --preserve=links, in that case cp will fails because will try to create a link to directory. ;) No, this has nothing to do with chrooting. The point is that if you're walking through a directory structure for an operation that's required to stay on a single filesystem, you're stat'ing every directory before descending into it (my example was actually backwards). Written in (probably nonworking) shell..
walk() { local pwd_dev dir_dev
pwd_dev=$(stat -c %d "$1")
for f in *; do if [[ -d $f ]]; then dir_dev=$(stat -c "$1/$f") if (( pwd_dev != dir_dev )); then # this is a mountpoint, skip it continue fi walk "$f" else callback "$f" fi done }
walk /
Why no just copy the needed files? Yes needs more steps... Because I don't want to have to calculate what's needed for teardown on an encrypted LVM root device. Make it optional, and everything is copasetic. Thanks for the explanations Dave and Gerardo.
I agree that it would be best to just copy everything, which would not require us to do anything fancy.
Still not sold on making it optional though. At least wait until someone can point to a use-case and some numbers that shows a real problem. If the initramfs is sufficiently huge, the time taken to copy it to /run would obviously be measurable. However, the time taken to extract the initramfs in the first place would probably dwarf this number.
If we start making things optional we'd have something like this:
copying /run/initramfs is required by "shutdown" and "shutdown" is required by "usr".
But all users who have a separate /usr must use the "usr" hook, and all users really should use the "shutdown" hook. So unless we find a case where including a hook causes some sort of real downside I'd say just make it unconditional, and thereby reduce the number of configurations we'd have to test.
From the point of view of initscripts it would be very nice to know that /usr is always mounted, and if the rootfs is on lvm or something like that it will always be torn down properly, without worrying about users possibly disabling these hooks in mkinitcpio.
Just my two cents.
-t
You are welcome! Note that you can bind mount some dir (outside rootfs) for example in /run, the overlap /lib/modules. Anyway the copy can be done at end of init just before switch_root, just after udev stopped. so you can rm -r /lib/modules ; cp -ax / /run/initramfs PS: uncompressed archiso.img is 22M. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 11/17/2011 01:08 PM, Tom Gundersen wrote:
This is useful for the future shutdown hook, and might make debugging easier, as well as potentially opening up for other usecases (that I cannot yet imagine ;-) ).
Signed-off-by: Tom Gundersen<teg@jklm.no> --- init | 2 +- install/base | 1 + 2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/init b/init index 7cc2d47..3c6fb81 100644 --- a/init +++ b/init @@ -21,7 +21,7 @@ else mknod /dev/mem c 1 1 fi mount -t tmpfs run /run -o nosuid,nodev,mode=755,size=10M -mkdir /run/initramfs +cp -ax / /run/initramfs
# parse the kernel command line parse_cmdline diff --git a/install/base b/install/base index 0726fa2..84e7f02 100644 --- a/install/base +++ b/install/base @@ -10,6 +10,7 @@ build() { add_binary /sbin/blkid add_binary /bin/mount add_binary /sbin/switch_root + add_binary /bin/cp
add_symlink "/etc/mtab" "/proc/self/mounts"
I guess, we should start thinking incrementing size of /run, 10M is becoming small, for example I am using 56% due archiso_shutdown hook (it takes 5.3M). -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, Nov 25, 2011 at 11:34:17PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 01:08 PM, Tom Gundersen wrote:
This is useful for the future shutdown hook, and might make debugging easier, as well as potentially opening up for other usecases (that I cannot yet imagine ;-) ).
Signed-off-by: Tom Gundersen<teg@jklm.no> --- init | 2 +- install/base | 1 + 2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/init b/init index 7cc2d47..3c6fb81 100644 --- a/init +++ b/init @@ -21,7 +21,7 @@ else mknod /dev/mem c 1 1 fi mount -t tmpfs run /run -o nosuid,nodev,mode=755,size=10M -mkdir /run/initramfs +cp -ax / /run/initramfs
# parse the kernel command line parse_cmdline diff --git a/install/base b/install/base index 0726fa2..84e7f02 100644 --- a/install/base +++ b/install/base @@ -10,6 +10,7 @@ build() { add_binary /sbin/blkid add_binary /bin/mount add_binary /sbin/switch_root + add_binary /bin/cp
add_symlink "/etc/mtab" "/proc/self/mounts"
I guess, we should start thinking incrementing size of /run, 10M is becoming small, for example I am using 56% due archiso_shutdown hook (it takes 5.3M).
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Given that /run is owned by root, I don't see why we need to worry about hard capping the size. d
On 11/25/2011 11:46 PM, Dave Reisner wrote:
On Fri, Nov 25, 2011 at 11:34:17PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 01:08 PM, Tom Gundersen wrote:
This is useful for the future shutdown hook, and might make debugging easier, as well as potentially opening up for other usecases (that I cannot yet imagine ;-) ).
Signed-off-by: Tom Gundersen<teg@jklm.no> --- init | 2 +- install/base | 1 + 2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/init b/init index 7cc2d47..3c6fb81 100644 --- a/init +++ b/init @@ -21,7 +21,7 @@ else mknod /dev/mem c 1 1 fi mount -t tmpfs run /run -o nosuid,nodev,mode=755,size=10M -mkdir /run/initramfs +cp -ax / /run/initramfs
# parse the kernel command line parse_cmdline diff --git a/install/base b/install/base index 0726fa2..84e7f02 100644 --- a/install/base +++ b/install/base @@ -10,6 +10,7 @@ build() { add_binary /sbin/blkid add_binary /bin/mount add_binary /sbin/switch_root + add_binary /bin/cp
add_symlink "/etc/mtab" "/proc/self/mounts"
I guess, we should start thinking incrementing size of /run, 10M is becoming small, for example I am using 56% due archiso_shutdown hook (it takes 5.3M).
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Given that /run is owned by root, I don't see why we need to worry about hard capping the size.
d Sure I never understand why limiting this, also for /dev. Initial patch [#1], size limit added [#2]
[#1] http://projects.archlinux.org/initscripts.git/commit/?id=e5248347fd0c00e9ea7... [#2] http://projects.archlinux.org/initscripts.git/commit/?id=757f653b8c9ba9d671d... -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Sat, Nov 26, 2011 at 4:03 AM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 11/25/2011 11:46 PM, Dave Reisner wrote:
On Fri, Nov 25, 2011 at 11:34:17PM -0300, Gerardo Exequiel Pozzi wrote:
On 11/17/2011 01:08 PM, Tom Gundersen wrote:
This is useful for the future shutdown hook, and might make debugging easier, as well as potentially opening up for other usecases (that I cannot yet imagine ;-) ).
Signed-off-by: Tom Gundersen<teg@jklm.no> --- init | 2 +- install/base | 1 + 2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/init b/init index 7cc2d47..3c6fb81 100644 --- a/init +++ b/init @@ -21,7 +21,7 @@ else mknod /dev/mem c 1 1 fi mount -t tmpfs run /run -o nosuid,nodev,mode=755,size=10M -mkdir /run/initramfs +cp -ax / /run/initramfs
# parse the kernel command line parse_cmdline diff --git a/install/base b/install/base index 0726fa2..84e7f02 100644 --- a/install/base +++ b/install/base @@ -10,6 +10,7 @@ build() { add_binary /sbin/blkid add_binary /bin/mount add_binary /sbin/switch_root + add_binary /bin/cp
add_symlink "/etc/mtab" "/proc/self/mounts"
I guess, we should start thinking incrementing size of /run, 10M is becoming small, for example I am using 56% due archiso_shutdown hook (it takes 5.3M).
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Given that /run is owned by root, I don't see why we need to worry about hard capping the size.
d
Sure I never understand why limiting this, also for /dev. Initial patch [#1], size limit added [#2]
[#1] http://projects.archlinux.org/initscripts.git/commit/?id=e5248347fd0c00e9ea7... [#2] http://projects.archlinux.org/initscripts.git/commit/?id=757f653b8c9ba9d671d...
I agree, we should probably just stop doing this. Worst case scenario something fills up dev/run, but it sure is worse running out of space on dev or run, than it is to potentially run out of memory... (?) -t
participants (4)
-
Dave Reisner
-
Gerardo Exequiel Pozzi
-
Thomas Bächler
-
Tom Gundersen