Useradd: cannot open /etc/shadow

Доброго дня.

Wirenboard 5, при попытке создать пользователя выдает ошибку.
root@wirenboard:~# useradd vlad
useradd: cannot open /etc/shadow

Права на shadow
root@wirenboard:~# ls -l /etc/shadow
lrwxrwxrwx 1 root root 20 Dec 18 13:11 /etc/shadow -> /mnt/data/etc/shadow

root@wirenboard:~# ls -l /mnt/data/etc/shadow
-rw-r----- 1 root shadow 744 Dec 7 03:34 /mnt/data/etc/shadow

у меня похожая ошибка:

root@wirenboard:~# useradd avp
useradd: cannot open /etc/passwd

при том, что запись в /etc/passwd проходит нормально

Вероятно useradd как-то странно реагирует на линки. возможно он их понимает и пытается явно по ним следовать. сам /mnt/data/etc/passwd на запись не доступен

passwd при этом нормально работает

WB4
вроде работает
root@wirenboard:~# useradd polsh
root@wirenboard:~# cut -d: -f1 /etc/passwd
root
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
proxy
www-data
backup
list
irc
gnats
nobody
libuuid
ntp
sshd
mosquitto
polsh
root@wirenboard:~# uname -a
Linux wirenboard 3.19.0-imxv5-x0.1 #506 Wed Dec 9 19:08:27 MSK 2015 armv5tejl GNU/Linux
root@wirenboard:~#

Да, убрал линк и useradd стал работать.
То есть shadow стал в /etc/ а не в /mnt/data/etc/
интересно что при этом отвалится.

Сборка та же, что и Polsh, только железка 5я а не 4я.

root@wirenboard:~# uname -a
Linux wirenboard 3.19.0-imxv5-x0.1 #506 Wed Dec 9 19:08:27 MSK 2015 armv5tejl GNU/Linux

Знаем, чиним.

можно пояснить как чинить планируете, чего ждать?

текущая реализация с симлинками на /mnt/data делает меня грустным :disappointed: штатным образом многое не ставится
wb4 сделан куда более стандартно и приятно в этом отношении

Та же проблема…

В новых прошивках (с версии wb-configs 1.63) уже исправлено: passwd, shadow теперь не симлинки ведущие в /mnt/data, а обычные файлы, и при изменениях они копируются туда-сюда. Это костыль, конечно, но жить можно.
Что именно у вас не ставится? wb-configs заботится о довольно небольшом колчестве файлов, список можно посмотреть в /etc/wb-configs.d/, при обновлениях пакетов эта машинерия тоже должна отрабатывать корректно, если нет - присылайте логи.

Вся эта хитрая система с симлинками нужна для того, чтоб иметь две независимые rootfs, у которых из общего только некоторые конфиги. Две rootfs нужны для обновлений путем заливки образа через web (чтоб не портить активную rootfs), плюс некоторая отказоустойчивость - если контроллер несколько раз не может нормально прогрузиться с одной rootfs (причины могут быть разные), бутлоадер автоматически переключается на другую. Рассматривали разные варианты как это организовать (вынос всего /etc, bind mount’ы, aufs2, чуть ли не контейнеры), и симлинки оказались меньшей из зол.