- Package:
- haveged-udeb
- Source:
- haveged-udeb
- Submitter:
- Cyril Brulebois
- Date:
- 2025-01-18 07:09:02 UTC
- Severity:
- normal
- Tags:
Package: haveged-udeb
Version: 1.9.19-2
Severity: serious
Tags: d-i
Justification: makes the package useless, arguably critical
X-Debbugs-Cc: debian-boot@lists.debian.org
Hi,
haveged doesn't start at all in d-i, and that's not an apparmor issue
(#1087318):
haveged: command socket is listening at fd 3
haveged: Couldn't create named semaphore haveged_sem error: No such file or directory
While haveged is supposed to be less critical than it used to be at the
time it was added to the installer, I don't remember seeing a study
making it clear it can be removed. At this point of the release cycle,
I'd rather see haveged fixed anyway.
Cheers,
El 11/11/24 a las 13:08, Cyril Brulebois escribió: Hi. I started to use haveged for my archive rebuilds because the build-time tests of several cryptography-related packages used to fail. (If you are curious, see #834683, #841208, #850269 or #850299). The changes in Linux 5.4 are said to make haveged unnecessary, so I removed it from my autobuilding setup in 2023-11. Since then, I've built the whole of bullseye, bookworm, trixie and sid several times, using the kernel in bookworm, and I have not experienced any of those problems again. So I believe it's generally safe to stop using haveged at this point (if you are using a recent enough kernel). (Not an "official study", but maybe it might help). Thanks.
# for some reason, bugs to udebs do not shop up on # tracker nor on ddpo, thus reassigning for visibility reassign 1087324 haveged thanks I'll check, thanks for reporting. I think the udeb should be removed right after trixie, it's only useful in very limited edge cases when running specific workloads (of installed systems). of course. Regards, Daniel
(Adding debian-boot@ back, and quoting in full accordingly.) Daniel Baumann <daniel@debian.org> (2024-11-15): Please don't drop it before getting a green light from our side. I really want some investigation to happen first. Last time I've been told “it's no longer useful” that wasn't true, at all. Cheers,
Daniel Baumann <daniel@debian.org> (2024-11-15): Also, irk! That lost version information, and the new version migrated to testing despite the RC bug! Cheers,
indeed - that is very weird and looks like a bug :/ Regards, Daniel
We believe that the bug you reported is fixed in the latest version of
haveged, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1087324@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Daniel Baumann <daniel@debian.org> (supplier of updated haveged package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 12 Dec 2024 17:50:31 +0100
Source: haveged
Architecture: source
Version: 1.9.19-4
Distribution: unstable
Urgency: medium
Maintainer: Daniel Baumann <daniel@debian.org>
Changed-By: Daniel Baumann <daniel@debian.org>
Closes: 1087324
Changes:
haveged (1.9.19-4) unstable; urgency=medium
.
* Adding empty /dev/shm in haveged-udeb to fix fail-to-start because
/dev/shm/sem.haveged_sem cannot be created (Closes: #1087324).
Checksums-Sha1:
f5fc73c7a33c11542a0714012c64295f5eb909aa 2044 haveged_1.9.19-4.dsc
acaaebe59a284d2a76a84eec3834184f7b45d6b6 10912 haveged_1.9.19-4.debian.tar.xz
e3583f7b9b50aef49514c93d020abdc8173da2e0 7099 haveged_1.9.19-4_amd64.buildinfo
Checksums-Sha256:
48dfc00378c744593dc4ab782fc9d0b63efbb0d3f2dfe29750950123f82c05a1 2044 haveged_1.9.19-4.dsc
e0268c990be9e680a443229b3dc52b4704c8e958d5b73c2984f7f631fef1113f 10912 haveged_1.9.19-4.debian.tar.xz
5e617c293fcd4763d1b2e1c687f2bec3de1f5d60e8a3764ad6770e8a75907bdb 7099 haveged_1.9.19-4_amd64.buildinfo
Files:
7b9b9663772dab41031e870a9423e513 2044 misc optional haveged_1.9.19-4.dsc
f02c1093daf524c251d056872cc9cf10 10912 misc optional haveged_1.9.19-4.debian.tar.xz
140d9ba0e6404924d4a1d97799e9f128 7099 misc optional haveged_1.9.19-4_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmdbFL0ACgkQVc8b+Yar
uceLGg/+PZ+/TKEojUFvFV4wcju/jZ6RqLvSeuyVMkHLh4TFTISJhMBKywbYmhqv
2yveZpkIqSOIEgwj/nVh8+cEBwY4bg7ki31Mh9KP9hcNh0A0VI7d25/K/ALkbbU7
ECspd4KeMr1kaAzTP6JIJ4y8qLVfprdGdCVOYYvi0peXHxCQPdPVGM+ee1AwiW4D
SgLENIE8k76paGLRFGNiYIG8We8DMr4SGBlTrr/CVojbExIfOGzf9rPZ7LgfVuKZ
VRTejVTK0JUACgZHfLtzWIK8ZhiEpYhSBvaJl7VRbM0kCJ92sE+IzomvMSCGW7E1
1aAPFJNYuNukoUAOJ2rly2CHpZvOLOZwaxMEeRyCkSofNerHDZTKO9m60X5rNJQE
A7FrIphS29fSdDn7bG6hL4fR0RhSL2dgXw3MvQaJPWCSh3BoA+QonLHea+cQE2NZ
PDZpvkoJ55qVvR9QpRZWUsxFmp/5JyJA49qmQW4881DfEp9h+IJoymT2X1YOb31I
0lXbAZehvv0cSbGPE4Lu07z3flRHmFBaWcwerWyIGZWE3+zTO7YKldNyelQvlyQS
RN31YFqXAGmhpQpDhdJ5qqDg6IWXCrFSzjaRiQhW/x+i6e3tfxidFk71gAAeJGpT
nCZcb54WVl4WzFJ1cPQ6rQhbiAxa8MWJgw/nV7AqUn/uQDME4ak=
=tIlb
-----END PGP SIGNATURE-----
Debian Bug Tracking System <owner@bugs.debian.org> (2024-12-12): No, this doesn't work: you cannot ship subdirectories of /dev in a Debian package and expect it to work, that's a directory managed by udev. In this specific context, the directory exists in the tree where d-i is built, it also exists in the initramfses that are built, but it's masked at runtime, probably as soon as udev kicks in and the /dev mountpoint is mounted as devtmpfs. As a result, haveged still fails to start. Cheers,
Cyril Brulebois <kibi@debian.org> (2024-12-26): Also, Daniel's mails are bouncing… Cheers,
We believe that the bug you reported is fixed in the latest version of
haveged, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1087324@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Daniel Baumann <daniel@debian.org> (supplier of updated haveged package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 14 Jan 2025 11:39:21 +0100
Source: haveged
Architecture: source
Version: 1.9.19-7
Distribution: unstable
Urgency: medium
Maintainer: Daniel Baumann <daniel@debian.org>
Changed-By: Daniel Baumann <daniel@debian.org>
Closes: 1087324
Changes:
haveged (1.9.19-7) unstable; urgency=medium
.
* Using postinst in haveged-udeb to create /dev/shm at runtime (Closes:
#1087324).
Checksums-Sha1:
6ba7a832f70936e9934cc966c0da793902a248bf 1439 haveged_1.9.19-7.dsc
980448c172afd26898a2a25dc2b8e7930f42e4eb 11064 haveged_1.9.19-7.debian.tar.xz
1067bee0f71af21d68e3ca568179909cf5fe3528 6438 haveged_1.9.19-7_amd64.buildinfo
Checksums-Sha256:
8059f9ffad88c2c4896d72c2dc8c424c9e7831333a583cd7e687eaf355d7a01e 1439 haveged_1.9.19-7.dsc
403bb8d36f5e8f78f393d8af409b361e1cb9ed25867a0dc34b8c7bcc941d1843 11064 haveged_1.9.19-7.debian.tar.xz
d3d44e73abf4704ccecf13c610153395295d3620050a4936ad7828f7d66ff59e 6438 haveged_1.9.19-7_amd64.buildinfo
Files:
d32d8a938b37e04314595f73b9fc6fba 1439 misc optional haveged_1.9.19-7.dsc
48b9d66e8ba50cea5e89d6909c7c08a0 11064 misc optional haveged_1.9.19-7.debian.tar.xz
17318e08fc1f670827317736f676eda7 6438 misc optional haveged_1.9.19-7_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQQmmGg4gLaoSj0ERgL7tPDoCoAiLwUCZ4ZWeQAKCRD7tPDoCoAi
L9P/AP47v877Uwx4jI67CfwNg4/q/drS5XZYpdbDzRJ52bN4awD+LDEsWLAkoiHL
dHIRD1RfwKAoa2uyF86qyi4UJ0eOfgg=
=Fx34
-----END PGP SIGNATURE-----
Hi Daniel, Debian Bug Tracking System <owner@bugs.debian.org> (2025-01-14): Sorry, that cannot work either, for the same reason as before: anything stored in /dev goes away when (re)starting. I'd expect having to detect + fix the missing directory at runtime to be the (only?) solution. Maybe let's keep this bug report open at important severity for the time being? I've worked around this issue for Trixie Alpha 1 (via [1]), so it's no longer on the critical path. Then, depending on whether we keep embedding haveged in d-i, either we (I) can work on a patch that could be submitted upstream to do the mkdir dance at runtime, or we can drop haveged-udeb altogether. Doing that research isn't on my timeline for Trixie though. 1. https://salsa.debian.org/installer-team/rootskel/-/commit/e084102ac1e85d6de559d1192a0cf0168218b91d Would that work for you? Cheers,
Hi Cyril, Cyril Brulebois <kibi@debian.org> wrote: I'm afraid I don't understand - would you mind explaining it to me? I figured that when haveged-udeb is installed via anna, that postinst is then creating the directory. What do you mean with "restarting"? done that in 1.9.19-8. Regards, Daniel
We believe that the bug you reported is fixed in the latest version of
haveged, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1087324@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Daniel Baumann <daniel@debian.org> (supplier of updated haveged package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 14 Jan 2025 18:47:02 +0100
Source: haveged
Architecture: source
Version: 1.9.19-8
Distribution: unstable
Urgency: medium
Maintainer: Daniel Baumann <daniel@debian.org>
Changed-By: Daniel Baumann <daniel@debian.org>
Closes: 1087324
Changes:
haveged (1.9.19-8) unstable; urgency=medium
.
* Adding patch to create /dev/shm in haveged itself if it is not
existing (Closes: #1087324).
* Removing haveged-udeb.postinst again.
Checksums-Sha1:
a7267823d0eebcbb782cbe5a0b680cef6a2e558e 1439 haveged_1.9.19-8.dsc
c8b9f026947b7fd8b552c457d5caf3228a67a477 11456 haveged_1.9.19-8.debian.tar.xz
cfeae49cc72910d4f15f24b18968b9e5220eafd0 6438 haveged_1.9.19-8_amd64.buildinfo
Checksums-Sha256:
e2d09a3d598a2385076e83eb6c8bf6a5a5e1d831b7a9b4c3f5c376b3d6e05a47 1439 haveged_1.9.19-8.dsc
434dcdc281b3b350c649b5ce2c8e02f8f8cd094667551fc8dfb3fbd192f086b4 11456 haveged_1.9.19-8.debian.tar.xz
0f0a6d1b95fde2960389dc552610513cd1a81dc4d9e2a8f49ed8795f7604c966 6438 haveged_1.9.19-8_amd64.buildinfo
Files:
f92c37d44e873ada38ee69ddc50dff64 1439 misc optional haveged_1.9.19-8.dsc
dfeb44a8358cd7e1471ee49fdce5c6e5 11456 misc optional haveged_1.9.19-8.debian.tar.xz
fa6aa04eb43ba70cfbf71b77f9a61a85 6438 misc optional haveged_1.9.19-8_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQQmmGg4gLaoSj0ERgL7tPDoCoAiLwUCZ4axwwAKCRD7tPDoCoAi
L5i4AP4nvM+hZHe0TAs8mhSe8fqhjfOfKPgc7XDDOBWaEIN2bwEAkWK/HHxLMi1z
gwORkPGNUmQE8R12iRXcy343v0rg2gQ=
=KO9W
-----END PGP SIGNATURE-----
Hi Daniel,
Daniel Baumann <daniel@debian.org> (2025-01-14):
What I meant here is that in general, anything that's manually added to
/dev goes away when rebooting (restarting); but that's also true in our
case, when d-i “just” starts.
From an earlier reply:
No, this doesn't work: you cannot ship subdirectories of /dev in a
Debian package and expect it to work, that's a directory managed by
udev.
In this specific context, the directory exists in the tree where d-i
is built, it also exists in the initramfses that are built, but it's
masked at runtime, probably as soon as udev kicks in and the /dev
mountpoint is mounted as devtmpfs.
To expand on this a bit, we start haveged at the very beginning of the
d-i runtime, so it's pulled during the build of the d-i package, not at
runtime. So “the directory exists in the tree where d-i is built” means
e.g. build/tmp/netboot-gtk/tree/dev/ in the src:debian-installer build
tree, for the netboot-gtk target; and even if the contents of the /dev
directory there makes it into the target system, that's getting masked
when d-i starts, once udev kicks in and /dev is mounted as a tmpfs on
top of it.
Thanks, I'll check that once I have a little more time.
Cheers,
Hi Cyril, I understand the generic/non-udeb case, but didn't get the d-i one. When haveged is included in the image (that was the missing part for me, I thought it's installed later on), then all is clear, thanks. Regards, Daniel