On 25.01.2022 17:23, Pascal wrote: > when I use grub-mkimage, the generated EFI executable automatically loads > the embedded modules which explains this change in behavior. > and so I don't need this command insmod linux normal minicmd gzio efi_uga > efi_gop fat part_gpt in my configuration file. > On the contrary, grub-mkstandalone incorporates all the modules in the EFI > executable that will be generated (unless the use of the --install-modules > option) but the latter will only preload those listed in the --modules > option. > is this right ? >
Yes. > except chain, do you know if these nine modules are the "vital minimum" to > boot my roaming live system present on the second partition of a USB key - > or even an internal disk - partitioned in GPT in a UEFI environment ? > if (,gpt2) means "the second partition on the disk grub was loaded from", > then I'm sure to boot the system selected from the UEFI firmware and not > another system that might be present on another drive ? > You do not really need efi_uga or efi_gop unless you want to display pretty pictures. But EFI does not have memory constraints of legacy BIOS, so what not simply have all modules? > Le mar. 25 janv. 2022 à 13:06, Andrei Borzenkov <arvidj...@gmail.com> a > écrit : > >> On Tue, Jan 25, 2022 at 12:13 PM Pascal <patate...@gmail.com> wrote: >>> >>> hi, >>> >>> first of all, a small precision which can be important : I use version >> 2.06 of GRUB. >>> >>> in both cases (tiny and full EFI), /efi/boot/bootx64.efi and /boot/ are >> on the same partition (gpt2). >>> >>> in first case, these few modules allow me to access my configuration >> file (/efi/boot/bootx64.efi read /efi/menu.cfg) and to boot my kernel >> (linux /boot/kernel) with its initialization file (initrd /boot/initramfs). >>> >>> in the second case, the presence of all modules disturbs the expected >> behavior. I don't think that grub-mkstandalone will add more modules than >> the ones requested in this case. >>> >> >> I never said "it will add more modules". I said "it will add modules >> differently so they will not interfere with grub loading". >> >>> I added the nativedisk module (which has no dependency according to >> /usr/lib/grub/x86_64-efi/moddep.lst) to the few modules of the first case >> and it didn't change anything to its behavior : GRUB accesses its >> configuration file and boots my roaming live system. >>> this module doesn't seem to be the one that modifies GRUB's behaviour >> towards (,gpt2)/efi/boot prefix. >>> >>> in first case (with or without nativedisk), the ls command played in the >> GRUB console (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (cd0) (where (hd0) is my >> live disk). >> >> It is not enough to have the "nativedisk" module, you also need to >> have low level drivers (ahci, etc depending on your hardware). I >> assume nativedisk simply did not detect any native driver and its >> loading became noop. >> >>> in second case, it returns (ahci1) (ahci1,msdos1) (ahci0) (ahci0,gpt2) >> (ahci0,gpt1) (ahci2) (where (ahci0) is my live disk). >>> >> >> Well, (,gpt2) means "the second partition on the disk grub was loaded >> from". I doubt that grub magic to detect this disk will work with >> native drivers on UEFI (actually I am pretty sure it won't). >> >> nativedisk drivers were never intended for BIOS/UEFI systems. >> >>> regards, lacsaP. >>> >>> Le lun. 24 janv. 2022 à 19:28, Andrei Borzenkov <arvidj...@gmail.com> a >> écrit : >>>> >>>> On 24.01.2022 17:53, Pascal wrote: >>>>> hi, >>>>> I use grub successfully to boot my removable "UEFI only" roaming live >>>>> system. >>>>> I use grub-mkimage as follows to generate the EFI executable : >>>>> >>>>> cat > /tmp/cfg <<< "normal /efi/menu.cfg" >>>>> >>>>> grub-mkimage \ >>>>> --disable-shim-lock \ >>>>> -p "(,gpt2)/efi/boot/" \ >>>>> -o /run/live/bootmnt/efi/boot/bootx64.efi \ >>>>> -O x86_64-efi \ >>>>> -c /tmp/cfg \ >>>>> linux normal minicmd gzio efi_uga efi_gop fat part_gpt chain >>>>> >>>>> cat > /run/live/bootmnt/efi/menu.cfg <<~~~~ >>>>> insmod linux normal minicmd gzio efi_uga efi_gop fat part_gpt >>>>> menuentry "My Live Linux" { >>>>> linux … >>>>> initrd … >>>>> } >>>>> ~~~~ >>>>> >>>>> the executable being really minimal, I can't do much with it when I >>>>> encounter a boot problem. >>>>> so, I set up another EFI executable next to it, this time with all the >>>>> available modules : >>>>> >>>>> mods=$( ls -1 /usr/lib/grub/x86_64-efi/*.mod | sed -e >>>>> 's;/usr/lib/grub/x86_64-efi/;;g' -e 's/\.mod$//g' | tr '\n' ' ' ) >>>>> >>>>> echo $mods >>>>> acpi adler32 affs afs afsplitter ahci all_video aout appleldr archelp >>>>> at_keyboard ata backtrace bfs bitmap bitmap_scale blocklist boot >> boottime >>>>> bsd bswap_test btrfs bufio cacheinfo cat cbfs cbls cbmemc cbtable >> cbtime >>>>> chain cmdline_cat_test cmp cmp_test configfile cpio cpio_be cpuid >> crc64 >>>>> crypto cryptodisk cs5536 ctz_test date datehook datetime disk >> diskfilter >>>>> div div_test dm_nv echo efi_gop efi_uga efifwsetup efinet ehci elf >> eval >>>>> exfat exfctest ext2 extcmd f2fs fat file fixvideo font fshelp >>>>> functional_test gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 >>>>> gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 >>>>> gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 >>>>> gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool geli >> gettext >>>>> gfxmenu gfxterm gfxterm_background gfxterm_menu gptsync gzio halt >> hashsum >>>>> hdparm hello help hexdump hfs hfsplus hfspluscomp http iorw iso9660 >> jfs >>>>> jpeg json keylayouts keystatus ldm legacy_password_test legacycfg >> linux >>>>> linux16 loadbios loadenv loopback ls lsacpi lsefi lsefimmap >> lsefisystab >>>>> lsmmap lspci lssal luks luks2 lvm lzopio macbless macho mdraid09 >>>>> mdraid09_be mdraid1x memdisk memrw minicmd minix minix2 minix2_be >> minix3 >>>>> minix3_be minix_be mmap morse mpi msdospart mul_test multiboot >> multiboot2 >>>>> nativedisk net newc nilfs2 normal ntfs ntfscomp odc offsetio ohci >>>>> part_acorn part_amiga part_apple part_bsd part_dfly part_dvh part_gpt >>>>> part_msdos part_plan part_sun part_sunpc parttool password >> password_pbkdf2 >>>>> pata pbkdf2 pbkdf2_test pcidump pgp play png priority_queue probe >> procfs >>>>> progress raid5rec raid6rec random rdmsr read reboot regexp reiserfs >>>>> relocator romfs scsi search search_fs_file search_fs_uuid search_label >>>>> serial setjmp setjmp_test setpci sfs shift_test signature_test sleep >>>>> sleep_test smbios spkmodem squash4 strtoull_test syslinuxcfg tar >> terminal >>>>> terminfo test test_blockarg testload testspeed tftp tga time tpm tr >> trig >>>>> true udf ufs1 ufs1_be ufs2 uhci usb usb_keyboard usbms >> usbserial_common >>>>> usbserial_ftdi usbserial_pl2303 usbserial_usbdebug usbtest video >>>>> video_bochs video_cirrus video_colors video_fb videoinfo videotest >>>>> videotest_checksum wrmsr xfs xnu xnu_uuid xnu_uuid_test xzio zfs >> zfscrypt >>>>> zfsinfo zstd >>>>> >>>>> grub-mkimage \ >>>>> --disable-shim-lock \ >>>>> -p "(,gpt2)/efi/boot" \ >>>>> -o /run/live/bootmnt/efi/boot/helpx64.efi \ >>>>> -O x86_64-efi \ >>>>> -c /tmp/cfg \ >>>>> $mods >>>>> >>>>> however, when I choose to boot this one, I get the following error : >>>>> >>>>> error: disk `,gpt2' not found. >>>>> error: you need to load the kernel first. >>>>> >>>>> does anyone know why the *minimal* is fully functional while the >> *maximal* >>>>> refuses to consider (,gpt2)/efi/boot/ ? >>>>> >>>> >>>> Modules listed in grub-mkimage are intended only for access to >> /boot/grub >>>> directory and are initialized when grub image is executed. One of >> modules >>>> is nativedisk which replaces firmware disk drivers with native drivers >> (like >>>> ahci. usb, etc). These driver are using different name conventions so >> none of >>>> them recognizes gpt2. Moreover, I am not really sure whether those >> drivers >>>> will work under UEFI at all (they compete with UEFI for hardware >> access). >>>> >>>> If you need image with more grub modules consider using >> grub-mkstandalone. It >>>> creates image with embedded RAM disk and sets $prefix to refer to this >> disk. >>>> So you have usual grub environment with modules autoloading and avoid >> this >>>> problem. You can chose which modules are included into RAM disk. You >> can also >>>> create usual grub.cfg on this RAM disk which boots whatever you like >> automatically. >>>> >> >> >