IRC channel logs
2024-02-21.log
back to list of logs
<Guest991>Hi, After doing git pull, I put img on usb driver and turned on bios, but linux_ 4.14.336 the computer restarts <Googulator>Guest991: update submodules (and submodules of submodules) <Googulator>and make sure you aren't building on a system with a wonky memory map (boot a regular kernel and check dmesg for e820) <Guest991>Googulator I updated all the files, but it restarts from there <Guest991>I installed it again and executed these commands ./download.sh ./rootfs.py -b -a x86 --cores 4 and again the same error on another computer, I also tried <Mikaku>Googulator: I can pastebin the exact QEMU parameters I'm using, if that's necessary <Googulator>It does output fine in live-bootstrap, that's what I know so far <Googulator>& it shows a slightly different memory map when kexec'd using kexec-linux inside live-bootstrap, compared to when I boot it directly with grub on the same hardware <Mikaku>I'm just trying to reproduce the issue on an simpler environment <Mikaku>fiwix-ext2.img is my FiwixOS image <Mikaku>after running that script, I just do 'shutdown -h 0' <Mikaku>the Fiwix kernel kexecs Linux kernel successfully boot the Linux kernel doesn't show the messages to the serial line <Mikaku>I boot the Fiwix kernel with the following command line: <Mikaku>ro root=/dev/hda2 kexec_proto=linux kexec_size=8000 kexec_cmdline=\"rootdelay=900 console=ttyS0\" <Mikaku>I tried with ttyS1, but it doesn't work either <Mikaku>I don't care if the Linux kernel cannot reach the /sbin/init, I just want to see the first boot lines where there is the memory map <Mikaku>yes, your kernel weights 7.4M aprox <Googulator>I wasn't quite sure because the current kernel in lvie-bootstrap is quite a bit larger <Mikaku>you can check the 'kernels.zip' archive you posted in the above link <Mikaku>Googulator: yes, fiwix-ext2.img is based on FiwixOS 3.3 <Mikaku>the kexec procedure works successfully but I don't know why the Linux kernel refuses to write on ttyS0 <Mikaku>Googulator: I'll be away for a while, I'll read your posts later <Googulator>Mikaku: I can't even boot the live-bootstrap Fiwix kernel using FiwixOS's grub if I specify *any* kexec_size parameter, it just freezes right on startup <Googulator>I'm afraid this path to trying to reproduce won't really get us anywhere <Googulator>but it's fully reproducible if you run a live-bootstrap session in qemu or bare metal mode (i.e. with kernel bootstrap) <Mikaku>Googulator: in my image the kernel is not the stock kernel of FiwixOS 3.3 because that kernel don't has enabled kexec feature <Mikaku>I mean, if you are using the flat ATA disk that comes with the FiwixOS 3.3 we won't be able to kexec anything because kexec features is not enabled by default <Mikaku>Googulator: I'm using a kernel with CONFIG_KEXEC enabled and using the FiwixOS 3.3 filesystem <Mikaku>Let met repeat again; the kexec procedure works successfully but I don't know why the Linux kernel refuses to write on ttyS0 <Googulator>I did install the kernel from live-bootstrap into that FS <Googulator>and it fails to boot completely if I set kexec_size <Googulator>The stock kernel just ignores kexec_size and boots anyway <Mikaku>CONFIG_KEXEC is not enabled by default in the stock kernel <Googulator>Did you build your own kexec-enabled kernel for your test, or did you use the one I sent (which is taken directly from an LB session)? <Mikaku>I did build the stock kernel with CONFIG_KEXEC enabled <Mikaku>the only think I use from your archive kernels.zip is the Linux kernel <Mikaku>Googulator: nvm, I've built a new Linux kernel 4.9.54 using a minimal config (make tinyconfig), and it turns out that there are so few boot messages that I'm able to scroll back up to the first one <Googulator>ranges ending @ 0x...fffe instead of 0x...ffff, and an extra reservation @ 0x9d000 <Googulator>there's a chance it would shift structures around in such a way to avoid the issue, although I wouldn't call that "fixing" the issue <Googulator>unfortunately I don't have access to Raptor Lake hardware, which appears to be necessary to reproduce that issue <pder>Is work still needed in builder-hex0 to fix up these memory mapping issues? <Googulator>builder-hex0 currently stores the BIOS e820 memory map for later use by Fiwix & Linux, but itself doesn't use it <Googulator>this is probably unrelated to the Raptor Lake virtualized Fiwix boot issue <stikonas>Googulator: but I guess there is an assumption in builder-hex0 that Bios memory map does not reserve hardcoded range where stage0-posix binaries are loaded... <stikonas>I guess in practice BIOSes don't reserve such high ranges... <stikonas>well, I guess any memory used in builder-hex0 (not just for loading binaries but all other usage) <Googulator>there's an assumption that 0x100000 to 0xBBFFFFFF is available physical RAM, with no gaps, reservations or MMIO regions <Googulator>which is true of most "true" BIOSes with 3GiB or more memory installed <Googulator>but fails spectacularly on some versions of edk2 in CSM mode <stikonas>yeah, that's where all those structures to strore process metadata / memory and other buider-hex0 stuff are... <stikonas>well, for edk2 machines we should get stage0-uefi working... <stikonas>so longer term not a big problem I guess <Googulator>yes, we don't really intend to ever support CSM bootstrapping <Googulator>"UEFI Class 1" systems are vanishingly rare, let alone Class 1 systems based on buggy versions of edk2 <Googulator>(Class 1 is a firmware that's internally a UEFI, but only exposes CSM interfaces) <Googulator>the only "UEFI Class 1" system I know of is the Acer Aspire 5720 <Googulator>which is a 32-bit UEFI, to make matters even more confusing <stikonas>even if they support proper UEFI API, we don't have support for that in stage0-uefi <stikonas>I think I had either BIOS or later normal UEFI with CSM <Googulator>e.g. with the old UgaDraw protocol instead of GOP <Googulator>but it never really publishes any of the EFI APIs to the outside world (unless you patch the EFI to do so, which I did to some amusement - it was _almost_ able to natively boot versions of Mac OS X intended for the first Intel Macs, which also had EFI 1.x firmwarae) <Googulator>UEFIs with buggy memory map in CSM seem to all come from the early-to-mid-2010s <Googulator>there were also some tablets with 32-bit Class 3 UEFIs (i.e. no CSM) <Googulator>the resulting Gentoo chroot so far successfully built a stage3 tarball and a working live install CD image that boots fine in qemu in both BIOS and UEFI mode <Googulator>LiveGUI image building as we speak, as the ultimate verification of successful bootstrap <stikonas>Googulator: nice! I'm a bit behind on this <stikonas>put it slightly on hold till my new USB -> Gigabit ethernet adapter arrives <stikonas>(though I didn't do kernel bootstrap but that's impossible on that machine yet <Googulator>update: also boots on real hardware, although it takes considerably longer due to my crappy USB drive <stikonas>Googulator: also I had some trouble with our live-bootstrap kernel config <stikonas>I was not able to mount FAT32 drives with UEFI partitions <stikonas>Googulator: so that module is not included in 4.14 kernel config <stikonas>but I think that encoding is set to default <stikonas>I think this inconsistency causes the problem <stikonas>which is why I wasn't able to create a bootable system...