Это CentOS 6.4 со всеми обновлениями внутри Virtualbox OSE (довольно старая версия). Вся информация ниже относится к ВМ, я не думаю, что есть какие-либо проблемы на хосте.

/boot это отдельная файловая система ext2 для /dev /sda1 (hd0,0)

Что я сделал:

  1. cp /boot/grub/menu.lst /boot/grub/menu.lst.old
  2. vi /boot/grub/menu.lst

После перезагрузки меню grub не отражает сделанные мной изменения (некоторые изменения в командной строке ядра). Загрузка не удалась, потому что старая команда больше не может работать.

Если в командной строке grub я звоню

  1. cat (hd0,0)/grub/menu.lst новое содержимое будет показано, как ожидается
  2. cat (hd0,0)/grub/menu.lst.old старое содержимое будет показано как ожидается

Если я интерактивно повторю свои изменения в команде grub, редактирование загрузки будет успешным.

Я повторил это много раз. Скопировали menu.lst (чтобы блочный список изменился), но это всегда одна и та же проблема. Grub "видит" новую версию в команде cat, но не в ее меню.

На машине только один диск, на одном диске только один раздел ext2 (остальное - LVM2), один раздел ext2 содержит только 1 файл с именем menu.lst. Таким образом, любая путаница с дисками, разделами или путями должна быть исключена.

(По какой-то странной причине grub показывает один и тот же диск 5 раз: hd0, hd8, hd9, hd10 и hd11, но все они имеют одинаковое содержимое, и корень правильно установлен как (hd0,0), поэтому я не думаю, что это должно быть причиной проблемы)

Таким образом, кажется, что старый menu.lst был скопирован в какое-то скрытое место, и grub использует его из этого скрытого места для своего меню. Редактирование файла не изменило "скрытое место". Но для первого файла есть комментарий

# Note that you do not have to rerun grub after making changes to this file

во-вторых, я вполне уверен, что я делал такие обновления много раз назад во времена, когда Ubuntu все еще использовал устаревший grub, и в-третьих, я понимаю, что grub может читать файловые системы ext2 (может команда grub's cat поддерживает это), так что должно быть нет причин для "скрытого места".

1 ответ1

0

Ах, я разместил свой вопрос на неправильном сайте, я намеревался опубликовать на serverfault. Superuser звучал как Unix su для меня. Просто слишком долгая отладка слишком поздно ночью ...

Во всяком случае, я нашел решение:

RHEL и, следовательно, CentOS вообще не используют menu.lst, вместо этого они используют grub.conf. (Используемое имя файла может быть указано во время установки grub.)

Однако есть символическая ссылка menu.lst -> grub.conf

Так что, если администратор не знает другого имени, вызов vi в menu.lst волшебным образом сделает правильную вещь.

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

sed -i s/foo/bar/g menu.lst

сделать мои изменения. Я даже звонила

diff menu.lst.old menu.lst

чтобы убедиться, что все было хорошо, и это действительно выглядело правильно.

Однако sed -i не редактировал цель символической ссылки (как это делает vi), но заменил символическую ссылку новым файлом с новым содержимым. grub.conf остался неизменным, так что это действительно было "скрытое место", которое я подозревал

призвание

sed -i s/foo/bar/g grub.conf

решает все это.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .