Bug#1075968: /usr/sbin/discover-modprobe: 63: .: cannot open /etc/default/rcS: No such file
On Mon, Jul 08, 2024 at 05:04:53PM +0200, Chris Hofstaedtler wrote: > Running discover-modprobe on a normal install gives: > /usr/sbin/discover-modprobe: 63: .: cannot open /etc/default/rcS: No such file > > It would seem this is just plainly broken on systemd systems. > > Given I could not find any references to discover-modprobe anywhere, > maybe it can just be removed? Here is a lightly tested MR to do that: https://salsa.debian.org/installer-team/discover/-/merge_requests/3 Please consider it. Chris
Bug#1075968: /usr/sbin/discover-modprobe: 63: .: cannot open /etc/default/rcS: No such file
Package: discover Version: 2.1.2-10 Severity: normal Running discover-modprobe on a normal install gives: /usr/sbin/discover-modprobe: 63: .: cannot open /etc/default/rcS: No such file It would seem this is just plainly broken on systemd systems. Given I could not find any references to discover-modprobe anywhere, maybe it can just be removed? Chris
Bug#1075967: hw-detect: Please uninstall discover after using it
On Mon, Jul 08, 2024 at 03:57:14PM +0200, Chris Hofstaedtler wrote: > hw-detect installs discover in the target system, to call > discover-pkginstall. Specifically, this is done in hw-detect.pre-pkgsel.d/20install-hwpackages. https://salsa.debian.org/installer-team/hw-detect/-/blob/master/hw-detect.pre-pkgsel.d/20install-hwpackages?ref_type=heads
Bug#1075967: hw-detect: Please uninstall discover after using it
Source: hw-detect Version: 1.159 Severity: normal hw-detect installs discover in the target system, to call discover-pkginstall. This causes discover, discover-data, libdiscover2 to be installed on all d-i installed systems, but then it just sits there as cruft. Please uninstall these packages after they've done their duty. Chris
Bug#1075966: RM: discover/experimental -- RoQA; unnecessary t64 transition
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: disco...@packages.debian.org Control: affects -1 + src:discover Please remove the aborted t64 transition of discover from experimental. Only discover itself depends on libdiscover2, so nothing is gained from having a t64 lib, and apparently nobody followed up on the transition. Chris
Bug#1058729: netcfg: Please replace libiw-dev dependency
Source: netcfg Severity: normal Hi, libiw-dev / libiw30 come from src:wireless-tools 30~pre9, which is over a decade old (i.e. upstream unmaintained since 2009). Please stop using it. Thanks, Chris
Bug#1058728: netcfg: Please switch away from wireless-tools
Source: netcfg Severity: important Hi, netcfg currently installs wireless-tools when configuring a WiFi interface without WPA key management. Please stop doing that. A possible solution is to always use wpa_supplicant, with wpa-key-mgmt NONE for no encryption. If I'm reading wpa_supplicant's README.Debian right, WEP should work the same as WPA2, but I have no way of testing this. I'm filing this bug so we can remove the wireless-tools binary package, as wireless-tools is dead for more than a decade already. I'll file a separate bug to also switch away from libiw-dev, which is also built from src:wireless-tools. Removing the wireless-tools binary is IMO higher prio then removing the entire stack, as we really don't want to leave users with a completely dead and no-future network setup. Chris
Bug#1033535: installation-guide: Remove dmraid information
Source: installation-guide Version: dmraid support was removed Severity: normal Tags: patch Please remove information related to dmraid from the installation-guide. Installer support for dmraid was removed in #864423. MR: https://salsa.debian.org/zeha/installation-guide/-/merge_requests/2 Chris
Bug#1033524: Simplify the instructions for making bootable media
* Steve McIntyre [230326 23:23]: > On Mon, Mar 27, 2023 at 12:52:41AM +0200, Chris Hofstaedtler wrote: > >* Steve McIntyre : > >> We should definitely also kill section 4.4.2: Loadlin is *dead* - > >> *nobody* has DOS any more. > > > >Section 5.1.4. "Booting from DOS using loadlin" should also go, I > >guess. > > Yup, good call. Trivial MR for removing loadlin sections is here: https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/27
Bug#1033524: Simplify the instructions for making bootable media
* Steve McIntyre : > We should definitely also kill section 4.4.2: Loadlin is *dead* - > *nobody* has DOS any more. Section 5.1.4. "Booting from DOS using loadlin" should also go, I guess.
Re: Bug#864423: Software RAID is not activated at boot time
Hi,
* Holger Wansing [220802 23:37]:
> Cyril Brulebois wrote (Sun, 31 Jul 2022 14:31:20 +0200):
> > > I was digging around in the d-i code, and it appears for dmraid to
> > > be invoked, one has to boot with disk-detect/dmraid/enable.
> > >
> > > I have opened merge requests to remove the dmraid/sataraid code from
> > > d-i. The changes look like low risk to me, but obviously I have no
> > > idea. For the lack of a build environment I also didn't test them.
> > >
> > > Given d-i does nothing with dmraid unless the boot flag is present,
> > > I want to ask if dmraid could also stop shipping its udeb, if thats
> > > ok with debian-boot?
> >
> > Given how specific it is, opt-in, on a specific arch, and dead upstream,
> > looks like a wholesale removal would be the best way forward, yes.
>
> I have merged the merge requests filed by Chris (partman-base, partman-auto,
> hw-detect, grub-installer).
>
> The packages build fine with those changings.
> And a locally built mini.iso with those changings in local udebs also
> installs fine (default install) in QEMU VM.
Great, thanks for testing!
Maybe these changes can make it into unstable soon?
I'm attaching a draft patch to drop udebs from src:dmraid. Maybe you
want to use this as a starting point, László?
I would also suggest keeping dmraid for one more release, and
putting something into the release notes. To keep dmraid, I think
the severity of this bug also might need adjusting, or something.
Thanks everyone for your helping hands.
Best,
Chris
diff -Nru dmraid-1.0.0.rc16/debian/changelog dmraid-1.0.0.rc16/debian/changelog
--- dmraid-1.0.0.rc16/debian/changelog 2022-02-16 16:44:50.0 +
+++ dmraid-1.0.0.rc16/debian/changelog 2022-08-02 23:30:56.0 +0000
@@ -1,3 +1,10 @@
+dmraid (1.0.0.rc16-11.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop udebs.
+
+ -- Chris Hofstaedtler Tue, 02 Aug 2022 23:30:56 +
+
dmraid (1.0.0.rc16-11) unstable; urgency=medium
[ Helmut Grohne ]
diff -Nru dmraid-1.0.0.rc16/debian/control dmraid-1.0.0.rc16/debian/control
--- dmraid-1.0.0.rc16/debian/control2022-02-16 16:44:50.0 +
+++ dmraid-1.0.0.rc16/debian/control2022-08-02 23:30:56.0 +
@@ -28,28 +28,6 @@
Please read the documentation in /usr/share/doc/dmraid BEFORE attempting
any use of this software. Improper use can cause data loss!
-Package: dmraid-udeb
-Architecture: linux-any
-Section: debian-installer
-Package-Type: udeb
-Depends: ${shlibs:Depends}, dmsetup-udeb
-Description: Device-Mapper Software RAID support tool (udeb)
- dmraid discovers, activates, deactivates and displays properties
- of software RAID sets (eg, ATARAID) and contained DOS partitions.
- .
- This is the minimal package (udeb) used by debian-installer
-
-Package: libdmraid1.0.0.rc16-udeb
-Architecture: linux-any
-Section: debian-installer
-Package-Type: udeb
-Depends: ${shlibs:Depends}
-Description: Device-Mapper Software RAID support tool - shared library (udeb)
- dmraid discovers, activates, deactivates and displays properties
- of software RAID sets (eg, ATARAID) and contained DOS partitions.
- .
- This is the minimal package (udeb shared library) used by debian-installer
-
Package: libdmraid1.0.0.rc16
Architecture: linux-any
Multi-Arch: same
diff -Nru dmraid-1.0.0.rc16/debian/dmraid.install
dmraid-1.0.0.rc16/debian/dmraid.install
--- dmraid-1.0.0.rc16/debian/dmraid.install 2017-08-30 21:28:37.0
+
+++ dmraid-1.0.0.rc16/debian/dmraid.install 2022-08-02 23:30:56.0
+
@@ -1,5 +1,5 @@
debian/initramfs/dmraid.initramfs-hook/dmraid usr/share/initramfs-tools/hooks
debian/initramfs/dmraid.initramfs-local-top/dmraid
usr/share/initramfs-tools/scripts/local-top
-debian/standard/sbin/dmraid sbin
-debian/standard/usr/share/man usr/share
+debian/tmp/sbin/dmraid sbin
+debian/tmp/usr/share/man usr/share
debian/dmraid-activate sbin
diff -Nru dmraid-1.0.0.rc16/debian/dmraid-udeb.install
dmraid-1.0.0.rc16/debian/dmraid-udeb.install
--- dmraid-1.0.0.rc16/debian/dmraid-udeb.install2017-08-30
21:28:37.0 +
+++ dmraid-1.0.0.rc16/debian/dmraid-udeb.install1970-01-01
00:00:00.0 +
@@ -1,2 +0,0 @@
-debian/udeb/sbin/dmraid sbin
-debian/dmraid-activate sbin
diff -Nru dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install
dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install
--- dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install2022-02-03
16:28:13.0 +
+++ dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install2022-08-02
23:30:56.0 +
@@ -1,2 +1,2 @@
#!/usr/bin/dh-exec
-debian/standard/lib/${DEB_HOST_MULTIARCH}/*.so.* lib/${DEB_HOST_MULTIARCH}
+debian/tmp/lib/${DEB_HOST_MULTIARCH}/*.so.* lib/${DEB_HOST_MULTIARCH}
diff -Nru dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16-udeb.install
Re: Bug#1013079: installation-reports: GUI install option isn't visible on boot
Control: reassign -1 debian-cd Hi, * Holger Wansing : > > > - On Jun 17, 2022, at 7:43 AM, Philip Hands p...@hands.com wrote: > > > > > > > > https://openqa.debian.net/tests/60553#step/_boot_to_debianinstaller/2 > > > > > > > > if you look closely in the highlighted box, you can just about see > > > > "Graphical install" as a black font on dark_blue background, but it's > > > > very close to invisible. > > > > > > > > It should have an inverted background on the selected item, which then > > > > makes the black text easily visible, as seen in the last working test, > > > > using a netinst ISO from 2022-06-07 17:27: > > > > > > > > https://openqa.debian.net/tests/59056#step/_boot_to_debianinstaller/1 I'm reassigning this to debian-cd, because: - grub2 upstream has deleted support for grayscale PNGs. I don't think this is coming back. - the menu on the installer ISOs uses a grayscale image to highlight the currently selected menu entry. As demonstrated in the bug report, this is now broken. While technically grub2 broke this, I'd think the way forward is for debian-cd to convert the highlight PNGs to non-grayscale. FTR: debian-cd/data/bookworm/hl_c.png: PNG image data, 20 x 20, 8-bit grayscale, non-interlaced Hope this helps in resolving the issue, Chris
Re: Bug#864423: Software RAID is not activated at boot time
Hi debian-boot, * László Böszörményi (GCS) [220730 15:34]: > On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler wrote: > > whats the status of dmraid? Do you have dmraid hardware or is this > > merely on life-support? > Please note dmraid upstream is dead for more than ten years. I might > find an old i386 hardware that needs it. > But yes, it's only on life-support. [..] > > I'm wondering if we should remove dmraid support from the d-i as a > > first step. AFAICT Intel Software RAID is supported by mdraid, not > > sure if the other RAID platforms are still sold. > Sounds like a good idea. This will show users early Debian doesn't > plan to ship it anymore. I was digging around in the d-i code, and it appears for dmraid to be invoked, one has to boot with disk-detect/dmraid/enable. I have opened merge requests to remove the dmraid/sataraid code from d-i. The changes look like low risk to me, but obviously I have no idea. For the lack of a build environment I also didn't test them. Given d-i does nothing with dmraid unless the boot flag is present, I want to ask if dmraid could also stop shipping its udeb, if thats ok with debian-boot? Thanks, Chris
Re: Bug#864423: Software RAID is not activated at boot time
Hi Laszlo, whats the status of dmraid? Do you have dmraid hardware or is this merely on life-support? * Paul Gevers : > What would you say about this? Even if d-i would not need it anymore, we > would need work to drop the dependency chain via > libblockdev/udisks2/gnome-control-center. I'm wondering if we should remove dmraid support from the d-i as a first step. AFAICT Intel Software RAID is supported by mdraid, not sure if the other RAID platforms are still sold. If its gone from di-i, at least no new installs can spring into existence "by accident", i.e. where mdraid would have been the better choice. What do you, Laszlo and d-boot, think? Chris
Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed
* Ben Hutchings : [..] > Right. So this seems like a botched transition - fuse3 should have > taken over the fuse binary package but instead each reverse-dependency > has to be updated. I agree it would make sense in the short term to > force fuse3 installation. [..] > Thank you for pointing out the problem. Even if the exact issue > doesn't occur in Debian, we should sort out fuse vs fuse3. I would imagine #918984 is related. Chris
Bug#991621: unblock: util-linux/2.36.1-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package util-linux
[ Reason ]
Fix for security bug CVE-2021-37600, reported as Debian bug #991619
[ Impact ]
Security issue remains open. From an util-linux perspective, I think
this is a local (=non-remote) issue.
[ Tests ]
util-linux build-time tests cover ipcs and lsipc, which are the two
affected commands.
[ Risks ]
The security bug is in a shared static .c file, used by the ipcs and
lsipc commands. I hope that ipc shmem/queue/semaphore users do not shell
out to ipcs/lsipc, and instead use some library. If this is true, only
"inspection" use cases of local admins would possibly break.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
util-linux builds udebs. debian-boot@ is x-cc'ed.
unblock util-linux/2.36.1-8
diff -Nru util-linux-2.36.1/debian/changelog util-linux-2.36.1/debian/changelog
--- util-linux-2.36.1/debian/changelog 2021-02-07 14:38:19.0 +
+++ util-linux-2.36.1/debian/changelog 2021-07-28 19:09:07.0 +
@@ -1,3 +1,9 @@
+util-linux (2.36.1-8) unstable; urgency=medium
+
+ * Apply upstream patch for CVE-2021-37600 (Closes: #991619)
+
+ -- Chris Hofstaedtler Wed, 28 Jul 2021 19:09:07 +
+
util-linux (2.36.1-7) unstable; urgency=medium
* libmount: allow --read-only for not-root users.
diff -Nru util-linux-2.36.1/debian/patches/series
util-linux-2.36.1/debian/patches/series
--- util-linux-2.36.1/debian/patches/series 2021-02-07 14:38:19.0
+
+++ util-linux-2.36.1/debian/patches/series 2021-07-28 19:09:07.0
+
@@ -6,3 +6,4 @@
debian/verbose-tests.patch
upstream/libmount-do-not-canonicalize-ZFS-source-dataset.patch
upstream/libmount-allow-read-only-for-not-root-users.patch
+upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
diff -Nru
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
---
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
1970-01-01 00:00:00.0 +
+++
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
2021-07-28 19:09:07.0 +
@@ -0,0 +1,23 @@
+From: Karel Zak
+Date: Tue, 27 Jul 2021 11:58:31 +0200
+Subject: sys-utils/ipcutils: be careful when call calloc() for uint64 nmembs
+
+Fix: https://github.com/karelzak/util-linux/issues/1395
+Signed-off-by: Karel Zak
+---
+ sys-utils/ipcutils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sys-utils/ipcutils.c b/sys-utils/ipcutils.c
+index 674b612..f2b04dd 100644
+--- a/sys-utils/ipcutils.c
b/sys-utils/ipcutils.c
+@@ -218,7 +218,7 @@ static void get_sem_elements(struct sem_data *p)
+ {
+ size_t i;
+
+- if (!p || !p->sem_nsems || p->sem_perm.id < 0)
++ if (!p || !p->sem_nsems || p->sem_nsems > SIZE_MAX || p->sem_perm.id <
0)
+ return;
+
+ p->elements = xcalloc(p->sem_nsems, sizeof(struct sem_elem));
Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations
* Cyril Brulebois [210430 09:47]: > Anyway, looking at the diffstat between 1.43.0 (last known good) and > 1.44.4 (first known bad), we have this: > 179 files changed, 19157 insertions(+), 7045 deletions(-) > > Between 1.43.0 and 1.44 (if it were an earlier known bad): > 165 files changed, 11006 insertions(+), 6766 deletions(-) > > which is a huge diff still. Indeed :-( > From your earlier report on #987449[1], something around > pango_default_break seemed to be happening. (In passing, I'd love to > learn how you generated it so that I can try my luck with #987377.) Quick steps: - I created a Debian bullseye install with a kernel version matching the installer, and also installed linux-perf(-5.10) - From the running, already stuck installer, I mounted the existing install, did the whole mount --bind stuff for sys, proc, dev. I cannot remember if one needs to actually chroot. - And then its mostly `perf top` and/or `perf record` + `perf report`. The former gives you an immediate view, while the latter writes into a file which you can look at later. Having more debug symbols would have been useful, but I did not manage to set that up. Chris
Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations
* Cyril Brulebois [210429 18:03]: > Cyril Brulebois (2021-04-29): > > This time around, testing 1.43.0 with debian/ carried over from > > debian/1.42.4-8, adjusted for docs (some files are missing) and symbols > > (one new symbol), the problem cannot be triggered in an obvious manner. > > > > Moving to 1.44* tags now. > > Alright, I think I'm hitting my limits here. > > Versions 1.44, 1.44.2, and 1.44.3 all fail in a similar way: ../pango/pangofc-font.c:371:44: error: ‘HB_OT_METRICS_UNDERLINE_SIZE’ undeclared (first use in this function); did you mean ‘HB_OT_METRICS_TAG_UNDERLINE_SIZE’? [..] Just passing by, but I can build 1.44.0 with Debians 1.44.6 debian/ directory, when adding this patch from upstream: https://gitlab.gnome.org/GNOME/pango/-/commit/d835004502c801a8a16cc436a38900e548ecde52.patch HTH, Chris
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
* Holger Wansing [210425 16:53]: > Chris Hofstaedtler wrote (Sun, 25 Apr 2021 14:13:05 +0200): > > While the -exact- same bug does not appear on the > > 20210424-7/amd64/iso-cd/debian-testing-amd64-netinst.iso image, I > > think the bug is still there, just better hidden. > > I managed to make debconf hang by: > > - select Marathi > > - on the next screen, click the Back button > > - in the now appearing list, select something else (I think two > > above from what was selected) > > - click the Continue button > > - hangs > > Yes, that way it is still reproducible with recent dailies or self-built > images. It might be helpful to try older images, and see if they also show the hang if triggered like this. Then finding the first one that doesnt ... maybe that yields a super[cg]lue. Chris
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
Hi, * Holger Wansing [210425 11:34]: > Chris Hofstaedtler wrote (Sat, 24 Apr 2021 23:45:13 +0200): > > * Holger Wansing [210424 21:42]: > > > While trying to debug another problem yesterday, I found that the RC1 > > > graphical > > > installer fails to go forward, when selecting one of these languages: > > > - Kannada > > > - Marathi > > > - Persian > > > - Sinhala > > > > I spent a few hours today on this issue, but did not get very far. > > Not totally unexpected if you know nothing about the installer. > > > > I have, however, a perf top output to share. I believe this more or less > > means > > the font rendering (pango, fontconfig) is stuck somehow? > > That might support my wild guess, that "Drop fontconfig tweaks" changings > could be related. > https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f > > However, I don't get it, why recent dailies are not affected, while RC1 (and > alpha3) is ??? While the -exact- same bug does not appear on the 20210424-7/amd64/iso-cd/debian-testing-amd64-netinst.iso image, I think the bug is still there, just better hidden. I managed to make debconf hang by: - select Marathi - on the next screen, click the Back button - in the now appearing list, select something else (I think two above from what was selected) - click the Continue button - hangs Chris
Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages
Hello, * Holger Wansing [210424 21:42]: > While trying to debug another problem yesterday, I found that the RC1 > graphical > installer fails to go forward, when selecting one of these languages: > - Kannada > - Marathi > - Persian > - Sinhala I spent a few hours today on this issue, but did not get very far. Not totally unexpected if you know nothing about the installer. I have, however, a perf top output to share. I believe this more or less means the font rendering (pango, fontconfig) is stuck somehow? Good luck, Chris Samples: 82K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 4370334125 lost: 0/0 drop: 0/0 Overhead Shared ObjectSymbol 5.29% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0x13010 d [.] pango_default_break 1.44% /lib/libharfbuzz.so.0.20704.00x769b0 ! [.] 0x000769b0 1.17% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x8487e B [.] g_utf8_get_char 1.05% /lib/libharfbuzz.so.0.20704.00x57448 ! [.] 0x00057448 1.04% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0x1fff2 d [.] 0x0001fff2 1.02% /lib/libharfbuzz.so.0.20704.00x8eff5 ! [.] 0x0008eff5 0.88% /lib/libharfbuzz.so.0.20704.00x611d0 ! [.] 0x000611d0 0.83% /lib/libharfbuzz.so.0.20704.00x5741e ! [.] 0x0005741e 0.81% /lib/x86_64-linux-gnu/libc-2.31.so 0x88bbd D [.] _int_malloc 0.80% /lib/libharfbuzz.so.0.20704.00x5a9f7 ! [.] 0x0005a9f7 0.79% /lib/libharfbuzz.so.0.20704.00x573d9 ! [.] 0x000573d9 0.71% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x3edd8 B [.] g_hash_table_lookup 0.70% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0xf5a0 d [.] g_utf8_get_char@plt 0.68% /lib/libharfbuzz.so.0.20704.00x573ee ! [.] 0x000573ee 0.60% /lib/libharfbuzz.so.0.20704.00x5a830 ! [.] 0x0005a830 0.57% /lib/libharfbuzz.so.0.20704.00x71730 ! [.] 0x00071730 0.57% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x70590 B [.] g_slice_free1 0.56% /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.330x1e7883 d [.] gtk_text_layout_get_line_display 0.55% /lib/libharfbuzz.so.0.20704.00x6a190 ! [.] 0x0006a190 0.52% /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2 0x34977 d [.] pango_shape_with_flags 0.51% /lib/libharfbuzz.so.0.20704.00xc210 ! [.] 0xc210 0.51% /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8 0x18fff B [.] g_object_unref 0.46% /lib/libharfbuzz.so.0.20704.00x578b2 ! [.] 0x000578b2 0.44% /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x6ff70 B [.] g_slice_alloc 0.43% /lib/x86_64-linux-gnu/libc-2.31.so 0x86b1d D [.] _int_free 0.41% /lib/libharfbuzz.so.0.20704.00x5a8a4 ! [.] 0x0005a8a4 0.40% /lib/libharfbuzz.so.0.20704.00x612b0 ! [.] 0x000612b0 0.39% /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8 0x2bbe8 B [.] g_signal_emit_valist 0.39% /lib/libharfbuzz.so.0.20704.00x717e0 ! [.] 0x000717e0 0.39% /lib/libharfbuzz.so.0.20704.00x5a86b ! [.] 0x0005a86b 0.38% /lib/x86_64-linux-gnu/libc-2.31.so 0x95760 D [.] __strcmp_sse2 0.38% /lib/libharfbuzz.so.0.20704.00x612d2 ! [.]
Bug#985956: #985956 - missing kernel module in installer
Control: reassign -1 src:linux Control: retitle -1 Missing kernel module in install for Raspberry Pi 4 Ben already said in this bug report that src:linux also needs to be fixed for this to work.
Re: Bug#982283: override: bsdmainutils:oldlibs/optional
* Samuel Thibault [210211 00:56]: > As I mentioned previously in the bug, bsdutils (required) recommends > bsdextrautils, so for that part things don't change. > > For calendar and cal/ncal, the question indeed holds. For bsdmainutils > maintainers: I guess the goal of splitting them out of bsdmainutils was > precisely to not install them by default? There were two goals: 1) for bsdmainutils delegate most things to util-linux (for various reasons). This was done by moving the utilities to bsdextrautils (from util-linux). 2) util-linux has the goal of making users "not pay" for tools they do not need. That was achieved by putting the tools into bsdextrautils and not into, say, bsdutils. The idea was that the tools would still be there "on a normal install" (however that is defined, ...), but not on minimal installs. Maybe bsdextrautils should be prio standard then? (I don't know exactly how d-i decides what to install for "standard system".) Thanks, Chris
Bug#982283: override: bsdmainutils:oldlibs/optional
Package: ftp.debian.org Severity: normal Hi, bsdmainutils has become a transitional package in bullseye. It would be great if we don't install it by default - right now its Priority: important. Changing this will probably make these utilities not available by default: from package ncal: cal ncal from package bsdextrautils: col colcrt colrm column hd hexdump look ul write Personally I know I'll keep those installed on machines that I use "to type", but certainly not on servers. Thanks, Chris
Bug#982244: debian-installer: please stop using genisoimage
* John Paul Adrian Glaubitz [210207 17:24]: > On 2/7/21 5:18 PM, Chris Hofstaedtler wrote: > > Untested patch below: > > An untested change to debian-installer isn't really something we can commit. I didn't suggest for you to commit it untested. Chris
Bug#982244: debian-installer: please stop using genisoimage
Control: tags -1 + patch * Chris Hofstaedtler [210207 16:17]: > As far as I can tell, debian-installer uses genisoimage only for > alpha and hppa. It _looks_ like the genisoimage invocations could > be trivially replaced with xorriso, but I do not have any systems to > test this. Untested patch below: >From 63dc1eea2e458c79dbe8439f3f437dbb4f72f92d Mon Sep 17 00:00:00 2001 From: Chris Hofstaedtler Date: Sun, 7 Feb 2021 16:16:18 + Subject: [PATCH] Replace genisoimage with xorriso --- build/config/alpha/miniiso.cfg | 2 +- build/config/hppa/miniiso.cfg | 3 +-- debian/changelog | 3 +++ debian/control | 2 -- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/build/config/alpha/miniiso.cfg b/build/config/alpha/miniiso.cfg index d53a64da9..740c92e10 100644 --- a/build/config/alpha/miniiso.cfg +++ b/build/config/alpha/miniiso.cfg @@ -20,7 +20,7 @@ arch_miniiso: ln -f $(BASE_TMP)netboot/initrd.gz $(TEMP_CD_TREE)/boot/root.bin cp boot/alpha/aboot.conf $(TEMP_CD_TREE)/etc/ cp /boot/bootlx $(TEMP_CD_TREE)/boot - genisoimage -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) + xorriso -as mkisofs -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) # make bootable for SRM isomarkboot $(TEMP_MINIISO) /boot/bootlx diff --git a/build/config/hppa/miniiso.cfg b/build/config/hppa/miniiso.cfg index 5c6cde9d2..25502e6f3 100644 --- a/build/config/hppa/miniiso.cfg +++ b/build/config/hppa/miniiso.cfg @@ -14,8 +14,7 @@ arch_miniiso: install -m 644 -D $(BASE_TMP)miniiso/vmlinuz*parisc $(TEMP_CD_TREE)/boot/vmlinux-parisc install -m 644 -D $(BASE_TMP)miniiso/vmlinuz*parisc64 $(TEMP_CD_TREE)/boot/vmlinux-parisc64 install -m 644 -D /usr/share/palo/iplboot $(TEMP_CD_TREE)/boot/iplboot - - genisoimage -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) + xorriso -as mkisofs -r -J -o $(TEMP_MINIISO) $(TEMP_CD_TREE) palo -f /dev/null $(foreach kern,$(TEMP_KERNEL),-k $(kern) ) \ -r $(TEMP_INITRD) -b $(TEMP_CD_TREE)/boot/iplboot \ -c "0/linux initrd=0/ramdisk" \ diff --git a/debian/changelog b/debian/changelog index 3ce445fac..bb835f531 100644 --- a/debian/changelog +++ b/debian/changelog @@ -19,6 +19,9 @@ debian-installer (20201203) UNRELEASED; urgency=medium * On hurd-i386, mips, and powerpc, add debian-ports-archive-keyring-udeb also in the monolithic images for bootstraping from debian-ports' unreleased. + [ Chris Hofstaedtler ] + * Replace genisoimage with xorriso + -- Shawn Guo Sat, 12 Dec 2020 12:11:26 + debian-installer (20201202) unstable; urgency=medium diff --git a/debian/control b/debian/control index e58e6cdd9..a153d5ddb 100644 --- a/debian/control +++ b/debian/control @@ -44,8 +44,6 @@ Build-Depends: # them. # Lintian: Yes, we know it's essential. We prefer not to # count on it remaining so. - genisoimage [!s390 !s390x], -# For making mini isos. genromfs [sparc sparc64], # Used for creating sparc floppies (which are not built by # default.) -- 2.30.0
Bug#982244: debian-installer: please stop using genisoimage
Source: debian-installer Version: 20201202 Severity: important Dear Debian Installer Maintainers, the debian-installer package depends on genisoimage, which as you know, comes from cdrkit. This causes cdrkit to be marked as a key package for the release. As far as I can tell, debian-installer uses genisoimage only for alpha and hppa. It _looks_ like the genisoimage invocations could be trivially replaced with xorriso, but I do not have any systems to test this. Please consider doing the replacements, or at least marking genisoimage [alpha hppa]. I think we all agree that cdrkit should better go away except for cases where there are no replacements yet. Many thanks, Chris
Re: Bug#963267: buster-pu: package multipath-tools/0.7.9-3+deb10u1
* Adam D. Barratt [200706 17:17]: > Control: tags -1 + confirmed d-i > > On Sun, 2020-06-21 at 16:53 +0000, Chris Hofstaedtler wrote: > > I'd like to push a fix for #959727 to buster. The bug causes us some > > trouble with block devices that are -sometimes- missing. I've tested > > the fix a while ago (on buster), and it seemed to help. > > > > I'd be OK with that, but as multipath-tools creates a udeb, this will > need a KiBi-ack. Uploaded, as KiBi-ack was given. Thanks, Chris
Bug#963573: partman-target: please add systemd hints to fstab
Source: partman-target Version: 115 Dear Installer Team, please consider adding words informing users they should run "systemctl daemon-reload" after changing /etc/fstab. With stale mount units from an older /etc/fstab, users might observe "interesting surprises", f.e. systemd might umount newly mounted filesystems, if the in-memory mount units conflict with info in /etc/fstab. Please find a potential patch attached. Thanks, Chris >From 0cae8e3d5e18fae9961894336f5cd9bd0fdcc7f2 Mon Sep 17 00:00:00 2001 From: Chris Hofstaedtler Date: Tue, 23 Jun 2020 23:24:33 +0200 Subject: [PATCH] create_fstab_header: add systemd hints systemd reads /etc/fstab to generate mount units. They become stale in-memory configuration after fstab is changed, and this can lead to nasty surprises. Example: systemd might unmount newly mounted filesystems, if /etc/fstab had conflicting info previously. Signed-off-by: Chris Hofstaedtler --- finish.d/create_fstab_header | 3 +++ 1 file changed, 3 insertions(+) diff --git a/finish.d/create_fstab_header b/finish.d/create_fstab_header index e99fa5e..560087a 100755 --- a/finish.d/create_fstab_header +++ b/finish.d/create_fstab_header @@ -11,6 +11,9 @@ case `udpkg --print-os` in # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # +# systemd generates mount units based on this file, see systemd.mount(5). +# Please run 'systemctl daemon-reload' after making changes here. +# EOF printf "%-15s %-15s %-7s %-15s %-7s %s\n" '# ' '' '' '' '' '' >> /target/etc/fstab ;; -- 2.27.0
Re: Bug#959744: util-linux: install all libs into usr/lib
Hi Cyril, * Chris Hofstaedtler [200504 21:30]: > util-linux installs libraries into /lib and /usr/lib. It has been > requested that it should install everything into /usr/lib. > AFAIK there is no tracking bug for it, so here it is. > > Michael Biebl has provided a merge request at > https://salsa.debian.org/debian/util-linux/-/merge_requests/8/diffs The util-linux udebs will move their libraries from /lib to /usr/lib; mbiebl claims this is no problem. FTR, the list of udebs is: fdisk-udeb libblkid1-udeb libfdisk1-udeb libmount1-udeb libsmartcols1-udeb libuuid1-udeb util-linux-udeb I hope the "no problem" bit is true; I'd like to hear back from you though before actually uploading. Thanks, Chris
Re: Bug#737658: some notes on util-linux takeover of eject
Hi, * Cyril Brulebois : > Michael Biebl (2017-10-24): > > But there is one complication: I noticed that eject in util-linux > > currently linux only. > > > > If we made the udeb linux-any, how would this affect the installer? > > It might mean a regression on kfreebsd-* (I don't see an eject-udeb binary > on hurd). I'm adding debian-bsd@ and debian-hurd@ in copy. > > > KiBi, is this a blocker in your opinion? > > While non-Linux issues aren't usually a blocker, I wouldn't welcome a > gratuitous breakage there. I'll let porters comment first. We didn't hear anything from porters since 2017. Would it be a good or a bad time to do the udeb changes soon? Chris
