help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-mkimage


From: Pascal
Subject: Re: grub-mkimage
Date: Tue, 25 Jan 2022 15:23:18 +0100

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 ?

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 ?

Le mar. 25 janv. 2022 à 13:06, Andrei Borzenkov <arvidjaar@gmail.com> a
écrit :

> On Tue, Jan 25, 2022 at 12:13 PM Pascal <patatetom@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 <arvidjaar@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.
> >>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]