Package: qa.debian.org
Severity: wishlist
Hi,
I've switched off TLS1.2 on my git server (to see what would be
brocken), one of them is VCSWatch:
Error: fatal: unable to access
'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/':
gnutls_handshake() failed: Error
Package: qa.debian.org
Severity: wishlist
Hi,
I've switched off TLS1.2 on my git server (to see what would be
brocken), one of them is VCSWatch:
Error: fatal: unable to access
'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/':
gnutls_handshake() failed: Error
Hi,
On 4/23/24 13:58, Jakub Ružička wrote:
but we've agreed the time has come to get extra testing & feedback
through Debian experimental.
yay, thanks!
[ we use knot-resolver at work for the central resolvers for the
university, and we love it. kresd 6 offers some nice improvements for
us,
Hi,
any news or ETA on this? do you need help?
Regards,
Daniel
Package: nwipe
Hi,
it would be nice if you could upload the current nwipe release to Debian.
Regards,
Daniel
Hi Tobias,
On 4/14/24 13:55, Tobias Frost wrote:
As I have the package ready, I'd like to propose to maintain it as new
package
In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces
(and 5 other extensions) as individual source packages as every other
gnome-shell extension
Hi Tobias,
On 4/14/24 13:55, Tobias Frost wrote:
As I have the package ready, I'd like to propose to maintain it as new
package
In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces
(and 5 other extensions) as individual source packages as every other
gnome-shell extension
Hi Tobias,
On 4/14/24 10:14, Tobias Frost wrote:
* Package name: gnome-shell-extension-vertical-workspaces
this is already included in src:gnome-shell-extensions-extra.
Regards,
Daniel
Hi Tobias,
On 4/14/24 10:14, Tobias Frost wrote:
* Package name: gnome-shell-extension-vertical-workspaces
this is already included in src:gnome-shell-extensions-extra.
Regards,
Daniel
close 1062068
thanks
Hi Anubhav,
thank you for your report.
Unfortunately you're using a very old version of nvme-cli that can not
be expected to work with recent firmware files.
Please upgrade nvme-cli to a more recent version (at last the one in
stable).
Regards,
Daniel
close 1064390 4.3-1
thanks
Hi Graham,
thanks - I've just uploaded 4.3.
Regards,
Daniel
retitle 1042906 please package new upstream version 9.x
thanks
Hi Lee,
any updates since last year? Ansible is currently at 9.x and I'd really
like to be able to use a recent enough version of ansible via debian
packages. Is there anything I could help you with?
Regards,
Daniel
Package: inkscape-open-symbols
Severity: wishlist
Hi,
thank you for maintaining inkscape-open-symbols.
As inkscape-open-symbols 1.2 is incompatible with inkscape 1.3 in
experimental, it would be nice if you could upload a newer version of
inkscape-open-symbols to experimental too.
Regards,
-1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+ * Uploading to bookworm.
+ * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann Sun, 14 Apr 2024 08:57:21 +0200
+
libnvme (
-1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+ * Uploading to bookworm.
+ * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann Sun, 14 Apr 2024 08:57:21 +0200
+
libnvme (
Package: frr
Severity: wishlist
Hi David and Ondrej,
it would be nice if you could upload the newly released frr version. If
you need/want help, I'm happy to do so, just let me know.
Regards,
Daniel
close 1067450
thanks
Hi,
On 3/21/24 18:03, Daniel wrote:
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
libwebsockets context creation failed
Mar 21 17:59:09
close 1067450
thanks
Hi,
On 3/21/24 18:03, Daniel wrote:
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
libwebsockets context creation failed
Mar 21 17:59:09
Package: libyang2
Severity: wishlist
Hi Ondrej,
it would be nice if you could upload libyang2 >= 2.1.128 as the new frr
release requires that. If you need/want help, I'm happy to do so, just
let me know.
Regards,
Daniel
Package: knot-resolver
Severity: wishlist
Hi,
it would be nice if you could upload knot-resolver 6.x to experimental.
Regards,
Daniel
Package: frr
Version: 9.1-0.1
Severity: normal
Hi,
please find the diff of the NMU from 8.4.4-1.1 to 9.1-0.1 as patch attached.
I noticed that frr could do with some more packaging love, I'd be happy
to help out if you need/want any.
Regards,
Daniel
frr_9.1-0.1.patch.gz
Description:
On 3/8/24 15:28, Helmut Grohne wrote:
> $FILE needs to be used here.
thanks.
> I was about to NMU zutils. Can you move ahead soonish? Once zutils is
> uploaded, I can go ahead with gzip.
sure, will upload in ~3h from now.
Regards,
Daniel
Hi Helmut,
thanks for the patch and work on this, much appreciated.
Just to be sure - I think I've found a typo in the latest iteration of
the patch, could you please confirm?
On 12/22/23 12:30, Helmut Grohne wrote:
I am happy with all of these changes moving to
unstable and trixie.
applied and uploaded both p-l-metapackages and bfh-metapackages to unstable.
Thanks for your patience.
thank you for all your work and help!
Regards,
Daniel
On 12/22/23 12:30, Helmut Grohne wrote:
I am happy with all of these changes moving to
unstable and trixie.
applied and uploaded both p-l-metapackages and bfh-metapackages to unstable.
Thanks for your patience.
thank you for all your work and help!
Regards,
Daniel
Hi Helmut
On 12/19/23 15:13, Helmut Grohne wrote:
Based on the work on molly-guard, I'm ataching an updated patch and it
really is a copy of the one on bfh-container #1055509, so see there for
the why its done the way its done.
great, thanks!
I'll test it tomorrow and upload.
Regards,
Daniel
Hi Helmut
On 12/19/23 15:13, Helmut Grohne wrote:
Based on the work on molly-guard, I'm ataching an updated patch and it
really is a copy of the one on bfh-container #1055509, so see there for
the why its done the way its done.
great, thanks!
I'll test it tomorrow and upload.
Regards,
Daniel
Hi,
On 12/11/23 15:52, grin wrote:
> Could you write at least a short note into README.Debian (or TODO) behind the
> reasons
> why ML is not compiled in?
I'm currently re-working the netdata packaging after the latest upstream
changes, which is quite some work.. this issue is definitely on the
Package: sentinelsat
Severity: wishlist
Hi Simon,
thank you for maintaining sentinelsat in Debian.
It would be nice if you could update it to the current upstream version
(1.2.1).
Regards,
Daniel
Package: icingaweb2-module-reporting
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-reporting in Debian.
It would be nice if you could update it to the current upstream version
(1.0.1).
Regards,
Daniel
Package: port-for
Severity: wishlist
Hi David,
thank you for maintaining port-for in Debian.
It would be nice if you could update it to the current upstream version
(0.7.2).
Regards,
Daniel
Package: icingaweb2-module-x509
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-x509 in Debian.
It would be nice if you could update it to the current upstream version
(1.3.2).
Regards,
Daniel
Package: icingaweb2-module-director
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-director in Debian.
It would be nice if you could update it to the current upstream version
(1.11.0).
Regards,
Daniel
Package: icingaweb2-module-cube
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-cube in Debian.
It would be nice if you could update it to the current upstream version
(1.3.2).
Regards,
Daniel
Package: icingaweb2-module-businessprocess
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-businessprocess in Debian.
It would be nice if you could update it to the current upstream version
(2.5.0).
Regards,
Daniel
Package: icingaweb2-module-graphite
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-graphite in Debian.
It would be nice if you could update it to the current upstream version
(1.2.4).
Regards,
Daniel
Package: geomet
Severity: wishlist
Hi Simon,
thank you for maintaining geomet in Debian.
It would be nice if you could update it to the current upstream version
(1.1.0).
Regards,
Daniel
Hi Olivier,
thanks you, that is much apperciated. I've been mostly away/VAC the last
two weeks, but I'll take care about this and the other patch later today.
Regards,
Daniel
On 11/15/23 19:52, Daniel Baumann wrote:
> for 18.2.0, there's only one trivial thing needed:
> https://git.progress-linux.org/packages/graograman-backports-extras/ceph/commit/?id=ed59c69244ec7b81ec08f7a2d1a1f0a90e765de0
or, for mainline inclusion, an alternative depends would be suitab
On 11/15/23 19:31, Gregory Farnum wrote:
> There are versioning and dependency issues
for 18.2.0, there's only one trivial thing needed:
https://git.progress-linux.org/packages/graograman-backports-extras/ceph/commit/?id=ed59c69244ec7b81ec08f7a2d1a1f0a90e765de0
then, the packages build
On 11/13/23 17:14, Luke Hall wrote:
> How is it that Proxmox were able to release Debian12 packages for Quincy
> quite some time ago?
because you can, as always, just (re-)build the package yourself.
> My understanding is that they change almost nothing in their packages
> and just roll them to
On 11/9/23 07:35, Nizamudeen A wrote:
> On the Ceph GUI, we thought it could be interesting to show information
> regarding the community events, ceph release information
like others have already said, it's not the right place to put that
information for lots of reasons.
one more to add: putting
close 1041689 1.5-2
thanks
Hi Marc,
On 8/8/23 11:07, Marc Bres Gil wrote:
> I've downloaded it from sid repositories, installed manually and seems
> to work.
thank you for confirming and reporting it in the first place, I'm
closing the bug now.
Regards,
Daniel
Hi Marc,
I think the bug you reported is fixed when using libnvme 1.5-2. Can you
confirm?
Regards,
Daniel
Package: isc-kea
Severity: wishlist
Hi,
upstream has releases 2.4.0 this week, it would be nice if you could
upgrade to it in Debian.
Regards,
Daniel
notfound 1040051 prompt-toolkit/3.0.38-2
retitle 1040051 autopkgtest err "Task was destroyed but it is pending!"
thanks
Hi,
thanks for reporting this. however, I can't reproduce it - I don't think
the bug is caused by prompt-toolkit but by anthing other that is
different between testing and
notfound 1040051 prompt-toolkit/3.0.38-2
retitle 1040051 autopkgtest err "Task was destroyed but it is pending!"
thanks
Hi,
thanks for reporting this. however, I can't reproduce it - I don't think
the bug is caused by prompt-toolkit but by anthing other that is
different between testing and
close 1035999
thanks
Hi Bill,
thank you for your patience - it took some time to systematically
reproduce your bug report.
I've tried the following permutations:
1. virtualbox with one disk:
1.1 encrypted-partition-on-luks (guided partitioning)
1.1.1 installing "standard" (no tasks
close 1039168 2.1.1-3
thanks
Hi,
On 6/26/23 00:21, bl...@debian.org wrote:
> deluge has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file.
thanks; this is not the case since deluge 2.1.1-3 from 2023-02-24
already, so closing.
Regards,
Daniel
close 1039181 0.7.2-6
thanks
Hi,
On 6/26/23 00:21, bl...@debian.org wrote:
> doodle has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file.
thanks; the daemon just has been removed due to #1038809, so, this
doesn't apply anymore to the current
Package: python-pgspecial
Hi,
thank you for maintaining pgsepcial in Debian. Now that bookworm has
been released, it would be nice if you could update the package to the
current upstream version (2.1.0).
Regards,
Daniel
retitle 893069 new upstream (4.4.10)
thanks
Hi Javier,
another two years have passed, bookworm has been released.. I must
assume that you're MIA and would like to take over the package. Are you
fine with this?
Regards,
Daniel
On 6/24/23 19:03, Christian Grothoff wrote:
> Do we know if there is anything else that replaces
> libgamin in terms of functionality?
it's seems gamin has been abandoned quite some time ago already in
favour of using inotify.
maybe using libinotify from
On 6/24/23 18:37, Daniel Baumann wrote:
> removed now, so nevermind, thanks, and sorry for the noise.
sorry, I wrote that while the package was still building.
without libgamin-dev (containing libfam.so), there's no doodled then. so
now we now :)
Regards,
Daniel
On 6/24/23 16:10, Christian Grothoff wrote:
> I'm a bit confused where the build-depends comes from
confusing indeed - it seems it has creeped in in 2007 (probably from the
'fam' removal at that time) and has never been questioned ever since.
removed now, so nevermind, thanks, and sorry for the
close 1030683 20230618-2
thanks
Hi,
I'd like to once again point out that I'm just interested in having
these extensions apt-get'able - I don't have any strong opinions either
way (one src-package per extensions, or one src-package for all
extensions), so I'm happy to do/migrate to whatever is
Hi Christian,
On 6/21/23 18:05, Simon McVittie wrote:
> This package has a Depends or Build-Depends on gamin, which is unmaintained
> upstream (see #1008205).
>
> The Linux kernel's inotify interface is a good replacement.
>
> We shouldn't really be shipping gamin in Debian 13, so this is
Hi Mark,
On 6/18/23 10:33, Mark Hindley wrote:
> I would still disagree with that.
just to avoid misunderstandings, my current understanding is:
1) technical issue: non-bootable systems on some non-systemd systems
- can be handled by moving mdadm initscripts into
Hi Mark,
On 6/17/23 19:13, Mark Hindley wrote:
> I am asking gently for the reinstatement of the recently removed non-systemd
> initscripts.
I hear you, but I prefer not doing this for the stated reasons.
How about getting the mdadm initscript into orphan-sysvinit-scripts? I
read the section
Package: force-ip-protocol
Version: 0.2.0-2
Severity: wishlist
Hi Thorsten,
thank you very much for force-ip-protocol, it's very handy.
Unfortunately the debian package does not install /usr/bin/ipv4 or
/usr/bin/ipv6. Assuming you did that deliberately (because they would be
quite generic; I
retitle 1037496 show note about missing boot integration for non-systemd
thanks
Hi Mark,
On 6/13/23 14:28, Mark Hindley wrote:
> It would be a great help to users of non-systemd inits if you could restore
> them.
thanks you for your report.
Personally I'm using systemd, but in general I fully
Package: rspamd
Severity: wishlist
Hi,
thank you so much for maintaining rspamd in debian.
Some time ago, there was a new upstream release with some nice new
features. It would be nice if you could update the package to the
current version (3.5).
Regards,
Daniel
found 1036528 1.12-1
notfound 1036528 1.12-2
close 1036528 1.12-2
thanks
Hi Christoph,
thank you for your report, this has been fixed in 1.12-2:
https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=4596dac645e794ca9153e92a99d176dfc357c2ce
I've confirmed that
close 1037014 2.1.1-1
thanks
Hi Matt,
thank you for your report. Yes, you're right that deluge-console is
broken in current unstable/testing, this has been fixed in the newer
upstream version that can be found in experimental, I'm
versioned-closing the bug as such.
The situation for deluge in
close 1032969 4.2+20230508-1
thanks
Hi,
this has been fixed by newer mdadm, at least above version, thus closing
the bug.
Regards,
Daniel
tag 1035999 + moreinfo
thanks
Hi Bill,
thank you for your report. In order to reproduce it, I've got some
questions for you:
* you were using a live image, did you install with 'debian-installer'
(the "Install" item in the boot menu) or 'calamares' (an installer
application you can
close 1033696
thanks
Hi Christoph,
thank you for your report.
The problem you're describing sounds like #1031695 from
dh_installsystemd. However, when looking at the mdadm 4.2-5 .deb file,
it's not affected by that.
Installing it on a clean system (with and without merged-usr) works both
as
On 5/15/23 12:11, Frank Schilder wrote:
> Because more often than not it isn't.
Sadly, I have to agree. We basically gave up after luminous, where every
update (on our test-ceph cluster) was a major pain. Until then, we
always updated after one week of a new release.
To add one more point..
The
ges/graograman-backports-extras/python-deepmerge/commit/?id=31931e8c6f8353b5b1f2d8e67a33f819eadcb8f0
Regards,
DanielFrom 97d7dfd07987f54409fd7773658423cb73c0045b Mon Sep 17 00:00:00 2001
From: Daniel Baumann
Date: Thu, 11 May 2023 13:17:34 +0200
Subject: [PATCH 1/3] Removing
Remove-vcver-depende
close 0.9.75-6
thanks
On 4/24/23 09:01, Michael Biebl wrote:
> Since those errors come for libmicrohttp, I'm going to reassing the issue
> Checking the changelog of libmicrohttp, there are quite a few changes
> regarding the handling of those options, see
>
On 3/28/23 08:56, nb wrote:
> when will 2.1.1 version be available?
it's in experimental as testing/unstable is frozen.
I'll upload to unstable once bookworm is released.
Regards,
Daniel
On 3/22/23 06:18, Cyrus Lien wrote:
> This bug still needs a boot script mounting efivarfs in initrd for
> systems whose rootfs are on RAID volume.
as the bug sais: this has been fixed in mdadm 4.2+20230223-1.
Regards,
Daniel
Hi Jon,
thank you for your report.
On 3/14/23 23:16, Jon wrote:
> I think its from this script:
>
> https://salsa.debian.org/debian/mdadm/-/blob/debian/4.2-4/debian/initramfs/scripts/local-bottom/mdadm
yes, it's a cosmetical error. I'll fix it in one of the next uploads,
but it doesn't meet
On 3/10/23 16:33, Benjamin Drung wrote:
> My preference is that I will do the initial packaging
> and you become the maintainer and I only an uploader for it.
sounds like win-win, thanks :)
> Where should I put the packaging git repository? To
> https://salsa.debian.org/debian/nvme-stas?
sounds
On 3/10/23 16:33, Benjamin Drung wrote:
> My preference is that I will do the initial packaging
> and you become the maintainer and I only an uploader for it.
sounds like win-win, thanks :)
> Where should I put the packaging git repository? To
> https://salsa.debian.org/debian/nvme-stas?
sounds
Hi Benjamin
On 3/10/23 14:40, Benjamin Drung wrote:
> I would love to team maintain that package.
I've had this on my todo list (but didn't fill a ITP for it), so I'm
happy to (co)maintain it or take over if you just want do to the inital
but not longterm work.
Regards,
Daniel
Hi Benjamin
On 3/10/23 14:40, Benjamin Drung wrote:
> I would love to team maintain that package.
I've had this on my todo list (but didn't fill a ITP for it), so I'm
happy to (co)maintain it or take over if you just want do to the inital
but not longterm work.
Regards,
Daniel
Hi Bernhard,
On 3/10/23 08:59, Bernhard Schmidt wrote:
> I can do so later, but I would prefer to fix these bugs in bookworm,
> where uploading a whole new upstream version is not accepted at this
> point in the release preparation
right, ideally we'd have both; if you need help I'm happy to
On 3/8/23 14:11, Marc Haber wrote:
> They pulled the plug on relay and client from now to immediately, with
> no obvious replacement on the relay side, and then announced EOL for
> the server for end of 2022, leaving the world without the reference
> implementation.
that was unfortunate,
Package: freeradius
Hi,
the latest upstream release (3.2.2) fixes some important bugs for us,
e.g. the fact that using an intermediate CA for which EAP-TLS, upstream
writes:
"It's also worth mentioning that FreeRADIUS 3.2.1 has an issue with
partial chains. E.g. if you have
Root CA ->
retitle 1032272 ITP: pysilfont -- utilities for font development
owner 1032272 Daniel Baumann
tag 1032272 + pending
thanks
Hi Daniel,
I've uploaded pysilfont 1.6.0-1 to NEW.
Regards,
Daniel
retitle 1032272 ITP: pysilfont -- utilities for font development
owner 1032272 Daniel Baumann
tag 1032272 + pending
thanks
Hi Daniel,
I've uploaded pysilfont 1.6.0-1 to NEW.
Regards,
Daniel
On 2/28/23 18:58, Thorsten Alteholz wrote:
> which one would you recommend?
we use those extensively (several thousands), ymmv:
https://www.flexoptix.net/de/p-8596-02.html
Regards,
Daniel
On 2/28/23 18:58, Thorsten Alteholz wrote:
> which one would you recommend?
we use those extensively (several thousands), ymmv:
https://www.flexoptix.net/de/p-8596-02.html
Regards,
Daniel
close 909533
thanks
Hi,
thank you for your report.
EFI system partitions (ESP) are partitions with a specific partition
type, regardless of the filesystem within (usually fat32).
Linux MD depends on having the partitions of type Linux raid, so mdadm
cannot be used for this use case.
The
close 763207
thanks
Hi,
thank you for reporting this.
I second upstreams opinion that there's nothing at the MD layer involved
here. Given that the bugreport is a single issue nobody else reported
and is 9 years old without followups since, I'm closing this bug.
If you can still reproduce the
close 759063
thanks
Hi,
thank you for reporting this.
I second upstreams opinion that there's nothing at the MD layer involved
here. Given that the bugreport is a single issue nobody else reported
and is 9 years old without followups since, I'm closing this bug.
If you can still reproduce the
On 2/27/23 15:25, Daniel Baumann wrote:
> ixgbe.allow_unsupported_sfp=1
I've rebootet the server again just to check and indeed, the above
override doesn't work anymore (also tried with ...=1,1 because it's a
two slots adapter, but doesn't make any difference).
So, seems the reason for y
On 2/27/23 15:25, Daniel Baumann wrote:
> ixgbe.allow_unsupported_sfp=1
I've rebootet the server again just to check and indeed, the above
override doesn't work anymore (also tried with ...=1,1 because it's a
two slots adapter, but doesn't make any difference).
So, seems the reason for y
Hi Thorsten,
On 2/25/23 11:56, Thorsten Alteholz wrote:
> The I225-V are working fine, the other four make trouble.
right, but those are copper interfaces.
> I am using transceiver modules AXS85-192-M3 from 10Gtek.
It looks like they are not flashable (like flexoptix and others), so I
presume
Hi Thorsten,
On 2/25/23 11:56, Thorsten Alteholz wrote:
> The I225-V are working fine, the other four make trouble.
right, but those are copper interfaces.
> I am using transceiver modules AXS85-192-M3 from 10Gtek.
It looks like they are not flashable (like flexoptix and others), so I
presume
close 784874 3.3.4-1
thanks
Hi,
this bug has been fixed in upstreams 3.3.3 version, the next debian
upload was 3.3.4-1, thus closing this bug accordingly.
Regards,
Daniel
close 569359
thanks
Hi,
there's nothing left; map file location has been straightened,
consistently using UUID in both mdadm and d-i helps got conceptionally
rid of this issue, closing the bug now.
Regards,
Daniel
close 985536 4.1-1
thanks
Hi,
looking at the commit logs, this seems to have been fixed somewhen up to
the 4.1 version of mdadm, closing accordingly.
Regards,
Daniel
close 609795
thanks
Hi,
thank you for your suggestion, however:
* carrying this as a debian-specific patch doesn't make sense,
and getting that accepted upstream is not likely either.
* in general people are supposed to know that /usr/share/doc/$package/
might contain further
close 763917 3.3.4-1
thanks
Hi,
this was included in upstream version 3.3.3, the next debian version to
that was 3.3.4-1.
Regards,
Daniel
close 619265
thanks
Hi,
thank you for your report, however:
* the patches do not apply to the current upstream version anymore.
* even if they would, they are way to much of a burden to maintain
downstream/keep them debian specific and therefore rebase for every
new version, so
close 821355
thanks
Hi,
thank you for reporting this issue, however, there's no actionable
content wrt/ mdadm.
If your individual partitions are not accessible, there's nothing mdadm
can do.
Regards,
Daniel
close 873767
thanks
Hi,
given that there is no more information provided and the actual issue,
if any, is a noop (no MD loaded), I'm closing this bug.
Regards,
Daniel
close 844640
thanks
Hi,
thanks for reporting this issue.
mdadm requires that the devices are actually detected and present, so,
if you're missing a module in your initrd, it's not something mdadm can
do something about it.
Regards,
Daniel
1 - 100 of 18869 matches
Mail list logo
