linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [Q] pivot_root and initrd
@ 2001-10-23 17:42 Eric
  2001-10-23 18:14 ` H. Peter Anvin
  0 siblings, 1 reply; 20+ messages in thread
From: Eric @ 2001-10-23 17:42 UTC (permalink / raw)
  To: linux-kernel

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. 



^ permalink raw reply	[flat|nested] 20+ messages in thread
[parent not found: <p05100304b80cbe9cf127@[10.128.7.49]>]
[parent not found: <p05100328b7fb8dcb9473@[207.213.214.37]>]
[parent not found: <p05100300b7f2b3b94b17@[10.128.7.49]>]
* [Q] pivot_root and initrd
@ 2001-10-17  2:16 Eric
  2001-10-17  3:30 ` H. Peter Anvin
  0 siblings, 1 reply; 20+ messages in thread
From: Eric @ 2001-10-17  2:16 UTC (permalink / raw)
  To: linux-kernel

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






^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2001-11-06  0:11 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-23 17:42 [Q] pivot_root and initrd 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] <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

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).