Re: Kernel setup() and initrd problems

["H. Peter Anvin" <hpa@zytor.com>]

Chris Friesen wrote:
> H. Peter Anvin wrote:
> 
>> Chris Friesen wrote:
>>
>>>
>>> Below is the script that I used to pivot from a standard ramdisk (for
>>> with
>>> the infrastructure is already in place in our build environment) to a
>>> tmpfs
>>> filesystem.  This requires no changes to the boot args.
> 
> 
>> ... which means that you either have boot args or rdev so that
>> /dev/ram0 is the root filesystem (or it wouldn't work.)
> 
> 
> Yes, but after the pivot, /dev/ram0 isn't the real filesytem, its tmpfs
> mounted at /.  Isn't that what the original poster was talking about,
> where the root on the final running system is not the same as what the
> machine was booted with?
> 
> Maybe I'm just confused.
> 

I think so.

The fundamental problem is that the original initrd protocol considered
the initrd to be something different than "a real root", and its init
(linuxrc) to be something different than "a real init."

With pivot_root, all of that is historical baggage, and worse - it gets
in the way.

The way to get around the historical baggage is to tell the kernel that
the initrd is a "permanent" initrd by using the "root=/dev/ram0"
command-line option.  This has the side effect of bypassing all the
initrd historical crap and instead spawning /sbin/init using PID 1, like
any other system would do.  Now you can just pivot and "exec /sbin/init"
like you should be.

Of course, after the pivot_root, the root is something completely
different than the root= command-line option states, but that's
irrelevant.  The command-line option is there to disable the initrd
historical garbage, not for any other purpose.

	-hpa