2003-03-14 20:00:59

by Chris Friesen

[permalink] [raw]
Subject: Re: Kernel setup() and initrd problems

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.


Chris

--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]


2003-03-14 20:39:47

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Kernel setup() and initrd problems

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