This sounds reasonable to. It looks like you beat me to this with an
NMU. Thanks!
On 2024-03-15 04:08, Gianfranco Costamagna wrote:
Package: libgnt
Version: 2.14.4-1.1
Severity: serious
Tags: patch
Hello, I found some runtime dependencies, such as removed libglib2.0-0
breaking every 32bit
(Replying via mobile, so non-Debian address.)
It should be reasonably possible to convert this to .d style. I will have to
dig into this to fully consider all the implications, especially around
handling upgrades. I think part of the issue here is that ntpd logs there by
default. That is, you
Control: reopen -1
On 2024-03-12 11:10, MOESSBAUER, Felix wrote:
On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote:
This is intentional. The logging is optional and whether the
directory
exists controls this.
Hi Richard,
that's a quite uncommon interface. Is this at least documented
I think, but am not sure, that this is now functionally a duplicate of
#1060506. That one tells me to change it from systemd to systemd-dev
because:
Since systemd_253-2 [1], these two pkgconfig files have been split
into a separate package named systemd-dev. This package is arch:all,
I agree that the description, as provided, would be a bug.
However, I cannot reproduce this.
Can you provide your ntp.conf file, in full, please?
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
If I'm understanding this correctly, I just need to install a file with
the contents "ntpsec.service" to
/usr/lib/systemd/ntp-units.d/50-ntpsec.list. That's easy enough to do.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 2023-12-26 22:02, Martin-Éric Racine wrote:
On Wed, Dec 27, 2023 at 5:54 AM Richard Laager wrote:
On 2023-12-26 21:43, Martin-Éric Racine wrote:
Looking at the diff for the Hurd port
What Hurd port?
https://deb.debian.org/debian-ports/pool-hurd-i386/main/n/ntp/
That is the wrong
On 2023-12-26 21:43, Martin-Éric Racine wrote:
Looking at the diff for the Hurd port
What Hurd port?
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 2023-12-26 02:38, Martin-Éric Racine wrote:
On Mon, Dec 25, 2023 at 12:20 AM Richard Laager wrote:
If past me was correct, without systemd at build-time, waf will not
install the systemd units. Then we will end up with other failures in
debian/rules or from the .install files
On 2023-12-12 04:52, Martin-Éric Racine wrote:
Build-Depends: systemd must be changed to systemd [linux-any], since systemd
has not been powerted to non-Linux platforms.
I suspect that change would be necessary, but not sufficient.
In commit 7f969a0ecab4ef3ab50defd4fe9d7e7a47817dbe, I wrote:
Control: fixed 1.2.2+dfsg1-3
This looks to be the same as #1052664.
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 2023-12-18 16:15, Bob Proulx wrote:
Package: ntpsec
Version: 1.2.2+dfsg1-3
Severity: normal
Tags: patch
Every time the ntpsec package upgrades it attempts to unconditionally
add the ntpsec user and group as per the following postinst snippet.
addgroup --system --quiet ntpsec
On 2023-12-22 05:32, Stefan Bauer wrote:
Apparmor denies creation of /var/lib/ntp/drift-tmp.
Where are you getting /var/lib/ntp/drift from?
The ntpsec package in Debian has (from when both ntp and ntpsec existed
in Debian) everything namespaced under "ntpsec". It uses
On 2023-12-20 09:57, Sven Joachim wrote:
I have not tested it myself, but these errors should be fixed in libgnt
2.14.4 which has been released upstream the other day. See
https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which
explicitly mentions this bug.
Thanks for letting me
From ntpdate (the wrapper):
# Known bugs:
# * The -e and -p options of ntpdate are not yet implemented.
# * ntpdate took 4 samples and chose the best (shortest trip time).
# This takes the first.
I suppose there are maybe 4 options here:
A) Do nothing.
B) Change adjtimex to not pass -p.
C)
On 2023-08-15 10:35, Santiago Vila wrote:
Either a missing /var/log/ntpsec directory is considered a "supported
configuration" or it's not.
I agree with you on the general point.
I'll process this bug in more detail when time allows, in the relatively
near future. I currently expect the
The "pool" directive spins up more associations than it needs and then
prunes them back (which takes a while).
https://docs.ntpsec.org/latest/quick.html#pool
https://docs.ntpsec.org/latest/discover.html#assoc
With 4 pool servers each returning 4 A records and one of them returning
4
Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117
Feedback welcome!
1. I brought back some of the (manual) postrm bits for the ntp &
ntpdate packages. This was something I should have preserved when
making the transitional packages.
Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117
Feedback welcome!
1. I brought back some of the (manual) postrm bits for the ntp &
ntpdate packages. This was something I should have preserved when
making the transitional packages.
Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117
Feedback welcome!
1. I brought back some of the (manual) postrm bits for the ntp &
ntpdate packages. This was something I should have preserved when
making the transitional packages.
Is this reproducible for you? If you have experience with building from
source, upstream has proposed the following patch. Otherwise, I could
build a test package for you.
diff --git a/ntpd/nts_cookie.c b/ntpd/nts_cookie.c
index 166d0230f..a73955fb7 100644
--- a/ntpd/nts_cookie.c
+++
Some questions from upstream, with my commentary added...
How busy is this sustem? Is it just a simple client or also a server? If
server, how busy?
From the stack trace, the server side is trying to decode a NTS cookie. Is this
box setup as a NTS server? That needs a certificate and key so
I forwarded this upstream. I'm not sure how much upstream will care. But
hopefully I can get a firm answer either way.
--
Richard
On 2023-06-28 20:14, forest.ow...@riseup.net wrote:
On 2023-06-28 02:39, Richard Laager wrote:
The original submitter replied off the tracker (probably by accident). I'll
summarize here.
The ntp.conf he included is the stock ntp.conf.
He indicated he will try to get a backtrace.
I'm trying
On 2023-06-27 17:35, Bastian Germann wrote:
Am 28.06.23 um 00:13 schrieb Richard Laager:
The last bugfix release took them more than 3 years and when #767 is
released is unknown.
When a release happens is irrelevant, as you can carry #767 as a patch
in the Debian package until then.
Even
The original submitter replied off the tracker (probably by accident).
I'll summarize here.
The ntp.conf he included is the stock ntp.conf.
He indicated he will try to get a backtrace.
--
Richard
Wait a minute... You are a maintainer for cyrus-sasl.
You have already addressed the BSD-4-clause-KTH in the latest upload.
You also fixed debian/copyright to reference BSD-3-Clause-Attribution in
the latest upload. That license is fine for the reasons I mentioned.
That just leaves the MD5
On 2023-06-27 16:19, Richard Laager wrote:
For BSD-3-Clause-Attribution
BTW, my suggestion of asking CMU to drop the clause should not be read
as taking or agreeing to the position that it is GPL-incompatible.
I don't actually see an incompatibility with BSD-3-Clause-Attribution
Bastian,
I see you have raised the severity on this bug again.
What is your goal here?
Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500.
Quickly taking that list through UDD gives me just over 4,500 source
packages. Surely, a large number of those are going to be GPL
On 2023-06-27 16:19, Richard Laager wrote:
For RSA-MD, I'd imagine there are other MD5 implementations that could
be dropped in relatively easily.
Also, Bastian Germann mentioned in bug #1036113:
"See https://github.com/cyrusimap/cyrus-sasl/issues/513 for an
implementation that leaves
On Thu, 13 Apr 2023 14:36:12 +0200 Bastian Germann wrote:
Hi Philipp,
Thanks for clarifying that. There is one file in cyrus-sasl2 that is licensed under BSD-4-clause-KTH (which really has
an advertisement clause), which we can get rid of; see https://github.com/cyrusimap/cyrus-sasl/pull/724.
I'm not sure if you saw this, as he didn't send it directly to you, but
Matt Selsky asked:
> Can you please share your ntp.conf or if there's a particular server
> that seems to cause this segfault so that we can try to reproduce it?
Also, can you get a stack trace? There are some instructions
I've made a suggestion upstream of how we could do better here by making
this either a fatal error or at least a warning. If it was a fatal error
with a good error message, you would have figured it out immediately.
Let's see what people think of that.
--
Richard
On 2023-06-07 03:22, Rob Janssen wrote:
On 6/7/23 10:13, Richard Laager wrote:
On 2023-06-07 02:37, Rob Janssen wrote:
Yes I was using the "ntp" package before.
I have upgraded and it installed "ntpsec". I tried to remove it as I have no
need
for the "security&
On 2023-06-07 02:37, Rob Janssen wrote:
Yes I was using the "ntp" package before.
I have upgraded and it installed "ntpsec". I tried to remove it as I have no
need
for the "security" part but it removed "ntp" as well.
And then you presumably reinstalled it. Did this result in you starting
The answer is so obvious as soon as someone said it!
The default "minsane" is "3" (see "tos minclock 4 minsane 3" in
/etc/ntpsec/ntp.conf). Try commenting out that line, or if that doesn't
work, set both to "1".
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Since you've moved to chrony, this is probably moot for you. But in case
it affects anyone else, I forwarded this upstream:
https://gitlab.com/NTPsec/ntpsec/-/issues/790
Can you confirm you were running the "ntp" package on bullseye, not
"ntpsec"?
--
Richard
OpenPGP_signature
Description:
At first glance, I agree that these should be cleaned up. I just need to
actually do the work on this, ASAP, of course.
On 2023-05-22 08:40, Christoph Anton Mitterer wrote:
Oh and I've just noticed that I've had accidentally reported the bug
against ntpsec, not ntp.
That is correct, I
First, I've downgraded the severity on this to "important". We are
currently in a freeze with a release imminent. Removing pidgin from the
next Debian release is a significant step that we should not undertake
lightly. The issue at hand has existed for years, possibly a decade or
even two,
On 4/29/23 21:54, Steven Monai wrote:
I downloaded and unpacked this source on a Bookworm host. The build
system bundled with the source ("waf") seems to assume python 2.x, but,
unfortunately, Bookworm provides only python3. Any hints?
Quick approach is try this:
python3 waf configure ...
forwarded 1033088 https://gitlab.com/NTPsec/ntpsec/-/issues/785
thanks
Sorry for the delay in responding. I had hoped to try to reproduce this
myself. But I need to be honest with myself that it's simply not going
to happen.
Can you confirm whether you get either of these messages to stderr
On 9/27/22 14:00, Dima Kogan wrote:
root@shorty:/home/dima# ntpdate-debian
sed: can't read /etc/ntpsec/ntp.conf: No such file or directory
Yep, I see the issue. I'll upload a fix.
The missing file is in the "ntpsec" package, which is not in the
Depends, and maybe should be there. If I
I've submitted a patch upstream to suppress those messages except in
debug mode, since they are clearly confusing:
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1288
This bug probably should have been marked fixed already once the
upstream change to make them non-fatal was uploaded to
On 6/26/22 02:18, Klaus Ethgen wrote:
When package ntp is installed (from long history), the ntp daemon is
started by this /etc/init.d/ntp which uses user ntp:ntp. So all
auxiliary directories and files are owned by ntp:ntp.
I agree this is the expected "before" state.
When ntpsec starts to
I think this is because it Depends: a kernel << 5.18 and not
Conflicts/Breaks a kernel >= 5.18. Since you can install multiple kernel
packages, your existing kernel package is satisfying the dependency.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
[Responding on mobile.] I’ll take a look at it, as obviously it should be made
to work. But on Debian, there shouldn’t be a need for ntpleapfetch, as the
tzdata package ships the leap second file.
--
Richard
> On Jun 11, 2022, at 22:33, Martin Maney wrote:
>
>
> Correction: does not apply
On 5/25/22 02:05, Samtinel wrote:
Are other GTK apps working?
Yes, dino-im starts successfully.
GTK 2
Uh, this I did not check. I will do that when I get to my terminal later. So
you happen to know a simple GTK 2 package I can test on?
I don't. So much stuff has moved to GTK 3 (or now
I really don't know. Are other GTK apps working? If so, GTK 2 apps
specifically?
--
Richard
On 5/20/22 01:56, Evangelos Ribeiro Tzaras wrote:
Hi,
On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote:
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
Thanks for the patch! I'll upload a fixed version soon.
If you upload a new version, you (or I) can then close the binNMU
request
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:
Thanks for the patch! I'll upload a fixed version soon.
If you upload a new version, you (or I) can then close the binNMU
request, bug #1011201.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Control: notfound 1011166 pidgin/2.14.9-2
Control: tags 1011166 patch
On 5/17/22 15:34, Paul Gevers wrote:
I note that
the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to
/usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.
I converted from an ancient compat version to
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
chatty directly links against an internal library (libjabber.so.0) in
libpurple0. This is technically wrong, but at the moment, it is what it is.
I converted libpurple0 to multiarch, which
This has hopefully been fully fixed now (upstream). It will land in the
2.14.9 release, which should be coming next week. However, I've uploaded
a backport of it now.
--
Richard
On 1/31/22 19:37, Trey Glover wrote:
I had no idea that the treasury was doing this. Is there a code fix in place
yet?
In unstable, yes; it's fixed in 2.0.3-17. I wrote code to use the
Treasury API to generate old-style sbMM.asc files which are stored
(as always) in ~/.gbonds/
In
Package: ieee-data
Version: 20210605.1
I ran into this on 20180805.1 on Ubuntu 20.04, but I verified that the
same URLs are present in Debian's 20210605.1.
update-ieee-data references URLs (see the files_to_get variable near the
top) which which no longer work.
For example, this 404s:
On 1/25/22 17:08, Christoph Anton Mitterer wrote:
On Tue, 2022-01-25 at 16:34 -0600, Richard Laager wrote:
Consider a powerful attacker who a) runs a clocksource one trusts and
b) can block traffic to any other sources in the pool one uses?
Does NTP(sec) complain eventually (like too many
On 1/25/22 10:45, Christoph Anton Mitterer wrote:
On Tue, 2022-01-25 at 00:54 -0600, Richard Laager wrote:
There are two potential issues:
A) the server serves bogus/malicious time
B) a MITM messes with the time.
(A) is kinda what I'd want to prevent by having -g removed... at least
I'm relatively set on the idea of breaking out ntpdig, since it's the
renamed replacement for sntp which is broken out in src:ntp, which we
are talking (on debian-devel) about ntpsec replacing.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Control: reopen -1
On 1/24/22 13:25, Christoph Anton Mitterer wrote:
On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote:
Shouldn't -g be removed?
First off, note that the stock ntpsec.service has Restart=no, not
Restart=yes. So in the malicious/broken server scenario described,
ntpd
I have a few questions:
1. What is your use case for ntpdig and/or ntpdate (please be specific
which) if not for the hooks? Note that ntpdate is a wrapper script
around ntpdig that upstream does not install by default. And then
there's ntpdate-debian wrapping ntpdate.
2. My recollection is
A couple more things:
This seems like it would qualify for the stable-updates special case to
be pushed out before the next point release. Granted, this is not a
popular package, so I'm not sure if that affects the decision.
I don't immediately have plans to make updates for buster or
7:41:52.0
-0500
+++ gbonds-2.0.3/debian/patches/download-sites 1969-12-31 18:00:00.0
-0600
@@ -1,15 +0,0 @@
-Description: Remove snaught.com from the download list
- It didn't have the latest redemption data. This leaves only the
- official U.S. Treasury FTP site.
-Author:
Package: gbonds
Version: 2.0.3-8
Severity: grave
The U.S. Treasury has discontinued publishing the sbMM.asc files on
its FTP site. Unfortunately, this means that GBonds is unable to update
its redemption tables. Given that a, if not the, major reason to use
GBonds is to track the current
FWIW, you can force OpenSSL with this, which is what I do:
module(load="omrelp" tls.tlslib="openssl")
--
Richard
On a related note, I still need to bring this package's debehlper compat
level current. That would hopefully address these:
W: finch-dev: pkg-config-unavailable-for-cross-compilation
usr/lib/pkgconfig/finch.pc
W: libpurple-dev: pkg-config-unavailable-for-cross-compilation
I've uploaded a 2.14.7-2 with the upstream patch that should fix the
issue. If it doesn't, please let me know.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
On 10/1/21 7:11 AM, Václav Ovsík wrote:
This is the changeset causing segfaults.
Thanks! That's excellent that you bisected it all the way to a commit
(not just a release). I've copied this to the upstream bug report.
--
Richard
On 9/30/21 7:16 AM, Vaclav Ovsik wrote:
after ugprade of pidgin:amd64 to 2.14.7-1 from 2.14.1-1+b1
Are you in any position to bisect this by building the intermediate
2.14.x versions of Pidgin?
--
Richard
Thanks for your report. I was finally able to find some time today for
Debian work. I've updated to the latest Pidgin release. I do have a lot
more work to do on modernizing the packaging, but at least we're
shipping the latest upstream release now.
--
Richard
Package: systemd
Version: 247.9-2+b1
Severity: normal
$ pkg-config --variable systemd_system_unit_dir systemd
/lib/systemd/system
This should be /usr/lib/systemd/system instead. debhelper and lintian
now use/expect this path. See:
lintian-explain-tags systemd-service-in-odd-location
which
0+dfsg1/debian/changelog
--- ntpsec-1.2.0+dfsg1/debian/changelog 2021-01-20 20:36:38.0 -0600
+++ ntpsec-1.2.0+dfsg1/debian/changelog 2021-06-17 00:15:04.0 -0500
@@ -1,3 +1,9 @@
+ntpsec (1.2.0+dfsg1-4) unstable; urgency=medium
+
+ * ntpkeygen: Stop using # character: CVE-2021-22212 (Closes
I've uploaded a targeted fix to unstable and requested an unblock.
--
Richard
On 6/14/21 1:59 PM, Moritz Muehlenhoff wrote:
Package: ntpsec
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team
This was assigned CVE-2021-22212:
https://gitlab.com/NTPsec/ntpsec/-/issues/699
Patch:
Unfortunately, I don't see any references to 5353 in any of that.
However, I do see a mention of libgstmicrodns.so. I wonder if that's
related. Could you run:
dpkg -S /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstmicrodns.so
Then remove whatever package ships that library? You can reinstall
On 5/16/21 7:50 PM, Richard Laager wrote:
So it's happening in a child process.
Gary had an idea here... Pidgin generally only uses child processes for
DNS. Is it possible that you have some NSS plugin that is doing this?
Specifically, do you have libnss-mdns installed? I do, and I still
On 5/19/21 3:31 PM, Andreas Beckmann wrote:
Should libgnt-doc have a Depends/Recommends/Suggests: libglib2.0-doc ?
Yes. Thanks! In the course of investigating this, I found that I also
need libglib2.0-doc as a Build-Depends.
I've made both fixes, but intend to wait to upload until after the
On 5/16/21 3:21 AM, Slavko wrote:
I didn't see it, pidgin.log attached, but tcpdump shows them. Then i
tried it with -f option to strace:
Good thinking. So it's happening in a child process.
A good next step is to use gdb, but the fork will complicate things. I
think you can do "set
Can you try this:
rm -rf pidgin-test
mkdir pidgin-test
strace -e trace=socket,sendto pidgin -c pidgin-test 2>&1 | \
tee pidgin.log
Hopefully you'll see some socket() call for 5353 and some sendto() calls
as it sends the packets.
If so, then let's try to find out what is opening that
I was never able to reproduce this, nor was Gary (Pidgin lead developer).
Are you able to narrow this down at all? For example, if you run:
mkdir pidgin-test
pidgin -c pidgin-test
that will start with a blank config. Does it happen then? If not, try
adding accounts and/or enabling
I am not able to reproduce this. Do you have a packet capture?
Specifically, I'd like to know what sort of request it is.
--
Richard
This obviously took me a long time to get to, but I finally have.
1. As discussed with Ari, I have adopted the Pidgin package. I also
made a few cleanups at the same time. More extensive updating (e.g.
to modern debhelper compat) will probably have to wait until after
bullseye, given
On 1/19/21 6:09 PM, Diederik de Haas wrote:
# journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'
jan 20 00:45:32 kernel: audit: type=1400 audit(1611099932.689:41):
apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd"
name="/etc/ssl/openssl.cnf" pid=43157 comm="ntpd"
FWIW, I gave the patch a review and it seems sane to me. I also looked
at the package in unstable and confirmed that zgenhostid is being
installed to /sbin, not /bin.
--
Richard
On 12/21/20 2:51 AM, Debian Bug Tracking System wrote:
I'd expect the update of ntpsec triggers too the update of libssl1.1 to a
compatible version.
I ended up taking the opposite approach. I patched out the OpenSSL build
vs install version check from upstream NTPsec. While I definitely think
tags 971523 upstream
forwarded 971523 https://gitlab.com/NTPsec/ntpsec/-/issues/680
On 10/1/20 4:13 AM, Petter Reinholdtsen wrote:
> ntpdig: socket error on transmission: [Errno 101] Network is unreachable
>
> My guess is that you have working IPv6, while I do not.
>
> root@devuan-n900:~# ping6
On 10/12/20 9:29 PM, John Goerzen wrote:
> I have set up this system to use ZFS crypto rather than my more conventional
> zfs-atop-LUKS.
Can you explain a little bit more about how you setup your system?
This (root-on-ZFS with native encryption) already works for me on Buster
(with ZFS from
On 10/1/20 3:19 AM, Petter Reinholdtsen wrote:
> root@devuan-n900:~# /usr/sbin/ntpdate -b 0.debian.pool.ntp.org
> 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
> ntpdig: socket error on transmission: [Errno 101] Network is unreachable
NTPsec's ntpdate is just a
name):
--- mdadm-4.1/debian/changelog 2019-01-15 12:23:53.0 -0600
+++ mdadm-4.1/debian/changelog 2020-09-18 02:09:41.0 -0500
@@ -1,3 +1,9 @@
+mdadm (4.1-1+deb10u1) buster; urgency=medium
+
+ * Install misc/mdcheck (Closes: #960132)
+
+ -- Richard Laager Fri, 18 Sep 2020 02:
FWIW, this looks good to me. This is a new upstream release, but it's a
bug-fix only (adding a translation update at the same time seems fine).
Is there a particular reason this should NOT be uploaded?
--
Richard
signature.asc
Description: OpenPGP digital signature
On Sun, 10 May 2020 02:16:57 +0700 Павел Мотырев
wrote:
> There is a patch in attachment, that adds missed scripts into the
> package during build process.
syslog-events is already installed by a dh_installexamples call.
Also, I'm not sure why this would need to install the mdcheck script
into
On 9/7/20 4:00 AM, kvaps wrote:
> Thanks for your intention to help.
> It seems I already found the correct solution for my case,
>
> The problem persists only for the scripts/local, which is set by
> default (BOOT=local)
> We can review two cases where it might be caused:
>
> 1. LTSP and
On Tue, 9 Jun 2020 01:25:58 +0200 kvaps wrote:
> Package: initramfs-tools
> Version: 0.133+deb10u1
>
> Hi, after the change introduced in f8ceeb90 both zfs and http booting
> methods are not working anymore, it stops on the message:
>
> No root device specified. Boot arguments must include a
to make it easier to grep the files.
In the Root-on-ZFS HOWTOs that I maintain, I recommend people turn it
off for reason A.
At $DAYJOB, we use ext4 but turn off log compression for reason C (and
the implied B).
> p.s.: @Richard Laager: I quite did not get the point with the snapshots.
1. Write
for
_upstream_version_from_debian_upstream(). In a previous version, I
called it _mangle_upstream_version().
--
Richard
From 7cc1195bac48833fa551102a114d943be2cc006b Mon Sep 17 00:00:00 2001
From: Richard Laager
Date: Wed, 12 Aug 2020 21:54:06 -0500
Subject: [PATCH 1/4] import-orig: Fix a comme
On 7/30/20 1:58 PM, Antonio Russo wrote:
> Changing this line to
>
> pools=$(zpool list -H -o name | true)
This should be || true (two pipes, not one).
--
Richard
signature.asc
Description: OpenPGP digital signature
On 7/25/20 5:27 PM, Reiner Herrmann wrote:
> this has been fixed in version 1.1.9.
> The relevant commit is this one:
>
> https://gitlab.com/NTPsec/ntpsec/-/commit/ccdd9d4b941b30fc44b301595e42809dbe48628d
Thanks for that information! That saves me investigating. I need to get
1.1.9 packaged
On 6/9/20 7:02 PM, Wxcafé wrote:
> I don't use zfs-import-cache since it's a single pool that contains the
> root so it's in the kernel cmdline and imported at that point.
I wasn't asking about the pool cache, but the filesystem cache file used
by zfs-mount-generator. That would show all the
On 6/7/20 3:12 PM, wxcafe wrote:
> The systemd zfs-mount-generator script
> (/lib/systemd/system-generators/zfs-mount-generator) can break system
> boot if there are multiple datasets with the same mountpoint, because it
> ignores the zfs property canmount=noauto.
It certainly does not "ignore"
On 5/28/20 1:39 PM, Moritz Muehlenhoff wrote:
> Source: ntpsec
> Severity: normal
> Tags: security
>
> There was a "new" CVE assignment for ntp (2018 ID, but appeared today):
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8956
>
> Does this affect ntpsec?
Almost certainly not. NTPsec
On 5/19/20 7:34 PM, Real Carbonneau wrote:
> For example, every clone of a Debian system has a UUID (eg command "dmidecode
> -t 1"), thus it would be simple to generate a new hostid (possibly keeping the
> old one backed up) when the system uuid has been observed to have changed.
The BIOS UUID is
1 - 100 of 326 matches
Mail list logo
