| elflng | ravage: not related. the server boots fine, its only the bullseye domu that doesnt work. | 07:01 |
|---|---|---|
| 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. | 07:25 |
| === cpaelzer_ is now known as cpaelzer | ||
| 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:16 |
| 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:18 |
| 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:21 |
| arraybolt3 | alkisg: Yes, that's it. Thanks! | 08:22 |
| 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:23 |
| elflng | arraybolt3: thank you! is this also why the error is 'unable to find partition containing kernel' ? | 08:24 |
| elflng | trying it now with dep instead of most, we'll see if it loads and what the mem req is | 08:26 |
| elflng | nope, still fails with dep | 08:28 |
| elflng | (does xen-create-image use the initramfs-tools conf?) | 08:29 |
| 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:31 |
| elflng | debian buster works fine in 256 | 08:33 |
| elflng | bullseye doesnt | 08:33 |
| elflng | (for xen images, that is) | 08:33 |
| elflng | xen-create-image isnt using the /etc/initramfs-tools config. | 11:10 |
| elflng | from the looks of it. | 11:10 |
| elflng | even with changing the creation script to make the initramfs with MODULES=dep, it still blows up at 256M | 11:23 |
| ahasenack | cpaelzer: bin:probert depends on bin:probert-network (https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#probert) | 12:35 |
| 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:36 |
| 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 | 12:37 |
| cpaelzer | ahasenack: so it is "just" a component mismatch but there is a MIR that approved it int he past? | 13:42 |
| ahasenack | cpaelzer: there must have been, the source moved to main in Eoan | 13:43 |
| 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:44 |
| 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:45 |
| 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:50 | |
| 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:51 |
| 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:52 |
| cpaelzer | probert source and binary are in main, and like you say the dependency is rather straight forward | 13:53 |
| ahasenack | mystery | 13:54 |
| cpaelzer | ahasenack: I resovled it and updated the bug for later reference | 14:01 |
| ahasenack | thx | 14:01 |
| === smoser1 is now known as smoser | ||
| 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:53 | |
| lena_ | Thanks, I'll keep an eye on it | 17: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 | 18:55 |
| 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:20 | |
| kanashiro[m] | ahasenack: it seems so | 19:22 |
| ahasenack | I'll mark it as such | 19:23 |
| 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:26 |
| 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:27 |
| ahasenack | oh, I guess you mentioned this in comment #12 | 19:28 |
| ahasenack | ok, all good, it was discussed | 19:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!