01:05 <farkuhar> looks like lua retracted their 5.4.5 release: http://lua-users.org/lists/lua-l/2023-05/msg00014.html which would explain the 404 errors I get when trying to download the tarball.

01:21 <ukky> jaeger: ventoy does not see crux-3.7.iso in extFAT partition. I will change extFAT into ext4 and retest.

02:00 <ukky> it was my mistake, I copied ISO to wrong partition. Corrected.

02:01 <ukky> I see the issue with ventoy: crux ISO is not exposed as /dev/sd* device

02:03 <ukky> As a result, init script from crux initramfs mounts 32MiB partition with ventoy binaries as /media

02:28 <ukky> jaeger: The quick and dirty fix is to edit init srcipt line 58 like this: for DEV in $CDROM_DEVICES $BLOCK_DEVICES $(ls /dev/dm-* 2>/dev/null)

06:28 <cruxbot> [core.git/3.7]: less: update to 633

06:29 <cruxbot> [opt.git/3.7]: whois: update to 5.5.17

06:29 <cruxbot> [xorg.git/3.7]: xorg-libxi: update to 1.8.1

16:38 <ukky> I think I understand a bit why crux ISO fails boot from ventoy ISO. At boot ventoy substitutes (major,minor) for /dev/sd*2 for a USB key device. Ventoy remaps this device to point to a device with major code 253 (device mapper), while original major is 8. Thus inside initramfs we find crux media at /dev/sdd2, for example. When crux initramfs chroots into /newroot, /dev/sdd2 will be restored to original device,

16:38 <ukky> pointing to ventoy partition instead of crux media. I am still investigating.

20:01 <jaeger> Yeah, there's some goofy shuffling of devices going on. I hadn't dug into it yet, interesting stuff

20:10 <ukky> you can boot with 'dshell' and look at /ventoy/hook/ventoy-hook-lib.sh to see what ventoy is doing

21:13 <ukky> okay, I made a new ISO and it has proper /media mounted, I can run setup

21:21 <ukky> jaeger: you can check https://bpa.st/G73MW to see what has been changed to properly boot from ventoy iso. I didn't do verification on empty strings though.

21:47 <cruxbot> [contrib.git/3.7]: wine-staging: updated to version 8.7