search

void-linux / void-mklive

The Void Linux live image maker
https://voidlinux.org
Other
328 stars 194 forks source link

mklive.sh: simplify generate_squashfs() #311

Closed mobinmob closed 1 year ago

mobinmob commented 1 year ago

Tested with base, xfce and enlightenment images generated from build-x86-image.sh.

strec007 commented 1 year ago

Tested on i686. Works and solves the issue #292.

paper42 commented 1 year ago

solves the issue #292.

That's not related to this PR, any new build of an iso would solve that issue.

mobinmob commented 1 year ago

Tested on i686. Works and solves the issue #292.

Thank you for testing :)

strec007 commented 1 year ago

Tested on i686. Works and solves the issue #292.

solves the issue #292.

That's not related to this PR, any new build of an iso would solve that issue.

Well, I built and tested an i686 live image using master a few minutes ago and it the issue was still present.

paper42 commented 1 year ago

Well, I built and tested an i686 live image using master a few minutes ago and it the issue was still present.

That's interesting, other reports suggested that rebuilding the iso is enough to make it work and that it was just a random fs corruption.

strec007 commented 1 year ago

That's interesting, other reports suggested that rebuilding the iso is enough to make it work and that it was just a random fs corruption.

OK, I can imagine that this might be caused by the fact that I've been using a privileged Docker container to build the iso. I'll try again on a real void installation to exclude this suspicion...

strec007 commented 1 year ago

OK, so my suspicion is confirmed. The issue occurs only with Docker. In a normal system, it works almost as expected. (The installer is still missing certain packages, like dialog and grub and maybe more if not explicitly specified using -p)

paper42 commented 1 year ago

OK, so my suspicion is confirmed. The issue occurs only with Docker. In a normal system, it works almost as expected. (The installer is still missing certain packages, like dialog and grub and maybe more if not explicitly specified using -p)

That's expected if you ran just mklive.sh, you are supposed to run build-x86-packages.sh -b base if you want the base iso.

strec007 commented 1 year ago

That's expected if you ran just mklive.sh, you are supposed to run build-x86-packages.sh -b base if you want the base iso.

That's an important information. Is there any documentation on that?

paper42 commented 1 year ago

That's expected if you ran just mklive.sh, you are supposed to run build-x86-packages.sh -b base if you want the base iso.

That's an important information. Is there any documentation on that?

Unfortunately no, but there is an open issue about documenting this repository: https://github.com/void-linux/void-mklive/issues/126.

0x5c commented 1 year ago

This boots successfully when written as-is to a USB drive, but fails to boot as loopback from grub (dracut iso-scan/dmsquash-live). Not the same kind of bug as #294; it gets past the point of mounting the squashfs (and seemingly figuring out it's the actual rootfs), but fails to change the root. Possibly a dracut bug.

As for #292, it is caused by the ext3 rootfs image within the squashfs being corrupted. This PR bypasses its creation; can't get corrupted it if doesn't exist.

mobinmob commented 1 year ago

This boots successfully when written as-is to a USB drive, but fails to boot as loopback from grub (dracut iso-scan/dmsquash-live). Not the same kind of bug as #294; it gets past the point of mounting the squashfs (and seemingly figuring out it's the actual rootfs), but fails to change the root. Possibly a dracut bug.

Thank you for testing 😉 That is really surprising. I used usb drives (dd) and ventoy (which uses grub AFAICT) to test this without an issue. I will try again.

As for #292, it is caused by the ext3 rootfs image within the squashfs being corrupted. This PR bypasses its creation; can't get corrupted it if doesn't exist.

Yep.

0x5c commented 1 year ago

That is really surprising. I used usb drives (dd) and ventoy (which uses grub AFAICT) to test this without an issue. I will try again.

Does it generate menuentries that look vaguely like what's in this? Assuming it's grub, pressing e on an entry would show the entry's code https://github.com/classabbyamp/glim/blob/master/grub2/inc-void.cfg

AFAIK dracut's dmsquash-live module shouldn't activate if the image's grub is the one loading linux and the initrd

mobinmob commented 1 year ago

That is really surprising. I used usb drives (dd) and ventoy (which uses grub AFAICT) to test this without an issue. I will try again.

Does it generate menuentries that look vaguely like what's in this? Assuming it's grub, pressing e on an entry would show the entry's code https://github.com/classabbyamp/glim/blob/master/grub2/inc-void.cfg

AFAIK dracut's dmsquash-live module shouldn't activate if the image's grub is the one loading linux and the initrd

I just tested with fresh builds of base and xfce live images. They work fine with ventoy. It uses grub indeed but the menuentries are nothing like these of glim.

mobinmob commented 1 year ago
0x5c commented 1 year ago

That is really surprising. I used usb drives (dd) and ventoy (which uses grub AFAICT) to test this without an issue. I will try again.

Does it generate menuentries that look vaguely like what's in this? Assuming it's grub, pressing e on an entry would show the entry's code https://github.com/classabbyamp/glim/blob/master/grub2/inc-void.cfg

AFAIK dracut's dmsquash-live module shouldn't activate if the image's grub is the one loading linux and the initrd

I just tested with fresh builds of base and xfce live images. They work fine with ventoy. It uses grub indeed but the menuentries are nothing like these of glim.

What do they look like? I tried digging through the ventoy repo and can't see anything Also when you say it uses grub, you mean grub is what loads the iso or you mean the iso's normal menu (choice of normal and RAM boot, with void logo as background) is used?

mobinmob commented 1 year ago

What do they look like? I tried digging through the ventoy repo and can't see anything Also when you say it uses grub, you mean grub is what loads the iso or you mean the iso's normal menu (choice of normal and RAM boot, with void logo as background) is used?

Ventoy generates (on boot) a grub menu with a menu entry for every image available in the drive. The menuentry is simple - 2 lines of code. It chainloads and you actually use the bootloader of the image.

0x5c commented 1 year ago

Ventoy generates (on boot) a grub menu with a menu entry for every image available in the drive. The menuentry is simple - 2 lines of code. It chainloads and you actually use the bootloader of the image.

Ah I see Ability to boot the image properly from loopback (the glim way) is important because iirc it is also how an image is booted using PXE

mobinmob commented 1 year ago

Ventoy generates (on boot) a grub menu with a menu entry for every image available in the drive. The menuentry is simple - 2 lines of code. It chainloads and you actually use the bootloader of the image.

Ah I see Ability to boot the image properly from loopback (the glim way) is important because iirc it is also how an image is booted using PXE

Is the image produced from mklive supposed to be used like this? Yes, that can be a problem, so dracut must be fixed :D jk, I have not considered that ;) If someone tries to netboot with an image generated using this PR, I would like to know the results.