Re: [sisyphus] Фатальная ошибка при загрузке ядра 3.14.23

Re: [sisyphus] Фатальная ошибка при загрузке ядра 3.14.23

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

On Mon, Nov 17, 2014 at 10:00:15AM +0000, Eugine Kosenko wrote:
> При попытке загрузить ядро из пакета kernel-image-std-def-3.14.23-alt1
> система уходит в цикл, бесконечно выдавая сообщение
> 
> Code should not be reached 'Unknown argument' at
> src/udev/udevadm-settle.c:85, function adm_settle(). Aborting.

На сколько я понимаю, сама по себе эта ошибка не страшная. А выводится она
столько времени, сколько система ждёт появления файловой системы с корнем,
просто оно довольно долго ждёт, что она всё же появится и появляется
впечатление, что оно висит.

В make-initrd 3 минуты помимо времени работы программ:
data/lib/initrd/modules/080-loop-
data/lib/initrd/modules/080-loop-       # It is not currently limit since the execution of programs
data/lib/initrd/modules/080-loop-        # takes time, which is not counted. But we do not want to use
data/lib/initrd/modules/080-loop-        # additional utilities to calculate the time limit.
data/lib/initrd/modules/080-loop:       local sec=$((${ROOTDELAY:-180}*10))

Даже при успешной загрузке у меня успевает проскочить несколько таких
ошибок.

Подозреваю, что вам нужно смотреть куда-то в сторону initrd.

> После успешной перезагрузки на ядро kernel-image-std-def-3.14.18-alt1 нигде
> в журнале этого сообщения не нахожу.
> 
> Сообщение намекает, что проблема, вроде бы, где-то в udev, но причины мне
> непонятны.
> 
> # rpm -qa|grep udev
> udev-217-alt2
> libgudev-217-alt2
> udev-rules-217-alt2
> libudev1-217-alt2
> udev-hwdb-217-alt2
> udev-rule-generator-net-217-alt2
> 
> В принципе, система обновлена полностью. Что можно поправить, чтобы
> запустилось?

Для начала просто попробуйте перегенерировать initrd:

# installkernel '3.14.23-std-def-alt1'

И сравнить список модулей, которые туда попали с теми, что в были в
3.14.18.

-- 
glebfm

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Фатальная ошибка при загрузке ядра 3.14.23

[Alexey Borisenkov]

17.11.2014 15:31, Gleb Fotengauer-Malinovskiy пишет:
> Даже при успешной загрузке у меня успевает проскочить несколько таких
> ошибок.
>
> Подозреваю, что вам нужно смотреть куда-то в сторону initrd.

Так-то да, это initrd, только разбираться с ним не так-то просто. Я тоже 
получил такую проблему для гостевой системы (VirtualBox) на 32-битном 
Сизифе. Причём 64-битная гостевуха обновилась нормально, надо бы 
попробовать сделать их идентичными по пакетам.
Просто перегенерация initrd ничего не даёт. Если перегенерировать для 
старого ядра, то перестаёт загружаться и оно.

Re: [sisyphus] Фатальная ошибка при загрузке ядра 3.14.23

[Alexey Borisenkov]

17.11.2014 16:13, Alexey Borisenkov пишет:
> Так-то да, это initrd, только разбираться с ним не так-то просто.

А как остановить загрузку для рабочего initrd? Пробовал ядру подсунуть 
break=y, break=init, break=mount. Ничего не помогает.

Re: [sisyphus] Фатальная ошибка при загрузке ядра 3.14.23

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Mon, Nov 17, 2014 at 05:43:29PM +0400, Alexey Borisenkov wrote:
> 17.11.2014 16:13, Alexey Borisenkov пишет:
> >Так-то да, это initrd, только разбираться с ним не так-то просто.
> 
> А как остановить загрузку для рабочего initrd? Пробовал ядру подсунуть
> break=y, break=init, break=mount. Ничего не помогает.

STOP=<имя>

И имя модуля из /usr/share/make-initrd/data/lib/initrd/modules
без цифр и -, например:

STOP=loop

чтобы остановиться до loop.

-- 
glebfm

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Фатальная ошибка при загрузке ядра 3.14.23

[Eugine Kosenko]

Похоже, дело еще хуже. Решил посмотреть, что будет, если дождусь
загрузки ядра 3.14.23. В результате не стартовал LVM, на котором лежат
/usr, /var и /home. То есть, я сейчас в голом аварийном режиме.

Более того, теперь по той же причине не грузится и 3.14.18. Выдает
что-то вроде невозможности найти файл /var/run/lvn.lock. Даже не знаю,
что проще --- лечить, или спасти данные и переустановить. В любом
случае работа в аварийной консоли не в радость :-(.

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

2014-11-17 16:36 GMT+02:00, Alexey Borisenkov <grizlik78@gmail.com>:
> 17.11.2014 18:17, Gleb Fotengauer-Malinovskiy пишет:
>> On Mon, Nov 17, 2014 at 05:43:29PM +0400, Alexey Borisenkov wrote:
>>> А как остановить загрузку для рабочего initrd? Пробовал ядру подсунуть
>>> break=y, break=init, break=mount. Ничего не помогает.
>
>> STOP=<имя>
>
> Спасибо. Ещё бы придумать как в поломатой системе текстовый вывод
> сохранять... Проблему можно увидеть на прилагаемом скриншоте. Дисковых
> устройств нет почему-то. Если ввести udevadm trigger, то вывод
> получается похожим.
> Загружены модули:
> sd_mod, crc_t10dif, crct10dif_common, ahci, libahci, libata, serio_raw,
> scsi_mod, evdev, hid_generic, hid
> Диски в гостевой подключены через SATA контроллер.
>