Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
I had this unsent on my desktop, buried by other windows. Let me know if the conversation's moved on since, but if so I wasn't cc'd... On Thursday 19 July 2007 9:56:11 am Bodo Eggert wrote: > On Wed, 18 Jul 2007, Rob Landley wrote: > > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: > > > I toyed with setting up a diskless system in initramfs. In the process, > > > I came across some things: > > > > > > 1) There is no way to have the kernel not mount a filesystem, > > > unless you use /init or rdinit=. > > > > Er, yes. By design. > > > > The kernel has to run an init program in order to hand off control to > > userspace. In initramfs, this is defined as /init. It looks in exactly > > one documented place. > > > > The older root= mechanism fell back to a half-dozen places (eventually > > trying things like /bin/sh if it couldn't find anything else). This is > > because there wasn't a documented standard for what should be executed, > > like there is with initramfs. > > Ever since I started using linux in 1997, the first program to run from an > installed system was /sbin/init. (I might think about removing the other > paths.) So pass in rdinit=/sbin/init. (Back in 1997 you didn't have to specify "root=", you used rdev.) > The ramfs' /init was intended for system setup, which is a separate job. The ramfs /init was "intended" to be the first process to run, which inherits PID 1 and thus all responsibility for further system setup. You can't return back to the kernel from that, it panics if PID 1 exits. Whether you choose to do "system setup" or keep running with rootfs as your root filesystem (very popular with embedded devices) is not the kernel's problem. This has been documented and has worked fine for years. Note that the initrd mechanism (which used to run /linuxrc) was _not_ PID 1, and expected you to return to the kernel. That's one of the big improvements initramfs made over initrd. > It is not intended to be the program running the system. That's policy, and none of the kernel's business. > Mixing those two > up just does not feel right. You're mixing them in your head, and it sounds like you don't understand what it's doing. > Setting root= in order to change the root > directory is much more natural. Setting root= is not _used_ if initramfs triggers, because /init gets run before ever reaching that code. In initramfs, the root filesystem is rootfs, and no attempt to mount anything else is made by the kernel unless userspace explicitly asks for it. Userspace is welcome to mount anything it wants, and userspace can switch_root to it, but that's not the kernel's problem. > > > 1a) In the process of writing these patches, I found prepare_namespace > > > not to be called if /init is present. prepare_namespace will call > > > security_sb_post_mountroot after mounting the root fs. I did not > > > yet see a way to call this from /init, and grepping kinit for > > > "security" did not help, too. > > > > I don't use selinux. I'm neither a Fortune 500 company nor the NSA. > > That's no reason for keeping bugs in that part. *shrug* I was saying I can't really comment much on a subsystem I neither use nor see much point in. > > However, if you don't trust your own initramfs, where everything starts > > out running as root, you have bigger problems. > > Using that argument, you can deduce that nobody would need selinux at all. Yeah, pretty much. Then again I feel the same way about the Itanium, and try to stay out of the way of people who feel they do need it. > Obviously some people disagree, and maybe some of them are no fools, > therefore we should try to DTRT for them and do the callback when it's > supposed to happen. > > BTW: The problems start as soon as you have to do "reflections on trusting > trust". Which led to David Wheeler's "diverse double-compiling": http://www.dwheeler.com/trusting-trust/ Which led to rather a lot of patches being integrated into the tcc fork I maintain in my nonexistent free time, such as: http://www.landley.net/hg/tinycc?cs=e6ddaffce6a8 > > > Using tmpfs instead for the first root mount is as cheap as > > > using ramfs, as long as tmpfs is used anyway (and most likely it is). > > > > *shrug* I don't object to doing so, but I've heard nebulous technical > > objections from people who know more about the implementation details fo > > tmpfs than I do. > > Obviously these problems were solved. I'm all for a patch to make initramfs use tmpfs. I'm kind of dubious about one coming from somebody who thinks that the initramfs interface in use by thousands of developers for years now needs to be totally rewritten as a prerequisite of doing so. > > > 2a) I figured if you prepared the root fs to contain a running system, > > > you woud probably also set up a runnable system on it. > > > > *scratches head* > > > > That's a tautology, right? > > You may also use the same kernel with the same initramfs in order to
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
I had this unsent on my desktop, buried by other windows. Let me know if the conversation's moved on since, but if so I wasn't cc'd... On Thursday 19 July 2007 9:56:11 am Bodo Eggert wrote: On Wed, 18 Jul 2007, Rob Landley wrote: On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. Er, yes. By design. The kernel has to run an init program in order to hand off control to userspace. In initramfs, this is defined as /init. It looks in exactly one documented place. The older root= mechanism fell back to a half-dozen places (eventually trying things like /bin/sh if it couldn't find anything else). This is because there wasn't a documented standard for what should be executed, like there is with initramfs. Ever since I started using linux in 1997, the first program to run from an installed system was /sbin/init. (I might think about removing the other paths.) So pass in rdinit=/sbin/init. (Back in 1997 you didn't have to specify root=, you used rdev.) The ramfs' /init was intended for system setup, which is a separate job. The ramfs /init was intended to be the first process to run, which inherits PID 1 and thus all responsibility for further system setup. You can't return back to the kernel from that, it panics if PID 1 exits. Whether you choose to do system setup or keep running with rootfs as your root filesystem (very popular with embedded devices) is not the kernel's problem. This has been documented and has worked fine for years. Note that the initrd mechanism (which used to run /linuxrc) was _not_ PID 1, and expected you to return to the kernel. That's one of the big improvements initramfs made over initrd. It is not intended to be the program running the system. That's policy, and none of the kernel's business. Mixing those two up just does not feel right. You're mixing them in your head, and it sounds like you don't understand what it's doing. Setting root= in order to change the root directory is much more natural. Setting root= is not _used_ if initramfs triggers, because /init gets run before ever reaching that code. In initramfs, the root filesystem is rootfs, and no attempt to mount anything else is made by the kernel unless userspace explicitly asks for it. Userspace is welcome to mount anything it wants, and userspace can switch_root to it, but that's not the kernel's problem. 1a) In the process of writing these patches, I found prepare_namespace not to be called if /init is present. prepare_namespace will call security_sb_post_mountroot after mounting the root fs. I did not yet see a way to call this from /init, and grepping kinit for security did not help, too. I don't use selinux. I'm neither a Fortune 500 company nor the NSA. That's no reason for keeping bugs in that part. *shrug* I was saying I can't really comment much on a subsystem I neither use nor see much point in. However, if you don't trust your own initramfs, where everything starts out running as root, you have bigger problems. Using that argument, you can deduce that nobody would need selinux at all. Yeah, pretty much. Then again I feel the same way about the Itanium, and try to stay out of the way of people who feel they do need it. Obviously some people disagree, and maybe some of them are no fools, therefore we should try to DTRT for them and do the callback when it's supposed to happen. BTW: The problems start as soon as you have to do reflections on trusting trust. Which led to David Wheeler's diverse double-compiling: http://www.dwheeler.com/trusting-trust/ Which led to rather a lot of patches being integrated into the tcc fork I maintain in my nonexistent free time, such as: http://www.landley.net/hg/tinycc?cs=e6ddaffce6a8 Using tmpfs instead for the first root mount is as cheap as using ramfs, as long as tmpfs is used anyway (and most likely it is). *shrug* I don't object to doing so, but I've heard nebulous technical objections from people who know more about the implementation details fo tmpfs than I do. Obviously these problems were solved. I'm all for a patch to make initramfs use tmpfs. I'm kind of dubious about one coming from somebody who thinks that the initramfs interface in use by thousands of developers for years now needs to be totally rewritten as a prerequisite of doing so. 2a) I figured if you prepared the root fs to contain a running system, you woud probably also set up a runnable system on it. *scratches head* That's a tautology, right? You may also use the same kernel with the same initramfs in order to start a classic system, just by changing root=. Do you mean if you program initramfs to parse the environment variable root, or
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Thu, 19 Jul 2007, Stephen Smalley wrote: > Not wanting to get into any flamewars here about selinux, but just FYI: > security_sb_post_mountroot is obsolete and can be removed without harm > to selinux; it is a leftover of selinux before we moved the initial > policy load to userspace. These days, initial policy load is done > by /sbin/init in most distros that support selinux, although I'd prefer > to do it earlier from the initramfs (the Fedora folks didn't like that > idea though at the time, so /sbin/init got patched instead - but that > was back in 2003, so maybe things have changed). Thanks, that information will help a lot. -- Funny quotes: 7. You have the right to remain silent. Anything you say will be misquoted, then used against you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Thu, 2007-07-19 at 15:56 +0200, Bodo Eggert wrote: > On Wed, 18 Jul 2007, Rob Landley wrote: > > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: > > > > I toyed with setting up a diskless system in initramfs. In the process, I > > > came across some things: > > > > > > 1) There is no way to have the kernel not mount a filesystem, > > > unless you use /init or rdinit=. > > > > Er, yes. By design. > > > > The kernel has to run an init program in order to hand off control to > > userspace. In initramfs, this is defined as /init. It looks in exactly > > one > > documented place. > > > > The older root= mechanism fell back to a half-dozen places (eventually > > trying > > things like /bin/sh if it couldn't find anything else). This is because > > there wasn't a documented standard for what should be executed, like there > > is > > with initramfs. > > Ever since I started using linux in 1997, the first program to run from an > installed system was /sbin/init. (I might think about removing the other > paths.) > > The ramfs' /init was intended for system setup, which is a separate job. > It is not intended to be the program running the system. Mixing those two > up just does not feel right. Setting root= in order to change the root > directory is much more natural. > > > > 1a) In the process of writing these patches, I found prepare_namespace not > > > to be called if /init is present. prepare_namespace will call > > > security_sb_post_mountroot after mounting the root fs. I did not yet > > > see a way to call this from /init, and grepping kinit for "security" did > > > not help, too. > > > > I don't use selinux. I'm neither a Fortune 500 company nor the NSA. > > That's no reason for keeping bugs in that part. > > > However, if you don't trust your own initramfs, where everything starts out > > running as root, you have bigger problems. > > Using that argument, you can deduce that nobody would need selinux at all. > Obviously some people disagree, and maybe some of them are no fools, > therefore we should try to DTRT for them and do the callback when it's > supposed to happen. Not wanting to get into any flamewars here about selinux, but just FYI: security_sb_post_mountroot is obsolete and can be removed without harm to selinux; it is a leftover of selinux before we moved the initial policy load to userspace. These days, initial policy load is done by /sbin/init in most distros that support selinux, although I'd prefer to do it earlier from the initramfs (the Fedora folks didn't like that idea though at the time, so /sbin/init got patched instead - but that was back in 2003, so maybe things have changed). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Wed, 18 Jul 2007, Rob Landley wrote: > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: > > I toyed with setting up a diskless system in initramfs. In the process, I > > came across some things: > > > > 1) There is no way to have the kernel not mount a filesystem, > > unless you use /init or rdinit=. > > Er, yes. By design. > > The kernel has to run an init program in order to hand off control to > userspace. In initramfs, this is defined as /init. It looks in exactly one > documented place. > > The older root= mechanism fell back to a half-dozen places (eventually trying > things like /bin/sh if it couldn't find anything else). This is because > there wasn't a documented standard for what should be executed, like there is > with initramfs. Ever since I started using linux in 1997, the first program to run from an installed system was /sbin/init. (I might think about removing the other paths.) The ramfs' /init was intended for system setup, which is a separate job. It is not intended to be the program running the system. Mixing those two up just does not feel right. Setting root= in order to change the root directory is much more natural. > > 1a) In the process of writing these patches, I found prepare_namespace not > > to be called if /init is present. prepare_namespace will call > > security_sb_post_mountroot after mounting the root fs. I did not yet > > see a way to call this from /init, and grepping kinit for "security" did > > not help, too. > > I don't use selinux. I'm neither a Fortune 500 company nor the NSA. That's no reason for keeping bugs in that part. > However, if you don't trust your own initramfs, where everything starts out > running as root, you have bigger problems. Using that argument, you can deduce that nobody would need selinux at all. Obviously some people disagree, and maybe some of them are no fools, therefore we should try to DTRT for them and do the callback when it's supposed to happen. BTW: The problems start as soon as you have to do "reflections on trusting trust". > >This is probably a bug, but using the features of this patchset, you'll > >avoid hitting it. Therefore this patchset does nothing about that. > > > > 2) If you want to use tmpfs, you need a script which essentially > > duplicates the work the kernel just did: Mount the root fs, unpack or move > > the files. > > mkdir sub > mount -t tmpfs sub sub > cp -ax / sub > switch_root sub /init-stage-2 > > I haven't tried it but it really doesn't sound like brain surgery. If your > switch_root is statically linked, you can use mv instead of cp. Why should I have to do that if I can do the right thing in the first place with in each respect negative costs? > > Using tmpfs instead for the first root mount is as cheap as > > using ramfs, as long as tmpfs is used anyway (and most likely it is). > > *shrug* I don't object to doing so, but I've heard nebulous technical > objections from people who know more about the implementation details fo > tmpfs than I do. Obviously these problems were solved. > > 2a) I figured if you prepared the root fs to contain a running system, you > > woud probably also set up a runnable system on it. > > *scratches head* > > That's a tautology, right? You may also use the same kernel with the same initramfs in order to start a classic system, just by changing root=. This may be nice for rescue systems. Off cause after applying the third patch, you may also unselect that feature. > > Therefore I changed > > the default to boot from tmpfs if there was no /init nor a root= > > option. (If there is a /init, it will be executed as usural.) > > I have no idea what you just said. If there's an /init, we boot from it. If > there's no /init, they just violated the spec and we don't know what to boot > from. These patches changes the spec in order to support system-on-rootfs: If there is an init, it will run. No change from the current situation ever, at least if not using rdev. If you use root=rootfs, a system-on-rootfs will run. If you use rootfs=tmpfs, root= will default to rootfs, and I did it in a way disabeling that obsolete rdev. > They made an initramfs. They constructed it, explicitly, for the Linux > kernel, and /init is what the kernel will try to boot. I documented this > years ago. If they chose not to put an /init, then they didn't want us to > boot from initramfs. (Maybe they're supplying firmware and an /sbin/hotplug > for a statically linked device. I dunno.) Not booting /using/ an intramfs differs from not booting /from/ an intramfs. Mixing them works by accident. > > Unfortunately the way I do it, this will override the rdev setting, but > > that should be OK, since rdev is dead. Isn't it? > > > > 3) While I was at it, I figured I would not need most of the init/mount* > > code anymore. Therefore I made patch 3, which ifdefs it out as far as > > possible while still
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Wed, 18 Jul 2007, Rob Landley wrote: On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. Er, yes. By design. The kernel has to run an init program in order to hand off control to userspace. In initramfs, this is defined as /init. It looks in exactly one documented place. The older root= mechanism fell back to a half-dozen places (eventually trying things like /bin/sh if it couldn't find anything else). This is because there wasn't a documented standard for what should be executed, like there is with initramfs. Ever since I started using linux in 1997, the first program to run from an installed system was /sbin/init. (I might think about removing the other paths.) The ramfs' /init was intended for system setup, which is a separate job. It is not intended to be the program running the system. Mixing those two up just does not feel right. Setting root= in order to change the root directory is much more natural. 1a) In the process of writing these patches, I found prepare_namespace not to be called if /init is present. prepare_namespace will call security_sb_post_mountroot after mounting the root fs. I did not yet see a way to call this from /init, and grepping kinit for security did not help, too. I don't use selinux. I'm neither a Fortune 500 company nor the NSA. That's no reason for keeping bugs in that part. However, if you don't trust your own initramfs, where everything starts out running as root, you have bigger problems. Using that argument, you can deduce that nobody would need selinux at all. Obviously some people disagree, and maybe some of them are no fools, therefore we should try to DTRT for them and do the callback when it's supposed to happen. BTW: The problems start as soon as you have to do reflections on trusting trust. This is probably a bug, but using the features of this patchset, you'll avoid hitting it. Therefore this patchset does nothing about that. 2) If you want to use tmpfs, you need a script which essentially duplicates the work the kernel just did: Mount the root fs, unpack or move the files. mkdir sub mount -t tmpfs sub sub cp -ax / sub switch_root sub /init-stage-2 I haven't tried it but it really doesn't sound like brain surgery. If your switch_root is statically linked, you can use mv instead of cp. Why should I have to do that if I can do the right thing in the first place with in each respect negative costs? Using tmpfs instead for the first root mount is as cheap as using ramfs, as long as tmpfs is used anyway (and most likely it is). *shrug* I don't object to doing so, but I've heard nebulous technical objections from people who know more about the implementation details fo tmpfs than I do. Obviously these problems were solved. 2a) I figured if you prepared the root fs to contain a running system, you woud probably also set up a runnable system on it. *scratches head* That's a tautology, right? You may also use the same kernel with the same initramfs in order to start a classic system, just by changing root=. This may be nice for rescue systems. Off cause after applying the third patch, you may also unselect that feature. Therefore I changed the default to boot from tmpfs if there was no /init nor a root= option. (If there is a /init, it will be executed as usural.) I have no idea what you just said. If there's an /init, we boot from it. If there's no /init, they just violated the spec and we don't know what to boot from. These patches changes the spec in order to support system-on-rootfs: If there is an init, it will run. No change from the current situation ever, at least if not using rdev. If you use root=rootfs, a system-on-rootfs will run. If you use rootfs=tmpfs, root= will default to rootfs, and I did it in a way disabeling that obsolete rdev. They made an initramfs. They constructed it, explicitly, for the Linux kernel, and /init is what the kernel will try to boot. I documented this years ago. If they chose not to put an /init, then they didn't want us to boot from initramfs. (Maybe they're supplying firmware and an /sbin/hotplug for a statically linked device. I dunno.) Not booting /using/ an intramfs differs from not booting /from/ an intramfs. Mixing them works by accident. Unfortunately the way I do it, this will override the rdev setting, but that should be OK, since rdev is dead. Isn't it? 3) While I was at it, I figured I would not need most of the init/mount* code anymore. Therefore I made patch 3, which ifdefs it out as far as possible while still aiming for a small change. Patch 1 adds the capability to use root=rootfs. I've been using
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Thu, 2007-07-19 at 15:56 +0200, Bodo Eggert wrote: On Wed, 18 Jul 2007, Rob Landley wrote: On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. Er, yes. By design. The kernel has to run an init program in order to hand off control to userspace. In initramfs, this is defined as /init. It looks in exactly one documented place. The older root= mechanism fell back to a half-dozen places (eventually trying things like /bin/sh if it couldn't find anything else). This is because there wasn't a documented standard for what should be executed, like there is with initramfs. Ever since I started using linux in 1997, the first program to run from an installed system was /sbin/init. (I might think about removing the other paths.) The ramfs' /init was intended for system setup, which is a separate job. It is not intended to be the program running the system. Mixing those two up just does not feel right. Setting root= in order to change the root directory is much more natural. 1a) In the process of writing these patches, I found prepare_namespace not to be called if /init is present. prepare_namespace will call security_sb_post_mountroot after mounting the root fs. I did not yet see a way to call this from /init, and grepping kinit for security did not help, too. I don't use selinux. I'm neither a Fortune 500 company nor the NSA. That's no reason for keeping bugs in that part. However, if you don't trust your own initramfs, where everything starts out running as root, you have bigger problems. Using that argument, you can deduce that nobody would need selinux at all. Obviously some people disagree, and maybe some of them are no fools, therefore we should try to DTRT for them and do the callback when it's supposed to happen. Not wanting to get into any flamewars here about selinux, but just FYI: security_sb_post_mountroot is obsolete and can be removed without harm to selinux; it is a leftover of selinux before we moved the initial policy load to userspace. These days, initial policy load is done by /sbin/init in most distros that support selinux, although I'd prefer to do it earlier from the initramfs (the Fedora folks didn't like that idea though at the time, so /sbin/init got patched instead - but that was back in 2003, so maybe things have changed). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Thu, 19 Jul 2007, Stephen Smalley wrote: Not wanting to get into any flamewars here about selinux, but just FYI: security_sb_post_mountroot is obsolete and can be removed without harm to selinux; it is a leftover of selinux before we moved the initial policy load to userspace. These days, initial policy load is done by /sbin/init in most distros that support selinux, although I'd prefer to do it earlier from the initramfs (the Fedora folks didn't like that idea though at the time, so /sbin/init got patched instead - but that was back in 2003, so maybe things have changed). Thanks, that information will help a lot. -- Funny quotes: 7. You have the right to remain silent. Anything you say will be misquoted, then used against you. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: > I toyed with setting up a diskless system in initramfs. In the process, I > came across some things: > > 1) There is no way to have the kernel not mount a filesystem, > unless you use /init or rdinit=. Er, yes. By design. The kernel has to run an init program in order to hand off control to userspace. In initramfs, this is defined as /init. It looks in exactly one documented place. The older root= mechanism fell back to a half-dozen places (eventually trying things like /bin/sh if it couldn't find anything else). This is because there wasn't a documented standard for what should be executed, like there is with initramfs. > 1a) In the process of writing these patches, I found prepare_namespace not > to be called if /init is present. prepare_namespace will call > security_sb_post_mountroot after mounting the root fs. I did not yet > see a way to call this from /init, and grepping kinit for "security" did > not help, too. I don't use selinux. I'm neither a Fortune 500 company nor the NSA. However, if you don't trust your own initramfs, where everything starts out running as root, you have bigger problems. >This is probably a bug, but using the features of this patchset, you'll >avoid hitting it. Therefore this patchset does nothing about that. > > 2) If you want to use tmpfs, you need a script which essentially > duplicates the work the kernel just did: Mount the root fs, unpack or move > the files. mkdir sub mount -t tmpfs sub sub cp -ax / sub switch_root sub /init-stage-2 I haven't tried it but it really doesn't sound like brain surgery. If your switch_root is statically linked, you can use mv instead of cp. > Using tmpfs instead for the first root mount is as cheap as > using ramfs, as long as tmpfs is used anyway (and most likely it is). *shrug* I don't object to doing so, but I've heard nebulous technical objections from people who know more about the implementation details fo tmpfs than I do. > 2a) I figured if you prepared the root fs to contain a running system, you > woud probably also set up a runnable system on it. *scratches head* That's a tautology, right? > Therefore I changed > the default to boot from tmpfs if there was no /init nor a root= > option. (If there is a /init, it will be executed as usural.) I have no idea what you just said. If there's an /init, we boot from it. If there's no /init, they just violated the spec and we don't know what to boot from. They made an initramfs. They constructed it, explicitly, for the Linux kernel, and /init is what the kernel will try to boot. I documented this years ago. If they chose not to put an /init, then they didn't want us to boot from initramfs. (Maybe they're supplying firmware and an /sbin/hotplug for a statically linked device. I dunno.) > Unfortunately the way I do it, this will override the rdev setting, but > that should be OK, since rdev is dead. Isn't it? > > 3) While I was at it, I figured I would not need most of the init/mount* > code anymore. Therefore I made patch 3, which ifdefs it out as far as > possible while still aiming for a small change. > > Patch 1 adds the capability to use root=rootfs. I've been using initramfs since back around 2.6.12. It works fine. Why are you patching the kernel for something that already works? > Patch 2 adds the capability to use tmpfs for root, default root=rootfs. > ramfs becomes optional if rootfs=tmpfs. > Patch 3 allows to remove the capability of automounting filesystems. > > All patches appyl to 2.6.22.1 Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. Er, yes. By design. The kernel has to run an init program in order to hand off control to userspace. In initramfs, this is defined as /init. It looks in exactly one documented place. The older root= mechanism fell back to a half-dozen places (eventually trying things like /bin/sh if it couldn't find anything else). This is because there wasn't a documented standard for what should be executed, like there is with initramfs. 1a) In the process of writing these patches, I found prepare_namespace not to be called if /init is present. prepare_namespace will call security_sb_post_mountroot after mounting the root fs. I did not yet see a way to call this from /init, and grepping kinit for security did not help, too. I don't use selinux. I'm neither a Fortune 500 company nor the NSA. However, if you don't trust your own initramfs, where everything starts out running as root, you have bigger problems. This is probably a bug, but using the features of this patchset, you'll avoid hitting it. Therefore this patchset does nothing about that. 2) If you want to use tmpfs, you need a script which essentially duplicates the work the kernel just did: Mount the root fs, unpack or move the files. mkdir sub mount -t tmpfs sub sub cp -ax / sub switch_root sub /init-stage-2 I haven't tried it but it really doesn't sound like brain surgery. If your switch_root is statically linked, you can use mv instead of cp. Using tmpfs instead for the first root mount is as cheap as using ramfs, as long as tmpfs is used anyway (and most likely it is). *shrug* I don't object to doing so, but I've heard nebulous technical objections from people who know more about the implementation details fo tmpfs than I do. 2a) I figured if you prepared the root fs to contain a running system, you woud probably also set up a runnable system on it. *scratches head* That's a tautology, right? Therefore I changed the default to boot from tmpfs if there was no /init nor a root= option. (If there is a /init, it will be executed as usural.) I have no idea what you just said. If there's an /init, we boot from it. If there's no /init, they just violated the spec and we don't know what to boot from. They made an initramfs. They constructed it, explicitly, for the Linux kernel, and /init is what the kernel will try to boot. I documented this years ago. If they chose not to put an /init, then they didn't want us to boot from initramfs. (Maybe they're supplying firmware and an /sbin/hotplug for a statically linked device. I dunno.) Unfortunately the way I do it, this will override the rdev setting, but that should be OK, since rdev is dead. Isn't it? 3) While I was at it, I figured I would not need most of the init/mount* code anymore. Therefore I made patch 3, which ifdefs it out as far as possible while still aiming for a small change. Patch 1 adds the capability to use root=rootfs. I've been using initramfs since back around 2.6.12. It works fine. Why are you patching the kernel for something that already works? Patch 2 adds the capability to use tmpfs for root, default root=rootfs. ramfs becomes optional if rootfs=tmpfs. Patch 3 allows to remove the capability of automounting filesystems. All patches appyl to 2.6.22.1 Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: > On Sat, 14 Jul 2007, H. Peter Anvin wrote: > > Bodo Eggert wrote: > > > On Sat, 14 Jul 2007, H. Peter Anvin wrote: > > >> Bodo Eggert wrote: > > >>> Setting the name of the rdinit process to the name of the init > > >>> process in order to select the root device should not be the right > > >>> knob. > > >> > > >> What's wrong with it? > > > > > > rdinit is supposed to be the program that mounts, root is supposed to > > > be whatever is mounted and init is supposed to run the system. Three > > > different things. Now if you want to change the third, just set the > > > first to the second ... > > > > That only applies to a model that you explicitly doesn't want to use. > > I don't want to use rdinit, because there is no task for rdinit(3), and I > don't want to mount a filesystem(3). But I do want to use init(2). > > I have to lie to the kernel saying (2) is (1) in order to trick it into > beleaving I'd do (3) myself, which I don't, just in order to not do (3). > If the bug of not calling the security hook would be fixed, this trick > would use the path where rdinit is expected to trigger the callback, but > since that rdinit would be no rdinit, that callback would still be wrongly > skipped. That would not be a bad thing for my setup, but it clearly shows > this setup to be wrong. > > The correct solution is tell the kernel not to do (3) if you don't want > it to do (3). The rest will work as intended. Sounds rather confusing. This is how I see it: initrd=initrd.img.gz implies root=rootfs rdinit=/bin/sh is the special init=/bin/sh for initrd. Both initrd/root and rdinit/init must be separate for pivoting to succeed. If you want to drop into the initrd (i.e. rootfs), then instruct your initrd.img.gz not to pivot (i.e. not over-mount another filesystem). Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Sat, 14 Jul 2007, H. Peter Anvin wrote: > Bodo Eggert wrote: > > On Sat, 14 Jul 2007, H. Peter Anvin wrote: > >> Bodo Eggert wrote: > >>> Setting the name of the rdinit process to the name of the init process > >>> in order to select the root device should not be the right knob. > >>> > >> What's wrong with it? > > > > rdinit is supposed to be the program that mounts, root is supposed to be > > whatever is mounted and init is supposed to run the system. Three > > different things. Now if you want to change the third, just set the first > > to the second ... > > That only applies to a model that you explicitly doesn't want to use. I don't want to use rdinit, because there is no task for rdinit(3), and I don't want to mount a filesystem(3). But I do want to use init(2). I have to lie to the kernel saying (2) is (1) in order to trick it into beleaving I'd do (3) myself, which I don't, just in order to not do (3). If the bug of not calling the security hook would be fixed, this trick would use the path where rdinit is expected to trigger the callback, but since that rdinit would be no rdinit, that callback would still be wrongly skipped. That would not be a bad thing for my setup, but it clearly shows this setup to be wrong. The correct solution is tell the kernel not to do (3) if you don't want it to do (3). The rest will work as intended. -- This message transmitted on 100% recycled electrons. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: > On Sat, 14 Jul 2007, H. Peter Anvin wrote: >> Bodo Eggert wrote: > >>> Setting the name of the rdinit process to the name of the init process >>> in order to select the root device should not be the right knob. >>> >> What's wrong with it? > > rdinit is supposed to be the program that mounts, root is supposed to be > whatever is mounted and init is supposed to run the system. Three > different things. Now if you want to change the third, just set the first > to the second ... That only applies to a model that you explicitly doesn't want to use. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Sat, 14 Jul 2007, H. Peter Anvin wrote: > Bodo Eggert wrote: > > Setting the name of the rdinit process to the name of the init process > > in order to select the root device should not be the right knob. > > > > What's wrong with it? rdinit is supposed to be the program that mounts, root is supposed to be whatever is mounted and init is supposed to run the system. Three different things. Now if you want to change the third, just set the first to the second ... -- Whenever you have plenty of ammo, you never miss. Whenever you are low on ammo, you can't hit the broad side of a barn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: > > Setting the name of the rdinit process to the name of the init process > in order to select the root device should not be the right knob. > What's wrong with it? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Fri, 13 Jul 2007, H. Peter Anvin wrote: > Bodo Eggert wrote: > > On Fri, 13 Jul 2007, H. Peter Anvin wrote: > >> Bodo Eggert wrote: > >>> I toyed with setting up a diskless system in initramfs. In the process, I > >>> came across some things: > >>> > >>> 1) There is no way to have the kernel not mount a filesystem, > >>> unless you use /init or rdinit=. > >> And? Just use rdinit=/sbin/init and no patch is needed. > > > > rdinit is supposed to do a different job from /sbin/init, therefore it > > will not do the security callbacks the original code would do. > > > > And besides that, it feels like turning the wrong knob for that task. > > No, it is exactly the right knob for the task. Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. > The fact that the security callbacks don't get invoked when using an > initramfs *AT ALL* is the real problem. It's one more problem. -- Interchangeable parts aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Fri, 13 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: On Fri, 13 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. And? Just use rdinit=/sbin/init and no patch is needed. rdinit is supposed to do a different job from /sbin/init, therefore it will not do the security callbacks the original code would do. And besides that, it feels like turning the wrong knob for that task. No, it is exactly the right knob for the task. Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. The fact that the security callbacks don't get invoked when using an initramfs *AT ALL* is the real problem. It's one more problem. -- Interchangeable parts aren't. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. What's wrong with it? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Sat, 14 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. What's wrong with it? rdinit is supposed to be the program that mounts, root is supposed to be whatever is mounted and init is supposed to run the system. Three different things. Now if you want to change the third, just set the first to the second ... -- Whenever you have plenty of ammo, you never miss. Whenever you are low on ammo, you can't hit the broad side of a barn. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: On Sat, 14 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. What's wrong with it? rdinit is supposed to be the program that mounts, root is supposed to be whatever is mounted and init is supposed to run the system. Three different things. Now if you want to change the third, just set the first to the second ... That only applies to a model that you explicitly doesn't want to use. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Sat, 14 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: On Sat, 14 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. What's wrong with it? rdinit is supposed to be the program that mounts, root is supposed to be whatever is mounted and init is supposed to run the system. Three different things. Now if you want to change the third, just set the first to the second ... That only applies to a model that you explicitly doesn't want to use. I don't want to use rdinit, because there is no task for rdinit(3), and I don't want to mount a filesystem(3). But I do want to use init(2). I have to lie to the kernel saying (2) is (1) in order to trick it into beleaving I'd do (3) myself, which I don't, just in order to not do (3). If the bug of not calling the security hook would be fixed, this trick would use the path where rdinit is expected to trigger the callback, but since that rdinit would be no rdinit, that callback would still be wrongly skipped. That would not be a bad thing for my setup, but it clearly shows this setup to be wrong. The correct solution is tell the kernel not to do (3) if you don't want it to do (3). The rest will work as intended. -- This message transmitted on 100% recycled electrons. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: On Sat, 14 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: On Sat, 14 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: Setting the name of the rdinit process to the name of the init process in order to select the root device should not be the right knob. What's wrong with it? rdinit is supposed to be the program that mounts, root is supposed to be whatever is mounted and init is supposed to run the system. Three different things. Now if you want to change the third, just set the first to the second ... That only applies to a model that you explicitly doesn't want to use. I don't want to use rdinit, because there is no task for rdinit(3), and I don't want to mount a filesystem(3). But I do want to use init(2). I have to lie to the kernel saying (2) is (1) in order to trick it into beleaving I'd do (3) myself, which I don't, just in order to not do (3). If the bug of not calling the security hook would be fixed, this trick would use the path where rdinit is expected to trigger the callback, but since that rdinit would be no rdinit, that callback would still be wrongly skipped. That would not be a bad thing for my setup, but it clearly shows this setup to be wrong. The correct solution is tell the kernel not to do (3) if you don't want it to do (3). The rest will work as intended. Sounds rather confusing. This is how I see it: initrd=initrd.img.gz implies root=rootfs rdinit=/bin/sh is the special init=/bin/sh for initrd. Both initrd/root and rdinit/init must be separate for pivoting to succeed. If you want to drop into the initrd (i.e. rootfs), then instruct your initrd.img.gz not to pivot (i.e. not over-mount another filesystem). Thanks! -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: > On Fri, 13 Jul 2007, H. Peter Anvin wrote: >> Bodo Eggert wrote: > >>> I toyed with setting up a diskless system in initramfs. In the process, I >>> came across some things: >>> >>> 1) There is no way to have the kernel not mount a filesystem, >>> unless you use /init or rdinit=. >> And? Just use rdinit=/sbin/init and no patch is needed. > > rdinit is supposed to do a different job from /sbin/init, therefore it > will not do the security callbacks the original code would do. > > And besides that, it feels like turning the wrong knob for that task. No, it is exactly the right knob for the task. The fact that the security callbacks don't get invoked when using an initramfs *AT ALL* is the real problem. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Fri, 13 Jul 2007, H. Peter Anvin wrote: > Bodo Eggert wrote: > > I toyed with setting up a diskless system in initramfs. In the process, I > > came across some things: > > > > 1) There is no way to have the kernel not mount a filesystem, > > unless you use /init or rdinit=. > > And? Just use rdinit=/sbin/init and no patch is needed. rdinit is supposed to do a different job from /sbin/init, therefore it will not do the security callbacks the original code would do. And besides that, it feels like turning the wrong knob for that task. > > 2a) I figured if you prepared the root fs to contain a running system, you > > woud probably also set up a runnable system on it. Therefore I changed > > the default to boot from tmpfs if there was no /init nor a root= option. > > (If there is a /init, it will be executed as usural.) > > > > Unfortunately the way I do it, this will override the rdev setting, but > > that should be OK, since rdev is dead. Isn't it? > > That's pretty hideous. There shouldn't be a need for doing that. > > rdev, unfortunately, isn't dead -- it lives on in the form of > /proc/sys/kernel/real-root-dev, as I found out doing the klibc set. It just missed it's own funeral: "Obsolete root change mechanism -- The following mechanism was used before the introduction of pivot_root. Current kernels still support it, but you should _not_ rely on its continued availability." (Documentation/initrd.txt) I don't insist on changing the default, it was just a logical step from preparing initramfs to hold a system. -- Top 100 things you don't want the sysadmin to say: 48. Tell me again what that '-r' option to rm does - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: > I toyed with setting up a diskless system in initramfs. In the process, I > came across some things: > > 1) There is no way to have the kernel not mount a filesystem, > unless you use /init or rdinit=. And? Just use rdinit=/sbin/init and no patch is needed. > 2a) I figured if you prepared the root fs to contain a running system, you > woud probably also set up a runnable system on it. Therefore I changed > the default to boot from tmpfs if there was no /init nor a root= option. > (If there is a /init, it will be executed as usural.) > > Unfortunately the way I do it, this will override the rdev setting, but > that should be OK, since rdev is dead. Isn't it? That's pretty hideous. There shouldn't be a need for doing that. rdev, unfortunately, isn't dead -- it lives on in the form of /proc/sys/kernel/real-root-dev, as I found out doing the klibc set. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. And? Just use rdinit=/sbin/init and no patch is needed. 2a) I figured if you prepared the root fs to contain a running system, you woud probably also set up a runnable system on it. Therefore I changed the default to boot from tmpfs if there was no /init nor a root= option. (If there is a /init, it will be executed as usural.) Unfortunately the way I do it, this will override the rdev setting, but that should be OK, since rdev is dead. Isn't it? That's pretty hideous. There shouldn't be a need for doing that. rdev, unfortunately, isn't dead -- it lives on in the form of /proc/sys/kernel/real-root-dev, as I found out doing the klibc set. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Fri, 13 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. And? Just use rdinit=/sbin/init and no patch is needed. rdinit is supposed to do a different job from /sbin/init, therefore it will not do the security callbacks the original code would do. And besides that, it feels like turning the wrong knob for that task. 2a) I figured if you prepared the root fs to contain a running system, you woud probably also set up a runnable system on it. Therefore I changed the default to boot from tmpfs if there was no /init nor a root= option. (If there is a /init, it will be executed as usural.) Unfortunately the way I do it, this will override the rdev setting, but that should be OK, since rdev is dead. Isn't it? That's pretty hideous. There shouldn't be a need for doing that. rdev, unfortunately, isn't dead -- it lives on in the form of /proc/sys/kernel/real-root-dev, as I found out doing the klibc set. It just missed it's own funeral: Obsolete root change mechanism -- The following mechanism was used before the introduction of pivot_root. Current kernels still support it, but you should _not_ rely on its continued availability. (Documentation/initrd.txt) I don't insist on changing the default, it was just a logical step from preparing initramfs to hold a system. -- Top 100 things you don't want the sysadmin to say: 48. Tell me again what that '-r' option to rm does - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
Bodo Eggert wrote: On Fri, 13 Jul 2007, H. Peter Anvin wrote: Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. And? Just use rdinit=/sbin/init and no patch is needed. rdinit is supposed to do a different job from /sbin/init, therefore it will not do the security callbacks the original code would do. And besides that, it feels like turning the wrong knob for that task. No, it is exactly the right knob for the task. The fact that the security callbacks don't get invoked when using an initramfs *AT ALL* is the real problem. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
