При старте в консоли мусор: Mounting proc filesystem: /etc/init.d/functions: line 547: echo: write error: Broken pipe [DONE] Mounting sys filesystem: /etc/init.d/functions: line 547: echo: write error: Broken pipe [DONE] Activating swap partitions: /etc/init.d/functions: line 547: echo: write error: Broken pipe [DONE] Setting hostname sass.frontier: /etc/init.d/functions: line 547: echo: write error: Broken pipe [DONE] Checking root filesystem /dev/hda2: clean, 124298/611648 files, 961710/1220940 blocks /etc/init.d/functions: line 547: echo: write error: Broken pipe [DONE] Remounting root filesystem in read/write mode: /etc/init.d/functions: line 547: echo: write error: Broken pipe [DONE]
/sbin/initlog упал? Почему?
Хороший вопрос. Вот и мне хотелось бы знать кто упал и почему. Это уже довольно давно наблюдается. Месяца два наверное. Написать было некогда.
У меня та же самая беда. Расскажите, в каком месте запускается этот initlog и куда он пытается писать - может я попробую поковырять это сам.
На всякий случай, история жизни этой системы: 1) Поставили древнюю бету Компакта 2) Удалили все, что было возможно 3) Обновили до Сизифа 4) Перетянули на RAID1/LVM2 5) Проблема начала появляться эпизодически, но я ее связал с тем, что сильно изуродовал rc.sysinit - как потом выяснилось зря 6) Обновили еще раз и словили проблемы с правами на /lib (об этом я недавно писал), а текущая проблема стала воспроизводиться регулярно 7) После вчерашнего обновления и отката на стандартный rc.sysinit проблема не решилась
Еще вопрос: а почему решили, что виноват initlog? Вот кусок кода, в окрестностях которого проблема: # Log that something succeeded success() { if [ -z "$IN_INITLOG" ]; then initlog $INITLOG_ARGS -n $0 -s "$1" -e 1 else local opipe opipe="$(trap -p SIGPIPE)" trap '' SIGPIPE echo "$INITLOG_ARGS -n $0 -s \"$1\" -e 1" >&21 $opipe fi echo_success return 0 } Т.е. если переменная IN_INITLOG пуста, производится запись в некий дескриптор 12 (кто это? почему так жестко в коде прошили? может переменную хотя бы стоило завести, чтоб понятно было что это такое?) Далее видим: # Remount the root filesystem read-write splash_update remount 2 action "Remounting root filesystem in read/write mode:" mount -n -o remount,rw / # The root filesystem is now read-write, so we can now log via syslog() directly [ -z "$IN_INITLOG" ] || IN_INITLOG= Если обнулить IN_INITLOG в самом начале, то и ругательств никаких не будет. Но ведь в IN_INITLOG=yes, наверное, есть какой-то смысл? Какой?
То, что падает initlog, очевидно. То, что он не должен падать, тоже очевидно. Неясно, почему он падает. Может, устройство какое-то во время работы исчезает?
У меня это происходит на начальном этапе загрузки системы до загрузки сервисов.
Прошу прощения - соврал! Предыдущий постинг прощу считать недействительным!
Алексей, ты это, кажется, тоже умеешь воспроизводить?
*** Bug 8870 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Алексей, ты это, кажется, тоже умеешь воспроизводить? Да. Я делал образ на котором эта ошибка воспроизводилась на 100% ASSIGNED?
(In reply to comment #11) > (In reply to comment #9) > > Алексей, ты это, кажется, тоже умеешь воспроизводить? > > Да. Я делал образ на котором эта ошибка воспроизводилась на 100% Профиль сохранился?
Посмотри на дату моего поста :) ... разумеется нет. Это из прошлой жизни, когда я делал Серверные исошки. Можно попробовать исошку из среза за ту дату и попробовать воспроизвести. Попроси спецов по выпечке дистров сделать это. У меня воспроизводилось довольно регулярно.
Кто умеет воспроизводить этот баг?
я такого не видел.
Невозможно воспроизвести, закрываю как WONTFIX. При необходимости откройте.
