новая установка 16,04 начальных загрузок 3.13.0-96 несмотря на факт это даже не присутствует ни в какой смонтированной файловой системе

Новая установка 16,04 от mini.iso. После базовой установки я использовал склонный - добираются, чтобы установить Xorg, openbox, thunar и так далее, установить некоторые группы и сбросить tty шрифт. Никакой DM. Никакой DE кроме самого Openbox. Я использую LILO, потому что ошибки тестера ОС, которые влияют на grub2, были таким кошмаром в системе с большим количеством установленного OSs, включая некоторых на внешних медиа, которые могли бы или не могли бы присутствовать. Я вернусь к grub2, когда я просто буду нуждаться в суицидальном отчаянии, поэтому давайте не идти туда, если мы можем избежать его. Я видел обсуждения подобных проблем с grub2 также, но ни одно из решений не работало на меня. Это, кажется, пример общего класса подобных проблем с 16,04 конкретно. LILO хорошо работает для 3 установок изменений 14,04 и Победа что-то (7, я думаю - я только загрузил его время или 2), но на новой установке 16,04 он загружает показ приятно большого, разноцветного шрифта в tty7 и зависает после этого вывода: "запущенное обновление, UTMP о системе runlevel изменения" Иногда прежде, иногда после этого, будет выводом "getty@ttyN.service", где N является целым числом от 1 - 6, включительно. Я не уверен, что N последователен. Иногда это сообщение повторяется с другими значениями N, другими целыми числами от 1-6. Я думаю, что это - то, только если я получаю доступ к тем ttys с cntrl-alt-FN. Возможно, 16.04 пытается запустить x сессию даже при том, что я еще не сказал ее, и по некоторым причинам перестал работать на этом шаге. Это составляло бы то, чтобы он был сфокусированным на tty7, в то время как то, что похоже на нормальную неграфическую загрузку, происходит в tty1? Так или иначе, после этого зависает, я нахожу в tty1, что, кажется, насколько я могу сказать, конец нормального процесса неграфической загрузки, с приглашением ко входу в систему. Я могу обычно входить в систему. Startx обычно работает. Это не сделало сначала, но это было то, потому что ~/.Xauthority принадлежал root:root, который я зафиксировал. На самом деле все, что я проверил, кажется, работает довольно обычно кроме, он - неправильное ядро. Я подтвердил это с обоими: uname-r и кошка/proc/version. Самая странная вещь состоит в том, что 3.13.0-96 не присутствует нигде, я ожидал бы, что эта система сможет получить доступ. Смонтируйте шоу только / смонтированный раздел. Fstab только говорит этому монтировать что один раздел. Я не useing подкачка или раздел начальной загрузки. / начальная загрузка содержит только 4 серийных ядра, которые Вы ожидали бы. Таким образом, если это не скрывает его где-то в другом месте в файловой системе, это должно монтировать один из других разделов достаточно долго, чтобы, по крайней мере, считать 3.13.0-96 ядер, но смонтироваться, не показывает это. Однажды я думал, что это было то, потому что у меня были некоторые системы с помощью общего раздела начальной загрузки и других, использующих каталог начальной загрузки и что это путало LILO, конкретно означая команду lilo, которая читает/etc/lilo.conf, и по-видимому разрешает символьные ссылки как vmlinuz в корневых каталогах файловых систем и хранит то, что их цель где-нибудь. Я предполагаю, что, потому что у меня есть записи, указывающие на символьные ссылки в дополнение к некоторому указанию на определенные ядра и тех, которые указывают на символьные ссылки, не работают после обновления ядра, пока я не выполняю lilo и затем они работают. Так или иначе я изменил это, изменил весь fstabs, скопировал материал в разделе начальной загрузки к каталогам начальной загрузки в системах, которым был нужен он, удалил раздел начальной загрузки, выполнил lilo, и все хорошо работает на 3 14,04 с, но тем не менее 16,04 начальных загрузок 14,04 ядер.

Это в eleventy-седьмой раз, когда я установил 16.04. Если ни у кого нет решения этого, я могу попробовать еще раз и проверить подробно, как оно ведет себя, прежде чем я установлю что-либо. Но я о готовом для отказываний от него. Спасибо за чтение. Любые идеи ценились бы. Даже непродуманные, потому что я пробежал все свои разумные и непродуманные идеи и работаю над необработанными. <|;-)

= = = = = = =

Обновление:

Некоторые места как это, люди придают большое значение "точкам" или некоторым такой, и ответ на Ваш собственный вопрос рассматривается как обман или грубый. Так, я не делаю этого. Каково пользовательское здесь?? Так или иначе я решил это. Таким образом, часто артикулирование проблемы разъясняет Ваши взгляды на нем, и я предполагаю то, именно это произошел. Так, я, как предполагается, говорю, в пользу людей, находящих это от поисковой системы? Или оставьте его, чтобы кто-то нашел общий язык с? Или ожидайте 24 часа или что-то?

-2
задан 8 September 2016 в 20:06

1 ответ

Проблема состояла в том, что я неправильно понял синтаксис lilo.conf. Пути, указанные в каждой строке файла конфигурации, не относительно корня файловой системы, данной как корень. Они относительно корня файловой системы, содержащей установку с эффективным lilo.conf. Какой бы ни ОС отвечает за lilo, другими словами.

А именно, они - пути в действительности В ДАННЫЙ МОМЕНТ, команда "lilo" выполняется, независимо от того, является ли точка монтирования чем-то в fstab или чем-то произвольном и временном. Так же, например, если Вы монтируете корень другой системы как "/mnt/othersys" и затем выполняете команду "sudo lilo", пути для строки файла конфигурации для другого sys, нуждаетесь для начала "/mnt/othersys /". В следующий раз при обновлении ядра Вы монтируете его по-другому, например, как "/mnt/ubuntu1604", и Вам не удается изменить lilo.conf для отражения этого, это не будет работать. Если пути происходят, как в моем случае, чтобы указать где-нибудь, что существует файл, соответствующий имени ядра (как в случае мая, я указывал на них назад к корню файловой системы, содержащей ОС, что я был загружен в то, так как я думал, что они были относительно указанного корня, и работающий "sudo lilo" на, при этом цели были символьными ссылками в/), это, будет КАЗАТЬСЯ, будет успешно выполняться, но информация о начальной загрузке сохранила, будет указан на неправильное ядро и изображение.

, Весь из которого - то, потому что команда "lilo" находит физическое местоположение (или что передачи для нее на современном диске, который отказывается делать ОС посвященной в ее внутренние работы) изображения и файлов ядра, указанных с точки зрения файловой системы, смонтированной в то время, когда, команда была выполнена и хранит ФИЗИЧЕСКИХ (снова, не действительно, но во всяком случае в терминах только внутренние механизмы HD могут перевести), местоположения, не местоположения путей/имени файла. Таким образом, на самом деле lilo.conf, насколько я вижу, ничего не делает промежуточные выполнения команды lilo. Информация, необходимая в начальной загрузке, хранится где-то в другом месте. Lilo.conf является просто руководством по lilo в поколении той информации

0
ответ дан 28 September 2019 в 14:45

Другие вопросы по тегам:

Похожие вопросы: