chroot= as a new kernel parameter
PATCH 1/1 chroot= as a new kernel parameter
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
---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¥
Quoted 4 lines · 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.
It has been discussed and *rejected* a large number of times.
This is completely useless bloat.
-hpa
Quoted 7 lines · H. Peter Anvin
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
Quoted 9 lines · H. Peter Anvin
Quoted 4 lines · 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.
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
Quoted 9 lines · Ingo Molnar
Quoted 6 lines · H. Peter Anvin
Quoted 4 lines · 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.
Quoted 9 lines
Quoted 3 lines
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 :-(
Quoted 5 lines · Ingo Molnar
Quoted 3 lines · H. Peter Anvin
Quoted 2 lines · Pawel Plociennik
Hi Andrew and other *real* hackers,
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 3 lines · H. Peter Anvin
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
Quoted 8 lines · Ingo Molnar
Quoted 3 lines · H. Peter Anvin
It's useless because it's exactly and trivially replaceable with:
init=/path/to/any/sbin/chroot /newroot
/sbin/initok, 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
Quoted 12 lines · H. Peter Anvin
Quoted 11 lines · Ingo Molnar
Quoted 8 lines · H. Peter Anvin
Quoted 4 lines · 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.
It has been discussed and *rejected* a large number of times.
This is completely useless bloat.
Quoted 7 lines
Quoted 3 lines
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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 4 lines · Pavel Machek
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
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines · Pavel Machek
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
Signature · 4 lines
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.
Quoted 7 lines · H. Peter Anvin
Quoted 4 lines · Pavel Machek
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
Signature · 3 lines
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and ServicesQuoted 10 lines · Bernd Petrovitsch
Quoted 5 lines · H. Peter Anvin
Quoted 3 lines · Pavel Machek
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
Quoted 6 lines · Pavel Machek
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 ...
Quoted 8 lines
...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/sbinor /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
Quoted 3 lines · Ingo Molnar
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
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines
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
Quoted 1 line · Pavel Machek
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:
Some documentation here:
http://www.linuxfromscratch.org/hints/downloads/files/lfs_next_to_existing_systems.txt
Regards
Greg
Quoted 21 lines · Pavel Machek
Quoted 12 lines · H. Peter Anvin
Quoted 11 lines · Ingo Molnar
Quoted 8 lines · H. Peter Anvin
Quoted 4 lines · 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.
It has been discussed and *rejected* a large number of times.
This is completely useless bloat.
Quoted 7 lines
Quoted 3 lines
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
Quoted 7 lines
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.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 3 lines · Pawel Plociennik
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...
Quoted 7 lines · Chris Wedgwood
Quoted 3 lines · Pawel Plociennik
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
Quoted 1 line · Ingo Molnar
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.
Quoted 2 lines
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?
Quoted 5 lines · Chris Wedgwood
Quoted 2 lines
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
Quoted 9 lines · Ingo Molnar
Quoted 5 lines · Chris Wedgwood
Quoted 2 lines
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?
Quoted 8 lines
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.
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 13 lines · Pavel Machek
Quoted 12 lines · Ingo Molnar
Quoted 5 lines · Chris Wedgwood
Quoted 2 lines
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.
Quoted 7 lines
Quoted 5 lines
"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=.
Quoted 21 lines · Peter Zijlstra
Quoted 19 lines · Pavel Machek
Quoted 17 lines · Ingo Molnar
Quoted 5 lines · Chris Wedgwood
Quoted 2 lines
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.
Quoted 5 lines
Quoted 1 line
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
Quoted 2 lines · Ingo Molnar
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).
Quoted 3 lines
_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.