1 /* vi: set sw=4 ts=4: */
2 /* Copyright 2005 Rob Landley <rob@landley.net>
4 * Switch from rootfs to another filesystem as the root of the mount tree.
6 * Licensed under GPLv2, see file LICENSE in this source tree.
8 //config:config SWITCH_ROOT
9 //config: bool "switch_root (5.2 kb)"
11 //config: select PLATFORM_LINUX
13 //config: The switch_root utility is used from initramfs to select a new
14 //config: root device. Under initramfs, you have to use this instead of
15 //config: pivot_root. (Stop reading here if you don't care why.)
17 //config: Booting with initramfs extracts a gzipped cpio archive into rootfs
18 //config: (which is a variant of ramfs/tmpfs). Because rootfs can't be moved
19 //config: or unmounted*, pivot_root will not work from initramfs. Instead,
20 //config: switch_root deletes everything out of rootfs (including itself),
21 //config: does a mount --move that overmounts rootfs with the new root, and
22 //config: then execs the specified init program.
24 //config: * Because the Linux kernel uses rootfs internally as the starting
25 //config: and ending point for searching through the kernel's doubly linked
26 //config: list of active mount points. That's why.
28 //applet:IF_SWITCH_ROOT(APPLET(switch_root, BB_DIR_SBIN, BB_SUID_DROP))
30 //kbuild:lib-$(CONFIG_SWITCH_ROOT) += switch_root.o
32 //usage:#define switch_root_trivial_usage
33 //usage: "[-c /dev/console] NEW_ROOT NEW_INIT [ARGS]"
34 //usage:#define switch_root_full_usage "\n\n"
35 //usage: "Free initramfs and switch to another root fs:\n"
36 //usage: "chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,\n"
37 //usage: "execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.\n"
38 //usage: "\n -c DEV Reopen stdio to DEV after switch"
41 #include <sys/mount.h>
43 // Make up for header deficiencies
45 # define RAMFS_MAGIC ((unsigned)0x858458f6)
48 # define TMPFS_MAGIC ((unsigned)0x01021994)
54 // Recursively delete contents of rootfs
55 static void delete_contents(const char *directory, dev_t rootdev)
61 // Don't descend into other filesystems
62 if (lstat(directory, &st) || st.st_dev != rootdev)
65 // Recursively delete the contents of directories
66 if (S_ISDIR(st.st_mode)) {
67 dir = opendir(directory);
69 while ((d = readdir(dir))) {
70 char *newdir = d->d_name;
73 if (DOT_OR_DOTDOT(newdir))
76 // Recurse to delete contents
77 newdir = concat_path_file(directory, newdir);
78 delete_contents(newdir, rootdev);
83 // Directory should now be empty, zap it
87 // It wasn't a directory, zap it
92 int switch_root_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
93 int switch_root_main(int argc UNUSED_PARAM, char **argv)
95 char *newroot, *console = NULL;
100 // Parse args (-c console). '+': stop at first non-option
101 getopt32(argv, "^+" "c:" "\0" "-2" /* minimum 2 args */, &console);
105 // Change to new root directory and verify it's a different fs
110 if (st.st_dev == rootdev || getpid() != 1) {
111 // Show usage, it says new root must be a mountpoint
112 // and we must be PID 1
116 // Additional sanity checks: we're about to rm -rf /, so be REALLY SURE
117 // we mean it. I could make this a CONFIG option, but I would get email
118 // from all the people who WILL destroy their filesystems.
119 if (stat("/init", &st) != 0 || !S_ISREG(st.st_mode)) {
120 bb_error_msg_and_die("/init is not a regular file");
122 statfs("/", &stfs); // this never fails
123 if ((unsigned)stfs.f_type != RAMFS_MAGIC
124 && (unsigned)stfs.f_type != TMPFS_MAGIC
126 bb_error_msg_and_die("root filesystem is not ramfs/tmpfs");
129 // Zap everything out of rootdev
130 delete_contents("/", rootdev);
132 // Overmount / with newdir and chroot into it
133 if (mount(".", "/", NULL, MS_MOVE, NULL)) {
134 // For example, fails when newroot is not a mountpoint
135 bb_perror_msg_and_die("error moving root");
138 // The chdir is needed to recalculate "." and ".." links
139 /*xchdir("/"); - done in xchroot */
141 // If a new console specified, redirect stdin/stdout/stderr to it
143 int fd = open_or_warn(console, O_RDWR);
152 execv(argv[0], argv);
153 bb_perror_msg_and_die("can't execute '%s'", argv[0]);
157 From: Rob Landley <rob@landley.net>
158 Date: Tue, Jun 16, 2009 at 7:47 PM
159 Subject: Re: switch_root...
165 If you're _not_ running out of init_ramfs (if for example you're using initrd
166 instead), you probably shouldn't use switch_root because it's the wrong tool.
168 Basically what the sucker does is something like the following shell script:
170 find / -xdev | xargs rm -rf
176 There are a couple reasons that won't work as a shell script:
178 1) If you delete the commands out of your $PATH, your shell scripts can't run
179 more commands, but you can't start using dynamically linked _new_ commands
180 until after you do the chroot because the path to the dynamic linker is wrong.
181 So there's a step that needs to be sort of atomic but can't be as a shell
182 script. (You can work around this with static linking or very carefully laid
183 out paths and sequencing, but it's brittle, ugly, and non-obvious.)
185 2) The "find | rm" bit will actually delete everything because the mount points
186 still show up (even if their contents don't), and rm -rf will then happily zap
187 that. So the first line is an oversimplification of what you need to do _not_
188 to descend into other filesystems and delete their contents.
190 The reason we do this is to free up memory, by the way. Since initramfs is a
191 ramfs, deleting its contents frees up the memory it uses. (We leave it with
192 one remaining dentry for the new mount point, but that's ok.)
194 Note that you cannot ever umount rootfs, for approximately the same reason you
195 can't kill PID 1. The kernel tracks mount points as a doubly linked list, and
196 the pointer to the start/end of that list always points to an entry that's
197 known to be there (rootfs), so it never has to worry about moving that pointer
198 and it never has to worry about the list being empty. (Back around 2.6.13
199 there _was_ a bug that let you umount rootfs, and the system locked hard the
200 instant you did so endlessly looping to find the end of the mount list and
201 never stopping. They fixed it.)
203 Oh, and the reason we mount --move _and_ do the chroot is due to the way "/"
204 works. Each process has two special symlinks, ".", and "/". Each of them
205 points to the dentry of a directory, and give you a location paths can start
206 from. (Historically ".." was also special, because you could enter a
207 directory via a symlink so backing out to the directory you came from doesn't
208 necessarily mean the one physically above where "." points to. These days I
209 think it's just handed off to the filesystem.)
211 Anyway, path resolution starts with "." or "/" (although the "./" at the start
212 of the path may be implicit), meaning it's relative to one of those two
213 directories. Your current directory, and your current root directory. The
214 chdir() syscall changes where "." points to, and the chroot() syscall changes
215 where "/" points to. (Again, both are per-process which is why chroot only
216 affects your current process and its child processes.)
218 Note that chroot() does _not_ change where "." points to, and back before they
219 put crazy security checks into the kernel your current directory could be
220 somewhere you could no longer access after the chroot. (The command line
221 chroot does a cd as well, the chroot _syscall_ is what I'm talking about.)
223 The reason mounting something new over / has no obvious effect is the same
224 reason mounting something over your current directory has no obvious effect:
225 the . and / links aren't recalculated after a mount, so they still point to
226 the same dentry they did before, even if that dentry is no longer accessible
227 by other means. Note that "cd ." is a NOP, and "chroot /" is a nop; both look
228 up the cached dentry and set it right back. They don't re-parse any paths,
229 because they're what all paths your process uses would be relative to.
231 That's why the careful sequencing above: we cd into the new mount point before
232 we do the mount --move. Moving the mount point would otherwise make it
233 totally inaccessible to us because cd-ing to the old path wouldn't give it to
234 us anymore, and cd "/" just gives us the cached dentry from when the process
235 was created (in this case the old initramfs one). But the "." symlink gives
236 us the dentry of the filesystem we just moved, so we can then "chroot ." to
237 copy that dentry to "/" and get the new filesystem. If we _didn't_ save that
238 dentry in "." we couldn't get it back after the mount --move.
240 (Yes, this is all screwy and I had to email questions to Linus Torvalds to get
241 it straight myself. I keep meaning to write up a "how mount actually works"