Re: [PATCH 2.6.24] chroot= as a new kernel parameter

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Al Boldi]

Christian Kujau wrote:
>   On Fri, 7 Mar 2008, devzero@web.de wrote:
> >> * H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Christian Kujau]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Al Boldi]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[devzero]

>* H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Christian Kujau]

On Fri, 7 Mar 2008, devzero@web.de wrote:

>> * H. Peter Anvin <hpa@zytor.com> 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.

[PATCH 2.6.24] chroot= as a new kernel parameter

[Pawel Plociennik]

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 <pavel@suse.cz>Signed-off-by: Pawel Plociennik <paplociennik@gmail.com>
---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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[H. Peter Anvin]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[H. Peter Anvin]

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[H. Peter Anvin]

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Pavel Machek]

On Thu 2008-03-06 07:17:42, H. Peter Anvin wrote:
> Ingo Molnar wrote:
>> * H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[H. Peter Anvin]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Matthias Schniedermeyer]

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.

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Bernd Petrovitsch]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[H. Peter Anvin]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Ingo Molnar]

* Pavel Machek <pavel@ucw.cz> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[H. Peter Anvin]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Greg Schafer]

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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

> On Thu 2008-03-06 07:17:42, H. Peter Anvin wrote:
>> Ingo Molnar wrote:
>>> * H. Peter Anvin <hpa@zytor.com> 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
mans@mansr.com

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Pawel Plociennik]

On Thursday 06 March 2008 05:27, Ingo Molnar wrote:
> 
> * H. Peter Anvin <hpa@zytor.com> 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 :-(

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Pawel Plociennik]

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 

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Chris Wedgwood]

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...

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Ingo Molnar]

* Chris Wedgwood <cw@f00f.org> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Chris Wedgwood]

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?

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Ingo Molnar]

* Chris Wedgwood <cw@f00f.org> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Pavel Machek]

On Thu 2008-03-06 12:37:29, Ingo Molnar wrote:
> 
> * Chris Wedgwood <cw@f00f.org> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Peter Zijlstra]

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 <cw@f00f.org> 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=.

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Willy Tarreau]

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 <cw@f00f.org> 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

Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Chris Wedgwood]

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.