| 11 Mar 2025 |
 @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 | 18:05:10 |
| @elvishjerricco:matrix.org | "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:matrix.org | it's weird | 18:06:07 |
| @elvishjerricco:matrix.org | systemd-boot or systemd-stub will pass the initrd via a custom uefi protocl | 18:06:22 |
| @elvishjerricco:matrix.org | ... 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:matrix.org | yea.... | 18:07:27 |
| @elvishjerricco:matrix.org | certainly the issue must have to do with the massive initrd; that's such a strange and blatant variable | 18:08:22 |
| @elvishjerricco:matrix.org | 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:matrix.org | unless it wants to allocate that close to the 4G boundary I guess? | 18:08:54 |
| @elvishjerricco:matrix.org | no idea why it would | 18:09:01 |
| @elvishjerricco:matrix.org | i mean that might actually just be randomness or board specificness | 18:10:46 |
| @elvishjerricco:matrix.org | "EFI says to allocate here" and systemd-boot says "but I WANTED it behind there!" | 18:11:28 |
| @elvishjerricco:matrix.org | 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:matrix.org | yes | 18:16:15 |
| @elvishjerricco:matrix.org | so why should 358M be hard to allocate below 4G? | 18:16:28 |
| aloisw | It just asks the firmware to do that and it fails, ask the firmware I guess. | 18:16:48 |
| @elvishjerricco:matrix.org | (unless the decompressed size is huge) | 18:16:51 |
| @elvishjerricco:matrix.org | wait not it doesn't decompress | 18:17:05 |
| aloisw | Systemd-boot does not decompress the initrd and I think the kernel alread | 18:17:07 |
| @elvishjerricco:matrix.org | * wait no it doesn't decompress | 18:17:09 |
| aloisw | * Systemd-boot does not decompress the initrd and I think the kernel already has virtual memory at the point it does. | 18:17:18 |
| @elvishjerricco:matrix.org | regardless, the bug on nixos's side is how the hell we made a 358M initrd | 18:18:00 |
| @elvishjerricco:matrix.org | god dammit nvidia firmware | 18:41:01 |
| @elvishjerricco:matrix.org | K900: do you expect that putting your nvidia modules / firmware in initrd would make it 358M? Because that's what happened | 18:41:35 |
| @elvishjerricco:matrix.org | I don't know why it only happened for them on unstable, but I suspect they left some info out | 18:42:19 |
