[sisyphus] Fwd: Перенос UEFI диска на другой комп
Leonid Krivoshein
klark.devel на gmail.com
Пн Июл 29 22:24:53 MSK 2019
Картинку я посмотрел сразу.
Судя по первому логу, у Вас 1 диск с разметкой GPT (/dev/sda) и ещё один
диск с разметкой MBR (/dev/sdb). Вот что выдал efibootmgr по окончанию:
BootOrder: 0000
Boot0000* altlinux
HD(1,GPT,037bafbd-2af0-9248-b253-074fac98bdb5,0x800,0x7f800)/File(\EFI\altlinux\shimx64.efi)
То есть, BIOS'у сказано искать раздел EFI на GPT-диске с PARTUUID'ом
037bafbd-2af0-9248-b253-074fac98bdb5. Используя команду:
ls -l /dev/disk/by-partuuid/037bafbd-2af0-9248-b253-074fac98bdb5
../../sda1
несложно убедиться, что PARTUUID у нужного EFI-раздела /dev/sda именно
такой, а никакой-то другой. Или:
blkid -c /dev/null -o value -s PARTUUID /dev/sda1
037bafbd-2af0-9248-b253-074fac98bdb5
Покажет именно этот, а не какой-то другой PARTUUID.
А теперь ещё раз взгляните на скриншот с EFI-shell. Видите там этот
PARTUIID? Нет. Вот и я не вижу. Если при каждой загрузке у Вас меняются
UUID'ы на диске -- что-то не так дисковой подсистемой или самим SSD, и
тогда команды выше дадут другой вывод. Если после выполнения efibootmgr
показывает правильную картину, а после перезагрузки опять меняет
показания, значит, шалит BIOS либо что-то не так с модулями ядра
efivars/efivarfs/pstore. Скорее, первое.
29.07.2019 20:49, Dmitriy Rusetskiy пишет:
> Если посмотреть на картинку UEFI shell то видно, что
> шелл не видит на этом диске файловой системы, или по каким-либо
> причинам не
> монтирует ее.
> Думаю может дело не в биос? А с диском что-то не так.
> Почему UEFI shell не видит на нем FS?
> Может можно вручную в шелле прописать маппинг с FS2: на BLK6: ?
>
> P.S: Ссылку на картинку выслал ранее, не знаю получилось посмотреть
> кому-нибудь?
>
>
> пн, 29 июл. 2019 г. в 20:14, Leonid Krivoshein <klark.devel на gmail.com
> <mailto:klark.devel на gmail.com>>:
>
> Да нет, тут другое. После выполнения предложенных действий картина
> просто идеальная:
>
> BootOrder: 0000
> Boot0000* altlinux
> HD(1,GPT,037bafbd-2af0-9248-b253-074fac98bdb5,0x800,0x7f800)/File(\EFI\altlinux\shimx64.efi)
>
> Что говорит, что здесь всё сделано правильно. А вот после
> перезагрузки,
> судя по скриншоту с EFI-shell'ом, всё опять с ног на голову -- есть
> похожая запись, но GUID там совсем другой, что говорит о проблемной
> прошивке. Если не помогает обновление BIOS и сброс его настроек на
> дефолтные, нужно крутить его настройки -- что-то явно мешает
> efibootmgr
> зафиксировать новое состояние NVRAM. Возможно, придётся временно
> поставить пароль администратора на BIOS, убрать SecureBoot, пройти
> довольно сложный квест с изменением настроек BIOS, их сохранением и
> перезагрузками. Возможно, придётся выбирать этот загрузчик
> ("altlinux")
> средствами самого BIOS. Есть ещё пара вариантов, описанных по той
> ссылке, что уже приводил выше:
>
> https://www.altlinux.org/Rescue/Recovery#Работа_с_записями_о_EFI-загрузчиках_в_NVRAM
> <https://www.altlinux.org/Rescue/Recovery#%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8F%D0%BC%D0%B8_%D0%BE_EFI-%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D1%87%D0%B8%D0%BA%D0%B0%D1%85_%D0%B2_NVRAM>
>
> см. начиная со слов "Если у вашего компьютера проблемы с записью в
> NVRAM...". Используйте либо shim$ARCH.efi либо grub$ARCH.efi, в
> зависимости от SecureBoot. Кстати, а efibootmgr в целевой системе
> обновлён? Возможно, регрессия в модуле ядра, я честно говоря с этими
> штуками на 5-м ядре ещё не сталкивался.
>
>
>
> 29.07.2019 19:36, Dmitriy Rusetskiy пишет:
> > Все попробовал, результат тот-же :-(
> > Boot0000* altlinux VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
> > Лог действий прилагаю.
> >
> > пн, 29 июл. 2019 г. в 16:52, Leonid Krivoshein
> <klark.devel на gmail.com <mailto:klark.devel на gmail.com>
> > <mailto:klark.devel на gmail.com <mailto:klark.devel на gmail.com>>>:
> >
> > Добрый день!
> >
> >
> > 29.07.2019 16:12, Dmitriy Rusetskiy пишет:
> > > Добрый день!
> > > Я попробую сегодня вечером Ваши рекомендации.
> >
> > Да, интересно понять результат.
> >
> >
> > > Но что-то я не пойму почему Вы думаете что загрузочным
> раньше был
> > > /dev/sdb?
> > > Поясните подробнее пожалуйста.
> >
> > Диска с таким UUID'ом сейчас не подключено:
> > 99e275e7-75a0-4b37-a2e6-c5385e6c00cb
> > Он мог называться как угодно, а в конфиг мог быть прописан
> совсем
> > иной ID.
> > Нужно прописать GRUB_AUTOUPDATE_DEVICE='/dev/sda ' ЛИБО
> > '/dev/disk/by-id/<id> ' -- тот ID, который сейчас ссылается на
> > /dev/sda.
> >
> > Однако:
> >
> > Boot0000* altlinux VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
> >
> > Эта запись некорректна в любом случае.
> > Почему -- не знаю, но не грузится именно из-за неё.
> >
> >
> > > Я этого не найду в логах, но еще раз просмотрю и сравню
> что в файле
> > > /etc/sysconfig/grub2.
> > >
> >
> > Это правильно.
> > Также предлагалось первой командой почистить NVRAM от мусора.
> >
> >
> > --
> > Best regards,
> > Leonid Krivoshein.
> >
> > _______________________________________________
> > Sisyphus mailing list
> > Sisyphus на lists.altlinux.org <mailto:Sisyphus на lists.altlinux.org>
> <mailto:Sisyphus на lists.altlinux.org
> <mailto:Sisyphus на lists.altlinux.org>>
> > https://lists.altlinux.org/mailman/listinfo/sisyphus
> >
> >
> >
> > _______________________________________________
> > Sisyphus mailing list
> > Sisyphus на lists.altlinux.org <mailto:Sisyphus на lists.altlinux.org>
> > https://lists.altlinux.org/mailman/listinfo/sisyphus
>
> --
> Best regards,
> Leonid Krivoshein.
>
> _______________________________________________
> Sisyphus mailing list
> Sisyphus на lists.altlinux.org <mailto:Sisyphus на lists.altlinux.org>
> https://lists.altlinux.org/mailman/listinfo/sisyphus
>
>
>
> _______________________________________________
> Sisyphus mailing list
> Sisyphus на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus
--
Best regards,
Leonid Krivoshein.
Подробная информация о списке рассылки Sisyphus