Re: Debug grub scripts without rebooting into grub shell.

[Hongyi Zhao]

On Thu, Jul 13, 2023 at 8:33 AM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Thu, Jul 13, 2023 at 1:19 AM Glenn Washburn
> <development@efficientek.com> wrote:
> >
> > On Wed, 12 Jul 2023 15:26:18 +0800
> > Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
> >
> > > On Wed, Jul 12, 2023 at 2:15 PM Glenn Washburn
> > > <development@efficientek.com> wrote:
> > > >
> > > > On Wed, 12 Jul 2023 09:25:15 +0800
> > > > Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
> > > >
> > > > > On Wed, Jul 12, 2023 at 5:26 AM Glenn Washburn
> > > > > <development@efficientek.com> wrote:
> > > > > >
> > > > > > On Sat, 8 Jul 2023 19:58:29 +0800
> > > > > > Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
> > > > > >
> > > > > > > Hi here,
> > > > > > >
> > > > > > > Are there some convenient methods to debug grub scripts without
> > > > > > > rebooting into grub shell?
> > > > > >
> > > > > > I would recommend running the GRUB EFI application in QEMU, as it 
> > > > > > will act
> > > > > > more closely to when running on bare metal. Here's an example of a 
> > > > > > QEMU
> > > > > > command that I use when doing development:
> > > > > >
> > > > > > qemu-system-x86_64 -name '[x86_64-efi] Test Grub' \
> > > > > >  -m 2048 -bios OVMF.fd --enable-kvm -boot once=c,menu=on \
> > > > > >  -nodefaults -rtc base=localtime -vga std -snapshot \
> > > > > >  -drive file=/home/grub-tester/bootloader/efidisk.img,format=raw \
> > > > > >  -device virtio-scsi-pci,id=scsi0,num_queues=4 \
> > > > > >  -device 
> > > > > > scsi-hd,drive=drive0,id=systema,bus=scsi0.0,scsi-id=0,lun=0,channel=0
> > > > > >  \
> > > > > >  -drive file=/dev/sdc,format=raw,if=none,id=drive0,readonly=on \
> > > > > >  -device 
> > > > > > scsi-hd,drive=drive1,id=systemb,bus=scsi0.0,scsi-id=0,lun=1,channel=0
> > > > > >  \
> > > > > >  -drive 
> > > > > > file=/home/user/disk.img,format=raw,if=none,id=drive1,readonly=on
> > > > > >
> > > > > > If you want to use a block device, then you'll need to run as root 
> > > > > > or
> > > > > > otherwise have correct permissions to read from the device. But you 
> > > > > > can have everything in a disk image file and not need to run as 
> > > > > > root.
> > > > >
> > > > > I tried to adapt your approach to my case, but it didn't work:
> > > > >
> > > > > werner@X10DAi:/media/werner/a5d0e46f-aea7-43f0-9a3e-cfb6d517d214/EFI/grub-mkstandalone$
> > > > > sudo qemu-system-x86_64 -name '[x86_64-efi] Test Grub'  -m 2048 -bios
> > > > > OVMF.fd --enable-kvm -boot once=c,menu=on  -nodefaults -rtc
> > > > > base=localtime -vga std -snapshot  -drive
> > > > > file=./grubx64.efi,format=raw  -device
> > > > > virtio-scsi-pci,id=scsi0,num_queues=4  -device
> > > > > scsi-hd,drive=drive0,id=systema,bus=scsi0.0,scsi-id=0,lun=0,channel=0
> > > > > -drive file=/dev/sdc,format=raw,if=none,id=drive0,readonly=on  -device
> > > > > scsi-hd,drive=drive1,id=systemb,bus=scsi0.0,scsi-id=0,lun=1,channel=0
> > > > > format=raw,if=none,id=drive1,readonly=on
> > > > > qemu-system-x86_64: -drive
> > > > > file=/dev/sdc,format=raw,if=none,id=drive0,readonly=on: Could not open
> > > > > '/dev/sdc': No such file or directory
> > > >
> > > > The above arguments emulate two disks. One coming from grubx64.efi and
> > > > one /dev/sdc. I think for your use case, you only need one drive. But
> > > > it needs to be an EFI bootable disk image. The file grubx64.efi is just
> > > > the EFI application, not the disk image, which contains grubx64.efi.
> > > > Remember, the disk image file will show up as a scsi hard drive, so it
> > > > needs to look like a bootable drive (ie has a GPT label and EFI System
> > > > Partition correctly setup). This link[1] shows how to do it on a block
> > > > device, but you can create everything in a file too (though you might
> > > > need to learn how to use losetup).
> > > >
> > > > Glenn
> > > >
> > > > [1]
> > > > https://old.nixaid.com/creating-uefi-bootable-usb-flash-drive-with-several-linux-distributions/
> > >
> > > I noticed the following description on the above Tech blog, which is
> > > used to construct the linux & initrd lines based on the corresponding
> > > grub configurations on the iso files:
> > >
> > > To construct linux & initrd lines I have used the contents of
> > > isolinux/menu.cfg file (in some cases it is different, but easy to
> > > find using grep) that can be accessed if you simply mount/open the
> > > .iso file
> > >
> > >
> > > But I want to know whether this can be used as a general method to
> > > construct the linux & initrd lines to boot the isos using grub.
> >
> > No, it won't work in general, but it might work for most of your isos
> > depending on which ones you use. Checkout supergrubdisk[1] as Andrei
> > mentioned. Also here are a couple other links that might be
> > helpful[2][3].
> >
> > Glenn
> >
> > [1]
> > https://github.com/supergrub/supergrub/blob/master/menus/sgd/autoiso.cfg
> > [2] https://github.com/jim945/autoiso-multiboot
> > [3] https://www.supergrubdisk.org/wiki/Loopback.cfg
>
> Thank you very much again for these wonderful tips and tricks.
>
> Basically, there are two main types of methods mentioned here used to
> boot the iso without burning it:
>
> 1. isolinux (linux & initrd) based method.
> 2. Loopback.cfg based method.
>
> So, I want to know which method is more robust or advisable when
> installing an operating system directly using an iso image?

See https://github.com/jim945/autoiso-multiboot/issues/1 for the
related discussion.

> > >
> > > Best,
> > > Zhao
> > >
> > > >
> > > > >
> > > > > > Also You can add the options "--nographic -serial stdio" to have 
> > > > > > the interface
> > > > > > be via serial, which allows text selection. In this case GRUB will 
> > > > > > need to be
> > > > > > configured to output to serial.
> > > > > >
> > > > > > Glenn
> > > > >
> > > > > Zhao