| 11 Mar 2025 |
 aloisw | Well 350M not fitting into memory after decompression sounds plausible. | 18:00:44 |
 ElvishJerricco | plausible for the 4G boundary, yes | 18:01:06 |
| ElvishJerricco | I wouldn't say likely | 18:01:11 |
| ElvishJerricco | it's like right on the edge | 18:01:14 |
| ElvishJerricco | when do you get a more than 10x compression ratio? | 18:01:50 |
| aloisw | It has to be contiguous memory below 4G. | 18:01:59 |
| ElvishJerricco | oh so it might be putting the uncompressed initrd near-to-but-not-right-at the boundary? | 18:02:30 |
| ElvishJerricco | close enough that it pretty much always fits, unless you have a massive initrd? | 18:02:47 |
| aloisw | In reply to @elvishjerricco:matrix.org
when do you get a more than 10x compression ratio? I have no idea what got put in their initrd, it's so out of the normal that it's plausible that it either compresses very well or not at all. (Really it should be figured out what got into there and the bug fixed.) | 18:03:36 |
| ElvishJerricco | well yea, like I said, there's two bugs here. An initrd like that should obviously not happen, but also systemd-boot shouldn't die over it | 18:04:26 |
| ElvishJerricco | oh I have a suspicion | 18:04:35 |
| ElvishJerricco | they used scripted initrd and added a *Commands fragment that pulled in some super massive package because scripted initrd pulls in whole closures | 18:05:10 |
| ElvishJerricco | "super massive" that's not even that massive | 18:05:35 |
| aloisw | In reply to @elvishjerricco:matrix.org
close enough that it pretty much always fits, unless you have a massive initrd? I have no idea where it puts the stuff (probably it just uses the UEFI allocator), but most machines don't have contiguous physical memory and who knows where the compressed initrd fragmented it more. | 18:05:44 |
| aloisw | In reply to @elvishjerricco:matrix.org
they used scripted initrd and added a *Commands fragment that pulled in some super massive package because scripted initrd pulls in whole closures Why did it only blow up on 25.05 then? | 18:06:07 |
| ElvishJerricco | it's weird | 18:06:07 |
| ElvishJerricco | systemd-boot or systemd-stub will pass the initrd via a custom uefi protocl | 18:06:22 |
| ElvishJerricco | ... yea good point nevermind | 18:06:37 |
| aloisw | In reply to @elvishjerricco:matrix.org
systemd-boot or systemd-stub will pass the initrd via a custom uefi protocl Oh wait, it's only the kernel that decompresses it. Ignore what I said then. | 18:07:10 |
| ElvishJerricco | yea.... | 18:07:27 |
| ElvishJerricco | certainly the issue must have to do with the massive initrd; that's such a strange and blatant variable | 18:08:22 |
| ElvishJerricco | but I have no idea why | 18:08:26 |
| aloisw | (Unless for some reason it fails to do a contiguous allocation of the 358.5 megabytes, but that's not that much from remote speculation.) | 18:08:27 |
| ElvishJerricco | unless it wants to allocate that close to the 4G boundary I guess? | 18:08:54 |
| ElvishJerricco | no idea why it would | 18:09:01 |
| ElvishJerricco | i mean that might actually just be randomness or board specificness | 18:10:46 |
| ElvishJerricco | "EFI says to allocate here" and systemd-boot says "but I WANTED it behind there!" | 18:11:28 |
| ElvishJerricco | sidenote, I'm extremely annoyed by andre4ik3's comment claiming to show the answer clearly when it's anything but clear | 18:13:13 |
| aloisw | If xmalloc_initrd_pages is the correct function, then it asks the firmware to allocate anywhere below 4G: https://github.com/systemd/systemd/blob/7fa3b5018bfffa176c77a2a5794dce792eebadcb/src/boot/util.h#L111-L115 | 18:15:59 |
| ElvishJerricco | yes | 18:16:15 |
