Дуга не монтирует массив btrfs на начальной загрузке
С ksh, zsh или ударом, с помощью замены процесса:
diff <(cut -d: -f1 passwd2 | sort) <(sort aix_old)
дает:
4,5c4
< harry
< henry
---
> ftp
7,8c6,7
< jennifer
< julie
---
> joe
> julietdiff -y <(cut -d: -f1 passwd2 | sort) <(sort aix_old)
дает:
amadeus amadeus
bill bill
charlie charlie
harry | ftp
henry <
image image
jennifer | joe
julie | juliet
romeo romeoОт процесса substition Wiki: http://en.wikipedia.org/wiki/Process_substitution
Команда разности Unix обычно принимает, что названия двух файлов выдерживают сравнение, или одно имя файла и стандартный вход. Замена процесса позволяет Вам сравнивать вывод двух программ непосредственно:
Разность $ <(вид file1) <(вид file2)
<(command)выражение говорит интерпретатор команд команде выполнения, и заставьте ее вывод появиться как файл. Команда может быть любой произвольно сложной командой оболочки.
То же перенаправление процесса yash's использования (в системах с /dev/fd/n):
diff /dev/fd/3 3<(cut -d: -f1 passwd2 | sort) /dev/fd/4 4<(sort aix_old)
Или более громоздким образом с любой подобной Границе оболочкой (в системах с /dev/fd/n):
cut -d: -f1 passwd2 | sort | {
sort aix_old 3<&- | diff /dev/fd/3 -
} 3<&0
Существует ловушка для mkinitcpio , которую вы можете включить, чтобы убедиться, что
btrfs device scan
будет запускаться во время загрузки до монтирования корневой файловой системы.
Вы можете включить эту ловушку, изменив /etc/mkinitcpio.conf , найдите строку HOOKS и поместите btrfs перед udev .
После модификации не забудьте восстановить initramfs с помощью mkinitcpio -p linux
Arch Wiki на самом деле рекомендует использовать ловушку udev , однако у меня такая же проблема, и она исправлена таким образом .
Два комментария. Во-первых, попробуйте монтировать по Label или UUID вместо устройства. Имена устройств иногда могут меняться.
Иначе, btrfs требует вызова brtfs device scan, прежде чем узнает о btrfs файловых системах на вашей машине. Я ожидал, что arch справится с этим, но почему-то это не работало, пока я не создал служебный файл для этого и не поместил его в /etc/systemd/system/local-fs-pre.target.wants/btrfs-dev-scan.service:
[Unit]
Description=Btrfs scan devices
Before=local-fs-pre.target
DefaultDependencies=false
[Service]
Type=oneshot
ExecStart=/usr/bin/btrfs device scan
[Install]
WantedBy=local-fs-pre.target
DefaultDependencies=false необходимо, иначе это испортит загрузку. (У не-архивных пользователей btrfs может быть расположен в /sbin вместо /usr/bin)
Это то, что должно обрабатываться btrfs хуком (я понял это немного позже), но все же, возможно, с этим есть проблема.
Однако у вас может быть какая-то другая проблема. Это Dependency failed предполагает, что какая-то ранее требуемая служба не запустилась. Я понятия не имею, что это может быть, вам следует проверить journalctl -b и поискать жалобы на зависимость, обычно там указано, чего именно не хватает. Или, по крайней мере, вы получите цепочку зависимостей, которые не сработали - возможно, что сбои зависимостей распространяются...
Вы также можете сгенерировать systemd-analyze plot > boot.svg и проверить последовательность, что именно загрузилось в каком порядке. Из этого можно догадаться, что именно пошло не так - кто кого ждал? И, что говорит systemctl --failed?