Second try; this time with a doc-update, and the ability to remount normally.
Tested against 2.6.23.
---
This patch introduces a rootdir kernel boot parameter, which specifies the
path to the kernel sys_chroot boot dir.
This is useful for systems that have more than one distribution installed on
the same fs/partition.
Cc: H. Peter Anvin <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Al Boldi <[email protected]>
---
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1506,6 +1506,10 @@ and is between 256 and 4096 characters.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rootdir= [KNL] Set root dir to chroot to on bootup.
+ Useful for systems that have more than one distribution
+ installed on the same filesystem.
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -252,6 +252,16 @@ __setup("rootflags=", root_data_setup);
__setup("rootfstype=", fs_names_setup);
__setup("rootdelay=", root_delay_setup);
+static char __initdata root_dir[128];
+static int __init root_dir_setup(char *str)
+{
+ strcpy(root_dir, "./");
+ strlcat(root_dir, str, sizeof(root_dir));
+ return 1;
+}
+
+__setup("rootdir=", root_dir_setup);
+
static void __init get_fs_names(char *page)
{
char *s = page;
@@ -469,6 +479,12 @@ void __init prepare_namespace(void)
mount_root();
out:
sys_mount(".", "/", NULL, MS_MOVE, NULL);
+
+ if (root_dir) {
+ sys_mount(root_dir, root_dir, NULL, MS_BIND, NULL);
+ sys_chdir(root_dir);
+ }
+
sys_chroot(".");
security_sb_post_mountroot();
}
Al Boldi <[email protected]> wrote:
> Second try; this time with a doc-update, and the ability to remount normally.
>
> Tested against 2.6.23.
>
> ---
>
> This patch introduces a rootdir kernel boot parameter, which specifies the
> path to the kernel sys_chroot boot dir.
>
> This is useful for systems that have more than one distribution installed on
> the same fs/partition.
1) This is useful for booting a rescue or test system, too. In those cases,
you might want to have the old root moved somewhere.
(Always "$rootdir/oldroot"? Additional parameter? I'm not sure ...)
2) You use a static buffer, but you don't check for bad return values of
strlcat().
Bodo Eggert wrote:
>
> 1) This is useful for booting a rescue or test system, too. In those cases,
> you might want to have the old root moved somewhere.
> (Always "$rootdir/oldroot"? Additional parameter? I'm not sure ...)
>
Again, this is a good example of why this really shouldn't be additional
hacks in kernel space.
-hpa
On Sun, 18 Nov 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
>> 1) This is useful for booting a rescue or test system, too. In those cases,
>> you might want to have the old root moved somewhere.
>> (Always "$rootdir/oldroot"? Additional parameter? I'm not sure ...)
>>
>
> Again, this is a good example of why this really shouldn't be additional
> hacks in kernel space.
ACK, but until kinit is default (and Godot arrives), this little hack does
seem to be useful.
--
Top 100 things you don't want the sysadmin to say:
63. Oracle will be down until 8pm, but you can come back in and finish your
work when it comes up tonight.
Bodo Eggert wrote:
> On Sun, 18 Nov 2007, H. Peter Anvin wrote:
>> Bodo Eggert wrote:
>
>>> 1) This is useful for booting a rescue or test system, too. In those cases,
>>> you might want to have the old root moved somewhere.
>>> (Always "$rootdir/oldroot"? Additional parameter? I'm not sure ...)
>>>
>> Again, this is a good example of why this really shouldn't be additional
>> hacks in kernel space.
>
> ACK, but until kinit is default (and Godot arrives), this little hack does
> seem to be useful.
I disagree, on two accounts:
a. For as long as we keep throwing more crap into the kernel, kinit will
not get merged, because it "provides no new functionality."
b. You don't need kinit and kernel-tree integeration to do this in an
external initramfs. You can do this with any number of codebases as an
external initramfs.
-hpa
On Sun, 18 Nov 2007 20:09:19 +0300
Al Boldi <[email protected]> wrote:
>
> Second try; this time with a doc-update, and the ability to remount
> normally.
Hi,
to be honest, this is something that really should be done in the
initramfs image; we should strive to keep the more complex bootup
scenarios there and not inside the kernel bootup code...
Greetings,
Arjan van de Ven
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
H. Peter Anvin wrote:
> a. For as long as we keep throwing more crap into the kernel, kinit will
> not get merged, because it "provides no new functionality."
I'm not really familiar with kinit, but it sounds unfair to hinder new
features because it would reduce the usefulness of another project.
kinit should have nothing to fear, as its purpose would not be to add new
features, but rather to modularize the boot process, by replacing the
current init, and thus allow for more flexibility to add/modify features.
Thanks!
--
Al
Arjan van de Ven wrote:
> to be honest, this is something that really should be done in the
> initramfs image; we should strive to keep the more complex bootup
> scenarios there and not inside the kernel bootup code...
Agreed, but this is neither complex nor is it a scenario.
This is a shortcut. And, IMHO, a clean one.
Thanks!
--
Al