From: Eric <ebrower@usa.net>
To: linux-kernel@vger.kernel.org
Subject: Re: [Q] pivot_root and initrd
Date: Tue, 23 Oct 2001 10:42:11 -0700 [thread overview]
Message-ID: <3BD5ABF3.1040404@usa.net> (raw)
Would it even be worthwhile to propose a patch that would set a flag
when pivot_root is called during an initrd and prevent change_root from
occuring once the linuxrc thread exits?
Your method of placing "initrx=xxx" and "root=xxx" is similar to my
method of stuffing those values into /proc/sys/kernel/real_root_dev once
the pivot_root is complete; I am not really happy with that solution,
not the least of which because it is an undocumented work-around and
somewhat unexpected behavior for a system call that is to (presumably)
replace or augment change_root.
I was also hoping that Warner or Hans would chime-in either in defense
of the current documentation or with clarifications...
E
HPA wrote:
>>
>> I am mystified that the call to 'exec /sbin/init' works
>> if you are using the standard (you mention "based on RedHat7.1"
>> util-linux") /sbin/init proggie, and that a standard RH7.1
>> initscripts would not complain when the root filesystem is already
>> mounted r/w.
>>
>> I would also guess that you are susceptible to the kernel's
>> change_root call if your /sbin/init terminates. I'll have to
>> play with the disk a bit.
>>
>
> I modify the initscripts to not try to fsck and remount the root --
> its a ramfs (tmpfs in a later version) after all. If I had been
> mounting a filesystem off the harddisk I would either have mounted it
> readonly and left the init scripts as-is, or fscked it before
> mounting.
>
> I pass the following command line options to the kernel (this is set
> up in isolinux.cfg):
>
> append initrd=initrd.gz root=/dev/ram0 init=/linuxrc single
>
> By specifying root=/dev/ram0 and an explicit init (which I'm calling
> /linuxrc but could just as easily have called /sbin/init) I'm telling
> the kernel that this is the final root, and effectively turn off most
> of the initrd legacy weirdness.
>
> If /sbin/init exits, the kernel panics, just like it would normally do
> if init goes away.
next reply other threads:[~2001-10-23 17:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-23 17:42 Eric [this message]
2001-10-23 18:14 ` [Q] pivot_root and initrd H. Peter Anvin
2001-10-23 19:54 ` bill davidsen
2001-10-23 19:59 ` Rik van Riel
2001-10-23 20:21 ` bill davidsen
2001-10-23 21:00 ` H. Peter Anvin
2001-10-23 20:37 ` Werner Almesberger
2001-10-23 20:46 ` Richard B. Johnson
2001-10-23 20:52 ` H. Peter Anvin
2001-10-23 21:05 ` Richard B. Johnson
2001-10-23 21:06 ` H. Peter Anvin
[not found] <p05100304b80cbe9cf127@[10.128.7.49]>
2001-11-06 0:05 ` Eric
[not found] <p05100328b7fb8dcb9473@[207.213.214.37]>
2001-10-23 21:54 ` Eric
2001-10-24 0:20 ` Werner Almesberger
[not found] <p05100300b7f2b3b94b17@[10.128.7.49]>
2001-10-17 18:34 ` Eric
2001-10-17 21:17 ` H. Peter Anvin
2001-10-27 12:45 ` Kai Henningsen
2001-11-05 21:52 ` Andreas Schwab
-- strict thread matches above, loose matches on Subject: below --
2001-10-17 2:16 Eric
2001-10-17 3:30 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BD5ABF3.1040404@usa.net \
--to=ebrower@usa.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).