[07:01] <elflng> ravage: not related. the server boots fine, its only the bullseye domu that doesnt work.
[07:25] <elflng> oke. i just changed the line to be 512mb memory instead of 256, and that works.
[07:25] <elflng> which is a little weird, as it shouldnt take that much memory.
=== cpaelzer_ is now known as cpaelzer
[08:16] <alkisg> It would be awesome if the kernel could directly use (initrd.squashfs + tmpfs overlay) instead of the typical initramfs. It would save both decompression time and the huge initial RAM usage, which drops after the initramfs is freed.
[08:18] <arraybolt3> You might be able to reduce the RAM usage by changing some option in your initramfs-tools config file.
[08:18] <arraybolt3> Can't remember at the moment, can find it soon.
[08:21] <alkisg> unmkinitramfs /boot/initrd.img . && du -sh . => 341M, if you add the 100+ MB that the kernel and initrd already use, it needs more than 500 MB nowadays. My idea above would allow it to boot with just the initial 100+ MB RAM.
[08:21] <alkisg> arraybolt3: grep dep /etc/initramfs-tools/initramfs.conf
[08:22] <arraybolt3> alkisg: Yes, that's it. Thanks!
[08:23] <arraybolt3> elflng: In /etc/initramfs-tools/initramfs.conf, change the 'MODULES=most' line to 'MODULES=dep' and then rebuild your initramfs files, that may significantly reduce their size and RAM requirements. This trick has gotten around a couple of out-of-memory errors in the past. You might also be able to change the compression mode to further reduce size, but I don't know if that will actually
[08:23] <arraybolt3> affect the in-memory size or not.
[08:24] <elflng> arraybolt3: thank you! is this also why the error is 'unable to find partition containing kernel' ?
[08:26] <elflng> trying it now with dep instead of most, we'll see if it loads and what the mem req is
[08:28] <elflng> nope, still fails with dep
[08:29] <elflng> (does xen-create-image use the initramfs-tools conf?)
[08:31] <arraybolt3> I personally have managed to boot a modern Linux distro with only 256 MB RAM, but that was Arch Linux 32 with an i486 kernel, which was specifically meant for low-RAM systems. I would imagine that Debian would give someone quite a bit more grief trying to make it fit in that small of a space.
[08:33] <elflng> debian buster works fine in 256
[08:33] <elflng> bullseye doesnt
[08:33] <elflng> (for xen images, that is)
[11:10] <elflng> xen-create-image isnt using the /etc/initramfs-tools config.
[11:10] <elflng> from the looks of it.
[11:23] <elflng> even with changing the creation script to make the initramfs with MODULES=dep, it still blows up at 256M
[12:35] <ahasenack> cpaelzer: bin:probert depends on bin:probert-network (https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#probert)
[12:36] <ahasenack> cpaelzer: somehow probert-network flipped between main and universe since jammy
[12:36] <ahasenack> https://launchpad.net/ubuntu/jammy/amd64/probert-network
[12:36] <ahasenack> and is now in universe again
[12:36] <ahasenack> https://launchpad.net/ubuntu/lunar/amd64/probert-network
[12:37] <ahasenack> I don't even understand how it was released in universe in kinetic, since the dependency was there and should have kept it in main
[13:42] <cpaelzer> ahasenack: so it is "just" a component mismatch but there is a MIR that approved it int he past?
[13:43] <ahasenack> cpaelzer: there must have been, the source moved to main in Eoan
[13:44] <ahasenack> I don't know how to track the binary publishing history across releases
[13:44] <ahasenack> focal: universe: https://launchpad.net/ubuntu/focal/amd64/probert-network
[13:45] <ahasenack> but briefly in main
[13:45] <ahasenack> jammy: universe, main, universe, main, then universe
[13:45] <ahasenack> it dances a lot
[13:45] <ahasenack> (jammy: https://launchpad.net/ubuntu/jammy/amd64/probert-network)
[13:50] <cpaelzer> ahasenack: https://bugs.launchpad.net/ubuntu/+source/probert/+bug/1830347
[13:50] -ubottu:#ubuntu-server- Launchpad bug 1830347 in probert (Ubuntu) "[MIR] probert as dependency of curtin and subiquity" [Undecided, Fix Released]
[13:51] <ahasenack> ok, eoan
[13:51] <ahasenack> so why is probert-network dancing around
[13:51] <cpaelzer> ahasenack: but I do not see it in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
[13:51] <cpaelzer> ahasenack: so is it actually a problem?
[13:51] <ahasenack> me neither
[13:51] <ahasenack> excuses says it is
[13:51] <ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#probert
[13:51] <ahasenack> generated earlier today
[13:51] <ahasenack> was the same yesterday
[13:52] <ahasenack> bin:probert-network is in lunar-proposed/universe
[13:52] <ahasenack>  probert-network | 0.0.20build5   | lunar/universe          | amd64, arm64, armhf, ppc64el, riscv64, s390x
[13:52] <ahasenack>  probert-network | 0.0.20build6   | lunar-proposed/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[13:52] <ahasenack> specifically build6
[13:53] <cpaelzer> probert source and binary are in main, and like you say the dependency is rather straight forward
[13:54] <ahasenack> mystery
[14:01] <cpaelzer> ahasenack: I resovled it and updated the bug for later reference
[14:01] <ahasenack> thx
=== smoser1 is now known as smoser
[17:53] <rbasak> lena_: o/  FYI I asked upstream in https://github.com/net-snmp/net-snmp/issues/476
[17:53] -ubottu:#ubuntu-server- Issue 476 in net-snmp/net-snmp "SNMP request fails to resolve hostname if DNS entry is longer than 64 characters" [Closed]
[17:55] <lena_> Thanks, I'll keep an eye on it
[18:55] <athos> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#postgis says there is a binary package in proposed which is a leftover from the previous version (which never migrated to the release pocket). I am wondering if it will be cleaned up eventually by some archive automation or if I will need to request its (manual) removal
[19:20] <ahasenack> kanashiro[m]: is https://bugs.launchpad.net/ubuntu/+source/bsfilter/+bug/1972040 a dupe of https://bugs.launchpad.net/ubuntu/+source/ruby-sdbm/+bug/1979128 perhaps?
[19:20] -ubottu:#ubuntu-server- Launchpad bug 1972040 in bsfilter (Ubuntu) "bsfilter on jammy needs ruby-sdbm" [Undecided, Confirmed]
[19:20] -ubottu:#ubuntu-server- Launchpad bug 1979128 in bsfilter (Ubuntu Jammy) "[SRU] ruby-sdbm should be backported to jammy" [Undecided, In Progress]
[19:22] <kanashiro[m]> ahasenack: it seems so
[19:23] <ahasenack> I'll mark it as such
[19:26] <ahasenack> kanashiro[m]: any particular reason the bsfilter depends on ruby-sdbm is versioned in lunar (>= 1.0.0-1) but not versioned in the jammy sru?
[19:27] <ahasenack> I know the package didn't exist in jammy before, and you backported the correct version, so it will work
[19:27] <ahasenack> but I'm comparing the change from the SRU to the change in devel
[19:28] <ahasenack> oh, I guess you mentioned this in comment #12
[19:29] <ahasenack> ok, all good, it was discussed