Citrix клиент замедляет загрузку ОС Линукс Минт 20.3

Не неси чушь, ну неужели тебе самому не очевидно что добавление пользователей никак на скорость загрузки влиять не может? На скорость загрузки влияют запускающиеся во время загрузки процессы.

Покажи вывод:

systemd-analyze blame | head

Не забудь разметить: Как правильно копировать вывод терминала

Уважаемый firkax! Если человек задаёт вопрос, наверное ему что-то не очевидно?

Или ты родился сразу с флешкой в голове и тебе не понять, что люди вопросы на форумах задают с просьбой о помощи? Тебе с каждым обновлением Линукса автоматом перепрошивают мозг и ты знаешь все ответы на все вопросы?

Описываю ситуацию - как она возникла. Прошу помощи.

Можешь помочь - помоги, пожалуйста! Объясни - как ты видишь ситуацию.

Не можешь помочь, но хочешь поумничать и повысить собственное эго - поучи GPS навигатор строить маршруты.

2-3 минуты? Эта команда выводит топ 10 самых долгих по времени старта сервисов. И даже сумма этого времени (так-то они параллельно стартуют) меньше нескольких минут.

Тебе правильно сказали. В системе из коробки присутствует довольно много групп и пользователей. К тому же при установке создаётся пользователь под которым ты работаешь.

Судя твоей логике каждый новый добавленный пользователь в систему должен замедлять её работу?

Ну тогда на контроллерах домена, где сотни и тысячи пользователей всё вообще ползает.

А по поводу того, что замедляет работу, как раз работу замедляет citrix, смотри его логи.

По сути citrix - это прослойка авторизации на eDirectory сервере, что-то вроде LDAP (AD). Citrix предоставляет новое хранилище пользователей. А в системе есть приоритеты по каким базам (хранилищам) пользователей авторизовать учётные записи.

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

Если у тебя неправильно настроен citrix или допустим на момент проверки ещё не поднялась сеть, а скорее так и есть, то это вызовет проблемы.

В особенности если сети нет, а приоритет citrix (eDirectory) хранилища пользователей стоит самый высокий.

Так что читай логи авторизации в системе, логи citrix клиента и исправляй работу.

Приоритет хранилища пользователей задается в файле /etc/nsswitch.conf.

Ну и ещё настройки в /etc/pam.d играют роль.

Вообще citrix и eDirectory очень старые вещи, ты уверен что они тебе нужны? У тебя не Netware случаем? Хотя вряд ли судя по твоему пониманию.

Удачи.

kostik87, спасибо за комментарий!

1. Могу выложить видео загрузки - специально заснял. 2 мин 12 сек от момента нажатия кнопки «Перезагрузить» до появления окна выбора пользователя.
2. Я не претендую ни на какую новую логику загрузки системы.

Я столкнулся с реальной ситуацией: система грузилась 20-30 секунд, стала грузиться больше 2-х минут. Случилось это после установки софта от Citrix.

ICA клиент не стоит в автозагрузке. По простой логике (по моей) он не может влиять на загрузку системы, т.к. до момента его запуска на исполнение он просто файл на диске.

Из видимых изменений в процессе загрузки - появление нового пользователя, которого установил ICA клиент.

Опять же - до появления окна выбора пользователя никакие процессы не должны самостоятельно грузиться.

Моя логика понятна?

Загрузка замедляется НЕ ПОСЛЕ ввода пароля и загрузки параметров пользователя, а ДО ПОЯВЛЕНИЯ ОКНА выбора пользователя.

Ещё раз формулирую ситуацию.

Система грузится до окна выбора пользователя 20-30 сек. Устанавливается ICA клиент. Он добавляет нового пользователя. Система грузится до окна выбора пользователя 2 минуты.

Вопрос: Можно ли ускорить (вернуть прежнюю скорость) загрузки системы, удалив этого пользователя и не потерять работоспособность Citrix?

Кто знает - прошу помочь.

Помочь в конкретной ситуации.

Если ты ТОЧНО ЗНАЕШЬ (или предполагаешь), что ICA клиент, отсутствующий в автозагрузке, просто своим присутствием на диске заставляет систему подгружать какие-то процессы просто из уважения к нему, то так и скажи.

Я буду тебе очень благодарен за КОНКРЕТНЫЙ ответ.

Да! И на кой нужен пользователь «citrixlog», которым я ни разу не воспользовался?

Теперь понятно изложил ситуацию?

ICA клиент не стоит в автозагрузке. По простой логике (по моей) он не может влиять на загрузку системы, т.к. до момента его запуска на исполнение он просто файл на диске.

Проверь файл /etc/nsswitch.conf и файлы в директории /etc/pam.d если в них подключены библиотеки авторизации citrix - то это будет вызывать проблему, если citrix не запущен или неправильно настроен.

Вопрос: Можно ли ускорить (вернуть прежнюю скорость) загрузки системы, удалив этого пользователя и не потерять работоспособность Citrix?

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

Загрузка замедляется НЕ ПОСЛЕ ввода пароля и загрузки параметров пользователя, а ДО ПОЯВЛЕНИЯ ОКНА выбора пользователя.

И что?

Повторяю, сервисы в Linux запускаются от разных пользователей. При запуске любого сервиса он запускается от какого-то пользователя. При этом происходит авторизация пользователя в системе, т.е. уже в этот момент в дело вступает /etc/nsswitch.conf и файлы в /etc/pam.d.

Ввод пароля в графической оболочке роли не играет.

Читай логи авторизации в системе /var/log/auth.log и системные журналы, исправляй ошибки.

Теперь понятно изложил ситуацию?

Понятно только одно, что ты не понял что тебе написано.

Удачи.

Спасибо! Завтра пройдусь по всем указанным тобой для проверки файлам.

Проверю твою логику: сервисы citrix запускаются самостоятельно при загрузке системы, независимо от наличия их в автозагрузке.

О результатах отпишусь.

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

У тебя случилось всё как не надо: деталей ты не знаешь, но как-то (как? ну откуда такое можно было придумать?) ты сложил причинно-следственную связь между наличием пользователя в таблице пользователей и временем загрузки.

Если б ты написал «стало долго грузиться, не понимаю почему» - это было б норм. Если б выдвинул какую-то версию, которая может и была бы неправильной, но хотя бы не шла вразрез с элементарной бытовой логикой - тоже норм. А тут ты взял безо всяких обоснований совершенно нелогичное (повторю - дело не в технических деталях, оно нелогично изначально) утверждение, и вставил его в условие задачи как будто это уже доказанный факт.

Уваажемый kostik87! Как и обещал - проделал работу и делюсь результатами.

Проверь файл /etc/nsswitch.conf и файлы в директории /etc/pam.d если в них подключены библиотеки авторизации citrix - то это будет вызывать проблему, если citrix не запущен или неправильно настроен.

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Следов Citrix нигде нет…

Список файлов в /etc/pam.d. Следов Citrix нет ни в одном файле.

chfn
chpasswd
chsh
cinnamon-screensaver
common-account
common-auth
common-password
common-session
common-session-noninteractive
cron
cups
lightdm
lightdm-autologin
lightdm-greeter
login
newusers
other
passwd
polkit-1
ppp
runuser
runuser-l
samba
su
sudo
su-l
systemd-user

После загрузки системы в системном мониторе нет ни одного процесса, связанного с Citrix.

После запуска ICA клиента (вручную) в системном мониторе появляются 4 процесса:

storebrowse
AuthManagerDaemon
ServiceRecord
selfservice

В файле /var/log/auth.log два упоминания о Citrix. Оба - в процессе установки обновления ICA клиента.

for system-bus-name::1.1071 [/usr/bin/python3 /usr/bin/gdebi-gtk /home/seiseich/Загрузки/SOFT/Citrix/icaclient_22.7.0.20_amd64.deb] (owned by unix-user:seiseich)

Jul 27 22:42:37 MaestroLM useradd[277295]: failed adding user 'citrixlog', data deleted

Чем я ещё могу помочь уважаемым экспертам разобраться в ситуации?

Уважаемый firkax! Я описал логику своих размышлений чуть выше. Не обладая глубокими знаниями в системных процессах, я описываю то, что вижу внешне. Я не претендую на диагноз. Я описываю имеющуюся проблему и желаемый результат. С этими речами обращаюсь к сообществу за помощью.

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

Поэтому прошу меня простить за вчерашнюю не очень вежливую реплику.

Надеюсь на понимание.

Лучше будет plot посмотреть, там можно увидеть, в каком месте затуп произошёл.

Если можно - чуть подробнее про plot: где его найти?

Уважаемый SieSeich, а что написано вот в этом фрагменте лога

for system-bus-name::1.1071 [/usr/bin/python3 /usr/bin/gdebi-gtk /home/seiseich/Загрузки/SOFT/Citrix/icaclient_22.7.0.20_amd64.deb] (owned by unix-user:seiseich)

Jul 27 22:42:37 MaestroLM useradd[277295]: failed adding user 'citrixlog', data deleted

В частности вот: «MaestroLM useradd[277295]: failed adding user ‘citrixlog’, data deleted».

Посмотри вывод:

id citrixlog

После загрузки системы в системном мониторе нет ни одного процесса, связанного с Citrix.

Смотри вывод ps aux.

systemd-analyze plot > file.svg

Получится красивый график загрузки. Там где-то будет место с затыком загрузки.

График действительно очень красивый! Но, поскольку я его смотрю впервые - не могу понять какое именно место является затыком.

Я могу этот файл каким-то образом прикрепить к сообщению, чтобы Вы могли на него посмотреть?

Длинный промежуток между запусками двух юнитов. Обычно возникает, когда один юнит ожидает запуск другого юнита, или монтирования ФС, например.

systemd-analyze без параметров что говорит о времени запуска юзерспейса?

В теги добавь systemd, чтобы умельцы подтянулись.

systemd-analyze без параметров что говорит о времени запуска юзерспейса?

$ systemd-analyze
Startup finished in 2.946s (kernel) + 1min 32.057s (userspace) = 1min 35.003s 
graphical.target reached after 1min 32.050s in userspace

Я могу в сообщении прислать ссылку на файлообменник с svg файлом?

Присылай, лишним не будет.

1min 32.057s (userspace)

Всё равно 2-3 минуты не получается. Похоже, что надо будет ещё процесс авторизации колупать, но с этим я помочь не могу.

Ссылка на svg - https://dropmefiles.com/4sxat

2 минуты получается от запуска перезагрузки до появления окна ввода пароля. Т.е. какое-то время тратится на выгрузку всех процессов и завершение работы (если я правильно понимаю)

Это «у страха глаза велики» после того, как система перезагружалась мгновенно до установки Citrix…

Я вполне допускаю, что замедление процесса загрузки могло случиться одномоментно с установкой Citrix и на самом деле эти два явления существуют параллельно, не влияя друг на друга…

Но как-то очень уж они случились одновременно…

у вас минт, но в минте в отличие от убунту snap вырезан, но в выхлопе

systemd-analyze blame | head

1.509s snapd.service 

Snap прикрутил для установки какого-то нужного софта, которого не было в репозитории (или версия не устраивала) - сейчас не вспомню.

Но snap был установлен задолго до того, как приключилось замедление загрузки и система с ним перезагружалась мгновенно…

Да и сейчас на производительность системы не жалуюсь. Всё работает как часы.

Вот только загрузки (перезагрузки) приходится ждать как на Винде - можно успеть чаю налить и накромсать бутербродов… )))

По хронологии возникновения проблемы грешу на Citrix…

В частности вот: «MaestroLM useradd[277295]: failed adding user ‘citrixlog’, data deleted».

Я могу ошибаться, но может быть эта строчка говорит о том, что в процессе обновления ICA клиента из файла =icaclient_22.7.0.20_amd64.deb= установщик обнаружил ,что пользователь ‘citrixlog’ уже существует, поэтому добавление нового юзера было прекращено, а все, связанные с процессом добавления нового юзера данные, были удалены? По крайней мере, так я перевожу с английского.

Здесь есть другая трактовка?

Посмотри вывод: id citrixlog

$ id citrixlog
uid=1001(citrixlog) gid=1001(citrixlog) группы=1001(citrixlog)

Смотри вывод ps aux

Здесь есть одна строчка Citrix, но она неполная.

$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.4  0.0 168388 11832 ?        Ss   16:22   0:00 /sbin/init sp


citrixl+    1010  0.0  0.0 142080    92 ?        Sl   16:24   0:00 /opt/Citrix/I

Я также на дебиан накатил Snap, система заметно замедлилась удаление его значительно ускорило систему, для каждого пакета Snap порождает несколько изолированных файловых систем посмотреть можно

df -h | grep snap

df -h | grep snap

$ sudo df -h | grep snap
[sudo] пароль для seiseich:           
/dev/loop2        56M          56M     0          100% /snap/core18/2409
/dev/loop1        56M          56M     0          100% /snap/core18/2538
/dev/loop0       128K         128K     0          100% /snap/bare/5
/dev/loop3       165M         165M     0          100% /snap/gnome-3-28-1804/161
/dev/loop4        82M          82M     0          100% /snap/gtk-common-themes/1534
/dev/loop5        47M          47M     0          100% /snap/snapd/16010
/dev/loop7        47M          47M     0          100% /snap/snapd/16292
/dev/loop6        92M          92M     0          100% /snap/gtk-common-themes/1535

Предлагаете грохнуть Snap и посмотреть с секундомером на процесс загрузки?

Надо провести ревизию - посмотреть какой софт у меня висит на Snap. Проанализирую в ближайшее время. О результатах отпишусь.

Что-то очень прилично тормозит наступление sysinit.target

systemd-analyze critical-chain
systemd-analyze critical-chain sysinit.target graphical.target multi-user.target

Должно вывести цепочку с временем задержки инициализации каждого звена.

systemd-analyze critical-chain

Вывел много вот таких блоков. Но, похоже ,что они все одинаковые…

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 32.229s
└─multi-user.target @1min 32.229s
  └─snapd.seeded.service @1min 32.163s +65ms
    └─snapd.service @1min 30.622s +1.539s
      └─basic.target @1min 30.583s
        └─sockets.target @1min 30.583s
          └─snapd.socket @1min 30.582s +580us
            └─sysinit.target @1min 30.576s
              └─systemd-timesyncd.service @1.904s +88ms
                └─systemd-tmpfiles-setup.service @1.855s +42ms
                  └─local-fs.target @1.848s
                    └─boot.mount @1.841s +7ms
                      └─systemd-fsck@dev-disk-by\x2duuid-57e21a7b\x2d35dc\x2d4d>
                        └─dev-disk-by\x2duuid-57e21a7b\x2d35dc\x2d4de5\x2da33b\>
lines 1-17/17 (END)

systemd-analyze critical-chain sysinit.target graphical.target multi-user.target

Здесь вывод только вот такой

$ systemd-analyze critical-chain sysinit.target graphical.target multi-user.target
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

sysinit.target @1min 30.576s
└─systemd-timesyncd.service @1.904s +88ms
  └─systemd-tmpfiles-setup.service @1.855s +42ms
    └─local-fs.target @1.848s
      └─boot.mount @1.841s +7ms
        └─systemd-fsck@dev-disk-by\x2duuid-57e21a7b\x2d35dc\x2d4de5\x2da33b\x2dbd4bbbf92c3e.service @1.787s +51ms
          └─dev-disk-by\x2duuid-57e21a7b\x2d35dc\x2d4de5\x2da33b\x2dbd4bbbf92c3e.device @1.786s
graphical.target @1min 32.229s
└─multi-user.target @1min 32.229s
  └─snapd.seeded.service @1min 32.163s +65ms
    └─snapd.service @1min 30.622s +1.539s
      └─basic.target @1min 30.583s
        └─sockets.target @1min 30.583s
          └─snapd.socket @1min 30.582s +580us
            └─sysinit.target @1min 30.576s
              └─systemd-timesyncd.service @1.904s +88ms
                └─systemd-tmpfiles-setup.service @1.855s +42ms
                  └─local-fs.target @1.848s
                    └─boot.mount @1.841s +7ms
                      └─systemd-fsck@dev-disk-by\x2duuid-57e21a7b\x2d35dc\x2d4de5\x2da33b\x2dbd4bbbf92c3e.service @1.787s +51ms

Забыл про --no-pager написать, чтобы просто выплюнуло без прокрутки.

Cast intelfx!

Как там ещё отладить можно? У меня идеи закончились.

            └─sysinit.target @1min 30.576s
              └─systemd-timesyncd.service @1.904s +88ms

sysinit.target @1min 30.576s
└─systemd-timesyncd.service @1.904s +88ms

судя по этим двум кусочкам, 1.5 минуты тратится на синхронизацию времени через интернет, может обычно комп изначально к интернету подключен и синхронизация ntp быстро проходила, а тут без него по таймауту 1.5 минуты пытается

судя по этим двум кусочкам, 1.5 минуты тратится на синхронизацию времени через интернет, может обычно комп изначально к интернету подключен и синхронизация ntp быстро проходила, а тут без него по таймауту 1.5 минуты пытается

Отключил в настройках «использовать время сети». Перезагрузил. Время загрузки не уменьшилось.

Компьютер постоянно подключен к проводному интернету.

Чертовщина какая-то, блин…

Нет, это просто не получилось построить critical chain (он строится эвристически и не всегда это срабатывает). NTP-клиент тут совсем ни при чём — его запуск завершается где-то между 1-й и 2-й секундой.

SeiSeich, выгрузи plot ещё куда-нибудь. DropMeFiles не работает почему-то.

SeiSeich, выгрузи plot ещё куда-нибудь. DropMeFiles не работает почему-то.

Проверил, ссылка работает: https://transfiles.ru/e30pg

Ок. Нужен лог. Никакой процесс загрузку явно не блокирует — systemd чего-то ждёт, не дожидается и продолжает грузиться по таймауту.

Закинь куда-нибудь вывод journalctl -b после загрузки с воспроизведённой проблемой. Надеюсь, у вас в минте журнал по умолчанию включен…

Закинь куда-нибудь вывод journalctl -b после загрузки с воспроизведённой проблемой. Надеюсь, у вас в минте журнал по умолчанию включен…

Вывод журнала после событий: Перезагрузка (так же долго по времени) + запуск вручную Я.Браузера.

Ссылка проверена на работоспособность.

https://transfiles.ru/gzwu4

Попробуйте загрузиться с опцией usbhid.quirks=0x0458:0x003a:0x00000400 или с отключенной мышью.

Попробуйте загрузиться с опцией usbhid.quirks=0x0458:0x003a:0x00000400

Как это сделать?

Так же, как модифицировать любую опцию ядра:

• Если временно, то при загрузке после BIOS(UEFI) заставки нажми Esc; после чего нажми на пункте по умолчанию клавишу E; после чего у тебя откроется код скрипта загрузки, тебе нужна строчка, что начинается с linux, нужно просто дописать эту опцию в её конец; обрати внимание — строчка может переноситься, но оставаться одной строчкой, просто поставь курсор на слово «linux» в начале строчки и нажми клавишу End — сразу перебросит в её конец; после чего нажми F10 и загрузись.

• Если на постоянной основе нужно прописать, то нужно открыть на редактирование файл: sudo nano /etc/default/grub, после чего добавить этот параметр в строку с параметрами GRUB_CMDLINE_LINUX_DEFAULT=, после чего выполнить sudo update-grub.

Так же, как модифицировать любую опцию ядра:

На это я пойтить не могу! ))) Боюсь накосячить с ядром. Я не настолько продвинут. )))

Проще перезагрузиться с отключённой мышью… Сейчас отпишусь про результаты такой перезагрузки.

Попробуйте загрузиться … или с отключенной мышью.

Отключение мыши никак не повлияло на ускорения загрузки…

+Разберитесь со свопом. Задерживает загрузку именно он.

+Разберитесь со свопом. Задерживает загрузку именно он.

Вы имеете в виду раздел подкачки /dev/sdb3 , который смонтирован как Swap?

Я, честно говоря, даже не понимаю в какую сторону думать, чтобы с ним разобраться…

Всё, что пришло на ум:

1. Отключить автомонтирование и юзать систему без этого раздела
2. Отформатировать

Мои размышления не слишком далеки от истины - как с ним ещё можно разобраться?

Что посоветуете?

Разберитесь, что за устройство /dev/disk/by-uuid/65dffeeb-b1e3-459d-a295-bdac4e4aeb99, что с ним не так, и как организован своп.

С мышью сделайте так, как Всеволод сказал. На время загрузки это не влияет, но отваливаться каждую минуту она не должна.

… как организован своп.

Своп организован на отдельном разделе диска, объёмом 8 Гб, тип раздела - linux-swap. Параметры монтирования - системные, по умолчанию.

Что с ним может быть не так?

Разберитесь, что за устройство /dev/disk/by-uuid/65dffeeb-b1e3-459d-a295-bdac4e4aeb99

Раздела такого в системе нет. Подозреваю, что это UUID умершего недавно харда…

На нём стояла Винда 8.1. Может GRUB её безуспешно ищет и потому загрузка подвисает?

Проанализирую. О результатах отпишусь.

С мышью сделайте так, как Всеволод сказал. На время загрузки это не влияет, но отваливаться каждую минуту она не должна.

С мышью, как пользователь, не вижу никаких проблем. Следов «отваливания» не замечаю..

В ядро сейчас не полезу - стремно. Только, если буду готов к переустановке системы. Тогда можно поковыряться…

июл 30 07:57:37 MaestroLM dbus-daemon[942]: [system] Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)

июл 30 07:56:36 MaestroLM systemd[1]: dev-disk-by\x2duuid-65dffeeb\x2db1e3\x2d459d\x2da295\x2dbdac4e4aeb99.device: Job dev-disk-by\x2duuid-65dffeeb\x2db1e3\x2d459d\x2da295\x2dbdac4e4aeb99.device/start timed >
июл 30 07:56:36 MaestroLM systemd[1]: Timed out waiting for device /dev/disk/by-uuid/65dffeeb-b1e3-459d-a295-bdac4e4aeb99.
июл 30 07:56:36 MaestroLM systemd[1]: Dependency failed for /dev/disk/by-uuid/65dffeeb-b1e3-459d-a295-bdac4e4aeb99.
июл 30 07:56:36 MaestroLM systemd[1]: Dependency failed for Swap.
июл 30 07:56:36 MaestroLM systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
июл 30 07:56:36 MaestroLM systemd[1]: dev-disk-by\x2duuid-65dffeeb\x2db1e3\x2d459d\x2da295\x2dbdac4e4aeb99.swap: Job dev-disk-by\x2duuid-65dffeeb\x2db1e3\x2d459d\x2da295\x2dbdac4e4aeb99.swap/start failed wit>
июл 30 07:56:36 MaestroLM systemd[1]: dev-disk-by\x2duuid-65dffeeb\x2db1e3\x2d459d\x2da295\x2dbdac4e4aeb99.device: Job dev-disk-by\x2duuid-65dffeeb\x2db1e3\x2d459d\x2da295\x2dbdac4e4aeb99.device/start failed>

Что-то в системе (скорее всего, fstab) ссылается на несуществующий раздел /dev/disk/by-uuid/65dffeeb-b1e3-459d-a295-bdac4e4aeb99. Пойди в /etc/fstab и убери все упоминания этого раздела, ну или исправь их на существующий раздел.

Эту опцию вместо kernel строки можно в /etc/modprobe.d прописать, не?

Понял. Спасибо! Чуть выше уже указали, что система ищет несуществующий раздел.

Чуть позже проанализирую эту ситуацию, исправлю что смогу. Про результаты отпишусь.

Эту опцию вместо kernel строки можно в /etc/modprobe.d прописать, не?

Вопрос

не?

относится ко мне, или к i586 ?