Bug 26375
| Summary: | Сбои файловой системы | ||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | george0575 | ||||||||||||||||||||||||||||||||||||||||
| Component: | plymouth | Assignee: | Anton V. Boyarshinov <boyarsh> | ||||||||||||||||||||||||||||||||||||||||
| Status: | REOPENED --- | QA Contact: | qa-sisyphus | ||||||||||||||||||||||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||||||||||||||||||||||
| Priority: | P3 | CC: | aen, amike, antohami, anubix, asy, boyarsh, cas, dd1email, gns, jackie.rosen, ldv, legion, mike, monordure, sem, shakirov, vitty, zerg, zxwarior | ||||||||||||||||||||||||||||||||||||||||
| Version: | unstable | ||||||||||||||||||||||||||||||||||||||||||
| Hardware: | all | ||||||||||||||||||||||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||||||||||||||||||||||||
| Bug Blocks: | 23155, 26742 | ||||||||||||||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||
В догонку:
>Это проявилось на обеих платформах дистрибутива Simply (x86 и x86_64)
соответственно и на абсолютно разных машинах (ноутбук x86_64 и стац. машина x86) с полностью исправными жесткими дисками.
Created attachment 5125 [details]
Скриншоты загрузки ОС.
Created attachment 5126 [details]
Скриншоты останова ОС.
Забыл сказать о важном моменте: проблема касается только одного раздела, смонтированного на /usr, причем ФС не важна (ext4, reiserfs на разных машинах - эффект один и тот же). Проверил на машине с ext4. /dev/sda8 - как раз /usr раздел. На другой машине с reiser было тоже самое, тоже /usr на раздел диска другой. 1) Загрузил ОС штатно. Есть исправления ФС. На скриншоте boot1.jpg сообщение /dev/sda8: recovering journal 2) Перезагрузил ОС еще раз. Есть исправления ФС. На скриншоте boot2.jpg сообщение то же /dev/sda8: recovering journal 3) Скриншот смонтированных разделов на всякий случай mount_table.jpg. 4) Загрузился с livecd (скриншот livecd_check.jpg) и проверил раздел. Исправления ФС с сообщением /dev/sda8: recovering journal Тут же проверил еще два раза. Исправлений больше нет. 5) Снова загрузил ОС штатно (скриншот aftercheck_boot1.jpg). Сообщение про superblock. 6) Перезагрузил ОС еще раз (скриншот aftercheck_boot2.jpg). Сообщение то же /dev/sda8: recovering journal Косвенно подтверждается моя догадка о том, что при выключении/перезагрузке ОС /usr не успевает размонтироваться. Видимо его кто-то держит. Created attachment 5127 [details]
boot1.jpg
Created attachment 5128 [details]
boot2.jpg
Created attachment 5129 [details]
mount_table.jpg
Created attachment 5130 [details]
livecd_check.jpg
Created attachment 5131 [details]
aftercheck_boot1.jpg
Created attachment 5132 [details]
aftercheck_boot2.jpg
> 5) Снова загрузил ОС штатно (скриншот aftercheck_boot1.jpg).
> Сообщение про superblock.
ну тут просто время. Это не при чём. Картинку про суперблок можно смело удалять, чтобы место не занимала.
Что-то пункта удаления не нашел. Этот скриншот (aftercheck_boot1.jpg) нужен. Он доказывает, что заранее исправленная в livecd ФС не портится при первой загрузке ОС, о оказывается испорченной самой ОС после ее shutdown/reboot. Опять же указание на неразмонтирование (как один из вариантов) раздела при останове/перезагрузке ОС. Еще хочу обратить внимание на то, что это проблема не отдельно Simply, а всего branch/p6, так как это касается базовой системы, а Simply выделяется только графической средой. (In reply to comment #13) > Он доказывает, что заранее исправленная в livecd ФС Он доказывает только то, что у Вас или таймер сбоит на материнке, или синхронизируетесь не так. Более - ничего. > Еще хочу обратить внимание на то, что это проблема не отдельно Simply, а всего branch/p6, У меня уже много что переведено на Branch p6, я этой проблемы не видел (хотя мониторы не везде, но кое-где были). И рабочий компьютер на p6 - с момента отбранчёвываения. На форуме, смотрю, тоже никто присоединиться с подтверждением проблемы не спешит. Выкладываю скриншот с другой машины с reiserfs (reuser.jpg). Там видны исправления раздела /dev/sda5 (который тоже /usr). И так происходит при каждой перезагрузке.
>На форуме, смотрю, тоже никто присоединиться с подтверждением проблемы не спешит.
Я уже понял, что на мою проблему обращать внимания вообще никто не спешит. Логика железная: у меня не воспроизводится, никто больше проблему не подтверждает, значит и рассматривать не будем. Но как еще вам доказать, что проблема не локальная? Почему для вас законы логики и здравого смыслы не имеют значения!? Ну _НЕ МОЖЕТ_ на двух абсолютно разных машинах с разными ФС проблема быть локальной!!! Одна - новый ноутбук Sony Vaio x86_64, другая - старый Pentium 3 1700 (естественно x86). Оба исправны, что подтверждается нормальной работой других ОС (и разных линуксов в том числе).
На открытую багу не было вообще никакой реакции (даже ее статус до сих пор не изменился - NEW), пока я в форуме сигналить не начал, но и там меня послали куда подальше.
Эту багу вообще кто-то начал исследовать? Если да, то почему здесь об этом не известно? Были ли попытки воспроизвести у себя ситуацию, максимально приближенную к моей? Ответ - нет. Иначе бы меня спросили, например:
1) как происходит инсталляция, с образа или апгрейдом с 5.0.2?
2) Какие были действия после инсталляции, добавлялся ли какой-то софт, выключались или включались какие-то сервисы?
3) и т.д......
Если у других эта бага не воспроизводится, это не значит что ее нет. Это значит то, что у остальных другие условия, при которых она не проявляется.
Я уверен что другие не жалуются потому, что этого не замечают, так как сбоям в самой работе ОС это не приводит (ведь ФС все-таки исправляется), либо не "заглядывают" за кулисы bootsplash, либо не обращают внимания на сами текстовые сообщения.
Бага открыта 26, сегодня 30, _попыток_ решить проблему не замечено.
Created attachment 5133 [details]
reiser.jpg
> Он доказывает только то, что у Вас или таймер сбоит на материнке, или синхронизируетесь не так. Более - ничего.
Остаюсь при своем мнении: скриншот нужен и сужает круг поиска.
Кстати, до Simply 6 на старой машине стоял Simply 5.0.2 и этой проблемы не было. Даже разделы были те же, только при установке переформатировались. (In reply to comment #16) > Если у других эта бага не воспроизводится, это не значит что ее нет. Это значит > то, что у остальных другие условия, при которых она не проявляется. Так вот, как пользователь p6, чисто для статистики и того, кто будет заниматься проблемой, я и написал, что у меня эта проблема НЕ воспроизводится. Так что это или специфика Simply, или, вообще, Ваша. >что у меня эта проблема НЕ воспроизводится. Так что это или специфика Simply, или, вообще, Ваша.
Я же написал про две _РАЗНЫЕ_ машины и ФС и про законы логики . Как же она может быть только моя?
Еще раз:
1) Если у других эта бага не воспроизводится, это не значит что ее нет. Это значит
то, что у остальных другие условия, при которых она не проявляется.
2) Это проблема не только моя, так как я качаю образ стабильного симпли 6 с сайта, нарезаю болванку, и ставлю ее на заведомо исправные два разных компьютера.
При этом я создаю разделы вручную по своей схеме, а не автоматом. Это первая особенность которая гипотетически может повлиять на проблему, но логически повлиять не должна, так как размер раздела и его номер не должен влиять на появление ошибок в ФС. Или может? Это первое нестандартное действие.
Затем я поставил ОС и после установки отключаю ненужные мне сервисы. Это второе нестандартное действие.
Потом обновляю систему из реп. Это действие стандартное.
Потом добавляю некоторый нужный мне софт из реп. Это третье нестандартное действие.
В итоге получилось 2 нестандартных действия, которые могут повлиять на проблему.
Я соглашусь, что это может быть проблема только Симпли, так как диск могут держать процессы из xfce. И я это сейчас проверю: переведу систему в загрузку только в консоль, если проблема пропадет, попробую поставить другую граф. среду и снова проверю.
> В итоге получилось 2 нестандартных действия, которые могут повлиять на
проблему.
Поправка: 3 нестандартных действия
(In reply to comment #21) > Я соглашусь, что это может быть проблема только Симпли, так как диск могут > держать процессы из xfce. И я это сейчас проверю: переведу систему в загрузку > только в консоль, если проблема пропадет, попробую поставить другую граф. среду > и снова проверю. Можно более кардинально поступить: в /etc/inittab, в строке id:5:initdefault:, поменять 5 и 3. Загрузится только текстовая консоль. (In reply to comment #23) > поменять 5 и 3. Загрузится только текстовая консоль. "5 на 3" в смысле. именно так только что и сделал. Только поменял 5 на 4. То есть многопользовательский консольный. После этого 3 раза перезагружался - проблема есть. Раздел каждый раз исправляется. Сейчас на 3 переделаю и посмотрю. Для надежности переключился сразу на 1 (single-mode) и несколько раз перезагрузился. Даже вариант ядра failsave выбирал. Проблема осталась. Вот тут уж точно не Симпли виноват. Заметил, что как раз перед исправлениями раздела стартует LVM2, хотя я его в панели управления в сервисах выключал. А как его из консоли надежно отключить? Что-то у меня на него подозрения появились. (In reply to comment #26) > Даже вариант ядра failsave выбирал. Проблема осталась. Вот тут уж точно не > Симпли виноват. надо как-то найти, что. Может, действительно, какой-то вариант с монтированием разделов... Но у меня тоже их много и /usr отдельно всегда. И инсталляций с p6 поболее пары десятков, не считая десктопа, за которым сам сижу. > Заметил, что как раз перед исправлениями раздела стартует LVM2, Надо с отключением разбираться, а не со стартом. Проблема где-то там. > хотя я его в панели управления в сервисах выключал. А как его из консоли надежно отключить ? Если не ошибаюсь, только удалением пакета. Но не думаю, что в нём дело. А что mount выводит ? Покажите вывод команд от root'а: # fdisk -l # cat /etc/fstab Прикрепите вывод команды: # dmesg | gzip >/tmp/dmesg.txt.gz P.S.: Постарайтесь немного сжимать скриншоты, качать 5мб архивы не весело :) P.S.S: Попробуйте стандартную разбивку диска, которую предлагает инсталлер. Это уже ноутбук с ext4: [root@homenout ~]# mount udevfs on /dev type devtmpfs (rw,relatime,size=5120k,nr_inodes=213698,mode=755) /dev/sda7 on / type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) runfs on /run type tmpfs (rw,relatime,size=5120k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shmfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,relatime) /dev/sda10 on /home type ext4 (rw,nosuid,relatime,user_xattr,acl,barrier=1,data=ordered) /dev/sda11 on /mnt/archive type ext4 (rw,nosuid,nodev,noexec,relatime,user_xattr,acl,barrier=1,data=ordered) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) /dev/sda3 on /mnt/win_c type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) /dev/sda5 on /mnt/win_d type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) /dev/sda8 on /usr type ext4 (rw,nodev,relatime,user_xattr,acl,barrier=1,data=ordered) /dev/sda9 on /var type ext4 (rw,nosuid,relatime,user_xattr,acl,barrier=1,data=ordered) /dev/sda2 on /mnt/sda2 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) /dev/sda1 on /mnt/sda1 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) /etc/auto.tab on /mnt/auto type autofs (rw,relatime,fd=6,pgrp=5013,timeout=5,minproto=5,maxproto=5,indirect) /etc/auto.avahi on /mnt/net type autofs (rw,relatime,fd=12,pgrp=5013,timeout=120,minproto=5,maxproto=5,indirect) [root@homenout ~]# [root@homenout ~]# fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, всего 976773168 секторов Units = секторы of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe5ad49dd Устр-во Загр Начало Конец Блоки Id Система /dev/sda1 2048 27629567 13813760 27 Hidden NTFS WinRE /dev/sda2 * 27629568 27834367 102400 7 HPFS/NTFS/exFAT /dev/sda3 27834368 152823807 62494720 7 HPFS/NTFS/exFAT /dev/sda4 152823808 976773167 411974680 5 Расширенный /dev/sda5 152825856 572256255 209715200 7 HPFS/NTFS/exFAT /dev/sda6 572258304 580646911 4194304 82 Linux своп / Solaris /dev/sda7 580648960 591134719 5242880 83 Linux /dev/sda8 591136768 612108287 10485760 83 Linux /dev/sda9 612110336 622596095 5242880 83 Linux /dev/sda10 622598144 643569663 10485760 83 Linux /dev/sda11 643571712 976773167 166600728 83 Linux [root@homenout ~]# [root@homenout ~]# cat /etc/fstab proc /proc proc nosuid,noexec,gid=proc 0 0 devpts /dev/pts devpts nosuid,noexec,gid=tty,mode=620 0 0 tmpfs /tmp tmpfs nosuid 0 0 UUID=dca7ef56-0f6b-4461-9c63-8be05f54de96 / ext4 relatime 1 1 UUID=842d1f0b-aeea-4468-b9ff-d83b11cc472f /home ext4 nosuid,relatime 1 2 UUID=1ea9a4e5-7abe-4c0d-bf6f-e7e9d4744815 /mnt/archive ext4 nosuid,nodev,noexec 1 0 UUID=5066AA9266AA77FC /mnt/win_c ntfs-3g umask=0 1 0 UUID=F2A47A64A47A2AED /mnt/win_d ntfs-3g umask=0 1 0 UUID=6a8cd330-3805-408a-b060-3bb447540c65 /usr ext4 nodev,relatime 1 2 UUID=e8a037b4-2e08-4d88-8187-de1ff86b1cd9 /var ext4 nosuid,relatime 1 2 UUID=952ab700-bade-4a46-88e8-a54da76519d1 swap swap defaults 0 0 UUID=0A0CA8920CA87A79 /mnt/sda2 ntfs-3g locale=ru_RU.UTF-8,dmask=0,fmask=0111 0 0 UUID=AE22A81922A7E495 /mnt/sda1 ntfs-3g locale=ru_RU.UTF-8,dmask=0,fmask=0111 0 0 /dev/sr0 /media/cdrom udf,iso9660 ro,noauto,user,utf8 0 0 [root@homenout ~]# Created attachment 5134 [details]
dmesg
Переделал inittab на 1 (single-mode). Перезагрузился в single-mode. Естественно ошибки ФС были найдены и исправлены. Логинюсь рутом, даю руками umount /usr, смотрю mount - /usr отмонтирован. Перезагружаюсь. При загрузке ошибок _НЕТ_. Логинюсь root, делаю umount /usr, перезагружаюсь, ошибок НЕТ. Логинюсь root, перезагружаюсь без ручного отмонтирования /usr, ошибки ЕСТЬ. Вывод: /usr не отмонтируется автоматически. Причем в single-mode что может его держать? И как это проверить? Или ошибка в скриптах завершения работы? Но тогда почему это отражается только на /usr? Огромное спасибо Сергею Афонину за идею этой проверки. Подключил старый комп (с reiserfs) к другому компу по null-модемному кабелю и зафиксировал завершение работы ОС (из single-mode загрузки) без ручного отмонтирования /usr: ---------------------------------------------------------------------------------------------- INIT: Sending processes the TERM signalinux ~]# [root@linux ~]# INIT: Pid 3661 [id ~~] seems to hang Activating splash [ DONE ] Starting killall: [ DONE ] Asking all remaining processes to terminate Unmounting tmpfs filesystem [/dev/shm]: Unmounting tmpfs filesystem [/tmp]: Unmounting tmpfs filesystem [/run]: Turning off swap: Unmounting filesystem [/mnt/archive]: Unmounting filesystem [/var]: Unmounting filesystem [/usr]: Unmounting filesystem [/home]: Remounting remaining filesystems (if any) read-only: umount2: Device or resource busy umount: udevfs busy - remounted read-only Remounting root filesystem read-only: Please stand by while rebooting the system... [ 87.675395] Restarting system. ---------------------------------------------------------------------------------------------- После перезагрузки ошибки были. Видно, что сообщение про отмонтирование /usr есть и оно без ошибок. Затем в консоли отмонтировал /usr руками, он отмонтировался молча, без ошибок. Задал mount и перезагрузил машину. Ниже вывод mount и лог завершения: ---------------------------------------------------------------------------------------------- [root@linux ~]# [root@linux ~]# udevfs on /dev type devtmpfs (rw,relatime,size=5120k,nr_inodes=95826,mode=755) /dev/sda6 on / type reiserfs (rw,noatime,notail) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) runfs on /run type tmpfs (rw,relatime,size=5120k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shmfs on /dev/shm type tmpfs (rw,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,relatime) /dev/sda7 on /home type reiserfs (rw,noatime,notail) /dev/sda8 on /mnt/archive type reiserfs (rw,noatime,notail) /dev/sda2 on /var type reiserfs (rw,noatime,notail) INIT: Sending processes the TERM signal INIT: Pid 3661 [id ~~] seems to hang Activating splash [ DONE ] Starting killall: [ DONE ] Asking all remaining processes to terminate Unmounting tmpfs filesystem [/dev/shm]: Unmounting tmpfs filesystem [/tmp]: Unmounting tmpfs filesystem [/run]: Turning off swap: Unmounting filesystem [/mnt/archive]: Unmounting filesystem [/var]: Unmounting filesystem [/home]: Remounting remaining filesystems (if any) read-only: umount2: Device or resource busy umount: udevfs busy - remounted read-only Remounting root filesystem read-only: Please stand by while rebooting the system... [ 140.529486] Restarting system. ---------------------------------------------------------------------------------------------- После перезагрузки ошибок не было. Видно, что нет сообщения про отмонтирование /usr, так как он уже был отмонтирован. Остальное все тоже самое. Получается, /usr тупо не отмонтируется, хотя идет сообщение о его отмонтировании. И раздел ничего не держит, иначе он бы не отмонтировался вручную.
Можно добавить вызов команды mount между двумя этими командами:
> Unmounting filesystem [/home]:
> Remounting remaining filesystems (if any) read-only: umount2: Device or
> resource busy
Если согласны на эксперимент, то выполните команду:
sed 's/multipath_stop/multipath_stop\nmount/' -i /etc/rc.d/init.d/halt
P.S.: вы не отвечаете на мое письмо в личку :)
Провел эксперимент. После выполнения команды два раза перезагрузился. Ошибки ФС есть оба раза. (В ответ на комментарий №36) > Провел эксперимент. После выполнения команды два раза перезагрузился. > Ошибки ФС есть оба раза. Этот эксперимент предполагал что вы подключите компьютер к другому по нуль-модемному кабелю и посмотрите на вывод команды mount между: Unmounting filesystem [/home]: и Remounting remaining filesystems (if any) read-only: umount2: Device or resource busy Проделал тест. Лог выключения машины: INIT: Sending processes the TERM signal INIT: Pid 3660 [id ~~] seems to hang Activating splash [ DONE ] Starting killall: [ DONE ] Asking all remaining processes to terminate Unmounting tmpfs filesystem [/dev/shm]: Unmounting tmpfs filesystem [/tmp]: Unmounting tmpfs filesystem [/run]: Turning off swap: Unmounting filesystem [/mnt/archive]: Unmounting filesystem [/var]: Unmounting filesystem [/usr]: Unmounting filesystem [/home]: udevfs on /dev type devtmpfs (rw,relatime,size=5120k,nr_inodes=95826,mode=755) /dev/sda6 on / type reiserfs (rw,noatime,notail) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) Remounting remaining filesystems (if any) read-only: umount2: Device or resource busy umount: udevfs busy - remounted read-only Remounting root filesystem read-only: Please stand by while rebooting the system... [ 91.599596] Restarting system. Теперь выполните: # sed 's/nodevfs/nodevfs,nodevtmpfs/' -i /etc/rc.d/init.d/halt и снова выполните проверку с нуль-модемным кабелем _И_ проверьте правильность размонтирования /usr Выполнил команду, перезагрузился. Ошибки ФС при загрузке есть (bad_boot_simply.txt.gz). Там часть ссобщений с исправлениями: Configuring kernel parameters: [ DONE ] Checking filesystems Checking all file systems. [/sbin/fsck.reiserfs (1) -- /home] fsck.reiserfs -ay /dev/sda7 Reiserfs super block in block 16 on 0x807 of format 3.6 with standard journal Blocks (total/free): 1220688/1056388 by 4096 bytes Filesystem is clean [/sbin/fsck.reiserfs (1) -- /usr] fsck.reiserfs -ay /dev/sda5 Replaying journal: Trans replayed: mountid 87, transid 990, desc 6773, len 1, commit 6775, next trans offset 6758 Trans replayed: mountid 87, transid 991, desc 6776, len 1, commit 6778, next trans offset 6761 Trans replayed: mountid 87, transid 992, desc 6779, len 1, commit 6781, next trans offset 6764 Trans replayed: mountid 87, transid 993, desc 6782, len 1, commit 6784, next trans offset 6767 Trans replayed: mountid 87, transid 994, desc 6785, len 1, commit 6787, next trans offset 6770 Trans replayed: mountid 87, transid 995, desc 6788, len 1, commit 6790, next trans offset 6773 Trans replayed: mountid 87, transid 996, desc 6791, len 1, commit 6793, next trans offset 6776 Replaying journal: Done. Reiserfs journal '/dev/sda5' in blocks [18..8211]: 7 transactions replayed Reiserfs super block in block 16 on 0x805 of format 3.6 with standard journal Blocks (total/free): 1464848/837164 by 4096 bytes Filesystem is NOT clean [/sbin/fsck.reiserfs (1) -- /var] fsck.reiserfs -ay /dev/sda2 Reiserfs super block in block 16 on 0x802 of format 3.6 with standard journal Blocks (total/free): 500016/349664 by 4096 bytes Filesystem is clean Затем зашел root, отмонтировал руками и перезагрузился. Ошибок нет (good_boot_simply.txt.gz). Сообщения: Configuring kernel parameters: [ DONE ] Checking filesystems Checking all file systems. [/sbin/fsck.reiserfs (1) -- /home] fsck.reiserfs -ay /dev/sda7 Reiserfs super block in block 16 on 0x807 of format 3.6 with standard journal Blocks (total/free): 1220688/1056388 by 4096 bytes Filesystem is clean [/sbin/fsck.reiserfs (1) -- /usr] fsck.reiserfs -ay /dev/sda5 Reiserfs super block in block 16 on 0x805 of format 3.6 with standard journal Blocks (total/free): 1464848/837164 by 4096 bytes Filesystem is clean [/sbin/fsck.reiserfs (1) -- /var] fsck.reiserfs -ay /dev/sda2 Reiserfs super block in block 16 on 0x802 of format 3.6 with standard journal Blocks (total/free): 500016/349663 by 4096 bytes Filesystem is clean [ DONE ] Created attachment 5144 [details]
bad_boot_simply.txt.gz
Created attachment 5145 [details]
good_boot_simply.txt.gz
Покажите, пожалуйста, лог выключения, интересует появляется ли ошибка: Remounting remaining filesystems (if any) read-only: umount2: Device or resource busy umount: udevfs busy - remounted read-only INIT: Sending processes the TERM signal INIT: Pid 3815 [id ~~] seems to hang Activating splash [ DONE ] Starting killall: [ DONE ] Asking all remaining processes to terminate Unmounting tmpfs filesystem [/dev/shm]: Unmounting tmpfs filesystem [/tmp]: Unmounting tmpfs filesystem [/run]: Turning off swap: Unmounting filesystem [/mnt/archive]: Unmounting filesystem [/var]: Unmounting filesystem [/usr]: Unmounting filesystem [/home]: udevfs on /dev type devtmpfs (rw,relatime,size=5120k,nr_inodes=95826,mode=755) /dev/sda6 on / type reiserfs (rw,noatime,notail) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) Remounting remaining filesystems (if any) read-only: Remounting root filesystem read-only: Please stand by while rebooting the system... [ 58.895779] Restarting system. Сообщение пропало. (В ответ на комментарий №44) > Сообщение пропало. Но разделу, который монтируется в /usr это не помогло? 1. Проверьте что у вас установлен пакет lsof. 2. Выполните: # sed 's,# Unmount all the,lsof|grep /usr \&>/root/lsof.txt\n# Unmount all the,' -i /etc/rc.d/init.d/halt 3. Перезагрузитесь два раза :) 4. Прикрепите сюда файл /root/lsof.txt 5. ВЫПОЛНЯЙТЕ СТРОГО ПОСЛЕ ВЫПОЛНЕНИЯ ПРЕДЫДУЩИХ ПУНКТОВ: # sed 's/umount -f -l -t noproc/umount -f -t noproc/' -i /etc/rc.d/init.d/functions 6. Перезагружайтесь и внимательно смотрите на ошибки во время выключения и включения P.S. Завел багу для исправления появляющейся при перезагрузке ошибки #26416 Смогу выполнить только завтра. Ленар, доброе утро. Сделал все как Вы сказали и на последней загрузке ОС ошибки пропали. Теперь, все по порядку. Выполнил первые 3 шага Вашей инструкции. Первая перезагрузка (старт и завершение ОС) - boot1_lsof.txt.gz. Вторая загрузка (только старт) - boot2_lsof.txt.gz. Затем сохранил lsof.txt - lsof.txt.gz. Выполнил команду из шага 5 и перезагрузился (завершение и старт ОС) - boot_step2.txt.gz. При старте ошибок уже не было. Created attachment 5148 [details]
boot1_lsof.txt.gz
Created attachment 5149 [details]
boot2_lsof.txt.gz
Created attachment 5150 [details]
boot_step2.txt.gz
Created attachment 5151 [details]
lsof.txt.gz
Отлично, похоже мы нашли виновника: plymouthd держит открытый файл /usr/lib/plymouth/details.so, поэтому в действительности раздел не отмонтируется (опция -l у umount). Теперь возвращаем обратно опцию и удаляем для проверки plymouth: 1. #sed 's/umount -f -t/umount -f -l -t/' -i /etc/rc.d/init.d/functions 2. #apt-get remove /sbin/plymouthd 3. Два раза перезагружаетесь :) 4. Прикрепляете сюда лог /root/lsof.txt и вывод через нуль-модемный кабель во время перезагрузки. 5. Проверяете будут ли ошибки при проверке ФС (In reply to comment #52) > Отлично, похоже мы нашли виновника: > plymouthd держит открытый файл /usr/lib/plymouth/details.so, поэтому в А сходится... У меня Плимута нет нигде. А если он где-то пытался ставиться, я его выносил нещадно. >(опция -l у umount)
В русском мане -l - "Ленивое" размонтирование :)
Лениво было ему размонтировать :)
Далее по теме. Проблема решена, ошибки пропали.
Выполнил команды, перезагрузился.
первая перезагрука - good_boot1.txt.gz
вторая перезагрука - good_boot2.txt.gz
и lsof - lsof2.txt.gz.
Ленар и Сергей. Ваша методика удаленного диагностирования и решения задач вызывает восхищение. Мое мнение - это высший пилотаж.
А как по плимуту, отдельная бага откроется?
Архивы чуть позже Created attachment 5154 [details]
lsof2.txt.gz
(In reply to comment #20) > > Если у других эта бага не воспроизводится, это не значит что ее нет. Именно. > Так вот, как пользователь p6, чисто для статистики и того, кто будет заниматься > проблемой, я и написал, что у меня эта проблема НЕ воспроизводится. Серёж, и всё-таки тон огорчает. Если проблема соседа сейчас не касается -- это не значит даже того, что не затронет завтра; уже поэтому "моя хата с краю, ничего не знаю" не работает. > Так что это или специфика Simply, или, вообще, Ваша. А этот вывод и вовсе неверен. Ленар и Георгий, спасибо за въедливость при диагностировании. Created attachment 5155 [details]
good_boot1.txt.gz
Created attachment 5156 [details]
good_boot2.txt.gz
>А сходится... У меня Плимута нет нигде. А если он где-то пытался ставиться, я его выносил нещадно.
А с iso-шника он ставится всегда и из простых пользователей его вряд ли кто-то будет выключать/удалять.
Поэтому странно, что никто не заметил проблемы. Видимо только по тому, как я раньше говорил, что внимания не обращает.
(In reply to comment #60) > >А сходится... У меня Плимута нет нигде. А если он где-то пытался ставиться, я его выносил нещадно. > > Поэтому странно, что никто не заметил проблемы. Видимо только по тому, как я > раньше говорил, что внимания не обращает. Потому, что мало у кого /usr на отдельном разделе. Переселить plymouth в /lib довольно сложно, так как расположение его файлов прошито ещё и в make-initrd. Возможно, было бы хорошим выходом выключать plymouth перед размонтированием /usr, то есть в пакете startup (In reply to comment #62) А если сделать plymouth-static ? (In reply to comment #57) >> Так что это или специфика Simply, или, вообще, Ваша. > А этот вывод и вовсе неверен. Как раз таки почти верен - Server Light, это не касается. По крайней мере, беты. Так что это дистрибутивозависимо в полный рост. Что касается тона, тут не вся переписка. Кое-что есть на форуме, кое-что в личной почте. Так что не всё так плохо, как кажется. ;-) (In reply to comment #61) > Потому, что мало у кого /usr на отдельном разделе. у меня, как раз, всегда на отдельном... Но вот Плимута не оказалось. (In reply to comment #62) > Переселить plymouth в /lib довольно сложно, так как расположение его файлов > прошито ещё и в make-initrd. > Возможно, было бы хорошим выходом выключать plymouth перед размонтированием > /usr, то есть в пакете startup Пакет startup нельзя обучать выключению каждого сервиса, для этой цели предназначены обычные startup-скрипты. Пусть у plymouth будет соответствующий startup-скрипт, который будет отвечать за своевременное деактивирование. На p6. (In reply to comment #62) > Переселить plymouth в /lib довольно сложно, так как расположение его файлов > прошито ещё и в make-initrd. Может, поправить и его, а на старый плимут конфликт прописать? (В ответ на комментарий №62)
> Переселить plymouth в /lib довольно сложно, так как расположение его файлов
> прошито ещё и в make-initrd.
Вроде там тупо прописать оба местоположения прокатит.
(In reply to comment #67) > > Переселить plymouth в /lib довольно сложно, так как расположение его файлов > > прошито ещё и в make-initrd. > Вроде там тупо прописать оба местоположения прокатит. Тем более. И пойдёмте на сизиф, наверное. (В ответ на комментарий №67) > Вроде там тупо прописать оба местоположения прокатит. Ругань только будет. Вот пример, как правильно и просто исправить http://git.altlinux.org/people/legion/packages/?p=make-initrd.git;a=commitdiff;h=8ce93ecc0b197d4c9609b247fbd65c2873ec0d04 *** Bug 27274 has been marked as a duplicate of this bug. *** (In reply to comment #69) > Вот пример, как правильно и просто исправить > http://git.altlinux.org/people/legion/packages/?p=make-initrd.git;a=commitdiff;h=8ce93ecc0b197d4c9609b247fbd65c2873ec0d04 А, вроде, была идея make-initrd 0.6.2 попробовать в p6 ? (In reply to comment #69) > Вот пример, как правильно и просто исправить А, тут способ имеется ввиду, а не дословно ?.. (In reply to comment #71) > А, вроде, была идея make-initrd 0.6.2 попробовать в p6 ? Если что, в t6 сейчас наблюдается make-initrd-0.7.8-alt1 (и тот, кто его молча закинул -- диверсант, т.к. копировать надо было и make-initrd-propagator с make-initrd-propagator-resume после выполнения соответствующей подгонки в сизифе). Не уверен, что стоит в p6, но по крайней мере можно обдумать. не могу воспроизвести на p6, на sisyphus, на реальных машинах и в KVM Сегодняшнее обновление. Никаких изменений не вижу: так же производится проверка отдельного /usr. Точно /usr отдельным разделом на тестируемых системах ? (В ответ на комментарий №76) > Сегодняшнее обновление. Никаких изменений не вижу: так же производится проверка > отдельного /usr. Точно /usr отдельным разделом на тестируемых системах ? 2amike, cas: ping (В ответ на комментарий №76) > Сегодняшнее обновление. Никаких изменений не вижу: так же производится проверка > отдельного /usr. Точно /usr отдельным разделом на тестируемых системах ? на новом образе, от 30.11, с отдельным /usr и sysvinit - подтверждается. на systemd - не подтверждается. (В ответ на комментарий №78)
> на новом образе, от 30.11, с отдельным /usr и sysvinit - подтверждается.
> на systemd - не подтверждается.
systemd реабилитирован. Похоже, мы столкнулись с вариантом "проблемы /usr", которую он как раз решает.
Пока вешаю на RM p7.
major->normal
А в интернетах то оказывается известная проблема . Вначале на lor-e прочёл что systemd не работает с отдельным /usr, а потом ещё оказалось что и какая-то версия udev тоже плохо работает с отдельным /usr. Есть ещё ссылка http://www.gentoo.ru/node/25066 там как-то через openrc исправляют вроде. Но это на генту. Простите за спам. Я тут мельком глянул. Подумал может пригодится. Если не будет мотивированных возражений, то в 15 часов 5 марта исключаю из числа блокеров p7. Возражение одно: отдельный /usr - это хорошо, и оно должно быть учтено. По крайней мере, пока всякий идиотизм, в виде systemd в частности, не является обязательной частью системы. Не блокер для p7 Кентавр 7.0.1, серверная инсталляция... Возвращаем блокер на p7, или как ? Я-то Плимут у себя, как обычно, снесу (как и Grub, врочем)... ping. (In reply to comment #79) > systemd реабилитирован. Нет. :-) > Похоже, мы столкнулись с вариантом "проблемы /usr", > которую он как раз решает. Он её не решает, а маскирует. Если бы не systemd, об этом бы подумали. Возможно. altlinux-p7-sysv-tde-20140912-x86_64.iso - воспроизводится. На сизифных сборках не проверял. |
Description
george0575 2011-09-26 16:58:17 MSK