From: Michal Soltys <soltys@ziu.info>
To: Phillip Susi <psusi@ubuntu.com>
Cc: util-linux@vger.kernel.org,
"Thomas Bächler" <thomas@archlinux.org>,
"Karel Zak" <kzak@redhat.com>
Subject: Re: pivot_root depreciated?
Date: Mon, 03 Feb 2014 11:31:08 +0100 [thread overview]
Message-ID: <52EF6FEC.4000207@ziu.info> (raw)
In-Reply-To: <52EA6DBA.6000903@ubuntu.com>
On 2014-01-30 16:20, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/30/2014 9:50 AM, Thomas Bächler wrote:
>> At least mkinitcpio now generates a fresh "initrd" to return to
>> during system shutdown instead of keeping around the actual
>> initrd.
>
> I see, so at shutdown the initramfs is re-loaded into a tmpfs that is
> then pivot_root()ed to? And at boot time, pivot_root is not used?
>
Initially when initramfs prepares /run and stuff (and switchroot moves
it to real root), workable "minisystem" is kept under /run/initramfs (or
similar).
On shutdown, /run/initramfs is bind-mounted to itself, which makes it
pivotable, with old root say available at /oldroot. Now your aim is to
cleanly unmount old root. In case of classic non-systemd, you would need:
- telinit u (graceful re-exec of init)
- mdmon --takeover (if you have non-native raid handled by md, to
gracefully reexec the daemon)
- etc.
This allows to close all open files on real root (things are usually
tried in loop, with attempts to stop stuff like lvm, md, ...) and
finally unmount old root.
Of course there is also a question - why bother doing all this, when
simple ro remount before halt has been working fine for decades (and
still works) ....
Dracut (and others) /could/ be doing even more clever thing (hmm, maybe
I should review certain old patches of mine) - during boot it could
prepare mini-root on tmpfs before (some copying, some symlinks and/or
PATH stuff) starting everything - then move actual tmpfs with living
root to real root. The small advantage of that is, that you can at any
moment chroot to such miniroot and do some maintenance on e.g.
boot-critical storage daemon that lacks ability to reexecute itself
gracefully.
Another interesting use for pivot_root() call - when paired with mount
namespaces - is ability to provide stronger chroot jails.
So the call itself is still pretty useful. It hasn't beed used during
boot anymore for years, but other possibilities emerged for it =)
next prev parent reply other threads:[~2014-02-03 10:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 15:04 pivot_root depreciated? Phillip Susi
2014-01-29 15:29 ` Dave Reisner
2014-01-30 8:16 ` Karel Zak
2014-01-30 14:15 ` Phillip Susi
2014-01-30 14:50 ` Thomas Bächler
2014-01-30 15:20 ` Phillip Susi
2014-01-30 16:13 ` Thomas Bächler
2014-02-03 10:31 ` Michal Soltys [this message]
2014-02-03 11:10 ` Kevin Wilson
2014-01-31 9:17 ` Karel Zak
2014-01-31 9:21 ` Thomas Bächler
2014-01-30 14:54 ` Dave Reisner
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=52EF6FEC.4000207@ziu.info \
--to=soltys@ziu.info \
--cc=kzak@redhat.com \
--cc=psusi@ubuntu.com \
--cc=thomas@archlinux.org \
--cc=util-linux@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.