☰

Непустые точки монтирования с btrfs (SLES15): нужны ли они?

tag-icon • tag-icon mount btrfs suse
Непустые точки монтирования с btrfs (SLES15): нужны ли они?

У меня многолетний опыт работы с UNIX, но, думаю, я совершил фатальную ошибку:

Увидев сообщения во время загрузки о непустых точках монтирования, я рискнул очистить их во время миграции системы в новую среду. Я загрузил SLES Rescue System, смонтировал корневую файловую систему и базовую структуру системы (proc, sys, dev) на /mnt, затем сделал chroot /mntи mount -va.

Итак, все выглядело хорошо, я изменил некоторые параметры конфигурации и во время размонтирования проверил точки монтирования. Например: /var/cacheбыл смонтирован, umountуспешно, но все еще ll /var/cacheпоказывал непустую точку монтирования, в то время как файловая система отображалась не смонтированной. Поэтому я удалил содержимое.

По сути, я повторил шаги для каждой смонтированной файловой системы, затем вышел из chrootсреды, размонтировал остальное и перезагрузился.

К сожалению, система не загружается, так как GRUB жалуется, что не может найти normal.mod.

Так это особенность btrfs subvolumes? Кто может объяснить, что происходит?

/etc/fstab

Как меня и просили /etc/fstab, вот что имеет типичная система:

/dev/sys/root                              /            btrfs  defaults              0  0
/dev/sys/root                              /var         btrfs  subvol=/@/var         0  0
/dev/sys/root                              /usr/local   btrfs  subvol=/@/usr/local   0  0
/dev/sys/root                              /tmp         btrfs  subvol=/@/tmp         0  0
/dev/sys/root                              /srv         btrfs  subvol=/@/srv         0  0
/dev/sys/root                              /root        btrfs  subvol=/@/root        0  0
/dev/sys/root                              /opt         btrfs  subvol=/@/opt         0  0
UUID=9fd27493-d194-48ba-a4bc-3551123e0d3b  /home        xfs    defaults              0  0
/dev/sys/boot                              /boot        btrfs  defaults              0  0
UUID=0092-D1D5                             /boot/efi    vfat   utf8                  0  2
/dev/sys/root                              /.snapshots  btrfs  subvol=/@/.snapshots  0  0

решение1

Как это работало

/dev/sys/rootсодержит файловую систему Btrfs. Несколько записей в вашем fstabмонтировании различных ее подтомов к разным точкам монтирования.

Гипотеза: подтом по умолчанию в файловой системе Btrfs /dev/sys/rootнаходится в /@, и как только он смонтирован в /, монтируется множество других подтомовв их конкретных точках крепленияне имеет особого смысла, поскольку нужные (и обычно непустые) каталоги уже находятся там, где вы их ожидаете.

(Чтобы увидеть подтом по умолчанию, запустите sudo btrfs subvolume get-default /.)

Пожалуйста прочтиэто еще один мой ответи понять концептуальную разницу между деревом каталогов Btrfs (и подтомов) на устройстве и структурой каталогов в вашей ОС. Без этих знаний остальная часть текущего ответа может оказаться для вас очень запутанной.

Если субтом по умолчанию/@, /@из дерева Btrfs выглядит так же, как /в дереве ОСвместе со всем, что ниже. Это креплениеодиндостаточно увидеть, например, каталог /@/varиз дерева Btrfs как /varв дереве ОС. Я имею в виду, если вы попытаетесь получить доступ/var до /varзатем монтируется

  • ОС проверит, /varявляется ли (ОС) точкой монтирования; это не так;
  • поэтому ОС проверит, /является ли (ОС) точкой монтирования; это так и она связана с /@Btrfs;
  • поэтому ОС покажет вам /@/varBtrfs как /varОС.

Так уж получилось /@/var, что Btrfs — это подтом.Кроме тогомонтирование subvol=/@/varв /var(ОС) приведет к появлению того же каталога, что и /var(ОС). В частности, если вы сейчас получите доступ к /varто

  • ОС проверит, /varявляется ли (ОС) точкой монтирования; она является таковой и связана с /@/varBtrfs;
  • поэтому ОС покажет вам /@/varBtrfs.

А если вы отмонтируете /var(ОС), то вы вернетесь к первому случаю.

Так что неважно, /varсмонтирована (ОС) или нет (фактически неважно, могут быть тонкости). Так или иначе вы увидите /@/varBtrfs /varв ОС.

Несколько других записей в вашем fstabмонтировании различных подтомовгде бы вы их ни увидели. Я на самом деле не вижу смысла в этих записях (возможно, смысл в какой-то тонкости, которую я не могу сейчас распознать; или эти записи действительно совершенно бессмысленны).

Для сравнения: если бы /var(ОС) была смонтирована с помощью, subvol=/varто монтирование имело бы смысл, поскольку /varBtrfs не находится под /@Btrfs, и, таким образом, вы не можете получить к нему доступ, просто смонтировав /@Btrfs как /ОС.

Как ты это сломал

… был смонтирован, umountуспешно, но все еще ll …показывал непустую точку монтирования, в то время как файловая система отображалась не смонтированной. Поэтому я удалил содержимое.

Как я уже сказал, несколько записей в вашем fstabмонтировании различных подтомов, где вы бы их увидели в любом случае. В этих случаях, удаляя содержимое после того, как umountвы удалили содержимое, которое вы видели ранее umount. Вы думали, что удалили затененное, нерелевантное содержимое, но на самом деле вы удалили фактическое, важное содержимое.

Однако есть две вещи, которые не вписываются:

  1. В вашем примере точка монтирования — , вы якобы ее размонтировали; но в опубликованном вами файле /var/cacheее нет ./var/cachefstab
  2. Согласно тому fstab, что вы разместили, в то время как /(ОС) происходит из /dev/sys/root, /boot(ОС) происходит из /dev/sys/boot. Описанный механизм поломки вещей не может быть применен. Тем не менее, вы утверждаете, что "GRUB жаловался, что не может найти normal.mod", и из этого я делаю вывод, что вы действительно сломали вещи под /bootкаким-то образом.

Поэтому я подозреваю, что опубликованное fstab(вы описали это как «то, что есть в типичной системе») не являетсяточный fstabзатронутой ОС. Я подозреваю, /bootчто там использовалась та же файловая система, что и /, была без необходимости смонтирована и, таким образом, подвержена описанному сценарию поломки.

Связанный контент