On Mon, Dec 28, 2020 at 3:57 PM Mihai Osian <mihai.os...@gmail.com> wrote:
> On 2020-12-28 02:29, Adrian Sevcenco wrote: > > Salutare! Nu am avut ce face si am zis ca daca tot am facut upgrade la > comp sa trec si eu civilizat la efi .. ca doar efi-ul e la fel peste tot > nu? (indiferent de placa de baza sau distro) > Well.. se pare ca nu chiar .. dupa o unga batalie in care am reusit sa > pierd doar o parte din /home (ca am facut in graba un --create fara sa > specific metadata si mi-a fxxck-uit partitia) acum am ajuns sa ma bag cu > o stupizenie de boot .. > > incep cu sfarsitul : > imi intra in grub shell unde dau frumos > configfile (hd0,1)/EFI/fedora/grub.conf si totul pleaca frumos.. > > am incercat in toate modurile posibile sa il lamuresc sa plece.. > initial ESP-urile erau in raid1.. desi am mai facut si am la serviciu > desktopuri cu ESP, / si /home in md-uri (metadata 1.0) astea sunt pe Ubuntu > si entry-urile de efibootmgr arata complet diferit (dar nu stiu daca de la > bios-ul respectiv sau de la distro) > > acasa, cu o placa asus (la care a trebuit mult sa caut cum sa dau disable > la secure boot) si fedora 33, nu vroia sa imi meraga grub2-install-ul decat > cu no-vram (si am incercat muulte combinatii de boot entry-uri cu > efibootmgr .. dar nu am gasit cum pot da manual un device path).. bun, am > desfacut md-ul de la espuri > (am facut un boot/efi2 unde montez esp-ul 2 si le tin in sync cu systemd) > si in sfartit a mers grub2-install cu tot cu creatul de boot entry.. doar > ca tot nu merge ... > > asa ca momentan am un sistem nefunctional (pentru nevasta) la care la boot > trebuie sa ii spun eu "ba boule incarca configul asta" .. fara doar si > poate, boul-ul poate sa fie si cel ce scrie mailul acum,.... > > So, aveti idee unde poate fi problema? > Multumesc frumos! > Adrian > > > Verifica daca grub.cfg exista langa fisierul grub64.efi (poate au alt nume > pe fedora). De exemplu la mine arata asa: > > root@kermit:/home/mike# efibootmgr -v > *BootCurrent: 0006* > > [...]*Boot0006** ubuntu HD(1,GPT,*3e62c35b* > -61b0-4fda-bb85-7d993a1f95f4,0x800,0x100000)/File( > *\EFI\UBUNTU\GRUBX64.EFI*) > > root@kermit:/home/mike# blkid | grep *3e62c35b* > */dev/nvme0n1p1*: UUID="AE49-4F7B" TYPE="vfat" PARTLABEL="EFI System > Partition" PARTUUID="3e62c35b-61b0-4fda-bb85-7d993a1f95f4" > > root@kermit:/home/mike# mount | grep */dev/nvme0n1p1* > */dev/nvme0n1p1* on */home/mike/tmp *type vfat > > root@kermit:/home/mike# ls */home/mike/tmp/EFI/ubuntu/* > *grub.cfg* grubx64.efi > > Mihai > Tocmai am gasit asta, poate te ajuta: https://wiki.archlinux.org/index.php/GRUB#Common_installation_errors Zice acolo: *Drop to rescue shell* *If GRUB loads but drops into the rescue shell with no errors, it can be due to one of these two reasons: * - *It may be because of a missing or misplaced **grub.cfg**. This will happen if GRUB UEFI was installed with **--boot-directory** and * *grub.cfg** is missing,* - *It also happens if the boot partition, which is hardcoded into the * *grubx64.efi** file, has changed.* Iar aici: https://unix.stackexchange.com/questions/565615/efi-boot-bootx64-efi-vs-efi-ubuntu-grubx64-efi-vs-boot-grub-x86-64-efi-grub-efi *Note:** On Debian/Ubuntu, the generated GRUB core image will include a baked-in UUID reference to whichever filesystem contains the **/boot** directory, so you won't be able to just make a copy of either * */boot/grub/x86_64-efi/grub.efi** or **grubx64.efi** from the ESP and transplant it to a removable media: it will just attempt to find the unique UUID of your **/boot** filesystem and will drop to rescue mode if it won't find it. If I recall correctly, the GRUB of RedHat/CentOS/Fedora should be more suitable for transplantation to removable media.* Mihai _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
