19:00:29 #startmeeting 19:00:29 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:34 welcome 19:00:36 hi 19:00:40 #chair bwh carnil ukleinek 19:00:40 Current chairs: bwh carnil ukleinek waldi 19:00:43 \o 19:00:54 Hi 19:01:19 sounds like everyone expected is here. let's start 19:01:27 #topic dracut 19:01:37 bwh: you wanted to discuss this further? 19:01:55 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 waldi: Yes, because we weren't able to make a decision last week 19:02:49 right 19:03:11 trixie has generic (i.e. hostonly=no) as default which does not work out of the box with encryption 19:03:33 bdrung: is a network program needed usually in the initramfs? 19:04:16 ukleinek, it's not needed if you boot locally. the network related modules are shipped in the dracut-network module 19:04:22 It's needed for boot from NFS, or iSCSI or NVMe-over-TCP (not sure if those are supported) 19:04:35 s/dracut-network module/dracut-network package/ 19:05:03 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 not want what? 19:05:31 bdrung: Does dracut have any support for NM? 19:05:31 NFS and iSCSI are supported and has upstream test cases (NVMeof should be supported but I haven't checked) 19:05:49 waldi: sytemd-networkd in the initramfs 19:06:00 waldi: see the bug that bdrung linked to 19:06:18 ukleinek: okay, i miss the context. this does not sound related to TC at all 19:06:40 "As the package maintainer I do not wish for networkd to be used as the 19:06:40 default, as it would be yet another avenue for package-breaking 19:06:40 demands to be escalated to the TC and so on. It's fine as a 19:06:41 non-default alternative." 19:06:44 waldi: bluca has some recent experience of being overruled by the TC regarding systemd packages 19:07:02 yes. and he have to cope or stop being the maintainer 19:07:35 bdrung: Also does dracut try to apply a network configuration copied from the host, or only from the kernel command line? 19:07:42 systemd-networkd, network-manager, isc-dhcp-client, and connman are supported (at least) 19:07:44 requesting some coordination is IMHO fine before such a change 19:08:45 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 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 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 https://salsa.debian.org/debian/dracut/-/commit/8e5cee719d47efc933bac6e78ca83c88670d1bac was the starting point 19:11:36 Oh right, it's the package dependencies 19:11:41 if user already have some network daemon installed this dependency order does not make a difference 19:12:05 so this could be dropped altogether 19:12:23 Yeah I don't see a problem 19:12:27 anyway. is this relevant for the part we wanted to discuss? 19:12:58 Right, how do we feel now about dracut as default? Are there blockers to that? 19:13:00 When a user installs dracut-network I want to make sure that at least one supported network daemon is installed. 19:13:50 ack for this being a detail that's little relevant for the general question if we want to switch or not 19:14:09 yes (it's unrelated to the general question) 19:14:41 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 My expectation is that dracut is up to the task, alone as it is the choice in rpm world (IIUC) 19:15:18 and mkosi-initrd will still have a long way to go to support all these non-standard use cases 19:16:21 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 Just like debian-installer, which breaks all the time 19:17:22 d-i is worse, but yes 19:17:29 anyway. any objections? 19:17:58 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 systemd has a tendency to break dracut, but the other components are more stable 19:18:56 okay, so we are in agreement 19:18:57 #agreed we want to switch to using dracut by default for forkie, mkosi-initrd is interesting but not ready 19:19:13 I didn't compare initramfs sizes, could that be relevant? 19:19:25 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 -rw-r--r-- 1 root root 43219216 Aug 5 22:34 initrd.img-6.12.35+deb13-amd64 19:19:46 -rw-r--r-- 1 root root 146104223 Aug 5 22:30 initrd.img-6.12.38+deb13-amd64 19:19:58 .35 is still from initramfs, .38 is dracut 19:20:17 Hmm, that's a surprisingly large increase 19:20:24 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 a big difference could be the drm modules. We currently carry a patch in Ubuntu to use simpledrm by default. 19:21:32 I would definitely like to move to simpledrm where possible 19:21:45 the biggest offenders are kernel modules and firmware files. those are unrelated to the initrd implementation. 19:22:07 yes, though we still have some differences in policy for what to incldue 19:22:16 in debian ready for using simpledrm by default? Then I can include Ubuntu's patch. 19:22:30 no, we still have to do those config changes 19:22:40 There is an outstanding MR for linux that I really need to review 19:22:56 okay. let me know once the kernel is ready for simpledrm. 19:23:10 bdrung: If you didn't already review that, please do 19:23:31 https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453 19:23:51 I guess we should move on now, though? 19:23:54 yes 19:23:57 +1 19:24:14 #topic #1109015 19:24:30 should we announce the dracut switch somewhere? 19:24:35 bwh reported that upstream. nothing to do 19:24:40 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 bdrung: not now, we are just before the release 19:24:53 bdrung: wouldn't consider that an important action item now 19:25:09 waldi: Well, I think I want to revert the change since the broken version is going into unstable soon 19:25:30 okay. so wait for trixie to be released. 19:25:55 bwh: sounds sensible, sad that upstream didn't react 19:26:31 #action bwh will revert broken file to fix #1109015 19:26:44 thank you 19:26:47 #topic #1109203 19:27:04 is moreinfo by carnil 19:27:13 still no replies :( 19:28:16 we would need jochen to bisect the changes beween 6.12.33 and 6.12.35 19:28:17 I think users are afraid compiling a kenrel 19:28:49 ack, without reporter cooperation there is little to do for us, next? 19:29:06 and downgrade to important, this is not a general problem 19:29:16 #topic #1038107 19:29:31 Only change is I tagged it moreinfo 19:29:42 nothing to do 19:29:49 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 #topic #1088522 19:30:49 iam_tj[m]: Can you comment on this? 19:30:56 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 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 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 #action ukleinek to forward #1088522 19:33:25 I think it doesn't need much understanding to forward and for simplicity's sake I will do it 19:33:38 thank you 19:33:42 #topic #1104269 19:34:37 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 agreed 19:34:44 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 so we close it, as the submitter is MIA 19:35:21 let's give them a bit more time than a week 19:36:03 you mean three months? the first request for more informations was in end of april 19:37:12 I don't see the point in pinging and then hurrying to close. I would wait another week 19:37:30 #topic #1109666 19:38:37 So this is really unfixed. I should forward this upstream, I think 19:38:55 Will request a log first though 19:39:05 * ukleinek was about to suggest that 19:39:13 #action bwh will get a log for #1109666, then forward upstream 19:39:28 thank you 19:39:31 #topic #1110256 19:40:09 I guess someone has to check the newly provided logs 19:40:58 I'm not seeing any crash in the log 19:41:09 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 Kiwix JS Electron.desktop 19:42:17 is "Asking for cache data failed" a problem indication? 19:43:06 kiwix is already mentioned in the first report 19:43:45 i don't see any crash indication 19:43:48 ukleinek: It can be emitted when revalidating a disk, but doesn't appear to be an error from normal I/O 19:44:59 I don't know what we can do here without any log 19:45:09 i wonder what happens if you mount the same filesystem with ntfs3 and the fuse ntfs-3g 19:45:16 asking for Sysrq-T next time? 19:46:31 do we have pstore enabled to catch crash messages? 19:46:40 and making sure the reporter waits long enough (IIRC 2 min?) for the hangcheck timer to expire 19:46:53 ukleinek: Maybe, but will require changing the sysrq mask first 19:47:43 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 should be easy to check… echo c > /proc/sysrq-trigger 19:49:28 does someone want to take action? 19:49:28 there is a warning a bit earlier in the log 19:49:30 is echoing into /proc/sysrq-trigger also prevented by the mask 19:49:41 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 c80211] 19:49:51 ukleinek: nope 19:50:48 WARN_ON_ONCE(softirq_count() == 0); 19:51:08 Comm: netconsole-setu 19:51:26 Oh so they're trying to do netconsole over wifi 19:52:08 I think this might work better over Ethernet 19:52:27 might not be practical though 19:53:04 Well, if the wifi stack warns when you try to use netconsole, it seems like it might not really be supported 19:54:06 jajajajaja, I agree, just think the request might be difficult for the reporter 19:54:09 right 19:54:52 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 and check pstore?! 19:55:22 right, but that should go in the journal anyway 19:55:34 is that autoenabled? 19:55:49 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 I can continue to follow up on that bugreport as I did some initial interaction 19:56:38 \o/ 19:57:00 #action carnil to follow up on #1110256 19:57:02 thank you 19:57:10 #topic AoB 19:57:21 #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 we are almost out of time. anything we need to discuss 19:57:36 not a topic to discuss but a comment so all are awre 19:57:51 on ftp-master side there are currently problems with the codesinging service 19:58:11 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 trixie++ should work 19:58:22 ..ooOO(they need new score sheets?) 19:58:23 6.1 is still broken, due to signing modules 19:58:23 i.e. the DSA is deferred at least 19:58:59 TTBOK ansgar is still working on that 19:59:01 Why can't the experimental upload be signed? 19:59:08 if it's specific to signing modules 19:59:22 bwh: the experimental one can now be signed, but AFIU 19:59:45 [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 trixie and newer will not work. there where some config problems with the uploads 19:59:53 so that should be ok once that's done 19:59:57 s/not/now/ 20:00:15 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 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 ukleinek: nic-shared-modules 20:00:51 bwh: ok, will rework the MR 20:00:52 (er, I think) 20:01:21 (though I wondered about the split, is one of the udebs usefull without the other?) 20:01:45 in theory yes 20:02:04 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 but let's see what we hear from ansgar 20:03:10 other than that I have nothing for the AoB topic, was more informational 20:03:20 okay. who wants to chair next week? 20:03:26 I guess it's my turn ... 20:03:49 * carnil raises hands 20:03:50 thanks 20:03:57 #action carnil will chair next week 20:03:57 * ukleinek is on vacation in week 35 + 36 20:04:22 nice :) enjoy it 20:04:24 i will be absent week 34, not sure auf 35 yet 20:04:37 thank you are for coming 20:04:45 Thanks for chairing 20:04:47 #endmeeting