From: Eric <ebrower@usa.net>
To: linux-kernel@vger.kernel.org
Subject: [Q] pivot_root and initrd
Date: Tue, 16 Oct 2001 19:16:57 -0700 [thread overview]
Message-ID: <3BCCEA19.8080809@usa.net> (raw)
I've been doing some work to boot a 2.4.x linux system from onboard
flash and then change_root to an attached disk.
As the kernel documentation admonishes us to use pivot_root instead of
relying on the change_root facility (Documentation/initrd.txt: "Current
kernels still support it, but you should _not_ rely on its continued
availability") I have given it a shot with less than stellar results--
perhaps someone (Warner?) could enlighten me on a few points:
1) What is the current status of pivot_root from an initrd? Is anyone
using it for this purpose, and is it being deprecated by the "union
mounts" mentioned in the bootinglinux-current document by Warner?
2) The initrd.txt and pivot_root manpages seem incorrect on how to
execute /sbin/init on the pivot-root'ed filesystem. In general, the
examples suggest the following should work, but it will not:
pivot_root . old_root
exec chroot . sh -c 'umount /old_root; exec /sbin/init' \
<dev/console >dev/console 2>&1
The standard util-linux /sbin/init program will not allow itself to be
executed without command-line args unless its PID is 1, or it is invoked
as "sh" or "init.new." As we are exec'ing init from userspace instead
of from the kernel, we fail these tests. Perhaps we can update these
examples with something (admitedly hokey) like:
pivot_root . old_root
exec chroot . sh -c 'umount /old_root; exec -a init.new /sbin/init' \
<dev/console >dev/console 2>&1
... or am I misunderstanding a finer point of the standard linux init
process? Note, if we substitute in the above "exec -a sh /sbin/init" we
get a truncated process name in the resulting 'ps' listing as 'in' (bug?).
3) The kernel does not understand pivot_root in the context of an
initrd. As I understand the process, an initd-aware kernel will spawn a
thread to handle the /linuxrc process in the initrd. Once it completes,
the kernel double-checks the real_root_dev against the initrd major and
minor and invokes change_root when the /linuxrc thread exits:
#ifdef CONFIG_BLK_DEV_INITRD
[ ... ]
pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
if (pid>0)
while (pid != wait(&i));
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
|| MINOR(real_root_dev) != 0) {
error = change_root(real_root_dev,"/initrd");
[ ... ]
#endif
This poses a problem-- I load an initrd, perform a pivot_root and exec
the real /sbin/init on the new root filesystem. I am happily running;
now I do 'shutdown -r now' and the init process is terminated. Once the
init process goes away the kernel decides it is time to change_root and
exec "the real /sbin/init."
I would expect to see some sort of fall-through mechanism to prevent the
change_root once a pivot_root is done during an initrd run. The only
method that seems (un)plausible is that I am responsible for setting the
real_root_dev via sysctl to the major/minor of the initrd device after a
successful pivot_root. For those of us without sysctl, we have precious
little to do but accept a restart of init.
What say ye with a better view of the landscape?
I do not subscribe, so cc's to me would be appreciated...
E
next reply other threads:[~2001-10-17 2:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-17 2:16 Eric [this message]
2001-10-17 3:30 ` [Q] pivot_root and initrd H. Peter Anvin
[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
2001-10-23 17:42 Eric
2001-10-23 18:14 ` 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] <p05100328b7fb8dcb9473@[207.213.214.37]>
2001-10-23 21:54 ` Eric
2001-10-24 0:20 ` Werner Almesberger
[not found] <p05100304b80cbe9cf127@[10.128.7.49]>
2001-11-06 0:05 ` Eric
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=3BCCEA19.8080809@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).