Глава 10. Аварийный режим и образы live

Существуют два способа запуска в аварийном режиме.

Как и предполагает его название, этот режим разработан для спасения тех систем, которые застряли в проблеме "can’t boot". Представим себе некую ситуацию, при которой наша система не имеет возможности смонтировать свою корневую файловую систему и вы получаете следующее никогда не прекращающееся вырабатываться сообщение:

‘dracut-initqueue: warning dracut-initqueue timeout - starting timeout scripts’
		

И, допустим, у вас имеется установленным лишь одно ядро, как это показано здесь:

<snip>
.
.
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Started Forward Password R...s to Plymouth Directory Watch.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
[  145.832487] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
[  146.541525] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
[  147.130873] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
[  147.703069] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
[  148.267123] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
[  148.852865] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
[  149.430171] dracut-initqueue[437]: Warning: dracut-initqueue timeout - starting timeout scripts
.
.
</snip>
 	   

Поскольку эта система имеет лишь одно ядро (которое не способно запуститься), как бы вы смогли исправить такую проблему "can’t boot" без некой среды? Аварийный режим был создан для такой единственной цели. Давайте прежде всего выберем аварийный режим по умолчанию, который поступает предустановленным с Linux и который можно выбрать из имеющегося меню GRUB. Обратимся к Рисунку 10-3.

Этот аварийный режим запустится нормально и, как вы можете видеть на Рисунке 10-4, если всё хорошо, это представит вашему пользователю его корневую файловую систему.

Но в сознании может возникнуть некий вопрос: раз наше обычное ядро не способно запускаться, тогда как же та же самая система способна запускаться в аварийном режиме?

Это происходит по той причине, что когда вы устанавливаете Fedora или любой прочий дистрибутив Linux, собственный установщик Linux, Anaconda, устанавливает внутри /boot два ядра.

# ls -lh /boot/
total 164M
-rw-r--r--. 1 root root 209K Oct 22 01:03 config-5.3.7-301.fc31.x86_64
drwx------. 4 root root 4.0K Oct 24 04:44 efi
-rw-r--r--. 1 root root 181K Aug  2  2019 elf-memtest86+-5.01
drwxr-xr-x. 2 root root 4.0K Oct 24 04:42 extlinux
drwx------. 5 root root 4.0K Mar 28 13:37 grub2
-rw-------. 1 root root  80M Dec  9 10:18 initramfs-0-rescue-2058a9f13f9e489dba29c477a8ae2493.img
-rw-------. 1 root root  32M Dec  9 10:19 initramfs-5.3.7-301.fc31.x86_64.img
drwxr-xr-x. 3 root root 4.0K Dec  9 10:18 loader
drwx------. 2 root root  16K Dec  9 10:12 lost+found
-rw-r--r--. 1 root root 179K Aug  2  2019 memtest86+-5.01
-rw-------. 1 root root  30M Jan  6 09:37 new.img
-rw-------. 1 root root 4.3M Oct 22 01:03 System.map-5.3.7-301.fc31.x86_64
-rwxr-xr-x. 1 root root 8.9M Dec  9 10:18 vmlinuz-0-rescue-2058a9f13f9e489dba29c477a8ae2493
-rwxr-xr-x. 1 root root 8.9M Oct 22 01:04 vmlinuz-5.3.7-301.fc31.x86_64
		

Как вы можете видеть, vmlinuz-5.3.7-301.fc31.x86_64 это обычное ядро, в то время как vmlinuz-0-rescue-19a08a3e86c24b459999fbac68e42c05 представляет собой соответствующее аварийное ядро, которое является неким обособленным ядром со своим собственным файлом initramfs, носящим название initramfs-0-rescue-19a08a3e86c24b459999fbac68e42c05.img.

Давайте предположим, ято мы установили некий новый пакет (.rpm или .deb) предоставляемый nvidia, который обладает в своём составе новый графический драйвер. Так как такие графические драйверы должны добавляться в initramfs, наш пакет nvidia повторно собирает свою первоначальную initramfs ядра (initramfs-5.3.7-301.fc31.x86_64.img). Итак, наше первоначальное ядро обладает вновь добавленным графическим драйвером, но наш аварийный initramfs не обладает таким добавленным драйвером. Когда наш пользователь пытается выполнить запуск, его система отказывает в запуске своего первоначального ядра (vmlinuz-5.3.7-301.fc31.x86_64) так как вновь установленный графический драйвер не совместим с подключаемой графической платой, однако в то же самое время наша система успешно запустится в аварийном режиме, ибо такие несовместимые драйверы не представлены в нашей аварийной initramfs. Наше ядро аварийного режима будет обладать теми же самыми параметрами командной строки, которыми обладает и обычное ядро, а следовательно, установленное нами аварийное ядро знает значение названия своей корневой файловой системы пользователя.

Рисунок 10-5 отображает параметры командной строки обычного ядра.

Рисунок 10-6 показывает параметры командной строки аварийного ядра.

Initramfs аварийного режима (initramfs-0-rescue-2058a9f13f9e489dba29c477a8ae2493.img) намного больше в размере нежели наш initramfs первоначального ядра (initramfs-5.3.7-301.fc31.x86_64.img).

# ls -lh /boot/
total 164M
-rw-r--r--. 1 root root 209K Oct 22 01:03 config-5.3.7-301.fc31.x86_64
drwx------. 4 root root 4.0K Oct 24 04:44 efi
-rw-r--r--. 1 root root 181K Aug  2  2019 elf-memtest86+-5.01
drwxr-xr-x. 2 root root 4.0K Oct 24 04:42 extlinux
drwx------. 5 root root 4.0K Mar 28 13:37 grub2
-rw-------. 1 root root  80M Dec  9 10:18 initramfs-0-rescue-2058a9f13f9e489dba29c477a8ae2493.img
-rw-------. 1 root root  32M Dec  9 10:19 initramfs-5.3.7-301.fc31.x86_64.img
drwxr-xr-x. 3 root root 4.0K Dec  9 10:18 loader
drwx------. 2 root root  16K Dec  9 10:12 lost+found
-rw-r--r--. 1 root root 179K Aug  2  2019 memtest86+-5.01
-rw-------. 1 root root  30M Jan  6 09:37 new.img
-rw-------. 1 root root 4.3M Oct 22 01:03 System.map-5.3.7-301.fc31.x86_64
-rwxr-xr-x. 1 root root 8.9M Dec  9 10:18 vmlinuz-0-rescue-2058a9f13f9e489dba29c477a8ae2493
-rwxr-xr-x. 1 root root 8.9M Oct 22 01:04 vmlinuz-5.3.7-301.fc31.x86_64
		

Почему так? Это потому, что такая аварийная initramfs не является специфичной для хоста вариантом, которым и является обычное ядро. Эта аварийная initramfs является общей initramfs, которая подготавливается с учётом всех возможных устройств в который некий пользователь может создавать корневую файловую систему. Давайте рассмотрим обе свои системы initramfs.

# tree

.
├── normal_kernel
│   └── initramfs-5.3.7-301.fc31.x86_64.img
└── rescue_kernel
    └── initramfs-0-rescue-2058a9f13f9e489dba29c477a8ae2493.img

2 directories, 2 files
		

Мы распакуем их в их соответствующие каталоги.

#/usr/lib/dracut/skipcpio
     initramfs-5.3.7-301.fc31.x86_64.img | gunzip -c | cpio -idv
#/usr/lib/dracut/skipcpio
     initramfs-0-rescue-2058a9f13f9e489dba29c477a8ae2493.img | gunzip -c | cpio -idv
		

Мы создадим перечни файлов обеих распакованных initramfs.

# tree normal_kernel/ > normal.txt
# tree rescue_kernel/ > rescue.txt
		

Ниже приводятся имеющиеся между этими обеими системами initramfs различия. Наша аварийная система initramfs обладает почти 2 189 дополнительными файлами по сравнению с нашей обычной initramfs. Кроме того, в нашу аварийную initramfs было добавлено почти 719 дополнительных модулей.

# diff -yt rescue.txt normal.txt  | grep '<' | wc -l
     2186
# diff -yt rescue.txt normal.txt  | grep '<' | grep -i '.ko'  | wc -l
     719
<skip>
.
.
│   │   ├── lspci                                               <
│   │   ├── mdadm                                               <
│   │   ├── mdmon                                               <
│   │   ├── mdraid-cleanup                                      <
│   │   ├── mdraid_start                                        <
│   │   ├── mount.cifs                                          <
│   │   ├── mount.nfs                                           <
│   │   ├── mount.nfs4 -> mount.nfs                             <
│   │   ├── mpathpersist                                        <
│   │   ├── multipath                                           <
│   │   ├── multipathd                                          <
│   │   ├── nfsroot                                             <
│   │   ├── partx                                               <
│   │   ├── pdata_tools                                         <
│   │   ├── ping -> ../bin/ping                                 <
│   │   ├── ping6 -> ../bin/ping                                <
│   │   ├── rpcbind -> ../bin/rpcbind                           <
│   │   ├── rpc.idmapd                                          <
│   │   ├── rpcinfo -> ../bin/rpcinfo                           <
│   │   ├── rpc.statd                                           <
│   │   ├── setpci                                              <
│   │   ├── showmount                                           <
│   │   ├── thin_check -> pdata_tools                           <
│   │   ├── thin_dump -> pdata_tools                            <
│   │   ├── thin_repair -> pdata_tools                          <
│   │   ├── thin_restore -> pdata_tools                         <
│   │   ├── xfs_db                                              <
│   │   ├── xfs_metadump                                        <
│   │   └── xfs_repair                                          <
    ├── lib                                                     <
    │   ├── iscsi                                               <
    │   ├── lldpad                                              <
    │   ├── nfs                                                 <
    │   │   ├── rpc_pipefs                                      <
    │   │   └── statd                                           <
    │   │       └── sm                                          <
</skip>
		

Аварийная initramfs будет обладать почти всеми модулями и поддерживать файлы для тех устройств, на которых наш пользователь может создавать некую корневую файловую систему, в то время как наша обычная initramfs будет особой для хоста. Она будет обладать только те модули и файлы поддержки на которых наш пользователь сделал свою корневую файловую систему. Если вы желаете сделать аварийную initramfs для собственных нужд, тогда вы можете установить пакет dracut-config-generic в системах на основе Fedora. Этот пакет предоставляет лишь один файл и он обладает определённой конфигурацией для отключения выработки специфичной для хоста initramfs.

# rpm -ql dracut-config-generic
     /usr/lib/dracut/dracut.conf.d/02-generic-image.conf
# cat /usr/lib/dracut/dracut.conf.d/02-generic-image.conf
     hostonly="no"
		

Как вы можете видеть, этот файл ограничит dracut от создания предназначенной для хоста initramfs.

Проблема: Оба ядра, и обычное и аварийное отказывают в запуске. Рисунок 10-7 отображает сообщения паники обычного ядра.

   
Выдаваемые панические сообщения ядра жалуются на то, что их ядро не может смонтировать свою корневую файловую 
   систему. Мы ранее наблюдали, что всякий раз, когда ядро не способно смонтировать свою корневую файловую систему, 
   оно выдаёт сообщения таймаута dracut-initqueue.
'dracut-initqueue: warning dracut-initqueue timeout - starting timeout scripts'
 	   

Однако на это раз наши панические сообщения иные. Поэтому, это выглядит как проблема, не относящаяся к самой корневой файловой системе пользователя. Ещё одной уликой является то, что упоминается, что в нашей файловой системе VFS символы VFS это сокращение для "virtual file system", а потому это указывает на то, что эти сообщения о панике не способны смонтировать необходимую корневую файловую систему из initramfs. Основываясь на этих подсказках, я полагаю, что мы вычленили свою проблему и нам следует сосредоточиться на initramfs обоих своих ядер.

Как вы можете видеть на Рисунке 10-8, наши сообщения о панике ядра аварийного режима также схожие.

Решение: Вот те шаги, которые разрешают нашу проблему.

Аварийный режим корпоративных дистрибутивов Linux

В некоторых прочих дистрибутивах Linux, например в CentOS подход аварийного образа слегка иной. Такая корпоративная редакция Linux попытается обнаружить необходимую корневую файловую систему пользователя внутри себя самой. Давайте рассмотрим это в действии. Рисунок 10-11 и Рисунок 10-12 отображают процедуру выбора надлежащего аварийного режима в CentOS.

 

Рисунок 10-11

Приветственное окно CentOS

 

Рисунок 10-12

Выбор аварийного режима

Это запустится и, как вы можете видеть на Рисунке 10-13, на вашем экране будут отображены некоторые сообщения.

 

Рисунок 10-13

Информационные сообщения

Если мы выбираем вариант 1, continue, тогда наш аварийный режим обыщет свой диск и найдёт в себе самом необходимую корневую файловую систему. После того как требуемая корневая файловая система была выявлена, она монтируется в каталоге /mnt/sysimage. Обращаем внимание на Рисунок 10-14.

 

Рисунок 10-14

Смонтированная в /mnt/sysimage корневая файловая система

Как вы можете наблюдать, в /mnt/sysimage была смонтирована необходимая корневая файловая система пользователя; нам всего лишь требуется chroot в неё. Но основная прелесть в том, что нам нет нужды монтировать заблаговременно все виртуальные файловые системы. Это обусловлено тем, что, как вы можете видеть на Рисунке 10-15, применяемый в CentOS chroot был индивидуализирован и он будет самостоятельно монтировать все необходимые виртуальные файловые системы.

 

Рисунок 10-15

chroot

Когда мы выбрали вариант 2, Read-Only Mount, тогда соответствующие аварийные сценарии смонтировали найденную корневую файловую систему в /mnt/sysimage, но в режиме только для чтения. Если бы мы выбрали третий вариант, Skip, наша аварийная система не предприняла бы попыток поиска и монтирования в себе самой необходимой корневой файловой системы; это просто предоставило бы нам некую оболочку.

Но как происходит управление обнаружением необходимой корневой файловой системы когда имеющееся аварийное ядро соответствующего ISO CentOS не обладает в себе названием корневой файловой системы пользователя?

Здесь нет никакого трюка в том, что Anaconda способна отыскать название необходимой корневой файловой системы пользователя. Anaconda смонтирует абсолютно все подключённые к данной системе диски и проверит наличие или отсутствие /etc/fstab. Если /etc/fstab найден, тогда из него будет осуществлено извлечение название корневой файловой системы пользователя. Когда ваша система обладает гигантским числом подключённых дисков, тогда велика возможность того, что Anaconda может потребовать большого времени для монтирования имеющейся корневой файловой системы пользователя. В такой ситуации лучше вручную смонтировать необходимую корневую файловую систему пользователя.. Представленный в tarball Anaconda исходный код для поиска необходимой корневой файловой системы пользователя отображён здесь:

#vim pyanaconda/storage/root.py

 91 def _find_existing_installations(devicetree):
 92     """Find existing GNU/Linux installations on devices from the device tree.
 93
 94     :param devicetree: a device tree to find existing installations in
 95     :return: roots of all found installations
 96     """
 97     if not os.path.exists(conf.target.physical_root):
 98         blivet_util.makedirs(conf.target.physical_root)
 99
100     sysroot = conf.target.physical_root
101     roots = []
102     direct_devices = (dev for dev in devicetree.devices if dev.direct)
103     for device in direct_devices:
104         if not device.format.linux_native or not device.format.mountable or \
105            not device.controllable or not device.format.exists:
106             continue
107
108         try:
109             device.setup()
110         except Exception:  # pylint: disable=broad-except
111             log_exception_info(log.warning, "setup of %s failed", [device.name])
112             continue
113
114         options = device.format.options + ",ro"
115         try:
116             device.format.mount(options=options, mountpoint=sysroot)
117         except Exception:  # pylint: disable=broad-except
118             log_exception_info(log.warning, "mount of %s as %s failed", [device.name, device.format.type])
119             blivet_util.umount(mountpoint=sysroot)
120             continue
121
122         if not os.access(sysroot + "/etc/fstab", os.R_OK):
123             blivet_util.umount(mountpoint=sysroot)
124             device.teardown()
125             continue
126
127         try:
128             (architecture, product, version) = get_release_string(chroot=sysroot)
129         except ValueError:
130             name = _("Linux on %s") % device.name
131         else:
132             # I'd like to make this finer grained, but it'd be very difficult
133             # to translate.
134             if not product or not version or not architecture:
135                 name = _("Unknown Linux")
136             elif "linux" in product.lower():
137                 name = _("%(product)s %(version)s for %(arch)s") % \
138                     {"product": product, "version": version, "arch": architecture}
139             else:
140                 name = _("%(product)s Linux %(version)s for %(arch)s") % \
141                     {"product": product, "version": version, "arch": architecture}
142
143         (mounts, swaps) = _parse_fstab(devicetree, chroot=sysroot)
144         blivet_util.umount(mountpoint=sysroot)
145         if not mounts and not swaps:
146             # empty /etc/fstab. weird, but I've seen it happen.
147             continue
148         roots.append(Root(mounts=mounts, swaps=swaps, name=name))
149
		

# mkdir live_image
# mount /dev/cdrom live_image/
mount: /home/yogesh/live_image: WARNING: device write-protected, mounted read-only.

# tree live_image/
live_image/
├── EFI
│   └── BOOT
│       ├── BOOT.conf
│       ├── BOOTIA32.EFI
│       ├── BOOTX64.EFI
│       ├── fonts
│       │   └── unicode.pf2
│       ├── grub.cfg
│       ├── grubia32.efi
│       ├── grubx64.efi
│       ├── mmia32.efi
│       └── mmx64.efi
├── images
│   ├── efiboot.img
│   ├── macboot.img
│   └── pxeboot
│       ├── initrd.img
│       └── vmlinuz
├── isolinux
│   ├── boot.cat
│   ├── boot.msg
│   ├── grub.conf
│   ├── initrd.img
│   ├── isolinux.bin
│   ├── isolinux.cfg
│   ├── ldlinux.c32
│   ├── libcom32.c32
│   ├── libutil.c32
│   ├── memtest
│   ├── splash.png
│   ├── vesamenu.c32
│   └── vmlinuz
└── LiveOS
    └── squashfs.img
		

# mkdir live_image_extract_1
# mount live_image/LiveOS/squashfs.img  live_image_extract_1/

# ls live_image_extract_1/
     LiveOS
# ls live_image_extract_1/LiveOS/
     rootfs.img

# mkdir live_image_extract_2
# mount live_image_extract_1/LiveOS/rootfs.img live_image_extract_2/

# ls live_image_extract_2/
     bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
		

# mount | grep -i rootfs
/home/yogesh/live_image_extract_1/LiveOS/rootfs.img on /home/yogesh/live_image_extract_2 type ext4 (ro,relatime,seclabel)
		

# file live_image_extract_1/LiveOS/rootfs.img
live_image_extract_1/LiveOS/rootfs.img: Linux rev 1.0 ext4 filesystem data, UUID=849bdfdc-c8a9-4fed-a727-de52e24d981f, volume name "Anaconda" (extents) (64bit) (large files) (huge files)