Kang-Che Sung <explore...@gmail.com> writes:

> Linus Heckemann <g...@sphalerite.org> 於 2024年4月19日 星期五寫道:
>> We were having some difficulty switching out of our custom initramfs
>> into the final filesystem, with the error "message '/init' is not a
>> regular file". We were confused as to why it was looking for `/init`
>> -- we didn't have `/init`, neither in our initrd nor in the
>> destination filesystem -- we were using the rdinit= command line
>> parameter to provide an alternative path for the init in the initrd,
>> and the target init was determined by userspace.
>>
>> Thankfully, the error message was fairly clear and easy to find in the
>> source!
>>
>> We thus propose removing this check, since not all initrds have their
>> init at /init -- setting rdinit= on the kernel command line allows
>> using an alternative path. Thus, this check can prevent switching root
>> in a scenario where it would be perfectly appropriate.
>> ---
>>  util-linux/switch_root.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/util-linux/switch_root.c b/util-linux/switch_root.c
>> index 14139736e..ef6669f5c 100644
>> --- a/util-linux/switch_root.c
>> +++ b/util-linux/switch_root.c
>> @@ -238,9 +238,6 @@ int switch_root_main(int argc UNUSED_PARAM, char
> **argv)
>>         // Additional sanity checks: we're about to rm -rf /, so be
> REALLY SURE
>>         // we mean it. I could make this a CONFIG option, but I would get
> email
>>         // from all the people who WILL destroy their filesystems.
>> -       if (stat("/init", &st) != 0 || !S_ISREG(st.st_mode)) {
>> -               bb_error_msg_and_die("'%s' is not a regular file",
> "/init");
>> -       }
>>         statfs("/", &stfs); // this never fails
>>         if ((unsigned)stfs.f_type != RAMFS_MAGIC
>>          && (unsigned)stfs.f_type != TMPFS_MAGIC
>> --
>> 2.42.0
>
> Did you read the code comments on the lines above what you deleted? It's a
> sanity check before deleting everything on the "/" filesystem.

I did! I don't really see the existence of /init being so critical for
this check given that we check below that it's a ramfs or tmpfs, which
seems to me to be enough that people won't be destroying filesystems
they cared a great deal about.

> Perhaps a better approach is to check the existence of what's specified in
> the "rdinit" parameter instead.

That would introduce an additional dependency on /proc being mounted and
require additional parsing. I don't think the check is that necessary,
again because we have the /-is-ramfs-or-tmpfs check. But if you do think
we need it I can rewrite the patch to check for rdinit= on cmdline as well.

Cheers
Linus
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to