[02:18] I have an ubuntu server box that i am trying to use for GPU accelerated pentesting, and i recently got a new mb, psu, cpu, and everything new except for the SSD with ubuntu server 22.04.1 installed. when i tried to put the drive into the new board with sata3 (I've tried all slots), it gives me the classic "please insert proper boot device or insert boot medium into device", or something very similar, since i am typing this message o [02:20] so i still cant get it to boot with the new board and everything [02:24] if anyone is there thinking or reading please aknowledge so i am not waiting here for nothing [02:58] perhaps your BIOS boot order is not picking up the drive as an available boot drive [03:10] im sur eyou know where im going with this, but are there publically available logs for this channel? [03:10] *sure [03:58] Liver_K: https://irclogs.ubuntu.com/2022/09/26/%23ubuntu-server.html [04:04] thanks [12:34] I'm trying to perform an installation using the ubuntu 22.04.1 live server iso on a VM but no matter how many times I try, the installer gets stuck on fetching ssh keys. I tried using my github username and I tried using my launchpad username. I installed ubuntu server using the same iso about 15 times durint the last month. [12:34] what could be the issue? networking seems to be working. [12:56] network MTU? [13:10] rbasak: (Missed your last messages on Friday:) We don't control metadata generation specifically, Artifactory does it for us. We would have to remove debs from Artifactory to remove them from metadata (which would also remove them from `pool/`, which could lead to apt failures while the old lists are cached somewhere). [13:12] I also realised over the weekend that Britney specifically handles these lists: it iterates and creates a "latest" set of packages (which is what it uses for dependency resolution) but also stores every package it finds separately. We use this for our dependency resolution scripting, so I know it works! [13:13] And we do have some use cases for multiple deb versions at a time: if we're rolling a new version of a package to the fleet, for example, we need hosts to be able to install either the new or the old package, depending on their rollout status. [13:19] frickler: VPS provider's DHCP server is giving out the correct IP + other parameters for every VM they supply [13:21] actually I got the installer a bit further this time where it managed to fetch the keys but right after I confirmed the keys to be added, the installer crashed. I tried looking around in the logs but I couldn't find anything obvious. [13:42] Odd_Bloke: we have had many bugs in debootstrap before w.r.t. handling multiple suites. I believe in a separate case Laney did "inteligent" merge of the suites to construct a merged one, with highest version of a the thing listed first. Any improvements to make things better would be welcome. I wonder what you use to publish your merged suite. I thougth for example reprepro already [13:42] correctly orders the highest version of the given package first, even if multiple are published simultaniously? It would be nice for debootstrap to be smarter and consider all the things. [13:42] or even better manage to actually debootstrap out of `lucid lucid-security lucid-updates` [13:42] without much problems. [13:43] Odd_Bloke: can you please open a bug report, and outline test case, example, expectations, reality and your proposed solutions? i will ponder on it, and see if we can get it into upstream debian. [13:54] xnox: Will do, thank you! [13:54] znf: thank you [13:56] xnox: We're using Artifactory's Debian plugin: it appears to append new artifacts to the end of the metadata, without reordering previously-generated stanzas. [14:06] Odd_Bloke: cool. === scoobydoo_ is now known as scoobydoo [18:37] xnox: Filed https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1990856 with details, provided a reproducer and a patch. LMK if there's anything else you'd like! [18:37] Launchpad bug 1990856 in debootstrap (Ubuntu) "Does not consider all versions in Packages files" [Undecided, New] [19:02] ahasenack: heh, I found that volatildap's dep8 test on armhf is suffering from the same problem that's affecting django-auth-ldap [19:02] interesting [19:02] because we're both trying to tweak apparmor during the test [19:02] and I think the armhf containers are unprivileged [19:03] sigh... [19:03] armhf containers are "different", but I don't think privilege is it [19:03] apparmor works just fine in unprivileged containers [19:03] can you load/unload profiles normally? [19:03] afaik yes, did it this week even with samba apparmor profiles inside jammy lxd containers (unprivileged) [19:04] hm, interesting. I did a quick search and a bunch of results regarding unprivileged containers showed up [19:04] bring an unprivileged container up, install slapd, then try apparmor operations on it [19:04] load, unload [19:04] on x86_64 [19:04] (your host) [19:04] should work just fine [19:05] that makes sense [19:05] the test is passing on all other architectures [19:05] so yeah, probably something else. [19:05] armhf is using 32bit containers on arm64 hosts [19:05] so the kernel is 64bits [19:06] things can get tricky with apparmor there perhaps [19:06] fair enough [19:06] but what is failing, disabling apparmor? Removing the slapd profile? Is it even confined when it starts? [19:06] removing the profile [19:06] ERROR: /sbin/apparmor_parser: Unable to remove "/usr/sbin/slapd". Permission denied; attempted to load a profile while confined? [19:06] perhaps before trying that, check if it's confined? [19:07] although I think I do that check in that volatildap test [19:07] and, well, it must have passed back then [19:09] I'm thinking about disabling apparmor entirely (assuming it works) [19:09] this would be a radical solution, but we really don't need apparmor in this test