Hi Andrew and other *real* hackers,
I have sent a *last* version of a patch which it has added a new kernel parameter chroot=It were discusioned a *long time* on a lkml so I hope that it will has been applied.
Thanks,Pawel
Acked-by: Pavel Machek <[email protected]>Signed-off-by: Pawel Plociennik <[email protected]>
---diff -urp linux-2.6.24-orig/Documentation/kernel-parameters.txt linux-2.6.24/Documentation/kernel-parameters.txt--- linux-2.6.24-orig/Documentation/kernel-parameters.txt???????2008-02-25 20:53:26.000000000 -0500+++ linux-2.6.24/Documentation/kernel-parameters.txt????2008-03-04 09:51:52.000000000 -0500@@ -381,6 +381,8 @@ and is between 256 and 4096 characters. ????????????????????????Value can be changed at runtime via????????????????????????????????/selinux/checkreqprot.????????+???????chroot=?????????[KNL] change a root for init process.+????????clock=??????????[BUGS=X86-32, HW] gettimeofday clocksource override.????????????????????????[Deprecated]????????????????????????Forces specified clocksource (if available) to be useddiff -urp linux-2.6.24-orig/init/main.c linux-2.6.24/init/main.c--- linux-2.6.24-orig/init/main.c???????2008-03-01 12:58:37.000000000 -0500+++ linux-2.6.24/init/main.c????2008-03-05 15:08:20.000000000 -0500@@ -755,8 +755,20 @@ static void __init do_pre_smp_initcalls(????????????????spawn_softlockup_task();?}?+static void *chroot_str;+static int __init chroot_setup(char *str)+{+???????chroot_str = str;+???????return 1;+}+__setup("chroot=", chroot_setup);+?static void run_init_process(char *init_filename)?{+???????if (chroot_str)+???????????????if (sys_chroot(chroot_str) < 0)+???????????????????????panic("chroot=%s failed\n", chroot_str);+????????argv_init[0] = init_filename;????????kernel_execve(init_filename, argv_init, envp_init);?}????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Pawel Plociennik wrote:
> Hi Andrew and other *real* hackers,
>
> I have sent a *last* version of a patch which it has added a new kernel parameter chroot=
> It were discusioned a *long time* on a lkml so I hope that it will has been applied.
It has been discussed and *rejected* a large number of times.
This is completely useless bloat.
-hpa
On Wednesday 05 March 2008 23:58, H. Peter Anvin wrote:
>
> It has been discussed and *rejected* a large number of times.
>
> This is completely useless bloat.
>
> -hpa
>
it is not a *completely useless bloat* because it has *only a few lines of the code* ;-)
However I have *left* this patch so if someone thinks that this patch is interested
I hope that it will be sent to Andrew Morton or someone other I have not a free time now :-(
Probably I have sent a previouses mails in a few copies because I have problem with a f... mail client
so I sorry very much :-(
Pawel
* H. Peter Anvin <[email protected]> wrote:
> Pawel Plociennik wrote:
>> Hi Andrew and other *real* hackers,
>>
>> I have sent a *last* version of a patch which it has added a new kernel parameter chroot=
>> It were discusioned a *long time* on a lkml so I hope that it will has been applied.
>
> It has been discussed and *rejected* a large number of times.
>
> This is completely useless bloat.
why is it useless? Would it be more acceptable were it made dependent on
a .config option?
Ingo
On Thu, Mar 06, 2008 at 12:01:38AM -0500, Pawel Plociennik wrote:
> I have sent a *last* version of a patch which it has added a new
> kernel parameter chroot= It were discusioned a *long time* on a lkml
> so I hope that it will has been applied.
That patch is mangled and you can do this with an initrd...
* Chris Wedgwood <[email protected]> wrote:
> On Thu, Mar 06, 2008 at 12:01:38AM -0500, Pawel Plociennik wrote:
>
> > I have sent a *last* version of a patch which it has added a new
> > kernel parameter chroot= It were discusioned a *long time* on a lkml
> > so I hope that it will has been applied.
>
> That patch is mangled and you can do this with an initrd...
we can/could do many other boot options via an initrd too. But given an
existing initrd (which might have come from the distro, etc.) i prefer
adding boot options instead of modifying the initrd.
Ingo
On Thursday 06 March 2008 05:27, Ingo Molnar wrote:
>
> * H. Peter Anvin <[email protected]> wrote:
>
> > Pawel Plociennik wrote:
> >> Hi Andrew and other *real* hackers,
> >>
> >> I have sent a *last* version of a patch which it has added a new kernel parameter chroot=
> >> It were discusioned a *long time* on a lkml so I hope that it will has been applied.
> >
> > It has been discussed and *rejected* a large number of times.
> >
> > This is completely useless bloat.
>
> why is it useless? Would it be more acceptable were it made dependent on
> a .config option?
>
> Ingo
>
I think that use it as a .config option is a nonsense because it nothing to do
if chroot= parameter has not been used in a booting time.
However as I said before I have *left* this patch and I am not interesting in that now :-(
On Thu, Mar 06, 2008 at 11:44:48AM +0100, Ingo Molnar wrote:
> we can/could do many other boot options via an initrd too.
There has been some talk of this and even an implementation of much of
it. I'm not convinced it's a bad idea, I've had to use it myself on
products where the in-kernel ip auto-configuration doesn't work.
> But given an existing initrd (which might have come from the distro,
> etc.) i prefer adding boot options instead of modifying the initrd.
I assume this is so you have have /distro1 /distro2 and use your boot
option to (help) select which one you boot into?
* Chris Wedgwood <[email protected]> wrote:
> > But given an existing initrd (which might have come from the distro,
> > etc.) i prefer adding boot options instead of modifying the initrd.
>
> I assume this is so you have have /distro1 /distro2 and use your boot
> option to (help) select which one you boot into?
while i have no personal use for chroot=, i generally test distros that
way, yes - and i try to keep them as unmodified as possible.
"Use the initrd as an extended boot commandline" is a poor answer IMO.
_Everything_ we do on the boot commandline that affects user-space can
be done in an initrd in theory - but still we have hundreds of boot
options.
Ingo
On Thu 2008-03-06 12:37:29, Ingo Molnar wrote:
>
> * Chris Wedgwood <[email protected]> wrote:
>
> > > But given an existing initrd (which might have come from the distro,
> > > etc.) i prefer adding boot options instead of modifying the initrd.
> >
> > I assume this is so you have have /distro1 /distro2 and use your boot
> > option to (help) select which one you boot into?
>
> while i have no personal use for chroot=, i generally test distros that
> way, yes - and i try to keep them as unmodified as possible.
>
> "Use the initrd as an extended boot commandline" is a poor answer IMO.
>
> _Everything_ we do on the boot commandline that affects user-space can
> be done in an initrd in theory - but still we have hundreds of boot
> options.
Yes, please. chroot= is useful, nonintrusive, and it just should be there.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Ingo Molnar wrote:
> * H. Peter Anvin <[email protected]> wrote:
>
>> Pawel Plociennik wrote:
>>> Hi Andrew and other *real* hackers,
>>>
>>> I have sent a *last* version of a patch which it has added a new kernel parameter chroot=
>>> It were discusioned a *long time* on a lkml so I hope that it will has been applied.
>> It has been discussed and *rejected* a large number of times.
>>
>> This is completely useless bloat.
>
> why is it useless? Would it be more acceptable were it made dependent on
> a .config option?
>
It's useless because it's exactly and trivially replaceable with:
init=/path/to/any/sbin/chroot /newroot /sbin/init
The last thing we want is to pile more stuff into the in-kernel
initialization code, and no, making it a config option makes it even worse.
-hpa
On Thu, 2008-03-06 at 12:53 +0100, Pavel Machek wrote:
> On Thu 2008-03-06 12:37:29, Ingo Molnar wrote:
> >
> > * Chris Wedgwood <[email protected]> wrote:
> >
> > > > But given an existing initrd (which might have come from the distro,
> > > > etc.) i prefer adding boot options instead of modifying the initrd.
> > >
> > > I assume this is so you have have /distro1 /distro2 and use your boot
> > > option to (help) select which one you boot into?
> >
> > while i have no personal use for chroot=, i generally test distros that
> > way, yes - and i try to keep them as unmodified as possible.
> >
> > "Use the initrd as an extended boot commandline" is a poor answer IMO.
> >
> > _Everything_ we do on the boot commandline that affects user-space can
> > be done in an initrd in theory - but still we have hundreds of boot
> > options.
>
> Yes, please. chroot= is useful, nonintrusive, and it just should be there.
As much as I hate initrd, and all features building dependencies on it,
I don't see the need for either initrd or kernel support for chroot= as
it can be trivially done using a slightly longer init=.
* H. Peter Anvin <[email protected]> wrote:
> It's useless because it's exactly and trivially replaceable with:
>
> init=/path/to/any/sbin/chroot /newroot /sbin/init
ok, i didnt realize that this was possible. Ah ... i see,
init/main.c:init_setup() is special and picks the whole boot parameter
string up to the end, right? So init= is the only multi-parameter
init-parameter.
Ingo
On Thu, Mar 06, 2008 at 08:46:21PM +0100, Peter Zijlstra wrote:
>
> On Thu, 2008-03-06 at 12:53 +0100, Pavel Machek wrote:
> > On Thu 2008-03-06 12:37:29, Ingo Molnar wrote:
> > >
> > > * Chris Wedgwood <[email protected]> wrote:
> > >
> > > > > But given an existing initrd (which might have come from the distro,
> > > > > etc.) i prefer adding boot options instead of modifying the initrd.
> > > >
> > > > I assume this is so you have have /distro1 /distro2 and use your boot
> > > > option to (help) select which one you boot into?
> > >
> > > while i have no personal use for chroot=, i generally test distros that
> > > way, yes - and i try to keep them as unmodified as possible.
> > >
> > > "Use the initrd as an extended boot commandline" is a poor answer IMO.
> > >
> > > _Everything_ we do on the boot commandline that affects user-space can
> > > be done in an initrd in theory - but still we have hundreds of boot
> > > options.
> >
> > Yes, please. chroot= is useful, nonintrusive, and it just should be there.
>
> As much as I hate initrd, and all features building dependencies on it,
> I don't see the need for either initrd or kernel support for chroot= as
> it can be trivially done using a slightly longer init=.
I don't want to play devil's advocate, but there is clearly *more* bloat
in adding a "chroot" executable in a directory than having a syscall and
boot option in the kernel. Not to mention that the chroot binary must be
replicated into all the available chroots (ok sometimes maybe it can be
achieved using hardlinks).
While I think that the feature does not bring much for mainline distros,
it makes more sense for embedded or rescue systems where init is responsible
for setting the system up, including extraction of libs and binaries (eg:
run busybox --install) or mounting of other filesystems.
Willy
Ingo Molnar wrote:
> * H. Peter Anvin <[email protected]> wrote:
>
>> It's useless because it's exactly and trivially replaceable with:
>>
>> init=/path/to/any/sbin/chroot /newroot /sbin/init
>
> ok, i didnt realize that this was possible. Ah ... i see,
> init/main.c:init_setup() is special and picks the whole boot parameter
> string up to the end, right? So init= is the only multi-parameter
> init-parameter.
>
Actually, any parameters without = get passed as arguments to init.
-hpa
On Thu 2008-03-06 07:17:42, H. Peter Anvin wrote:
> Ingo Molnar wrote:
>> * H. Peter Anvin <[email protected]> wrote:
>>
>>> Pawel Plociennik wrote:
>>>> Hi Andrew and other *real* hackers,
>>>>
>>>> I have sent a *last* version of a patch which it has added a new kernel parameter chroot=
>>>> It were discusioned a *long time* on a lkml so I hope that it will has been applied.
>>> It has been discussed and *rejected* a large number of times.
>>>
>>> This is completely useless bloat.
>>
>> why is it useless? Would it be more acceptable were it made dependent on a
>> .config option?
>>
>
> It's useless because it's exactly and trivially replaceable with:
>
> init=/path/to/any/sbin/chroot /newroot /sbin/init
No, that will not work, if you don't have libraries at /. This should
be exact replacement:
init=/working_distro/lib/ld-linux.so.2 --library-path /working_distro/lib /working_distro/usr/sbin/chroot /working_distro/ /sbin/init
...assuming your chroot uses ld-linux.so.2. I believe above is ugly
enough to warrant merge of chroot= option.
...heck, how many tries would it take to get that right? Is chroot
/usr/sbin or /sbin?
This really should be in kernel, I should not have to partition my
disk to get booting to few different distros.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
>
> This really should be in kernel, I should not have to partition my
> disk to get booting to few different distros.
>
Use a small initramfs. That's the Right Thing to do in the first place.
-hpa
* Pavel Machek <[email protected]> wrote:
> No, that will not work, if you don't have libraries at /. This should
> be exact replacement:
>
> init=/working_distro/lib/ld-linux.so.2 --library-path
> /working_distro/lib /working_distro/usr/sbin/chroot /working_distro/
> /sbin/init
ouch ...
> ...assuming your chroot uses ld-linux.so.2. I believe above is ugly
> enough to warrant merge of chroot= option.
>
> ...heck, how many tries would it take to get that right? Is chroot
> /usr/sbin or /sbin?
>
> This really should be in kernel, I should not have to partition my
> disk to get booting to few different distros.
agreed ...
i really find it so disheartening at times that people fight trivial
usability additions tooth and nail in a _9 million lines of code_ kernel
with a ... "bloat" argument.
Lets face it: Linux is _still_ hard and a pain to administer, our kernel
boot parameters are ad-hoc, they dont match up to the .config parameters
and it is all a total mess. There's absolutely no design behind them
(look at all the inconsistent parameter forms for turning off smp, acpi,
hpet, nohz, etc.).
if RAM overhead of a new boot option would really be an issue on smaller
setups then the right solution is to make a new .config option that
hardcodes a specific command line and _disable_ all the commandline
parsing. That would also be a nice security feature for certain setups
and would save _a lot more_ RAM than another rejected boot parameter.
Really, all the 'bloat' based objections are totally, utterly silly.
i had a similar experience when i added the relatime boot option:
http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch
Look back the lkml discussion for all the "bloat" and "use /etc/fstab"
clowning around that happened when i sent that patch ... and we still
have no good configuration vectors to turn atime off. I'd rate it good
comedy that happened around that patch: "Kernel hackers shoot in their
own foot and are proud of it".
multiple, consistent vectors for configurability are _GOOD_. That was
the success story behind Apache. Forcing everyone into a "you must use
an initrd for this" idea is 80's thinking and actively harmful to Linux.
Ingo
Ingo Molnar wrote:
>
> i really find it so disheartening at times that people fight trivial
> usability additions tooth and nail in a _9 million lines of code_ kernel
> with a ... "bloat" argument.
>
Because they come in one at a time, in a completely disorganized fashion
(which you yourself complain on further down.)
Yes, I'm bitter about it because my multiyear attempt at cleaning up and
modularizing this area was rejected, and I had to find out about it
secondhand.
To hell with it all.
-hpa
* H. Peter Anvin <[email protected]> wrote:
>> i really find it so disheartening at times that people fight trivial
>> usability additions tooth and nail in a _9 million lines of code_
>> kernel with a ... "bloat" argument.
>
> Because they come in one at a time, in a completely disorganized
> fashion (which you yourself complain on further down.)
yeah. I've got a CONFIG_BOOTPARAM patch already, which turns a lot of
boot parameters into .config options. (this is one of our conceptual
holes: for many boot parameters there's no matching .config)
another thing is that i think all parameters should have all their forms
active: so if there's "noacpi", then "acpi=0/1", "acpi=off/on" should
work as well.
furthermore, usability shortcuts for common combinations would be useful
too. Like "serialdebug" could be used as a shortcut for
"earlyprintk=ttyS0,115200 console=ttyS0,115200 console=vga debug".
Things like that would be really cool.
Ingo
On 06.03.2008 13:30, H. Peter Anvin wrote:
> Pavel Machek wrote:
>>
>> This really should be in kernel, I should not have to partition my
>> disk to get booting to few different distros.
>
> Use a small initramfs. That's the Right Thing to do in the first place.
And what's with the people that just don't have such a beast?
I use monolithic kernels, know the device-name of my root-fs and i'm
proud of it. ;-)
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Pavel Machek wrote:
> init=/working_distro/lib/ld-linux.so.2 --library-path /working_distro/lib /working_distro/usr/sbin/chroot /working_distro/ /sbin/init
There is another userland solution I have used in the past - pre-init. It
has a few unnecessary bells and whistles but does the job. You can find it
here:
http://www.linuxfromscratch.org/hints/downloads/files/ATTACHMENTS/lfs_next_to_existing_systems/lfs_next_helpers.tar.bz2
Some documentation here:
http://www.linuxfromscratch.org/hints/downloads/files/lfs_next_to_existing_systems.txt
Regards
Greg
On Thu, Mar 06, 2008 at 12:37:29PM +0100, Ingo Molnar wrote:
> while i have no personal use for chroot=, i generally test distros
> that way, yes - and i try to keep them as unmodified as possible.
It's not clear to me how this would work.
If the distro uses an initrd (most do now?) how will this work? The
chroot will happen inside the initrd which will then break (because
/init won't be there).
> _Everything_ we do on the boot commandline that affects user-space
> can be done in an initrd in theory - but still we have hundreds of
> boot options.
Precendent alone isn't a good reason to do something, a change should
have merit of it's own.
Pavel Machek <[email protected]> writes:
> On Thu 2008-03-06 07:17:42, H. Peter Anvin wrote:
>> Ingo Molnar wrote:
>>> * H. Peter Anvin <[email protected]> wrote:
>>>
>>>> Pawel Plociennik wrote:
>>>>> Hi Andrew and other *real* hackers,
>>>>>
>>>>> I have sent a *last* version of a patch which it has added a new kernel parameter chroot=
>>>>> It were discusioned a *long time* on a lkml so I hope that it will has been applied.
>>>> It has been discussed and *rejected* a large number of times.
>>>>
>>>> This is completely useless bloat.
>>>
>>> why is it useless? Would it be more acceptable were it made dependent on a
>>> .config option?
>>>
>>
>> It's useless because it's exactly and trivially replaceable with:
>>
>> init=/path/to/any/sbin/chroot /newroot /sbin/init
>
> No, that will not work, if you don't have libraries at /. This should
> be exact replacement:
>
> init=/working_distro/lib/ld-linux.so.2 --library-path /working_distro/lib /working_distro/usr/sbin/chroot /working_distro/ /sbin/init
>
> ...assuming your chroot uses ld-linux.so.2. I believe above is ugly
> enough to warrant merge of chroot= option.
I fail to see how a chroot= option would solve the problem of locating
libraries. If standard library paths won't work, linking chroot
statically seems the cleaner solution.
--
M?ns Rullg?rd
[email protected]
On Don, 2008-03-06 at 13:30 -0800, H. Peter Anvin wrote:
> Pavel Machek wrote:
> >
> > This really should be in kernel, I should not have to partition my
> > disk to get booting to few different distros.
> >
>
> Use a small initramfs. That's the Right Thing to do in the first place.
... or use a statically linked chroot program (not necessarily to be
found in /working_distro). Shouldn't be too large anyways ....
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Bernd Petrovitsch wrote:
> On Don, 2008-03-06 at 13:30 -0800, H. Peter Anvin wrote:
>> Pavel Machek wrote:
>>> This really should be in kernel, I should not have to partition my
>>> disk to get booting to few different distros.
>>>
>> Use a small initramfs. That's the Right Thing to do in the first place.
>
> ... or use a statically linked chroot program (not necessarily to be
> found in /working_distro). Shouldn't be too large anyways ....
>
For what it's worth:
: tazenda 102 ; ls -l ~/klibc/klibc/usr/utils/static/chroot
-rwxrwxr-x 1 hpa hpa 8488 2008-03-06 14:04
/home/hpa/klibc/klibc/usr/utils/static/chroot*
(compiled for x86-64)
-hpa
>* H. Peter Anvin <[email protected]> wrote:
>
>> It's useless because it's exactly and trivially replaceable with:
>>
>> init=/path/to/any/sbin/chroot /newroot /sbin/init
>
>ok, i didnt realize that this was possible. Ah ... i see,
>init/main.c:init_setup() is special and picks the whole boot parameter
>string up to the end, right? So init= is the only multi-parameter
>init-parameter.
>
> Ingo
wouldn`t it be useful to add a hint to kernel-parameters.txt ?
for now it just reads:
init= [KNL]
Format: <full_path>
Run specified binary instead of /sbin/init as init
process.
so, if there is no hint about that specialty (i.e. passing params to init, using for chroot etc..), no user will ever now.....
roland
_____________________________________________________________________
Unbegrenzter Speicherplatz f?r Ihr E-Mail Postfach? Jetzt aktivieren!
http://freemail.web.de/club/landingpage.htm/?mc=025555
On Fri, 7 Mar 2008, [email protected] wrote:
>> * H. Peter Anvin <[email protected]> wrote:
>>> init=/path/to/any/sbin/chroot /newroot /sbin/init
Great, I was looking for something like this myself some time ago!
> wouldn`t it be useful to add a hint to kernel-parameters.txt ?
How about:
--- linux-2.6-git/Documentation/kernel-parameters.txt 2008-02-21 12:01:37.000000000 +0100
+++ linux-2.6-git/Documentation/kernel-parameters.txt.edited 2008-03-07 23:26:39.000000000 +0100
@@ -799,9 +799,12 @@ and is between 256 and 4096 characters.
See header of drivers/scsi/in2000.c.
init= [KNL]
- Format: <full_path>
+ Format: <full_path> <options>
Run specified binary instead of /sbin/init as init
- process.
+ process. init= is able to take more than one option
+ allowing us to do:
+ init=/path/to/any/sbin/chroot /newroot /sbin/init
+ ...and thus booting into /newroot.
initcall_debug [KNL] Trace initcalls as they are executed. Useful
for working out where the kernel is dying during
Thanks,
Christian.
--
BOFH excuse #116:
the real ttys became pseudo ttys and vice-versa.
Christian Kujau wrote:
> On Fri, 7 Mar 2008, [email protected] wrote:
> >> * H. Peter Anvin <[email protected]> wrote:
> >>> init=/path/to/any/sbin/chroot /newroot /sbin/init
>
> Great, I was looking for something like this myself some time ago!
>
> > wouldn`t it be useful to add a hint to kernel-parameters.txt ?
>
> How about:
>
> init= [KNL]
> - Format: <full_path>
> + Format: <full_path> <options>
> Run specified binary instead of /sbin/init as init
> - process.
> + process. init= is able to take more than one option
> + allowing us to do:
> + init=/path/to/any/sbin/chroot /newroot /sbin/init
> + ...and thus booting into /newroot.
Nice try, but this only works on the surface. Try remounting root to see what I mean.
Now, for a patch that actually does what we want, try this:
[PATCH][retry-2] init: Introduce rootdir bootparm to select which dir to sys_chroot
Thanks!
--
Al
On Sat, 8 Mar 2008, Al Boldi wrote:
> Nice try, but this only works on the surface. Try remounting root to see what I mean.
Are you suggesting that hpa's init= thingy doesn't support remounting
root? If so, it'd have to be mentioned in kernel-parameters.txt as well.
> Now, for a patch that actually does what we want, try this:
> [PATCH][retry-2] init: Introduce rootdir bootparm to select which dir
> to sys_chroot
I didn't intend to introduce another bootparam, because of -ENOSKILL.
But somewhere in this thread is a patch for the chroot= bootparam, I
have not tested it though...
C.
--
BOFH excuse #93:
Feature not yet implemented
Christian Kujau wrote:
> On Sat, 8 Mar 2008, Al Boldi wrote:
> > Nice try, but this only works on the surface. Try remounting root to see
> > what I mean.
>
> Are you suggesting that hpa's init= thingy doesn't support remounting
> root?
Exactly.
> If so, it'd have to be mentioned in kernel-parameters.txt as well.
>
> > Now, for a patch that actually does what we want, try this:
> > [PATCH][retry-2] init: Introduce rootdir bootparm to select which dir
> > to sys_chroot
>
> I didn't intend to introduce another bootparam, because of -ENOSKILL.
> But somewhere in this thread is a patch for the chroot= bootparam, I
> have not tested it though...
Sure, your doc effort is much appreciated, but neither the proposed patch nor
the init= trick works as advertised, due to some strange /dev/root
dependencies.
Now, the rootdir= patch works around this by binding the rootdir before
sys_chroot.
Thanks!
--
Al