Using the initial RAM disk (initrd) | Linux 6.18.37

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

부팅 흐름과 옵션

initrd.rst:1-95

initrd의 2단계 부팅 흐름, 명령줄 옵션과 압축 cpio 이미지 생성법을 설명합니다.

이미지 생성과 부트로더

initrd.rst:96-209

loopback 이미지 구축과 LOADLIN·LILO 설정을 명령 예제와 함께 정리합니다.

루트 전환

initrd.rst:210-271

`pivot_root`, chroot, 이전 initrd 참조 제거와 RAM 디스크 해제 절차를 설명합니다.

사용 사례와 호환 방식

initrd.rst:272-383

설치·복구 시나리오, 폐기 예정 `change_root`, 혼합 방식과 참고 자료를 다룹니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기

1 Using the initial RAM disk (initrd)

2 ===================================

4 Written 1996,2000 by Werner Almesberger <werner.almesberger@epfl.ch> and

5 Hans Lermen <lermen@fgan.de>

8 initrd provides the capability to load a RAM disk by the boot loader.

9 This RAM disk can then be mounted as the root file system and programs

10 can be run from it. Afterwards, a new root file system can be mounted

11 from a different device. The previous root (from initrd) is then moved

12 to a directory and can be subsequently unmounted.

14 initrd is mainly designed to allow system startup to occur in two phases,

15 where the kernel comes up with a minimum set of compiled-in drivers, and

16 where additional modules are loaded from initrd.

18 This document gives a brief overview of the use of initrd. A more detailed

19 discussion of the boot process can be found in [#f1]_.

22 Operation

23 ---------

25 When using initrd, the system typically boots as follows:

27 1) the boot loader loads the kernel and the initial RAM disk

28 2) the kernel converts initrd into a "normal" RAM disk and

29 frees the memory used by initrd

30 3) if the root device is not ``/dev/ram0``, the old (deprecated)

31 change_root procedure is followed. see the "Obsolete root change

32 mechanism" section below.

33 4) root device is mounted. if it is ``/dev/ram0``, the initrd image is

34 then mounted as root

35 5) /sbin/init is executed (this can be any valid executable, including

36 shell scripts; it is run with uid 0 and can do basically everything

37 init can do).

38 6) init mounts the "real" root file system

39 7) init places the root file system at the root directory using the

40 pivot_root system call

41 8) init execs the ``/sbin/init`` on the new root filesystem, performing

42 the usual boot sequence

43 9) the initrd file system is removed

45 Note that changing the root directory does not involve unmounting it.

46 It is therefore possible to leave processes running on initrd during that

47 procedure. Also note that file systems mounted under initrd continue to

48 be accessible.

51 Boot command-line options

52 -------------------------

54 initrd adds the following new options::

56 initrd=<path> (e.g. LOADLIN)

58 Loads the specified file as the initial RAM disk. When using LILO, you

59 have to specify the RAM disk image file in /etc/lilo.conf, using the

60 INITRD configuration variable.

62 noinitrd

64 initrd data is preserved but it is not converted to a RAM disk and

65 the "normal" root file system is mounted. initrd data can be read

66 from /dev/initrd. Note that the data in initrd can have any structure

67 in this case and doesn't necessarily have to be a file system image.

68 This option is used mainly for debugging.

70 Note: /dev/initrd is read-only and it can only be used once. As soon

71 as the last process has closed it, all data is freed and /dev/initrd

72 can't be opened anymore.

74 root=/dev/ram0

76 initrd is mounted as root, and the normal boot procedure is followed,

77 with the RAM disk mounted as root.

79 Compressed cpio images

80 ----------------------

82 Recent kernels have support for populating a ramdisk from a compressed cpio

83 archive. On such systems, the creation of a ramdisk image doesn't need to

84 involve special block devices or loopbacks; you merely create a directory on

85 disk with the desired initrd content, cd to that directory, and run (as an

86 example)::

88 find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.img

90 Examining the contents of an existing image file is just as simple::

92 mkdir /tmp/imagefile

93 cd /tmp/imagefile

94 gzip -cd /boot/imagefile.img | cpio -imd --quiet

96 Installation

97 ------------

99 First, a directory for the initrd file system has to be created on the

100 "normal" root file system, e.g.::

101

102 # mkdir /initrd

103

104 The name is not relevant. More details can be found on the

105 :manpage:`pivot_root(2)` man page.

106

107 If the root file system is created during the boot procedure (i.e. if

108 you're building an install floppy), the root file system creation

109 procedure should create the ``/initrd`` directory.

110

111 If initrd will not be mounted in some cases, its content is still

112 accessible if the following device has been created::

113

114 # mknod /dev/initrd b 1 250

115 # chmod 400 /dev/initrd

116

117 Second, the kernel has to be compiled with RAM disk support and with

118 support for the initial RAM disk enabled. Also, at least all components

119 needed to execute programs from initrd (e.g. executable format and file

120 system) must be compiled into the kernel.

121

122 Third, you have to create the RAM disk image. This is done by creating a

123 file system on a block device, copying files to it as needed, and then

124 copying the content of the block device to the initrd file. With recent

125 kernels, at least three types of devices are suitable for that:

126

127 - a floppy disk (works everywhere but it's painfully slow)

128 - a RAM disk (fast, but allocates physical memory)

129 - a loopback device (the most elegant solution)

130

131 We'll describe the loopback device method:

132

133 1) make sure loopback block devices are configured into the kernel

134 2) create an empty file system of the appropriate size, e.g.::

135

136 # dd if=/dev/zero of=initrd bs=300k count=1

137 # mke2fs -F -m0 initrd

138

139 (if space is critical, you may want to use the Minix FS instead of Ext2)

140 3) mount the file system, e.g.::

141

142 # mount -t ext2 -o loop initrd /mnt

143

144 4) create the console device::

145

146 # mkdir /mnt/dev

147 # mknod /mnt/dev/console c 5 1

148

149 5) copy all the files that are needed to properly use the initrd

150 environment. Don't forget the most important file, ``/sbin/init``

151

152 .. note:: ``/sbin/init`` permissions must include "x" (execute).

153

154 6) correct operation the initrd environment can frequently be tested

155 even without rebooting with the command::

156

157 # chroot /mnt /sbin/init

158

159 This is of course limited to initrds that do not interfere with the

160 general system state (e.g. by reconfiguring network interfaces,

161 overwriting mounted devices, trying to start already running demons,

162 etc. Note however that it is usually possible to use pivot_root in

163 such a chroot'ed initrd environment.)

164 7) unmount the file system::

165

166 # umount /mnt

167

168 8) the initrd is now in the file "initrd". Optionally, it can now be

169 compressed::

170

171 # gzip -9 initrd

172

173 For experimenting with initrd, you may want to take a rescue floppy and

174 only add a symbolic link from ``/sbin/init`` to ``/bin/sh``. Alternatively, you

175 can try the experimental newlib environment [#f2]_ to create a small

176 initrd.

177

178 Finally, you have to boot the kernel and load initrd. Almost all Linux

179 boot loaders support initrd. Since the boot process is still compatible

180 with an older mechanism, the following boot command line parameters

181 have to be given::

182

183 root=/dev/ram0 rw

184

185 (rw is only necessary if writing to the initrd file system.)

186

187 With LOADLIN, you simply execute::

188

189 LOADLIN <kernel> initrd=<disk_image>

190

191 e.g.::

192

193 LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw

194

195 With LILO, you add the option ``INITRD=<path>`` to either the global section

196 or to the section of the respective kernel in ``/etc/lilo.conf``, and pass

197 the options using APPEND, e.g.::

198

199 image = /bzImage

200 initrd = /boot/initrd.gz

201 append = "root=/dev/ram0 rw"

202

203 and run ``/sbin/lilo``

204

205 For other boot loaders, please refer to the respective documentation.

206

207 Now you can boot and enjoy using initrd.

208

209

210 Changing the root device

211 ------------------------

212

213 When finished with its duties, init typically changes the root device

214 and proceeds with starting the Linux system on the "real" root device.

215

216 The procedure involves the following steps:

217 - mounting the new root file system

218 - turning it into the root file system

219 - removing all accesses to the old (initrd) root file system

220 - unmounting the initrd file system and de-allocating the RAM disk

221

222 Mounting the new root file system is easy: it just needs to be mounted on

223 a directory under the current root. Example::

224

225 # mkdir /new-root

226 # mount -o ro /dev/hda1 /new-root

227

228 The root change is accomplished with the pivot_root system call, which

229 is also available via the ``pivot_root`` utility (see :manpage:`pivot_root(8)`

230 man page; ``pivot_root`` is distributed with util-linux version 2.10h or higher

231 [#f3]_). ``pivot_root`` moves the current root to a directory under the new

232 root, and puts the new root at its place. The directory for the old root

233 must exist before calling ``pivot_root``. Example::

234

235 # cd /new-root

236 # mkdir initrd

237 # pivot_root . initrd

238

239 Now, the init process may still access the old root via its

240 executable, shared libraries, standard input/output/error, and its

241 current root directory. All these references are dropped by the

242 following command::

243

244 # exec chroot . what-follows <dev/console >dev/console 2>&1

245

246 Where what-follows is a program under the new root, e.g. ``/sbin/init``

247 If the new root file system will be used with udev and has no valid

248 ``/dev`` directory, udev must be initialized before invoking chroot in order

249 to provide ``/dev/console``.

250

251 Note: implementation details of pivot_root may change with time. In order

252 to ensure compatibility, the following points should be observed:

253

254 - before calling pivot_root, the current directory of the invoking

255 process should point to the new root directory

256 - use . as the first argument, and the _relative_ path of the directory

257 for the old root as the second argument

258 - a chroot program must be available under the old and the new root

259 - chroot to the new root afterwards

260 - use relative paths for dev/console in the exec command

261

262 Now, the initrd can be unmounted and the memory allocated by the RAM

263 disk can be freed::

264

265 # umount /initrd

266 # blockdev --flushbufs /dev/ram0

267

268 It is also possible to use initrd with an NFS-mounted root, see the

269 :manpage:`pivot_root(8)` man page for details.

270

271

272 Usage scenarios

273 ---------------

274

275 The main motivation for implementing initrd was to allow for modular

276 kernel configuration at system installation. The procedure would work

277 as follows:

278

279 1) system boots from floppy or other media with a minimal kernel

280 (e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and

281 loads initrd

282 2) ``/sbin/init`` determines what is needed to (1) mount the "real" root FS

283 (i.e. device type, device drivers, file system) and (2) the

284 distribution media (e.g. CD-ROM, network, tape, ...). This can be

285 done by asking the user, by auto-probing, or by using a hybrid

286 approach.

287 3) ``/sbin/init`` loads the necessary kernel modules

288 4) ``/sbin/init`` creates and populates the root file system (this doesn't

289 have to be a very usable system yet)

290 5) ``/sbin/init`` invokes ``pivot_root`` to change the root file system and

291 execs - via chroot - a program that continues the installation

292 6) the boot loader is installed

293 7) the boot loader is configured to load an initrd with the set of

294 modules that was used to bring up the system (e.g. ``/initrd`` can be

295 modified, then unmounted, and finally, the image is written from

296 ``/dev/ram0`` or ``/dev/rd/0`` to a file)

297 8) now the system is bootable and additional installation tasks can be

298 performed

299

300 The key role of initrd here is to re-use the configuration data during

301 normal system operation without requiring the use of a bloated "generic"

302 kernel or re-compiling or re-linking the kernel.

303

304 A second scenario is for installations where Linux runs on systems with

305 different hardware configurations in a single administrative domain. In

306 such cases, it is desirable to generate only a small set of kernels

307 (ideally only one) and to keep the system-specific part of configuration

308 information as small as possible. In this case, a common initrd could be

309 generated with all the necessary modules. Then, only ``/sbin/init`` or a file

310 read by it would have to be different.

311

312 A third scenario is more convenient recovery disks, because information

313 like the location of the root FS partition doesn't have to be provided at

314 boot time, but the system loaded from initrd can invoke a user-friendly

315 dialog and it can also perform some sanity checks (or even some form of

316 auto-detection).

317

318 Last not least, CD-ROM distributors may use it for better installation

319 from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM disk

320 via initrd from CD; or by booting via a loader like ``LOADLIN`` or directly

321 from the CD-ROM, and loading the RAM disk from CD without need of

322 floppies.

323

324

325 Obsolete root change mechanism

326 ------------------------------

327

328 The following mechanism was used before the introduction of pivot_root.

329 Current kernels still support it, but you should _not_ rely on its

330 continued availability.

331

332 It works by mounting the "real" root device (i.e. the one set with rdev

333 in the kernel image or with root=... at the boot command line) as the

334 root file system when linuxrc exits. The initrd file system is then

335 unmounted, or, if it is still busy, moved to a directory ``/initrd``, if

336 such a directory exists on the new root file system.

337

338 In order to use this mechanism, you do not have to specify the boot

339 command options root, init, or rw. (If specified, they will affect

340 the real root file system, not the initrd environment.)

341

342 If /proc is mounted, the "real" root device can be changed from within

343 linuxrc by writing the number of the new root FS device to the special

344 file /proc/sys/kernel/real-root-dev, e.g.::

345

346 # echo 0x301 >/proc/sys/kernel/real-root-dev

347

348 Note that the mechanism is incompatible with NFS and similar file

349 systems.

350

351 This old, deprecated mechanism is commonly called ``change_root``, while

352 the new, supported mechanism is called ``pivot_root``.

353

354

355 Mixed change_root and pivot_root mechanism

356 ------------------------------------------

357

358 In case you did not want to use ``root=/dev/ram0`` to trigger the pivot_root

359 mechanism, you may create both ``/linuxrc`` and ``/sbin/init`` in your initrd

360 image.

361

362 ``/linuxrc`` would contain only the following::

363

364 #! /bin/sh

365 mount -n -t proc proc /proc

366 echo 0x0100 >/proc/sys/kernel/real-root-dev

367 umount -n /proc

368

369 Once linuxrc exited, the kernel would mount again your initrd as root,

370 this time executing ``/sbin/init``. Again, it would be the duty of this init

371 to build the right environment (maybe using the ``root= device`` passed on

372 the cmdline) before the final execution of the real ``/sbin/init``.

373

374

375 Resources

376 ---------

377

378 .. [#f1] Almesberger, Werner; "Booting Linux: The History and the Future"

379 https://www.almesberger.net/cv/papers/ols2k-9.ps.gz

380 .. [#f2] newlib package (experimental), with initrd example

381 https://www.sourceware.org/newlib/

382 .. [#f3] util-linux: Miscellaneous utilities for Linux

383 https://www.kernel.org/pub/linux/utils/util-linux/

384

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

initrd 개요와 동작

1-50

초기 RAM 디스크(initrd) 사용

이 문서는 Werner Almesberger `<werner.almesberger@epfl.ch>`와 Hans Lermen `<lermen@fgan.de>`가 1996년과 2000년에 작성했습니다.

initrd는 부트로더가 RAM 디스크를 불러오게 합니다. 이 RAM 디스크를 루트 파일시스템으로 마운트하고 그 안의 프로그램을 실행할 수 있습니다. 이후 다른 장치에서 새 루트 파일시스템을 마운트하고, 이전 initrd 루트를 디렉터리로 옮긴 뒤 마운트 해제할 수 있습니다.

initrd는 주로 시스템 시작을 두 단계로 나누도록 설계되었습니다. 커널은 최소한의 내장 드라이버만으로 시작하고, 추가 모듈은 initrd에서 불러옵니다.

이 문서는 initrd 사용법을 간략히 설명합니다. 부팅 과정의 자세한 설명은 참고문헌 `[#f1]`에 있습니다.

동작

initrd를 사용할 때 시스템은 보통 다음 순서로 부팅합니다.

1) 부트로더가 커널과 초기 RAM 디스크를 불러옵니다.
2) 커널이 initrd를 일반 RAM 디스크로 변환하고 initrd가 사용하던 메모리를 해제합니다.
3) 루트 장치가 `/dev/ram0`이 아니면 아래의 `구식 루트 변경 메커니즘`에 설명된 폐기 예정 `change_root` 절차를 따릅니다.
4) 루트 장치를 마운트합니다. 루트가 `/dev/ram0`이면 initrd 이미지를 루트로 마운트합니다.
5) `/sbin/init`을 실행합니다. 셸 스크립트를 포함한 유효한 실행 파일이면 무엇이든 가능하며 uid 0으로 실행되어 일반 init이 할 수 있는 거의 모든 작업을 할 수 있습니다.
6) init이 실제 루트 파일시스템을 마운트합니다.
7) init이 `pivot_root` 시스템 호출로 새 파일시스템을 루트 디렉터리에 배치합니다.
8) 새 루트 파일시스템의 `/sbin/init`을 exec하여 일반적인 부팅 순서를 수행합니다.
9) initrd 파일시스템을 제거합니다.

루트 디렉터리를 바꾸는 작업에는 루트의 마운트 해제가 포함되지 않습니다. 따라서 절차 중에도 initrd에서 프로세스를 계속 실행할 수 있고, initrd 아래에 마운트된 파일시스템에도 계속 접근할 수 있습니다.

부팅 옵션과 압축 cpio 이미지

51-95

부팅 명령줄 옵션

initrd는 다음 옵션을 추가합니다.

옵션	동작
initrd=<path>	지정한 파일을 초기 RAM 디스크로 불러옵니다. 예로 LOADLIN에서 사용합니다. LILO에서는 `/etc/lilo.conf`에 `INITRD` 설정 변수로 RAM 디스크 이미지 파일을 지정해야 합니다.
noinitrd	initrd 데이터를 보존하지만 RAM 디스크로 변환하지 않고 일반 루트 파일시스템을 마운트합니다. `/dev/initrd`에서 데이터를 읽을 수 있으며 파일시스템 이미지일 필요는 없습니다. 주로 디버깅에 사용합니다. `/dev/initrd`는 읽기 전용이고 한 번만 사용할 수 있으며, 마지막 프로세스가 닫으면 데이터가 모두 해제되어 다시 열 수 없습니다.
root=/dev/ram0	initrd를 루트로 마운트하고 RAM 디스크가 루트인 상태에서 일반 부팅 절차를 따릅니다.

압축 cpio 이미지

최근 커널은 압축 cpio 아카이브에서 ramdisk를 채울 수 있습니다. 별도의 블록 장치나 loopback 없이 원하는 initrd 내용의 디렉터리를 만든 뒤 그 디렉터리에서 다음 명령을 실행하면 됩니다.

find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.img

기존 이미지 파일의 내용을 확인하는 것도 간단합니다.

mkdir /tmp/imagefile
cd /tmp/imagefile
gzip -cd /boot/imagefile.img | cpio -imd --quiet

initrd 설치와 이미지 생성

96-176

설치

먼저 일반 루트 파일시스템에 initrd 파일시스템용 디렉터리를 만듭니다.

# mkdir /initrd

디렉터리 이름은 중요하지 않습니다. 자세한 내용은 `pivot_root(2)` 매뉴얼 페이지를 참조하십시오. 부팅 중 루트 파일시스템을 만드는 설치 매체라면 해당 생성 절차에서 `/initrd` 디렉터리도 만들어야 합니다.

일부 경우 initrd를 마운트하지 않더라도 다음 장치를 만들면 내용에 접근할 수 있습니다.

# mknod /dev/initrd b 1 250
# chmod 400 /dev/initrd

둘째, 커널을 RAM 디스크와 초기 RAM 디스크 지원을 활성화해 컴파일해야 합니다. initrd에서 프로그램을 실행하는 데 필요한 실행 형식과 파일시스템 등의 구성 요소도 최소한 커널에 내장해야 합니다.

셋째, RAM 디스크 이미지를 만듭니다. 블록 장치에 파일시스템을 만들고 필요한 파일을 복사한 뒤 블록 장치의 내용을 initrd 파일로 복사합니다. 최근 커널에서는 다음 세 장치 유형을 사용할 수 있습니다.

플로피 디스크: 어디서나 동작하지만 매우 느립니다.
RAM 디스크: 빠르지만 물리 메모리를 할당합니다.
loopback 장치: 가장 깔끔한 방법입니다.

다음은 loopback 장치 방식입니다. 먼저 커널에 loopback 블록 장치가 설정되어 있는지 확인합니다.

1~2. 빈 파일시스템 생성

# dd if=/dev/zero of=initrd bs=300k count=1
# mke2fs -F -m0 initrd

공간이 매우 중요하다면 Ext2 대신 Minix FS를 사용할 수 있습니다.

3. 파일시스템 마운트

# mount -t ext2 -o loop initrd /mnt

4. 콘솔 장치 생성

# mkdir /mnt/dev
# mknod /mnt/dev/console c 5 1

5. 필요한 파일 복사

initrd 환경을 제대로 사용하는 데 필요한 파일을 모두 복사하십시오. 가장 중요한 `/sbin/init`을 잊지 말아야 하며 권한에 실행 비트 `x`가 포함되어야 합니다.

6. 재부팅 없이 환경 시험

# chroot /mnt /sbin/init

이 시험은 네트워크 인터페이스 재설정, 마운트된 장치 덮어쓰기, 이미 실행 중인 데몬 시작처럼 전체 시스템 상태를 방해하지 않는 initrd에만 적합합니다. 다만 이러한 chroot initrd 환경에서도 대개 `pivot_root`를 사용할 수 있습니다.

7. 파일시스템 마운트 해제

# umount /mnt

8. 선택적으로 이미지 압축

# gzip -9 initrd

이제 `initrd` 파일에 이미지가 있습니다. initrd를 시험할 때는 복구 플로피에서 `/sbin/init`이 `/bin/sh`를 가리키는 심볼릭 링크만 추가할 수 있습니다. 또는 실험적 newlib 환경 `[#f2]`로 작은 initrd를 만들 수 있습니다.

부트로더에서 initrd 불러오기

177-209

마지막으로 커널을 부팅하고 initrd를 불러와야 합니다. 거의 모든 Linux 부트로더가 initrd를 지원합니다. 부팅 과정이 구식 메커니즘과도 호환되므로 다음 커널 명령줄 매개변수를 지정해야 합니다.

root=/dev/ram0 rw

initrd 파일시스템에 쓸 때만 `rw`가 필요합니다.

LOADLIN에서는 다음과 같이 실행합니다.

LOADLIN <kernel> initrd=<disk_image>

예시는 다음과 같습니다.

LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw

LILO에서는 전역 절 또는 `/etc/lilo.conf`의 해당 커널 절에 `INITRD=<path>`를 추가하고 `APPEND`로 옵션을 전달합니다.

image = /bzImage
  initrd = /boot/initrd.gz
  append = "root=/dev/ram0 rw"

그 뒤 `/sbin/lilo`를 실행합니다. 다른 부트로더는 각 문서를 참조하십시오. 이제 initrd로 부팅할 수 있습니다.

루트 장치 변경과 pivot_root

210-271

init은 맡은 작업을 끝내면 보통 루트 장치를 변경하고 실제 루트 장치에서 Linux 시스템을 시작합니다.

절차는 다음 단계로 이루어집니다.

새 루트 파일시스템을 마운트합니다.
새 파일시스템을 루트 파일시스템으로 만듭니다.
이전 initrd 루트 파일시스템에 대한 모든 접근을 제거합니다.
initrd 파일시스템을 마운트 해제하고 RAM 디스크 할당을 해제합니다.

새 루트는 현재 루트 아래 디렉터리에 마운트하면 됩니다.

# mkdir /new-root
# mount -o ro /dev/hda1 /new-root

루트 변경은 `pivot_root` 시스템 호출로 수행하며 `pivot_root` 유틸리티로도 사용할 수 있습니다. `pivot_root(8)` 매뉴얼 페이지를 참조하십시오. 이 유틸리티는 util-linux 2.10h 이상에 포함됩니다 `[#f3]`. `pivot_root`는 현재 루트를 새 루트 아래 디렉터리로 옮기고 새 루트를 그 자리에 놓습니다. 호출 전에 이전 루트용 디렉터리가 있어야 합니다.

# cd /new-root
# mkdir initrd
# pivot_root . initrd

init 프로세스는 실행 파일, 공유 라이브러리, 표준 입력·출력·오류와 현재 루트 디렉터리를 통해 여전히 이전 루트를 참조할 수 있습니다. 다음 명령이 이 참조를 모두 끊습니다.

# exec chroot . what-follows <dev/console >dev/console 2>&1

`what-follows`는 새 루트 아래의 프로그램이며 예를 들면 `/sbin/init`입니다. 새 루트가 udev를 사용하지만 유효한 `/dev` 디렉터리가 없다면 `chroot` 전에 udev를 초기화하여 `/dev/console`을 제공해야 합니다.

`pivot_root` 구현 세부 사항은 바뀔 수 있으므로 호환성을 위해 다음 사항을 지키십시오.

`pivot_root` 호출 전에 호출 프로세스의 현재 디렉터리가 새 루트 디렉터리를 가리켜야 합니다.
첫 번째 인수로 `.`을 사용하고 두 번째 인수로 이전 루트 디렉터리의 상대 경로를 사용합니다.
이전 루트와 새 루트 모두에서 `chroot` 프로그램을 사용할 수 있어야 합니다.
그 뒤 새 루트로 chroot합니다.
exec 명령에서 `dev/console`의 상대 경로를 사용합니다.

이제 initrd를 마운트 해제하고 RAM 디스크 메모리를 해제할 수 있습니다.

# umount /initrd
# blockdev --flushbufs /dev/ram0

NFS로 마운트한 루트에서도 initrd를 사용할 수 있습니다. 자세한 내용은 `pivot_root(8)`을 참조하십시오.

initrd 사용 시나리오

272-324

initrd를 구현한 주된 동기는 시스템 설치 시 모듈식 커널 구성을 가능하게 하는 것이었습니다. 절차는 다음과 같습니다.

1) RAM 디스크, initrd, a.out, Ext2 FS 등을 지원하는 최소 커널로 플로피나 다른 매체에서 부팅하고 initrd를 불러옵니다.
2) `/sbin/init`이 실제 루트 FS의 장치 유형·드라이버·파일시스템과 CD-ROM·네트워크·테이프 같은 배포 매체에 필요한 요소를 판별합니다. 사용자 질문, 자동 탐색 또는 혼합 방식으로 수행할 수 있습니다.
3) `/sbin/init`이 필요한 커널 모듈을 불러옵니다.
4) `/sbin/init`이 루트 파일시스템을 만들고 채웁니다. 아직 완전히 사용 가능한 시스템일 필요는 없습니다.
5) `/sbin/init`이 `pivot_root`로 루트를 바꾸고 chroot를 통해 설치를 계속할 프로그램을 exec합니다.
6) 부트로더를 설치합니다.
7) 시스템을 시작할 때 사용한 모듈 집합의 initrd를 불러오도록 부트로더를 설정합니다. 예를 들어 `/initrd`를 수정하고 마운트 해제한 뒤 `/dev/ram0` 또는 `/dev/rd/0`에서 이미지를 파일로 쓸 수 있습니다.
8) 이제 시스템이 부팅 가능하며 나머지 설치 작업을 수행할 수 있습니다.

여기서 initrd의 핵심 역할은 비대한 범용 커널을 사용하거나 커널을 다시 컴파일·링크하지 않고도 정상 운영 중 설치 단계의 구성 데이터를 재사용하는 것입니다.

두 번째 시나리오는 한 관리 도메인 안에서 서로 다른 하드웨어 구성을 가진 시스템에 Linux를 설치하는 경우입니다. 적은 수의 커널, 이상적으로는 하나만 만들고 시스템별 구성 정보를 최소화할 수 있습니다. 필요한 모듈을 모두 담은 공통 initrd를 만들고 `/sbin/init` 또는 이 프로그램이 읽는 파일만 시스템별로 다르게 둘 수 있습니다.

세 번째 시나리오는 더 편리한 복구 디스크입니다. 부팅할 때 루트 FS 파티션 위치를 제공하는 대신 initrd에서 불러온 시스템이 사용자 친화적인 대화상자를 표시하고 건전성 검사나 자동 탐지를 수행할 수 있습니다.

마지막으로 CD-ROM 배포자는 부팅 플로피로 시작해 CD의 initrd에서 더 큰 RAM 디스크를 올리거나, LOADLIN 같은 로더 또는 CD-ROM에서 직접 부팅한 뒤 플로피 없이 CD에서 RAM 디스크를 불러오는 방식으로 설치를 개선할 수 있습니다.

구식 change_root 메커니즘

325-354

다음 메커니즘은 `pivot_root` 도입 전에 사용했습니다. 현재 커널도 지원하지만 앞으로 계속 제공된다고 기대해서는 안 됩니다.

`linuxrc`가 종료될 때 커널 이미지의 `rdev` 또는 부팅 명령줄의 `root=...`로 설정한 실제 루트 장치를 루트 파일시스템으로 마운트합니다. 이후 initrd를 마운트 해제하며, 아직 사용 중이면 새 루트에 `/initrd` 디렉터리가 있을 때 그곳으로 옮깁니다.

이 메커니즘을 사용할 때는 `root`, `init`, `rw` 부팅 옵션을 지정할 필요가 없습니다. 지정하면 initrd 환경이 아니라 실제 루트 파일시스템에 영향을 줍니다.

`/proc`가 마운트되어 있으면 `linuxrc`에서 새 루트 FS 장치 번호를 `/proc/sys/kernel/real-root-dev` 특수 파일에 써 실제 루트 장치를 바꿀 수 있습니다.

# echo 0x301 >/proc/sys/kernel/real-root-dev

이 메커니즘은 NFS와 유사 파일시스템과 호환되지 않습니다.

이 오래되고 폐기 예정인 메커니즘은 일반적으로 `change_root`, 새로 지원되는 메커니즘은 `pivot_root`라고 부릅니다.

혼합 방식과 참고 자료

355-383

change_root와 pivot_root 혼합 메커니즘

`root=/dev/ram0`으로 `pivot_root` 메커니즘을 시작하고 싶지 않다면 initrd 이미지에 `/linuxrc`와 `/sbin/init`을 모두 만들 수 있습니다.

`/linuxrc`에는 다음 내용만 둡니다.

#! /bin/sh
mount -n -t proc proc /proc
echo 0x0100 >/proc/sys/kernel/real-root-dev
umount -n /proc

`linuxrc`가 종료되면 커널은 initrd를 다시 루트로 마운트하고 이번에는 `/sbin/init`을 실행합니다. 이 init은 명령줄로 전달된 `root=` 장치를 사용할 수도 있으며, 실제 `/sbin/init`을 마지막으로 실행하기 전에 올바른 환경을 구성해야 합니다.