LINUX.ORG.RU

Странное поведение... даже не знаю чего - дисковой подсистемы?

 , , ,


0

1

Тема в результате этого топика: Проблемы монтирования в fstab но решил выделить в отдельную.

Вкратце суть: вынес часть файлов на ssd+btrfs. Выжимка fstab:

UUID=d3120e12-4dfe-4d3c-bc6b-50b948f7447f 	/mnt/dev/storage 		ext4    defaults,noatime,commit=117 # hdd с файлопомойкой (дальше будет важно)
UUID=b26be618-752f-480d-9de2-eef356fb2796 	/usr		 		btrfs   subvol=usr,noatime,ssd,ssd_spread,space_cache,inode_cache,discard 
UUID=b26be618-752f-480d-9de2-eef356fb2796 	/opt		 		btrfs   subvol=opt,noatime,ssd,ssd_spread,space_cache,inode_cache,discard
UUID=b26be618-752f-480d-9de2-eef356fb2796 	/mnt/dev/ignition 		btrfs   noatime,compress=lzo,ssd,ssd_spread,space_cache,inode_cache,discard # основной том

LABEL=user1000					/home/user1000			ext4	defaults,noatime,commit=120	
/mnt/dev/ignition/home/user1000/.config		/home/user1000/.config		none	bind # биндим некоторый каталоги в хомяк
/mnt/dev/ignition/home/user1000/.gconf		/home/user1000/.gconf		none	bind # и так далее...
# ...

LABEL=user1001					/home/user1001			ext4	defaults,noatime,commit=120 # хомяки двух других пользователей
LABEL=user1002					/home/user1002			ext4	defaults,noatime,commit=120

# А тут bindfs и зеркалирования прав, в частности для группы users
bindfs#/mnt/dev/storage 	/mnt/storage	fuse	create-as-mounter,create-for-group=users,create-with-perms=u=rwD:g=rD:o-rwx,chmod-filter=g-w:o-rwx,perms=u=rwD:g=rD:o-rwx,mirror=user1000:user1001,force-group=users
bindfs#/home/@users 		/home/@users	fuse	create-as-mounter,create-for-group=users,create-with-perms=ug=rwD:o-rwx,chmod-filter=o-rwx,perms=ug+rwD:o-rwx,mirror=@users,force-group=users
Проблема возникает если монтируется /usr (2 строка). Если не монтировать проблемы нет.

Суть проблемы:
Перегружаюсь. Меня встречает экран lightdm где не отображаются обои пользователей как это должно быть при их выборе - показываются дефолтные.

Проблема с доступом к /usr? Откуда тогда бы показывались дефолтные?

Логинюсь в консоль. Все в /usr доступно для чтения обычному смертному. Но это еще не все, потому что у всех пользователей сейчас стоят обои из /mnt/storage/images который примонтирован предпоследней строкой и группа users должна отлично читать из него. И в принципе читает. Там тоже все доступно для чтения. А lightdm включен в users и обычно видит обои прекрасно.

Ладно, пробую запустить сеанс. Сеанс запускается. Обои дефолтные. Иконки дефолтные. Цвета темы дефолтные. Но все это подергивается как буд-то пытаясь замениться на то что указано в настройках. Цвета темы иногда даже мельком проявляются. Т.е. тема, которая в /usr вполне себе доступна для чтения...

Если не монтировать /usr при загрузке, а оставить исходный - всё нормально.

Теряюсь в догадках. В dmesg ничего не нашел заметно. Может плохо искал.

Полный fstab: http://pastebin.com/5dx2BWyX
dmesg неудачной загрузки: http://pastebin.com/tFrK4Hw1
P.S. Ругать apparmor типа audit: type=1400 audit(1414963777.606:79): apparmor=«STATUS» operation=«profile_replace» name=«/usr/sbin/cupsd» pid=2411 comm=«apparmor_parser» присутствует всегда.

★★★★★

Если не монтировать /usr при загрузке, а оставить исходный - всё нормально.

то есть часть системы загружается со старым /usr (физически HDD) , потом монтируется новй /usr (физически SSD) и дальше продолжается загрузка?

может ли такое происходить?

судя по apparmor — это не Убунта случайно?

Убунта — умеет правильно монтировать /usr/ ?

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

то есть часть системы загружается со старым /usr (физически HDD) , потом монтируется новый /usr (физически SSD) и дальше продолжается загрузка?

Теоретически да. Однако же /usr не используется вроде до монтирования дисков. По крайней мере раньше его выносили на отдельный диск и значит до монтирования там вообще было пусто и ничего - никаких проблем не было. Да и сейчас они идентичны - я только что скопировал его. Ну meld поставил только что, но это уже прямо только что. На момент проблем были идентичны. Права просмотрел бегло, не знаю чем сравнить, вроде нормально всё. По крайней мере, как я говорил все доступно для чтения и у бинарников остался бит исполнения.

судя по apparmor — это не Убунта случайно?

Она, родимая. 14.04.

Убунта — умеет правильно монтировать /usr/ ?

Во времена когда я выносли /usr отдельным диском (это 8.04 - 10.10) проблем не было. При установке в установщике есть возможность указать его отдельной точкой монтирования.

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от user_id_68054

Сейчас (после написания предыдущего поста) примонтировал /usr. Вроде все работает. Обои поменял. Значки поменял. Все отлично. Запустил сеанс другого пользователя. Тоже все хорошо. Тема иконок на месте. Обои на месте. Цветовая схема меняется.

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от Suntechnic

всяё прям норм стало совсем?

просто хотел ещё предложить эксперимент такой:

старый /usr/ (который на HDD) переименовать в /usr_/

вместо него пустой каталог /usr/ (на HDD)

то есть монтировать /usr/ (SSD) — в момент когда в /usr/ (на HDD) ни чего нет..

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

всяё прям норм стало совсем?

Это только если после загрузки уже...

Но даже так не совсем норм - машина не выключается. Т.е. я обычной кнопкой выключения не могу ее выключить. Сеанс почти завершается, остается рабочий стол и так висит. Надо переходить в коносоль и ребутить. Вобщем проблема похоже как минимум в работе lightdm.

Смотрю в лог и вижу:

 WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
Сравниваю и оказывается при копировании файлов они потеряли владельцев. В оригинальном /usr на файле из лога владелец root:messagebus, а в копии root:root.

Похоже Решено. Буду делать новую копию аккуратнее.

Suntechnic ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.