legacy grub: обновленный menu.lst не используется
Это CentOS 6.4 со всеми обновлениями внутри Virtualbox OSE (довольно старая версия). Вся информация ниже относится к ВМ, я не думаю, что есть какие-либо проблемы на хосте.
/ boot это отдельная файловая система ext2 для /dev/sda1 (hd0,0)
Что я сделал:
- cp /boot/grub/menu.lst /boot/grub/menu.lst.old
- vi /boot/grub/menu.lst
После перезагрузки меню grub не отражает сделанные мной изменения (некоторые изменения в командной строке ядра). Загрузка не удалась, потому что старая команда больше не может работать.
Если в командной строке grub я звоню
- cat (hd0,0)/grub/menu.lst новое содержимое будет показано, как ожидается
- 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 ответ
Ах, я разместил свой вопрос на неправильном сайте, я намеревался опубликовать на 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
решает все это.