help-grub
[Top][All Lists]
Advanced

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

Re: Debug grub scripts without rebooting into grub shell.


From: Hongyi Zhao
Subject: Re: Debug grub scripts without rebooting into grub shell.
Date: Thu, 13 Jul 2023 08:33:59 +0800

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?

> >
> > 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



reply via email to

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