Re: [OE-core] [PATCH] initramfs-framework: remove hard dependency with busybox

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2025-04-10 at 23:27 +0200, Adrian Freihofer wrote:
> On Sat, 2025-03-29 at 09:29 -0700, Khem Raj via lists.openembedded.org
> wrote:
> > On Sat, Mar 29, 2025 at 9:01 AM Christos Gavros via
> > lists.openembedded.org <gavrosc=yahoo.com@lists.openembedded.org>
> > wrote:
> > > 
> > > hi Adrian
> > > 
> > > thank you for the comment. I had a look in commits log and it looks
> > > that '-c' was there since the beginning in 2008/09/10 in script
> > > 'init-live.sh' and then moved in 'finish.sh' in 2011/12/08.
> > > I reproduced the issue by using qemu and I described how I did it
> > > in detail in bug #15716.
> > > After I applied the change I tested both busybox and packagegroup-
> > > core-base-utils. The boot was successful in both cases.
> > > Also '-c' is an option in busybox:
> > > https://www.busybox.net/downloads/BusyBox.html
> > > 
> > 
> > -c option is to redirect the console after switching root. Some
> > devices it did not work properly because util-linux version moved the
> > pseudo filesystems like /dev automatically
> > but busybox version did not, maybe things have changed but I would
> > suggest that this operation is now happening with both switch_root
> > versions with you script manually doing so.
> 
> I tested this on a device with kernel 6.1+. It seams to work as
> expected also with a busybox based initramfs. Maybe you are right and
> this is more like a legacy thing which can (or even should?) be
> removed.
> 
> Additionally I looked into the code from busybox. The related lines
> are:
> 
> 	if (console) {
> 		close(0);
> 		xopen(console, O_RDWR);
> 		xdup2(0, 1);
> 		xdup2(0, 2);
> 	}
> https://github.com/brgl/busybox/blob/master/util-linux/switch_root.c#L143
> 
> At least on my device this would just close /dev/console and open it
> again. Not really useful.
> 
> I think the patch is beneficial for probably all kind of systems.

Thanks, this analysis really helps.

I agree that this does appear to make sense. I guess it is in case the
initramfs and the main system have different /dev/console entries but
that is probably/hopefully very rare. It would only be the init process
affected.

Cheers,

Richard