19:00:29 <waldi> #startmeeting 19:00:29 <MeetBot> Meeting started Wed Aug 6 19:00:29 2025 UTC. The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:34 <waldi> welcome 19:00:36 <carnil> hi 19:00:40 <waldi> #chair bwh carnil ukleinek 19:00:40 <MeetBot> Current chairs: bwh carnil ukleinek waldi 19:00:43 <bdrung> \o 19:00:54 <bwh> Hi 19:01:19 <waldi> sounds like everyone expected is here. let's start 19:01:27 <waldi> #topic dracut 19:01:37 <waldi> bwh: you wanted to discuss this further? 19:01:55 <bdrung> I like to ask you about your opinion on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110188 19:02:12 * ukleinek converted his laptop and had I used the version from trixie but unstable it would have been smooth 19:02:18 <bwh> waldi: Yes, because we weren't able to make a decision last week 19:02:49 <waldi> right 19:03:11 <bdrung> trixie has generic (i.e. hostonly=no) as default which does not work out of the box with encryption 19:03:33 <ukleinek> bdrung: is a network program needed usually in the initramfs? 19:04:16 <bdrung> ukleinek, it's not needed if you boot locally. the network related modules are shipped in the dracut-network module 19:04:22 <bwh> It's needed for boot from NFS, or iSCSI or NVMe-over-TCP (not sure if those are supported) 19:04:35 <bdrung> s/dracut-network module/dracut-network package/ 19:05:03 <ukleinek> It's a bit sad that the TC is the reason for bluca to not want it. I'd prefer a technical reason 19:05:27 <waldi> not want what? 19:05:31 <bwh> bdrung: Does dracut have any support for NM? 19:05:31 <bdrung> NFS and iSCSI are supported and has upstream test cases (NVMeof should be supported but I haven't checked) 19:05:49 <ukleinek> waldi: sytemd-networkd in the initramfs 19:06:00 <ukleinek> waldi: see the bug that bdrung linked to 19:06:18 <waldi> ukleinek: okay, i miss the context. this does not sound related to TC at all 19:06:40 <ukleinek> "As the package maintainer I do not wish for networkd to be used as the 19:06:40 <ukleinek> default, as it would be yet another avenue for package-breaking 19:06:40 <ukleinek> demands to be escalated to the TC and so on. It's fine as a 19:06:41 <ukleinek> non-default alternative." 19:06:44 <bwh> waldi: bluca has some recent experience of being overruled by the TC regarding systemd packages 19:07:02 <waldi> yes. and he have to cope or stop being the maintainer 19:07:35 <bwh> bdrung: Also does dracut try to apply a network configuration copied from the host, or only from the kernel command line? 19:07:42 <bdrung> systemd-networkd, network-manager, isc-dhcp-client, and connman are supported (at least) 19:07:44 <ukleinek> requesting some coordination is IMHO fine before such a change 19:08:45 <bwh> bdrung: OK, so what is the problem? Is it that the default generic initramfs is not sensitive to the host's choice of network configurator? 19:09:17 <bdrung> bwh, I think dracut will try to bring up the network devices needed for boot and not the ones from the host (but i haven't checked to confirm) 19:10:32 <ukleinek> My gut feeling is that networking in the initramfs is a corner case and the default choice affects a very low number of installations/users 19:11:20 <bdrung> https://salsa.debian.org/debian/dracut/-/commit/8e5cee719d47efc933bac6e78ca83c88670d1bac was the starting point 19:11:36 <bwh> Oh right, it's the package dependencies 19:11:41 <bdrung> if user already have some network daemon installed this dependency order does not make a difference 19:12:05 <waldi> so this could be dropped altogether 19:12:23 <bwh> Yeah I don't see a problem 19:12:27 <waldi> anyway. is this relevant for the part we wanted to discuss? 19:12:58 <bwh> Right, how do we feel now about dracut as default? Are there blockers to that? 19:13:00 <bdrung> When a user installs dracut-network I want to make sure that at least one supported network daemon is installed. 19:13:50 <ukleinek> ack for this being a detail that's little relevant for the general question if we want to switch or not 19:14:09 <bdrung> yes (it's unrelated to the general question) 19:14:41 <waldi> i don't know any blockers. the only thing is the up and coming mkosi-initrd, which wants to take up the same place, but is not ready as far as i know 19:15:05 <ukleinek> My expectation is that dracut is up to the task, alone as it is the choice in rpm world (IIUC) 19:15:18 <bdrung> and mkosi-initrd will still have a long way to go to support all these non-standard use cases 19:16:21 <waldi> mkosi-initrd needs other packages to support it, as it creates essentially a mini-debian, while dracut creates a copied together bastard 19:17:05 <bwh> Just like debian-installer, which breaks all the time 19:17:22 <waldi> d-i is worse, but yes 19:17:29 <waldi> anyway. any objections? 19:17:58 <bdrung> my hope/idea is that the work for mkosi-initrd will make the dracut modules simpler (and maybe we decide to switch to mkosi-initrd in the future) 19:18:25 <bdrung> systemd has a tendency to break dracut, but the other components are more stable 19:18:56 <waldi> okay, so we are in agreement 19:18:57 <waldi> #agreed we want to switch to using dracut by default for forkie, mkosi-initrd is interesting but not ready 19:19:13 <ukleinek> I didn't compare initramfs sizes, could that be relevant? 19:19:25 <bdrung> i expect dracut upstream to do a release in case the current dracut version does not work with the latest systemd release 19:19:43 <ukleinek> -rw-r--r-- 1 root root 43219216 Aug 5 22:34 initrd.img-6.12.35+deb13-amd64 19:19:46 <ukleinek> -rw-r--r-- 1 root root 146104223 Aug 5 22:30 initrd.img-6.12.38+deb13-amd64 19:19:58 <ukleinek> .35 is still from initramfs, .38 is dracut 19:20:17 <bwh> Hmm, that's a surprisingly large increase 19:20:24 <bdrung> with similar configs i would expect the sizes to be similar 19:20:43 * ukleinek will check the difference after the meeting 19:20:48 <bdrung> a big difference could be the drm modules. We currently carry a patch in Ubuntu to use simpledrm by default. 19:21:32 <bwh> I would definitely like to move to simpledrm where possible 19:21:45 <bdrung> the biggest offenders are kernel modules and firmware files. those are unrelated to the initrd implementation. 19:22:07 <bwh> yes, though we still have some differences in policy for what to incldue 19:22:16 <bdrung> in debian ready for using simpledrm by default? Then I can include Ubuntu's patch. 19:22:30 <waldi> no, we still have to do those config changes 19:22:40 <bwh> There is an outstanding MR for linux that I really need to review 19:22:56 <bdrung> okay. let me know once the kernel is ready for simpledrm. 19:23:10 <bwh> bdrung: If you didn't already review that, please do 19:23:31 <bwh> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453 19:23:51 <bwh> I guess we should move on now, though? 19:23:54 <waldi> yes 19:23:57 <ukleinek> +1 19:24:14 <waldi> #topic #1109015 19:24:30 <bdrung> should we announce the dracut switch somewhere? 19:24:35 <waldi> bwh reported that upstream. nothing to do 19:24:40 <carnil> fwiw, I do not have an objection to move to dracut, think we should do that. Questions I still have is how one would add support for projekcts which do not have yet the dracut support (like some on the list in the ubuntu discourse table, but I guess forky will have neough time to narrow those down) 19:24:48 <waldi> bdrung: not now, we are just before the release 19:24:53 <ukleinek> bdrung: wouldn't consider that an important action item now 19:25:09 <bwh> waldi: Well, I think I want to revert the change since the broken version is going into unstable soon 19:25:30 <bdrung> okay. so wait for trixie to be released. 19:25:55 <ukleinek> bwh: sounds sensible, sad that upstream didn't react 19:26:31 <bwh> #action bwh will revert broken file to fix #1109015 19:26:44 <waldi> thank you 19:26:47 <waldi> #topic #1109203 19:27:04 <waldi> is moreinfo by carnil 19:27:13 <carnil> still no replies :( 19:28:16 <carnil> we would need jochen to bisect the changes beween 6.12.33 and 6.12.35 19:28:17 <ukleinek> I think users are afraid compiling a kenrel 19:28:49 <ukleinek> ack, without reporter cooperation there is little to do for us, next? 19:29:06 <waldi> and downgrade to important, this is not a general problem 19:29:16 <waldi> #topic #1038107 19:29:31 <bwh> Only change is I tagged it moreinfo 19:29:42 <waldi> nothing to do 19:29:49 <ukleinek> re #1109203: The reporter announced via PM to me that he will not be able to work on that, but will come back to that 19:30:06 <waldi> #topic #1088522 19:30:49 <bwh> iam_tj[m]: Can you comment on this? 19:30:56 <ukleinek> I'm a bit clueless about that one. What tj wrote sounded sensible to me, I think we need to involve upstream 19:32:13 <carnil> sounds good, think should be done by someone who has at least a good partial understanding, maybe tj if you can motivate him to do? 19:32:20 <ukleinek> There was a theory that if compressed firmware is used the loader emits an error message for the uncompressed file before checking the compressed one. A quick look in the source didn't confirm that 19:33:04 <ukleinek> #action ukleinek to forward #1088522 19:33:25 <ukleinek> I think it doesn't need much understanding to forward and for simplicity's sake I will do it 19:33:38 <waldi> thank you 19:33:42 <waldi> #topic #1104269 19:34:37 <ukleinek> this is only on the agenda because I asked the original reporter if they could add their details to the upstream bug, I think there is no action needed from us now 19:34:44 <bwh> agreed 19:34:44 <carnil> no reply from original reporter (see last followup from ukleinek, there was recently one similar bug reported, which is as well on the list, but further down, ##1110419) 19:34:59 <waldi> so we close it, as the submitter is MIA 19:35:21 <ukleinek> let's give them a bit more time than a week 19:36:03 <waldi> you mean three months? the first request for more informations was in end of april 19:37:12 <bwh> I don't see the point in pinging and then hurrying to close. I would wait another week 19:37:30 <waldi> #topic #1109666 19:38:37 <bwh> So this is really unfixed. I should forward this upstream, I think 19:38:55 <bwh> Will request a log first though 19:39:05 * ukleinek was about to suggest that 19:39:13 <bwh> #action bwh will get a log for #1109666, then forward upstream 19:39:28 <waldi> thank you 19:39:31 <waldi> #topic #1110256 19:40:09 <ukleinek> I guess someone has to check the newly provided logs 19:40:58 <bwh> I'm not seeing any crash in the log 19:41:09 <carnil> reporter did followup with logs, as well the last one with netconsole attached, did not spot a kernel related problem, mabye gnome-shell freezing, which starts an Electron app, don't know it though 19:41:18 <carnil> Kiwix JS Electron.desktop 19:42:17 <ukleinek> is "Asking for cache data failed" a problem indication? 19:43:06 <ukleinek> kiwix is already mentioned in the first report 19:43:45 <waldi> i don't see any crash indication 19:43:48 <bwh> ukleinek: It can be emitted when revalidating a disk, but doesn't appear to be an error from normal I/O 19:44:59 <bwh> I don't know what we can do here without any log 19:45:09 <waldi> i wonder what happens if you mount the same filesystem with ntfs3 and the fuse ntfs-3g 19:45:16 <ukleinek> asking for Sysrq-T next time? 19:46:31 <waldi> do we have pstore enabled to catch crash messages? 19:46:40 <ukleinek> and making sure the reporter waits long enough (IIRC 2 min?) for the hangcheck timer to expire 19:46:53 <bwh> ukleinek: Maybe, but will require changing the sysrq mask first 19:47:43 <bwh> waldi: I think so. systemd-journald should fetch from there too, but I'm not sure which boot it gets associated with 19:48:15 <waldi> should be easy to check⦠echo c > /proc/sysrq-trigger 19:49:28 <waldi> does someone want to take action? 19:49:28 <carnil> there is a warning a bit earlier in the log 19:49:30 <ukleinek> is echoing into /proc/sysrq-trigger also prevented by the mask 19:49:41 <carnil> Aug 04 09:55:07 white kernel: WARNING: CPU: 3 PID: 2256 at net/mac80211/tx.c:3815 ieee80211_tx_dequeue+0xcf9/0xd60 [ma 19:49:44 <carnil> c80211] 19:49:51 <waldi> ukleinek: nope 19:50:48 <ukleinek> WARN_ON_ONCE(softirq_count() == 0); 19:51:08 <bwh> Comm: netconsole-setu 19:51:26 <bwh> Oh so they're trying to do netconsole over wifi 19:52:08 <bwh> I think this might work better over Ethernet 19:52:27 <ukleinek> might not be practical though 19:53:04 <bwh> Well, if the wifi stack warns when you try to use netconsole, it seems like it might not really be supported 19:54:06 <ukleinek> jajajajaja, I agree, just think the request might be difficult for the reporter 19:54:09 <bwh> right 19:54:52 <bwh> So it seems like we have 2 ideas: use SysRq T (making sure to enable that first), or retry netconsole with Ethernet 19:55:06 <ukleinek> and check pstore?! 19:55:22 <bwh> right, but that should go in the journal anyway 19:55:34 <ukleinek> is that autoenabled? 19:55:49 <bwh> OK someone needs to check that 19:56:09 * ukleinek remembers having to jump through some hoops on an ARM machine to get this up and running 19:56:29 <carnil> I can continue to follow up on that bugreport as I did some initial interaction 19:56:38 <ukleinek> \o/ 19:57:00 <waldi> #action carnil to follow up on #1110256 19:57:02 <waldi> thank you 19:57:10 <waldi> #topic AoB 19:57:21 <carnil> #action carnil follows up on #1110256: use sysrq T on next crash (help to ensure it is enabled); retry over netconsole over ethernet; check pstore 19:57:26 <waldi> we are almost out of time. anything we need to discuss 19:57:36 <carnil> not a topic to discuss but a comment so all are awre 19:57:51 <carnil> on ftp-master side there are currently problems with the codesinging service 19:58:11 <carnil> thus the current epxerimental upload and the pending DSA for linux/6.1.147-1 (as the uploads from ben for linux-6.1) cannot be signed 19:58:16 <waldi> trixie++ should work 19:58:22 <ukleinek> ..ooOO(they need new score sheets?) 19:58:23 <waldi> 6.1 is still broken, due to signing modules 19:58:23 <carnil> i.e. the DSA is deferred at least 19:58:59 <carnil> TTBOK ansgar is still working on that 19:59:01 <bwh> Why can't the experimental upload be signed? 19:59:08 <bwh> if it's specific to signing modules 19:59:22 <carnil> bwh: the experimental one can now be signed, but AFIU 19:59:45 <carnil> [07:46] < ansgar> carnil: Ah, forgot to add the new key to th source-only-NEW-allowed list... Will do that in the evening. 19:59:49 <waldi> trixie and newer will not work. there where some config problems with the uploads 19:59:53 <carnil> so that should be ok once that's done 19:59:57 <waldi> s/not/now/ 20:00:15 <ukleinek> a look on https://salsa.debian.org/kernel-team/linux/-/merge_requests/1597 would be appreciated to tell me if the phy module should go into nic-modules or nic-shared-modules 20:00:24 <bwh> If signing modules is going to be a problem I can work on backporting the change to using an ephermeral key, but without changing the ABI format 20:00:32 <bwh> ukleinek: nic-shared-modules 20:00:51 <ukleinek> bwh: ok, will rework the MR 20:00:52 <bwh> (er, I think) 20:01:21 <ukleinek> (though I wondered about the split, is one of the udebs usefull without the other?) 20:01:45 <bwh> in theory yes 20:02:04 <carnil> bwh: ack. I'm worried about the fact we are not able to release the DSA, so if that becomes necessary it is welcome if you look at it. 20:02:41 <carnil> but let's see what we hear from ansgar 20:03:10 <carnil> other than that I have nothing for the AoB topic, was more informational 20:03:20 <waldi> okay. who wants to chair next week? 20:03:26 <carnil> I guess it's my turn ... 20:03:49 * carnil raises hands 20:03:50 <waldi> thanks 20:03:57 <waldi> #action carnil will chair next week 20:03:57 * ukleinek is on vacation in week 35 + 36 20:04:22 <carnil> nice :) enjoy it 20:04:24 <waldi> i will be absent week 34, not sure auf 35 yet 20:04:37 <waldi> thank you are for coming 20:04:45 <bwh> Thanks for chairing 20:04:47 <waldi> #endmeeting