IRC channel logs
2024-02-17.log
back to list of logs
<oriansj>the only time you should be setting filesize to zero is when O_TRUNC is set; otherwise the standard would be not to truncate <oriansj>but other than that, yeah it looks reasonable <stikonas>let me double check what uses the other open mode <stikonas>almost everything else opens files with O_TRUNC <stikonas>but ok, I can limit the second if to (O_WRONLY | O_CREAT | O_TRUNC) <stikonas>or do you want me to do flag & O_TRUNC ? <oriansj>as O_TRUNC can be combined with other modes (which may not be reasonable) <stikonas>ok, now I think it works fine and is blocked by posix bootstrap issues only... <stikonas>we need to figure out why tcc-mes crashes on x86_64 <stikonas>not looking forward to debugging it though :( <oriansj>despite being wath appears to be a very simple AST walker. <stikonas>oriansj: well, here it's not really tcc's fault <stikonas>its 64-bit support is still really really experimental <stikonas>despite us managing to build that step on riscv64 <oriansj>well yes, binary generation is very touchy <oriansj>and tcc for some reason never thought: hey lets output assembly and simplify the parts so that they are easier to debug <stikonas>well, yeah, if tcc was more readable, debugging would be easier too <oriansj>even outputting a custom llvm style assembly would have been a better option <stikonas>though part of it is that blood-elf debug info is very minimal <oriansj>wouldn't be an issue if TCC didn't do the rewrite the binary blob sort of logic (which is just a bad idea) <fossy>Googulator: regarding i915_sw_fence.patch, does our gcc really not support __aligned? <fossy>or maybe it doesn't support __aligned(4)? <stikonas>hmm, doesn't look like posix-runner can binaries compiled with tcc (not yet bootstrapped) <stikonas>and even non-bootstrap tcc can't produce a working tcc on x86_64 with meslibc... <stikonas>so I don't think I'll be able to get it working anytime soon... <oriansj>I guess I have my work cut out for me then <stikonas>if anything, it seems that there is more work... <fossy>stikonas: "work cut out for me" is an idiom for having something very difficult to do <fossy>which is a very backwards idiom lol <oriansj>I am starting to wonder if C compilers were originally designed as a prank that went too far. <oriansj>like, originally there were no structs and 5[a] was a reasonable thing to write <oriansj>and it started with a macros powerful enough to have C code that looks like Basic and a great deal of basic optimizations were explicitly defined away by default <oriansj>there is for, while and do; when just loop would have been enough, simpler to implement and more suitable for optimizations <oriansj>fall through case by default; weird variable shadowing rules and the lack of proper types out of the box (uint8_t, int16_t, etc) <Googulator>checking on my bare metal test systems, the kernel upgrade to 4.14 (and/or the replacement of the deblob script by a patch) had a pleasant side effect: Intel integrated GPUs now have a proper framebuffer console after kexec to Linux, no longer locked in 80x25 text mode <Googulator>it's a semi-prerequisite for the 4.14 upgrade - the actual base tarball isn't required, but the accompanying hygenie fixes are <Googulator>...seems like I'm too tired to spell hygiene correctly :) <fossy>Googulator: LGTM, i was just waiting for ci to run tbh :) <stikonas>Exaga: first of all where do you want to run bootstrap on? <stikonas>and i would suggest starting with userspace only bootstrap before you move to baremetal <stikonas>former requires root and latter uses linux namespaces <stikonas>this does not do anything with the kernel at all <stikonas>then you could try running the whole thing in qemu with ./rootfs --qemu <stikonas>that will prepare qemu image for bootstrapping on x86 BIOS VM and will build from tiny 200 byte seed to proper linux system <stikonas>as for baremetal bootstrap we have some support via ./rootfs --bare-metal <stikonas>but it right now it is limited to BIOS systems <Exaga>stikonas: hello and thanks for assisting me <Exaga>just so you know... i am very, very new to bootstrapping <stikonas>so as usual, it might be a bit overwhelming at first <Exaga>ok so to answer you... i have an initrd <Exaga>and i'm looking to turn it into a minirootfs - if that makes sense <Exaga>sorry if my terminology is not accurate <stikonas>but no worries either me or somebody else can try to help <Exaga>the initrd is created from someone else's bash script <Exaga>i am trying to teach myself how to do it myself <Exaga>so the bash script builds the initrd <stikonas>well, initrd itself is just a small archive (similar to tar but is usually cpio) <Exaga>but it is just bare installs of pkgs and nothing more <Exaga>do you want a link to this script so you may review it ? <Exaga>and this is how i build my initrd, using this script. of course it has been modifed to suit my own settings <stikonas>is trying to start with almost no binary code <Exaga>i am trying to create a minirootfs that boots <Exaga>i have a kernel and an initrd but no clue how to put these together <Exaga>and i am so green it's unreal so please feel free to advise and instruct accordingly <stikonas>neither mescc-tools nor live-bootstrap would be too helpful here... <Exaga>ok so now... familiar territory. i have a bootlader <Exaga>i'm working on the raspberry pi <Exaga>it's a closed source bootloader <stikonas>hmm, perhaps #raspberrypi channel exists <Exaga>yes there is the #raspberrypi channel <Exaga>but this is nothing to do with raspberry pi OS <stikonas>yeah, but still they'll know about how raspberry pi boots <Exaga>i am using slackware aarch64 OS <Exaga>and it's easy to load the kernel and initrd from them <stikonas>I dont' have raspberry pi myself, so a bit harder for me to help here... <Exaga>but i'm knife and forking my way to doing it entirely myself <Exaga>tbh stikonas i don't think the hardware or software is a concern <stikonas>well, generally, you just put whatever you want in initramfs <Exaga>i'm interested in learning the processes involved in going from nothing to bootable minirootfs <stikonas>well, on arm you can't do it from nothing in any case right now <stikonas>we have only finished x86 (not even x86_64) <Exaga>so i am in uncharted waters here then <stikonas>and the process is using lots of steps, some of them are old software <stikonas>yeah, if you want to start with nothing, then yes <stikonas>but if you have an existing linux system <Exaga>that's a good thing where slackware is concerned <stikonas>then you just need to compile some binaries that you want to put in minirootfs <Exaga>it is one of the few distros resisting systemd :D <Exaga>ok binaries... which ones are we talkling about please ? <Exaga>stikonas: sorry for laughing but your knowledge and experience is too advanced for mine <Exaga>this is the problem i come across often, because i really do know very little :D <stikonas>ok, maybe let's wait for somebody else here who can explain <Exaga>i'm sure yours is quite appropriate and well founded, it's my problem in that i do not understand you fully. because i have so little knowledge and experience of this topic <Exaga>so binaries such as bash, gawk, etc. <mihi>Exaga, my approach in learning (if you never did it): 1) Try to build static busybox and create a rootfs from it where you can chroot into it and the binaries work. <Exaga>mihi: i have heard about busybox and have built the pkg and installed it <mihi>2) try to get the rootfs bootable (still with only static busybox in it) <mihi>Exaga, don't take the binary package, but get the source code and compil it yourself <Exaga>i have looked at other initrootfs and tried to work out how they've done it <mihi>once you got that working, have a look at LFS (or PiLFS) which is a tutorial how to build your own compiler and system without resorting to tools like busybox <Exaga>ok that sounds like a plan mihi - a static busybox in a chroot <Exaga>it's like going somewhere in real life for the first time... and you don;t know how to get there and lose your way. that's basically where i am :D <Exaga>if i can learn the methods and ways of achieving success... this is what i am interested in undertaking <mid-kid>Watching an "emerge -e @system" firing off without a hitch is oddly satisfying. <mid-kid>I'll publish my instructions once it's done, though they're not great. I've kind of brute forced my way here. <Guest85>Hi, init.img run qemu but does not continue from here ./kaem.x86 <Guest85>img create this command ./rootfs.py -b -a x86 --cores 4 <mid-kid>Why aren't you using ./rootfs.py -q? <mid-kid>If you want to do it manually I recommend reading the python scripts to see what qemu options they use to boot. <Googulator>Guest85: -b is for bare-metal usage - it's possible to run a -b image in qemu, but you will have to manually pad it to the right size, because qemu has no option to expand the size of a raw disk; it will present a 256MB disk image as a 256MB disk to the guest OS <Googulator>unless you're actually running it on bare metal, of course <stikonas>Googulator: do we still support non builder-hex0 -b builds? <Googulator>& IIRC it's rather complicated, possibly requiring 2 disks <stikonas>but with Linux perhaps it just works from USB drive <stikonas>as UEFI bootstrap doesn't seems to be nowhere close to working <stikonas>(despite working far better than a year ago) <Googulator> 1. Take baremetal-vmlinuz/disk/initramfs and your kernel, boot using this. <Googulator> 2. Take baremetal-vmlinuz/disk/disk.img and put this on a writable storage medium." <Googulator>baremetal-vmlinuz/disk/disk.img is actually baremetal-vmlinuz/disk.img, and baremetal-vmlinuz/disk/initramfs doesn't actually exist <stikonas>hmm, there is disk.img that is not in disk directory <stikonas>need to check rootfs.py to see what it contains... <stikonas>yeah, qemu mode with custom kernel also doesn't work <Googulator>I've changed that a while ago, because putting the image in the directory it's created from caused a rudimentary version of the image to be included in itself <Googulator>i.e. in kernel bootstrap mode, init.img ended up containing an incomplete init.img as a file <Googulator>seems like the reference to initramfs is just bogus - disk.img and your kernel is all you need <stikonas>I thought kernel needs initramfs with all those seeds and sources <Googulator>the kernel should have everything needed to access the disk <Googulator>on UEFI, put the kernel on a fat32 flash drive, and boot it via UEFI shell or whatever UI your firmware provides, passing the correct root= parameter <Googulator>qemu mode uses "console=ttyS0 root=/dev/sda1 rootfstype=ext3 init=/init rw" as the kernel command line <Googulator>on UEFI bare metal, you'd therefore use "consoleblank=0 root=/dev/sda1 rootfstype=ext3 init=/init rw", adjusting sda1 as needed <stikonas>oh, most likely tcc built binaries don't work because posix-runner does not yet handle elf segments <stikonas>we need to load .data segment to the appropriate offset <stikonas>and we need to allocate one big continuous block of memory to hold all segments <stikonas>and then hope that there are only relative uses <mid-kid>There might be some steps that seem to fail or have to be ran multiple times, idk <mid-kid>If I do this again I would try a different approach <mid-kid>I kinda used an oversized hammer to solve the multilib problem <mid-kid>I think sam_ was interested, maybe he can laugh at me and tell me how to do better. <Googulator>before that, it was going OOM with --cores > 3 unless you used swap <Googulator>of course, the kernel now has access to 4GiB RAM instead of just under 3GiB <Googulator>that was actually the reason why I added swap support in the first place <mid-kid>I don't remember the cores value I used,maybe it was 4 <Googulator>so I could make use of my 4 cores in my bare metal test rig and 8 in qemu on my main machine <mid-kid>true but I wrote that part retroactively <sam_>mid-kid: looks not bad at all <rickmasters>Googulator: On a curl failure of openssl-1.1.1l, I was hoping for bash interactive, but got a kernel panic "Attempted to kill init!" <rickmasters>Googulator: I'm wondering if the bash trap is working of if that error is outside scope? <rickmasters>Hmm, it looks like the trap is installed in /init for Linux but maybe its lost when bash 5 is launched? I'll try setting it again... <rickmasters>I don't think I was getting bash interactive at the end of a build either. <rickmasters>fossy: would you mind testing a potential fix for your bare metal output issue? <rickmasters>fossy: Before generating image, go to builder-hex0/ and run git fetch; git checkout 5c8c8a8991cb8b4063ae7a02c76235a8ce38af83 <GoogulatorMobile>rickmasters: weird, I did get a trap prompt from a curl failure just yesterday <rickmasters>I just got a one time download checksum error for gnulib-8e128e.tar.gz <rickmasters>The bad gnulib-8e128e.tar.gz has an extra 14MB of garbage on the end.