[00:01] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Kinetic Final] has been updated (20221018.1) [00:01] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Kinetic Final] has been updated (20221018) [00:02] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Kinetic Final] has been updated (20221018) [00:02] bdmurray: ^^ [00:03] thanks! [00:04] jawn-smith: also ^^ [00:28] vorlon: I'm not seeing an updated 20221018.1 image here https://cdimage.ubuntu.com/daily-live/ [00:40] that's getting sorted it was an issue with the us servers [05:14] -queuebot:#ubuntu-release- Unapproved: bully (kinetic-proposed/universe) [1.4.00-2 => 1.4.00-2ubuntu1] (no packageset) [05:15] -queuebot:#ubuntu-release- Unapproved: accepted bully [source] (kinetic-proposed) [1.4.00-2ubuntu1] [05:15] -queuebot:#ubuntu-release- Unapproved: mdk3 (kinetic-proposed/universe) [6.0-8 => 6.0-8ubuntu1] (no packageset) [05:16] -queuebot:#ubuntu-release- Unapproved: accepted mdk3 [source] (kinetic-proposed) [6.0-8ubuntu1] [05:16] -queuebot:#ubuntu-release- Unapproved: mdk4 (kinetic-proposed/universe) [4.2-3 => 4.2-3ubuntu1] (no packageset) [05:17] -queuebot:#ubuntu-release- Unapproved: accepted mdk4 [source] (kinetic-proposed) [4.2-3ubuntu1] [06:21] RAOF: I know it's not tuesday, but would you have a chance of looking at the thermald backport-sru? [06:22] tjaalton: I did, this morning! [06:22] (It is NA tuesday) [06:23] https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1981087/comments/9 [06:23] -ubottu:#ubuntu-release- Launchpad bug 1981087 in thermald (Ubuntu Jammy) "thermald prematurely throttling GPU" [Undecided, In Progress] [06:26] tjaalton: Particularly: can we sensibly get the fixes we want without *also* taking the refactorings? [06:26] tjaalton: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1981087/comments/9 [06:26] -ubottu:#ubuntu-release- Launchpad bug 1981087 in thermald (Ubuntu Jammy) "thermald prematurely throttling GPU" [Undecided, In Progress] [06:29] RAOF: oh, I missed that, thanks :) [06:29] I'll let koba answer those [06:31] oh he did [06:37] Yeah, just saw. [06:37] When I went looking for the link to send you :) [06:53] tjaalton: I guess actually that the ur-problem here is that the SRU bugs aren't very clear what the actual thermald-wrongness is, and so it's not clear what the fix is, and so it's not clear why all the diff is necessary. [06:53] Which is something you probably could have helped with 😉 [06:55] I've tried.. [06:55] 😃 [06:56] the first attempt of an sru was 2.4.9 with a patch that basically synced it to 2.5.1 [06:56] which is useless [06:56] Yes! [06:57] We *do* plan to have some form of "So, you sometimes need to upload an SRU. Here's what's important" training at the sprint. [06:57] Which continues to be a good idea :) [06:59] to be fair, upstream git history doesn't directly describe any of the bugs, so it's more like "do stuff! things get better!" [07:00] 🤷‍♀️ [07:00] intel is good at that [07:00] intel-graphics-compiler git history is 50% of commits like "changes in code" [07:04] Mmm, helpful! [07:09] in this case the most of the new code in 2.5 is due to this pr https://github.com/intel/thermal_daemon/pull/359 [07:09] -ubottu:#ubuntu-release- Pull 359 in intel/thermal_daemon "Thermald 2 5 merge" [Merged] [07:09] and then the release notes say "- Support of new thermal table for Alder Lake" [07:11] so I'd say the changes for bug 1983235 aren't cherry-pickable [07:11] -ubottu:#ubuntu-release- Bug 1983235 in thermald (Ubuntu Jammy) "ADL: Support for new thermal table" [Critical, In Progress] https://launchpad.net/bugs/1983235 [07:11] I mean that there's no single commit to just add that, the refactorings are part of it === guiverc2 is now known as guiverc [08:16] o/ [08:27] Aaargh, only now respinning raspi images [08:35] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Kinetic Final] has been updated (20221019) [08:35] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Kinetic Final] has been updated (20221019) [08:43] yay! Bringing up the rear ... as usual :) [08:43] -queuebot:#ubuntu-release- Builds: Ubuntu Core amd64 edge [Kinetic Final] (20221019) has been added [08:53] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.33 => 1.187.34] (core, kernel) [09:09] * utkarsh2102 waves \o [09:11] Argh, that core again, need to see why it appears under kinetic. Checking in a bit [10:32] hmmm, no Nvidia tests run yet, let me try that [10:56] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Kinetic Final] has been updated (3280820635) [11:24] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.34] [11:40] hm, okay, seems to work correctly, but weirdly I did not see the enrol mok screen this time [12:29] Ok, this time it worked perfectly [12:37] sil2100: I'll try one as well :) [12:46] do we have a build planned or in progress for live-server? Picking up the for LP: #1993257 would be preferable [12:46] -ubottu:#ubuntu-release- Launchpad bug 1993257 in Ubuntu on IBM z Systems "Installer ui crash on kinetic on s390x (but probably not limited to)" [High, Fix Committed] https://launchpad.net/bugs/1993257 [13:18] dbungert: a new one? [13:19] When did the fix land? [13:19] * sil2100 checks the build [13:19] s/build/bug [13:21] yesterday [13:24] Okay, so hm, we didn't plan on server respins, but this feels important [13:26] paride: heeey! You busy? [13:27] hey [13:28] (joined) [13:38] sil2100: so, we seem to have nvidia issues. Again. :-( [13:45] How? [13:45] Worked fine for me in offline mode [13:45] What's up? [13:45] I need more details than that, don't leave me on a cliffhanger like this [14:01] sil2100: sorry, I *just* broke my desktop system by trying out stuff hence the cliffhanger. [14:01] Basically the 515 driver is broken for some systems with 30** cards that connect via HDMI [14:01] tjaalton: [14:02] whoops [14:02] Ok, no tseliot? [14:02] klebers, apw: ^ [14:03] schopin: can you fill in out a bug for this? [14:03] Can you get some logs on that one? [14:04] sil2100: someone already beat me to it, and the bug is solved upstream, but in their 520 release [14:04] Sorry, I'm doing it all from memory as I had to switch systems [14:04] sil2100: I've poked him to join again :) [14:05] Okay, I see your bugs on the tracker [14:06] https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-515/+bug/1993041 [14:06] -ubottu:#ubuntu-release- Launchpad bug 1993041 in nvidia-graphics-drivers-515 (Ubuntu) "nvidia-driver-515 (515.76-0ubuntu0.22.04.1): blank screen after boot, can't log in" [Undecided, New] [14:11] schopin: I did point out that 515 bug on its SRU bug, but it still got let into the archive :/ [14:11] What? That's... unfortunate. [14:11] sil2100: Nasty bug in software-properties, probably affecting Lubuntu, Kubuntu, and Ubuntu Studio for people with Broadcom Wifi chipsets: bug 1993370 [14:11] -ubottu:#ubuntu-release- Bug 1993370 in software-properties (Ubuntu) "Cannot install proprietary Broadcom WiFi drivers on Ubuntu Studio Kinetic" [Undecided, New] https://launchpad.net/bugs/1993370 [14:12] schopin: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-515/+bug/1990835/comments/2 [14:12] -ubottu:#ubuntu-release- Launchpad bug 1990835 in nvidia-graphics-drivers-515 (Ubuntu Jammy) "Update the 515 (UDA) NVIDIA drivers in Bionic, Focal, Jammy" [High, Fix Released] [14:20] RikMills: grrr [14:20] Guess the kernel team didn't notice [14:20] apw: ^ [14:28] The software-properties bug raised earlier looks like bug 1969460 [14:28] -ubottu:#ubuntu-release- Bug 1969460 in software-properties (Ubuntu Jammy) "software-properties-gtk crashed with TypeError in on_driver_selection_changed(): Expected a string or a pair of strings" [High, Fix Released] https://launchpad.net/bugs/1969460 [14:29] just a different line number for the crash though [14:29] Eickmeyer[m]: eeek... [14:30] sil2100: Yeah, not sure how that one snuck in there. [14:30] Eickmeyer[m], bdmurray: I suppose if this was something we released jammy with, guess we didn't consider it release blocking? [14:30] Need a moment to read the description [14:30] (in detail) [14:30] (in meetings now) [14:33] its the same function in the gtk and qt frontend [14:34] I'll upload a fix [14:39] bdmurray: Thanks! [14:43] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Kinetic Final] has been updated (20221019) [14:43] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Kinetic Final] has been updated (20221019) [14:43] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Kinetic Final] has been updated (20221019) [14:43] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Kinetic Final] has been updated (20221019) [14:45] I appreciate it [14:46] -queuebot:#ubuntu-release- Unapproved: software-properties (kinetic-proposed/main) [0.99.27 => 0.99.27.1] (core) [15:03] There is also bug 1990592 for nvidia users who don't install the proprietary driver [15:03] -ubottu:#ubuntu-release- Bug 1990592 in xserver-xorg-video-nouveau (Ubuntu) "Desktop environment fails to start" [Undecided, New] https://launchpad.net/bugs/1990592 [15:57] fheimes58889454: ^ above build should have the fix we did for bug 1993257 [15:57] -ubottu:#ubuntu-release- Bug 1993257 in Ubuntu on IBM z Systems "Installer ui crash on kinetic on s390x (but probably not limited to)" [High, Fix Committed] https://launchpad.net/bugs/1993257 [16:13] bdmurray, I think I understand the failing jammy -> kinetic upgrade test now [16:15] the trigger condition is: start with jammy desktop but *without* firefox installed (neither the snap nor the package, which in jammy is not a dependency of ubuntu-deskop) [16:16] when doing the upgrade there will be a moment when systemd is upgraded to the Kinetic version, which does *not* include systemd-resolved (now split out in a separate systemd-resolved binary package) [16:16] in this moment name resolution is broken [16:17] if at this point firefox is installed (in kinetic it's a dependency of ubuntu-server, so it will be installed at some point), it will try to install the firefox snap, and fail because of lack a resolver [16:19] paride: there should be an SRU which will add firefox to the ubuntu desktop seed in jammy [16:19] I'm not sure if you meant the firefox deb or snap [16:19] the firefox *deb* is installed as a dependency of ubuntu-desktop, and that will bring in the snap [16:20] if that happens in the "broken network" window between the upgrade of systemd and the installation of systemd-resolved, it will fail [16:20] that's what happens in the automated upgrade tests [16:21] and yes a SRU adding a ubuntu-deskop -> bin:firefox dependency in jammy would work [16:25] bug 1992688 is the one of which I'm thinking [16:25] -ubottu:#ubuntu-release- Bug 1992688 in ubuntu-meta (Ubuntu Jammy) "firefox deb not installed" [High, In Progress] https://launchpad.net/bugs/1992688 [16:28] -queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (kinetic-proposed/main) [43.0-1ubuntu1 => 43.0-1ubuntu2] (ubuntu-desktop) [16:28] -queuebot:#ubuntu-release- New: accepted rpi-lgpio [source] (kinetic-proposed) [0.3-0ubuntu1] [16:30] -queuebot:#ubuntu-release- New binary: rpi-lgpio [amd64] (kinetic-proposed/none) [0.3-0ubuntu1] (no packageset) [16:36] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-515 (kinetic-proposed/restricted) [515.76-0ubuntu1 => 515.76+really.515.65.01-0ubuntu1] (i386-whitelist) [16:47] tseliot: ^ thanks [16:48] :) [16:48] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-515 [source] (kinetic-proposed) [515.76+really.515.65.01-0ubuntu1] [16:52] tseliot, apw: ^ does this also require an LRM respin? [16:52] Yes, I notified apw [16:54] bdmurray: Hey there, we would like a respin of the desktop iso to include a fix to gnome-initial-setup, and gnome-calendar bug fix release while we're at it. [17:03] calendar is a nice to have and not critical to the install, 0 day SRU would be understandable if you don't want it [17:03] what's the gnome-initial-setup one then? [17:03] the initial setup is to fix the default of the 'sent metrics' option [17:03] no choice is selected which we though a visual issue [17:04] the g-i-s issue is logged here: https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1993495 [17:04] -ubottu:#ubuntu-release- Launchpad bug 1993495 in gnome-initial-setup (Ubuntu) "No choice selected on the 'Help improving Ubuntu' screen" [Low, Confirmed] [17:04] but turns out it also means the default choice went wrong [17:04] the low importance comes from before we realized the default value was wrong [17:05] and I need to go away from the computer so from IRC, I will be on mattermost if you need more input from me [17:08] bdmurray: in case it helps, the default is to not send a report to Canonical, which would skew our data since it has historically been opt-out rather than opt-in [17:09] the default being used currently, with no button selected [17:09] hellsworth: this seems fine to me but I'd like to double check with vorlon or sil2100 [17:10] sounds good [17:15] -queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (kinetic-proposed) [43.0-1ubuntu2] [17:15] hello sru team, this should be ready to release if anyone gets a chance: https://bugs.launchpad.net/openvswitch/+bug/1985062 [17:15] -ubottu:#ubuntu-release- Launchpad bug 1985062 in openvswitch "ovsdbapp ssl send socket error" [Undecided, New] [17:20] hellsworth: g-i-s was accepted [17:22] thank you [17:22] how do you feel about accepting gnome-calendar too? [17:24] bdmurray: ^ [17:24] hellsworth: I think the gnome-calendar feels like more of a 0-day SRU [17:25] Right now we only accept installer-images or first-boot-experience impacting issues only [17:25] ok that makes sense. thanks sil2100 [17:26] when will you respin the desktop iso? [17:28] once we have l-r-m available [17:33] ok thanks [17:48] -queuebot:#ubuntu-release- New: accepted tcpbench [sync] (kinetic-proposed) [1.01-1] [17:49] -queuebot:#ubuntu-release- New: accepted rpi-lgpio [amd64] (kinetic-proposed) [0.3-0ubuntu1] [17:50] -queuebot:#ubuntu-release- New binary: tcpbench [amd64] (kinetic-proposed/none) [1.01-1] (no packageset) [17:50] -queuebot:#ubuntu-release- New binary: tcpbench [ppc64el] (kinetic-proposed/none) [1.01-1] (no packageset) [17:50] -queuebot:#ubuntu-release- New binary: tcpbench [arm64] (kinetic-proposed/none) [1.01-1] (no packageset) [17:50] -queuebot:#ubuntu-release- New binary: tcpbench [s390x] (kinetic-proposed/none) [1.01-1] (no packageset) [17:52] -queuebot:#ubuntu-release- New binary: tcpbench [armhf] (kinetic-proposed/none) [1.01-1] (no packageset) [17:53] -queuebot:#ubuntu-release- New: accepted tcpbench [amd64] (kinetic-proposed) [1.01-1] [17:53] -queuebot:#ubuntu-release- New: accepted tcpbench [armhf] (kinetic-proposed) [1.01-1] [17:53] -queuebot:#ubuntu-release- New: accepted tcpbench [s390x] (kinetic-proposed) [1.01-1] [17:53] -queuebot:#ubuntu-release- New: accepted tcpbench [arm64] (kinetic-proposed) [1.01-1] [17:53] -queuebot:#ubuntu-release- New: accepted tcpbench [ppc64el] (kinetic-proposed) [1.01-1] [17:57] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (kinetic-proposed) [0.99.27.1] [18:08] apw: Pinging you here too. nvidia-graphics-drivers-515 in -proposed fixed my nvidia related issues [18:14] jawn-smith: your issue was slightly different that schopin's though right? [18:16] jawn-smith: also this ubuntu-image is for an SRU right? [18:17] bdmurray: Yes, my issue was different from the one schopin was experiencing [18:17] The ubuntu-image in kinetic-proposed you mean? [18:18] or I suppose it's in the Unapproved queue [18:18] jawn-smith: its in the kinetic unapproved queue but would go to -proposed yes [18:18] It's not urgent, if that's what you're asking [18:18] It could be a 0-day SRU [18:19] It's probably safest to wait until all the kinetic preinstalled images are ready [18:19] 0-day means it should be in -updates immediately as opposed to wait 7 days like a regular SRU [18:21] It fixes 4 different LP bugs [18:21] Would I need to fill out the SRU template for all of those? [18:25] yes [18:30] I figured [18:31] Let me sync with sil2100 on whether or not this needs to exist in kinetic at all [18:31] might be easier to reject and upload to ll later [18:31] jawn-smith: which release images in kinetic are build with ubuntu-image today? [18:31] raspi ones [18:31] ok [18:32] I don't want to jeopardize those by accepting this into the release pocket [18:32] I was thinking of doing an SRU of this, so leaving it in the queue (or even accepting to -proposed) and then verifying and releasing as a normal SRU + forward copying to ll [18:33] JFYI, I'll review (and hopefully accept) one more package from Dave to kinetic [18:33] NEW package that is [18:36] sil2100: ftr software-properties is seeded everywhere so this looks like we should divert it to -updates and not respin the world for it alone [18:37] vorlon: yeah, +1. Originally I wanted to 0-day SRU it as well, but then when I thought we'll have to 'respin the world' anyway, I considered taking it in (as it does fix an installation issue) [18:38] So it's fine, we'll have less fixes, but I think this is good as otherwise we might not be able to get everything tested on time [18:39] We'd need to release note the issue [18:39] bdmurray: ^ do you know if we have anything already? [18:40] A release note for software-properties - no [18:45] -queuebot:#ubuntu-release- New: accepted micropython-mpremote [source] (kinetic-proposed) [0.4.0-0ubuntu1] [18:47] -queuebot:#ubuntu-release- New binary: micropython-mpremote [amd64] (kinetic-proposed/none) [0.4.0-0ubuntu1] (no packageset) [19:02] sil2100: sorry I did not push harder on that nvidia issue. My Kubuntu Focus with a RTX 3060 is on 510 and I did not want to mess with its custom setup to confirm. then got sidetracked [19:02] jawn-smith, thanks for that data point. [19:04] apw: how can I track where we are wrt lrm publication? [19:05] vorlon, the ckt unstable PPA has the primaries, its -ps has the secondaries. once they are built there you will see them in the primary signing PPA. [19:05] vorlon, this is all bounded by the PPA publisher performance which is horrible. [19:05] uh full urls please [19:05] https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+packages?field.name_filter=restricted-modules&field.status_filter=published&field.series_filter=kinetic [19:06] https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable-ps/+packages?field.name_filter=restricted-modules&field.status_filter=published&field.series_filter=kinetic [19:06] apw: and you're around to drive the publication through to the archive? [19:06] vorlon, yes, i'll monitor it all until it hits -proposed [19:06] apw: k I can't see that second link [19:06] but useful to have it in case I need to somehow tag someone else who can! [19:06] RikMills: no worries, we need to improve our processes that we don't miss such reports ourselves [19:07] apw: once it hits proposed are we trying to get this landed to release asap or is there other testing you intend to happen there before we make that decision? [19:07] vorlon, does giving you "access" help at all ? [19:07] apw: i.e.: can we stage the britney hints [19:08] apw: it helps in case you get hit by a bus in the next hour [19:08] vorlon, i think we want someone to test installing at least one of them, though the changes a minimal [19:08] ok [19:08] vorlon, heh, at least i am not leaving the house but yes. [19:08] apw: I've seen Harry Potter, I know busses do funny things in England [19:09] any objections to that install testing happening in parallel to proposed-migration running? [19:09] vorlon, fair point :) [19:09] vorlon, no, as if they are bad (and i don't expect them to be) then we have to redo them and where they are is of little import i guess. [19:09] apw: fwiw you gave me access to download packages from that ppa but it still doesn't give me access to see the above url :) [19:10] apw: ok. would you mind staging the britney hints? [19:10] the unblock hints [19:10] ack [19:10] ta [19:10] i should have the requisite versions etc when i make the signing incantations [19:17] sil2100: well, I am pondering on applying for core-dev in the next cycle, so not following up does that no favours :/ [19:17] but you learn from these things I guess [19:18] -queuebot:#ubuntu-release- Unapproved: argyll (kinetic-proposed/universe) [2.3.1+repack-1 => 2.3.1+repack-1ubuntu1] (ubuntustudio) [19:20] ^ wut? $ seeded-in-ubuntu argyll [19:20] argyll's binaries are not seeded. [19:21] ginggs: I see it in ubuntustudio's photography seed [19:22] seeded-in-ubuntu doesn't actually grab all seeds, I'm not sure what its rules are [19:22] but e.g. it doesn't report on 'supported' though by definition everything there is seeded (and defines main) [19:23] it goes by http://qa.ubuntuwire.org/ubuntu-seeded-packages/seeded.json.gz so the rules are "whatever tumbleweed is publishing over there" [19:24] vorlon: thanks, i'll reject then [19:26] it's all the image seeds and the "supported" seed [19:26] -queuebot:#ubuntu-release- Unapproved: rejected argyll [source] (kinetic-proposed) [2.3.1+repack-1ubuntu1] [19:26] https://bazaar.launchpad.net/~stefanor/+junk/ubuntu-seeded-packages/view/head:/update.py [19:27] tumbleweed: hmmm I am puzzled that supported is included then because I would expect that to then always return correct for anything in main, but it doesn't always - e.g. ubuntu-image as a recent example [19:28] tumbleweed: as for "all the image seeds" perhaps you're keying on the wrong seed for ubuntustudio on account of it being the only remaining flavor that does 'dvd' + 'dvd-live' instead of 'desktop' [19:30] (I don't see in the code how it identifies 'image seeds') [19:30] it reads image manifests [19:32] none of which seem to contain argyll [19:33] uh [19:34] well it's *seeded* so let me go see [19:35] confirmed that it's not in .manifest or .list [19:35] oh hah ! I missed that it's *commented out* in the seed [19:35] ginggs: ^^ [19:36] :P [19:36] '# (argyll)' != '* (argyll)' [19:37] ;-) [19:38] so I guess the bot is reporting instead on the packageset, which it would still be part of [19:39] sounds right [19:43] vorlon: should I upload again? [19:44] ginggs: can be rescued from rejected with a queue command [19:45] queue -Q rejected [...] [19:49] vorlon: so I should accept argyll from the rejected queue? [19:50] ginggs: it looks to me like it would've been autoaccepted if not caught by the packageset, so IMHO yes [19:54] vorlon: thanks, and done. I notice the bot didn't announce it [20:42] apw: how goes? [20:54] vorlon, things should now be visible to you as it progresses in the "primary" signing ppa; the britney hints for the LRMs are in place. [21:33] waveform: I see you've done some testing of ubuntu desktop arm64+raspi on your pi4 2Gb and 4Gb. I'm trying to do the same on my 8Gb pi4 but I cannot get to the boot screen after dd'ing the image to an sd card. I see the bios screen, then the color palette screen, then just blackness. Did you have to do anything special to get hdmi output? [21:35] I've tried with a couple of different hdmi cables and a couple of different monitors and all with the same blackness problem. I also tried with a raspberry pi os and DO see the boot and login and everything. So I'm worried it's ubuntu specific. [21:35] hellsworth, no just booted it straight off the freshly dd'd card -- but this was before the re-spin with the updated kernel (for an unrelated video issue on the server images) -- I'll disentangle my 8GB from its current predicament and see if I can reproduce [21:35] thanks so much! [21:35] * arraybolt3[m] has a free Pi 8GB around here [21:36] please ping a release team member if this ends up being confirmed [21:36] and bring some tissues too [21:36] this is with the 1018.1 image: http://cdimage.ubuntu.com/ubuntu/daily-preinstalled/20221018.1/kinetic-preinstalled-desktop-arm64+raspi.img.xz [21:36] bdmurray: where should an issue go? kernel? [21:37] linux-raspi at a guess as that's the only thing that got updated in the latest re-spin (I'm *reasonably* certain?) [21:37] but the respin was after the 1018.1 image, wasn't it? [21:37] is it correct that live-server risc-v is still building? [21:37] oh, did the re-spin only hit the server images? [21:38] apparently yes [21:38] Hey, my 8GB Pi 4B isn't doing anything. If you're willing to wait on me, no need for anyone to disentagle their stuff. [21:38] s/disentagle/disentangle/ [21:39] arraybolt3[m]: it would be helpful for you to test this please :) [21:39] arraybolt3[m], please feel free -- you just need to dd the image hellsworth linked above to a suitably large card (16+GB) and try booting it on your 8GB with a keyboard, mouse & monitor attached -- it'll take me a little while to try and reproduce here as my 8GB is currently in the midst of foundations triage :) [21:40] fwiw, i checked the sha256sum as well and it matches [21:40] 👍️ Download in progress, my connection is behaving itself well so this should be fast. I have everything necessary to do the testing waveform is mentioning. [21:40] Why does the desktop daily preinstalled image have a newer kernel than the server preinstalled? [21:41] it shouldn't -- it should be *behind* the server preinstalled because the latter got re-spun but not the former [21:41] Either I can't read or ? [21:41] https://cdimage.ubuntu.com/ubuntu/daily-preinstalled/20221018.1/kinetic-preinstalled-desktop-arm64+raspi.manifest [21:41] https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20221018.3/kinetic-preinstalled-server-arm64+raspi.manifest [21:42] o.O [21:42] oh, you're look at 20221018.3 not 20221019 [21:43] on the server images; http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/kinetic-preinstalled-server-arm64+raspi.manifest [21:43] sweet hooray for not being able to read [21:44] thanks waveform [21:44] * waveform recovers from the minor coronary... [21:45] bdmurray: when sil_2100 was talking about the respin I requested for live-server, risc-v was different but I'm not sure what that is (other than taking longer) - is that build running? [21:47] dbungert: It doesn't look like it https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/kinetic/ubuntu-server-live [21:51] bdmurray: arraybolt3[m] waveform I went ahead and filed a bug on the safe side: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1993587 [21:51] -ubottu:#ubuntu-release- Launchpad bug 1993587 in linux-raspi (Ubuntu) "No HDMI output on pi4 8Gb" [Undecided, New] [21:52] dbungert: so we need a new risc-v live server build? [21:52] hellsworth: What side SD card did you use? I have many sizes here (8, 32, 256, 512) [21:53] bdmurray: yes. Most of them are 20221019 with the latest snap, risc-v is 20221018.3 with the older. [21:53] I see yeah [21:53] 32Gb [21:54] Perfect, that's the size I'm about to use. Thanks! [21:54] he mentioned something about a copy-forward so the other arches would not actually be different? is that a thing? [21:55] arraybolt3[m]: I need to be afk for about an hour, but will check back in when I return. [21:56] np, I think I have all the data I need to test. [21:56] I'd like to phone a friend regis [21:57] bdmurray: sorry to find a potential issue so late in the game [21:57] dbungert: I don't know what he meant but I can kick off a build of it [21:57] hellsworth: its par for the course [21:57] bdmurray: I think that's best, thank you [21:58] * bdmurray kicks it [22:03] (Crud, just discovered the good card I'm using is actually 64Gb. I'm remembering my 32Gb cards may not be all intact, so I'm going to use this anyway, but if I can't reproduce the issue, I'll hunt for a 32Gb one.) [22:03] hellsworth, arraybolt3[m] got the image flashed to a 32GB here and I've dug out the 8GB -- it's booting happily to the oem-setup for me. In case it's relevant my monitor is a bog-standard 1080p job [22:04] I'm mid-flash over here, but that's hopeful! [22:04] well ... semi-hopeful ... still doesn't explain why hellsworth is seeing an issue in ubuntu, but not raspios ... that's worrying me [22:05] Well on the 22.04.1 point release fossfreedom couldn't get the .1 image to boot on his board but me and you could, so /shrug [22:05] Are there different hardware revisision of the 8Gb? Are there multiple HDMI ports? [22:05] There are multiple HDMI ports. [22:06] And I know from experience that RPiOS will not work right if you accidentally use HDMI1 rather than HDMI0. [22:06] actually there's less revisions of the 8GB than others; AFAIK it's only rev 1.4 and rev 1.5 (the rev 1.1 and rev 1.2 boards were only 4GB and below). That's a good point on the ports though -- I've only plugged into HDMI0 ... retrying with HDMI1 [22:07] (Actually waveform tested the RPi 400 on the 22.04.1 release, but still, sometimes things go wonky and someone can't boot an image for some reason - maybe an error in the flashing process?) [22:07] I can't edit the release notes, would someone add this blurb? [22:07] https://paste.ubuntu.com/p/D446S73MP6/ [22:11] dbungert, done [22:11] Alright, flash complete, booting, got rainbow screen, black screen, now boot screen. [22:11] arraybolt3[m], yup -- same here, working on HDMI1 too [22:12] Desktop appeared, cursor spinning, aaaand... We have oem-setup! [22:12] waveform: thank you so much [22:12] hellsworth, is there anything special about your monitor maybe? 4K resolution or something? [22:13] * waveform goes to compare the current raspios boot config to ours... [22:14] arraybolt3[m], and many thanks for verifying too! [22:15] No problem. I'll let everything finish so I can do a good, thorough test (last thing we need is to have another "Oh great Firefox is dead" moment...). [22:19] What is SSSD? I see a bunch of Dependency Failed messages just after oem-config finishes, though the desktop seems to come up right. [22:20] sssd is an authentication proxy and creds caching service that integrates with kerberos realms and Microsoft AD [22:22] Anyway, it appears that everything is working here. [22:24] I'll finish a full test later, I have stuff pulling me away from work atm. [22:24] * arraybolt3[m] goes afk for a while [22:26] -queuebot:#ubuntu-release- New: accepted rust-derive-more [sync] (kinetic-proposed) [0.99.11-1] [22:28] -queuebot:#ubuntu-release- New binary: rust-derive-more [amd64] (kinetic-proposed/none) [0.99.11-1] (no packageset) [22:28] -queuebot:#ubuntu-release- New binary: rust-derive-more [s390x] (kinetic-proposed/none) [0.99.11-1] (no packageset) [22:28] -queuebot:#ubuntu-release- New binary: rust-derive-more [ppc64el] (kinetic-proposed/none) [0.99.11-1] (no packageset) [22:29] -queuebot:#ubuntu-release- New: accepted rust-derive-more [amd64] (kinetic-proposed) [0.99.11-1] [22:29] -queuebot:#ubuntu-release- New: accepted rust-derive-more [s390x] (kinetic-proposed) [0.99.11-1] [22:29] -queuebot:#ubuntu-release- New: accepted rust-derive-more [ppc64el] (kinetic-proposed) [0.99.11-1] [22:29] -queuebot:#ubuntu-release- New binary: rust-derive-more [armhf] (kinetic-proposed/none) [0.99.11-1] (no packageset) [22:30] -queuebot:#ubuntu-release- New: accepted rust-derive-more [armhf] (kinetic-proposed) [0.99.11-1] [22:31] -queuebot:#ubuntu-release- New binary: rust-derive-more [arm64] (kinetic-proposed/none) [0.99.11-1] (no packageset) [22:38] -queuebot:#ubuntu-release- New: accepted rust-derive-more [arm64] (kinetic-proposed) [0.99.11-1] [22:42] hmm let me try another ssd card then.. [22:44] -queuebot:#ubuntu-release- New binary: rust-derive-more [riscv64] (kinetic-proposed/none) [0.99.11-1] (no packageset) [22:44] waveform: the monitor i'm using now is 4k but i tried with another monitor that was not [22:45] i'm currently dd'ing to another sd card (16Gb since the maybe bad one was my only 32Gb card) [22:45] -queuebot:#ubuntu-release- New: accepted micropython-mpremote [amd64] (kinetic-proposed) [0.4.0-0ubuntu1] [22:45] but the 32Gb card booted raspbian just fine.. anyways, still tying a different sd card [23:14] hellsworth, I've completed verification on my 8GB here but I'm still a bit concerned that I'm missing ... something. Do you happen to have a USB-serial adapter? If so, the fact that you're getting beyond the "rainbow" screen indicates that the kernel is at least starting and I'm tempted to try and get some serial console output (although that's not enabled by default on the desktop images) [23:24] waveform: dd took 40 min! but i do see the ubuntu logo. so sorry to have raised a fuss over an sd card [23:25] no worries, just glad I've not missed something (for once :) [23:27] hellsworth: have you tried using dd with a larger bs? [23:27] for reference, I generally use dd if=image.img of=/dev/sdX bs=16M status=progress [23:29] i usally just do straight dd without specifying bs but i can :) [23:29] the other thing to query is whether the writer is using USB2 or USB3 as its bus (assuming it's USB attached but the vast majority are, even in laptops); USB2 is dreadfully slow for image flashing though 40 minutes is still ... excessive! [23:35] it was usb3 to usb3