search

drakkar-lig / debootstick

Generate a bootable live image from any Debian/Ubuntu filesystem tree.
62 stars 18 forks source link

debootstick's grub configuration copied from host #32

Closed kgilmer closed 3 years ago

kgilmer commented 3 years ago

When I generate a Live image with debootstick, I notice grub entries that are set on my host system. For example I have extra options to boot from the SSD on my host laptop, and an option for UEFI configuration options. I've checked my host machines configuration and I believe they are coming from there. Is this expected behavior? In my opinion, the grub configuration should be entirely isolated from the build host, but I may be missing something. Is there a recommended way of having tight control over the grub configuration including the boot menu entries?

(FYI: I'm looking to reproduce something like the default Ubuntu livecd installer which allows either to boot into the live environment (now working) or to launch directly into the installer (Ubiquity) which I believe is possible via a grub boot option which passes specific flags to the kernel on boot.)

eduble commented 3 years ago

This is a side effect of the fact we install the bootloader in a chroot with is not completely isolated. If the chroot is for a PC (debian, ubuntu) then debootstick just runs update-grub, but this needs a few things to run correctly, including /dev. Thus /dev is shared from the host, which probably explains the entries you noticed. Grub configuration is just slightly edited (https://github.com/drakkar-lig/debootstick/blob/master/scripts/create-image/target/pc/grub#L20) however, and debootstick makes sure the entry of the guest OS comes first (https://github.com/drakkar-lig/debootstick/blob/master/scripts/create-image/target/pc/grub#L104). Adding GRUB_DISABLE_OS_PROBER="true" to /etc/default/grub may solve the problem. You can try by doing the change in your chroot. If it works we can automate it. A more general approach would be to rely on a more isolated environment, but up to know I did not find anything. If we use a virtual machine, such as kvm, this means we have to download large files (at least a kernel), which complicates distribution of the software. Projects such as libguestfs had installation problems on ubuntu last time I tried.

kgilmer commented 3 years ago

Thank you for the details @eduble , that's very helpful. I'm experimenting with calling debootstick from a Github Actions VM and will see what happens. If I wanted to specify my own Grub configuration, say something like this, how do you recommend I can specify that to debootstick? Would I override the update_grub_conf() function you linked above? What about adding an option to specify the grub configuration as a stand-alone file?

kgilmer commented 3 years ago

FYI I managed to generate this release from this github workflow file.

kgilmer commented 3 years ago

Hmm, the image doesn't boot in kvm. I took a peek at the build log and here is what i believe is the relevant info:

debootstick should be run as root. Trying sudo...
I: detected target system: amd64 PC
I: generating a UEFI bootloader binary... done
I: draft image - computing a size large enough... done
I: draft image - partitioning and formatting... done
I: draft image - copying filesystem tree... done
I: draft image - updating package manager database... done
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
I: draft image - setting up bootloader... done
Found Ubuntu 20.04.1 LTS (20.04) on /dev/sdb1
I: draft image - kernel bootargs: quiet rootdelay=3 splash
I: draft image - updating fstab... done
I: draft image - performing sanity checks... done
I: final image - computing minimal image size... done
I: final image - partitioning and formatting... done
I: final image - copying content from draft image... done
  pvscan[93880] PV /dev/mapper/loop5p3 online.
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Found Ubuntu 20.04.1 LTS (20.04) on /dev/sdb1
I: final image - setting up the bootloader... done
I: final image - setting up the EFI boot partition... done
I: cleaning up... done
I: /tmp/iso/regolith-v1.5.0-20201009042814.iso ready (size: 3.3G). 
ISO build complete: /tmp/iso/regolith-v1.5.0-20201009042814.iso

I'm guessing, there is some host configuration or script that does not exist on the Github-hosted OS by default... Any suggestions?

eduble commented 3 years ago

If I wanted to specify my own Grub configuration, say something like this, how do you recommend I can specify that to debootstick? Would I override the update_grub_conf() function you linked above? What about adding an option to specify the grub configuration as a stand-alone file?

One of the main design goals of debootstick is to make the guest OS usable over the long term, as a live system. Note: in this respect debootstick does better than official Ubuntu ISOs. Official images have a more complex structure involving a squashfs-compressed image file; since the kernel and the bootloader need to be stored outside the compressed image for bootup to work, updating their packages does not work, which obviously prevents to use such an image over the long term.

About grub, we have:

Users are not supposed to modify /boot/grub/grub.cfg because modifications would be lost next time update-grub is called (this occurs each time grub or linux kernel package is updated for instance).

Therefore valid modifications may only be:

Doing anything else would be overwritten by next package update...

eduble commented 3 years ago

For your case, I would suggest to:

Do you think that could work as you wish?

kgilmer commented 3 years ago

Thank you @eduble , that works well.