LINUX.ORG.RU
ФорумAdmin

fsck systemd raspberi pi 2

 , , ,


0

2

Такая фигня:

Часто при загрузке /dev/sda2 (mountpoint /storage) оказывается битым, останавливается загрузка на требовании вручную сделать fsck.ext4

Вопрос как осилить systemd, чтобы при ошибке/необходимости чинить sda2 выполнялся мой скрипт, например с sda3 брался файл sda2_image.dd.gz и за-dd-кался на /dev/sda2

Распаковал SYSTEM (squashfs)

man systemd-fsck смотрел, там написано что при проблемах с fsck система переходит в systemd-emergency mode или как-то так (пишу по памяти), но в скрипте emergency сообщение и предложение залогиниться, которых на моем экране нет (там предложение сделать fsck)

Кто-то с этим делом разбирался?

P.S. sda1/2/3 — условно, там на деле /dev/mmcblk0p1/2/3



Последнее исправление: most-fucktum (всего исправлений: 4)

ты уверен что дело не в флешке? малина к ним бывает капризна

upcFrost ★★★★★
()

Переопределить юнит systemd-fsck@экранированный-путь-до-раздела.service.

Строка после «@» — это результат systemd-escape --path от первого столбца нужной записи во fstab.

Например, если во fstab у тебя /dev/disk/by-label/data /mnt/data ext4 defaults 0 2, то переопределять нужно systemd-fsck@dev-disk-by\x2dlabel-data.service.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Не так как-то оно там.

$ find squashfs-root/ -type f -name 'fstab' -ls
84023982    0 -rw-rw-r--   1 root     root            0 Apr  1 00:38 squashfs-root/etc/fstab

fstab пустой

$ find squashfs-root/ -type f -name '*fsck*'
squashfs-root/sbin/e2fsck
squashfs-root/sbin/fsck_hfs
squashfs-root/usr/lib/systemd/system/systemd-fsck@.service
squashfs-root/usr/lib/systemd/systemd-fsck
squashfs-root/usr/sbin/fsck
squashfs-root/usr/sbin/fsck.fat

$ cd squashfs-root/usr/lib/systemd/system/
$  ls *fs*
fs-resize.service      local-fs-pre.target   sys-fs-fuse-connections.mount
fs-resize.target       local-fs.target       systemd-fsck@.service
initrd-fs.target       remote-fs-pre.target  systemd-remount-fs.service
initrd-root-fs.target  remote-fs.target

local-fs.target.wants:
kodi-rebrand.service  systemd-remount-fs.service  tmp.mount  var.mount


$ cat  systemd-fsck@.service
#  This file is part of systemd.
#
[Unit]
Description=File System Check on %f
Documentation=man:systemd-fsck@.service(8)
DefaultDependencies=no
BindsTo=%i.device
After=%i.device systemd-fsck-root.service local-fs-pre.target
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-fsck %f
StandardOutput=journal+console
TimeoutSec=0


$ cat local-fs-pre.target
#  This file is part of systemd.
#
[Unit]
Description=Local File Systems (Pre)
Documentation=man:systemd.special(7)
RefuseManualStart=yes

$ cat local-fs.target
#  This file is part of systemd.
#
[Unit]
Description=Local File Systems
Documentation=man:systemd.special(7)
DefaultDependencies=no
Conflicts=shutdown.target
After=local-fs-pre.target
OnFailure=emergency.target
OnFailureJobMode=replace-irreversibly

Епта, я 15 лет с unix/linux и как слепой котенок с этим systemd, будь оно проклято.

P.S. Чую проще будет перевести подкл. с wifi на ethernet и подкл. /storage по NFS.

most-fucktum
() автор топика
Ответ на: комментарий от most-fucktum

Епта, я 15 лет с unix/linux и как слепой котенок с этим systemd, будь оно проклято.

Это не проблема systemd, так ведь? :] Документации и разъяснительных статей — вагон.

Не так как-то оно там.

Не важно. Переопредели тот инстанс юнита systemd-fsck@.service, который соответствует твоему разделу. Если он монтируется именно как /dev/mmcblkXpY (а не по какому-либо симлинку) — то переопределяй systemd-fsck@dev-mmcblkXpY.service.

Под переопределением понимается копирование файла юнита (или его шаблона) в /etc/systemd/system и замена ExecStart= на самописный скрипт.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Да, это моя проблема, я ведь жалуюсь, а не systemd.

Мне не понятно, зачем его здесь использовали, железо ограниченное, кол-во софта ограниченно, их комбинаций не много. Зато все не прозрачно. Я не могу отследить цепочку запуска. fstab пустой, сделал 3-й раздел (не запланированный системой) и он тоже оказался примонтированным, т.е. монтируются автоматом все доступные разделы и т.д.

most-fucktum
() автор топика
Ответ на: комментарий от intelfx

Переопредели тот инстанс юнита systemd-fsck@.service, который соответствует твоему разделу.

где это и как выглядит? если что смотри вывод команды find ... -name '*fsck*'

most-fucktum
() автор топика
Ответ на: комментарий от most-fucktum

Я не могу отследить цепочку запуска

systemctl list-dependencies default.target?

intelfx ★★★★★
()
Ответ на: комментарий от most-fucktum

Ну вот есть у тебя файл /squashfs-root/usr/lib/systemd/system/systemd-fsck@.service.

Судя по squashfs-root, он в неизменяемом сквоше. Поэтому сначала найди оверлейный раздел и куда-нибудь примонтируй его — например, на $overlay. Потом пойди в $overlay/etc/systemd/system и скопируй в этот каталог вышеуказанный файл под именем systemd-fsck@dev-mmcblkXpY.service. Наконец, отредактируй его, указав в директиве ExecStart= путь к своему скрипту.

Только учти, что этот твой скрипт будет выполняться 1) когда ещё ничего не примонтировано и 2) параллельно с монтированием всех остальных разделов. Поэтому наверняка имеет смысл добавить в юнит директивы Requires= и After= для mount-юнита, соответствующего разделу с образом. Его имя равно выводу команды systemd-escape --suffix mount --path точка-монтирования.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Поэтому сначала найди оверлейный раздел и куда-нибудь примонтируй его

Нет в openelec оверлея. squashfs используется как / (readonly), а все userspace приложения работают с диском /storage (тот который портится). /tmp и /var в tmpfs

Так что работать надо прямо с squashfs, это муторно, поэтому хотелось бы быть максимально уверенным в необходимых действиях, без метода тыка.

most-fucktum
() автор топика
Ответ на: комментарий от most-fucktum

Гм. Тогда, наверное, стоит понять, почему портится, а не скотчекостылить :]

Но ладно. Во-первых, определи, из какого конкретно устройства монтируется storage (имеется в виду — напрямую из /dev/mmcblkXpY или из какого-то симлинка). Это нужно, чтобы переопределить соответствующий инстанс systemd-fsck@.service, потому что строка после @ — это просто строка, и в этом контексте симлинк != цель симлинка.

Во-вторых, нужно понять, кто отвечает за «автоматическое» монтирование всех найденных разделов (в т. ч. того, где у тебя будет резервный образ). Если там генератор, который на лету генерит systemd-юниты в самом начале загрузки — то в переопределённый инстанс нужно добавить After= от соответствующего mount-юнита. В противном случае нужно примонтировать его руками, а потом отмонтировать.

Ну и, наконец, что, fsck (именно полновесный fsck, а не fsck -p) не может починить этот раздел?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx


OpenELEC:~ # df -h | grep -v tmpfs
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1          255.7M    104.9M    150.8M  41% /flash
/dev/mmcblk0p2            3.1G    287.2M      2.6G  10% /storage
/dev/loop0               94.4M     94.4M         0 100% /

OpenELEC:~ # mount | grep ...
/dev/mmcblk0p1 on /flash type vfat (ro,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/mmcblk0p2 on /storage type ext4 (rw,noatime,data=ordered)
/dev/loop0 on / type squashfs (ro,relatime)

Если там генератор, который на лету генерит systemd-юниты в самом начале загрузки

Возможно, т.к. 3-ий раздел (не запланированный openelec'ом) тоже оказался примонтированным

Если ты хорошо разбираешься в systemd, может посмотришь в squashfs

http://releases.openelec.tv/OpenELEC-RPi2.arm-5.0.8.tar 100Mb

/target/SYSTEM — это и есть squashfs

распаковать unsquashfs SYSTEM

Ну и, наконец, что, fsck (именно полновесный fsck, а не fsck -p) не может починить этот раздел?

починить может, но часто слишком много файлов теряются и все-равно надо из бекапа восстанавливать.

most-fucktum
() автор топика
Ответ на: комментарий от most-fucktum

Я бы покопался, но времени не особо много. Может быть, вечером-ночью-завтра.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.