I should have Cc'd debian-kernel@lists.debian.org, but failed to do so.
As such now forwarding a copy. At the very least this involves the
Linux MD-RAID1 functionality, but I am unsure whether this is a Linux
kernel bug versus a Xen bug.
Forwarded:
I am also observing #988477 occur. This
On Wed, Aug 16, 2023 at 08:57:16AM +0200, Salvatore Bonaccorso wrote:
>
> On Tue, Aug 15, 2023 at 04:13:59PM -0700, Elliott Mitchell wrote:
> > Package: nfs-kernel-server
> > Version: 1:2.6.2-4
> >
> > Hopefully SSIA.
> >
> > `rpc.mountd` has a -N opt
Package: nfs-kernel-server
Version: 1:2.6.2-4
Hopefully SSIA.
`rpc.mountd` has a -N option to disable versions of NFS.
I had been previously using "-N 2", but that is now broken. The error
message was quite non-helpful ("nfsd2" if I recall correctly). Upon
removing "-N 2", luckily NFSv2
Package: src:linux
Version: 6.0.3-1~bpo11+1
Severity: wishlist
Looks like someone had the idea of a virtualized HW RNG. Yet looking at
the kernel source, there isn't a single actual implementation. Unless
I'm missing something, having CONFIG_HW_RANDOM_VIRTIO simply wastes
processor time during
On Sun, Apr 16, 2023 at 07:08:03AM +0200, Salvatore Bonaccorso wrote:
> CONFIG_AGP is built-in in Debian, in particular for:
>
> debian/config/alpha/config:CONFIG_AGP=y
> debian/config/amd64/config:CONFIG_AGP=y
> debian/config/hppa/config.parisc64:CONFIG_AGP=y
>
Package: src:linux
Version: 5.10.158+2
Severity: wishlist
Could AGP support be turned into a module for Debian kernels?
I'm tempted to suggest it shouldn't even be built for amd64, but does
seem reasonable for i686 kernels. Given this, module seems to make
sense.
--
(\___(\___(\__
Package: src:linux
Version: 5.10.106-1
Between 5.10.103-1 and 5.10.106-1 (image -13) something changed which
reliably causes what used to show as /dev/sda to show as /dev/sdb. Other
block devices plugged into the SCSI subsystem may have swapped around,
but I've yet to untangle the others.
A few
Having finally gotten to test this, the issue does NOT effect 5.10.70-1.
So far I've only gotten to try reboot, but that went fine.
Might have been an ACPI or Xen mismerge into 4.19. Alas this may simply
disappear into history.
--
(\___(\___(\__ --=> 8-) EHM <=--
Package: linux-source-5.10
Version: 5.10.70-1
SSIA. Debian's 5.10 configuration will NOT build without the "dwarves"
package (`pahole`). In light of this some package, likely
linux-source-5.10 should recommend "dwarves".
--
(\___(\___(\__ --=> 8-) EHM <=--
On Tue, Sep 21, 2021 at 06:33:20AM -0400, Chuck Zmudzinski wrote:
> I presume you are suggesting I try booting 4.19.181-1 on the
> current version of Xen-4.14 for bullseye as a dom0. I am not
> inclined to try it until an official Debian developer endorses
> your opinion that the bug I am seeing
On Mon, Sep 20, 2021 at 10:23:39PM -0400, Chuck Zmudzinski wrote:
>
> On 9/20/21 7:39 PM, Diederik de Haas wrote:
> > On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote:
> >> Merely having the path is a sufficiently strong indicator for me to
> >>
On Mon, Sep 20, 2021 at 06:29:49PM -0400, Chuck Zmudzinski wrote:
> On 9/20/21 1:43 PM, Chuck Zmudzinski wrote:
> >
> > On 9/20/21 12:27 AM, Elliott Mitchell wrote:
> >> On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> >>
> >>>
On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64
>
> linux kernel version: 5.10.46-4 (the current amd64 kernel
> for bullseye)
>
> Boot system: EFI, not using secure boot, booting xen
> hypervisor and dom0 bullseye with
On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> On Sat, 11 Sep 2021 13:29:12 +0200 Salvatore Bonaccorso
> wrote:
> >
> > On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
> > > An experiment lead to a potential alternat
On Sat, Sep 11, 2021 at 01:29:12PM +0200, Salvatore Bonaccorso wrote:
> On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
> > An experiment lead to a potential alternative explanation for #991967.
> > The issue may be ACPI (non-UEFI) powerdown/reset was broken at
An experiment lead to a potential alternative explanation for #991967.
The issue may be ACPI (non-UEFI) powerdown/reset was broken at
4.19.194-3. Presence of Xen on the system may be unrelated.
Failing that, it could be Xen and non-UEFI systems are effected. (Xen
was tried on a UEFI system and
Package: src:linux
Version: 4.19.194-3
Control: affects -1 src:xen
SSIA. Previous versions of 4.19 had no issues (4.19.181-1 according to
notes), but this cropped up with 4.19.194-3 (-1 and -2 weren't tested).
When a Xen domain 0 tries to reboot or powerdown the computer, it hangs
with the
found 935456 5.9.6-1~bpo10+1
quit
After having spent several hours on kernel compiles and experimenting
with the situation, I'm fairly sure this also applies to
linux-source-5.9.
Odd thing is, when I booted the device using the Tianocore implementation
it came right up with no problems. I'm
On Wed, Nov 25, 2020 at 02:30:30PM -0800, Elliott Mitchell wrote:
> The kernel versions are quite different, but #923814 reads suspiciously
> like it is a duplicate of #906225.
On double-checking, hit the wrong follow-up address. I was wanting to
advise the maintainers these two
found 939633 5.8.10-1~bpo10+1
severity 939633 important
merge 935456 939633
quit
I'm left suspecting bugs #935456 and #939633, are in reality a single
bug: Raspberry Pi device trees were garbled during Debian's 5.2 kernel
development.
They appear to remain very garbled, to the point of being
On Tue, Jul 14, 2020 at 08:20:29PM -0700, Elliott Mitchell wrote:
> I'm speculating the build may work if I run the correct rule, but I
> haven't yet identified that.
To make things easier for others, "all" was sufficient.
--
(\___(\___(\__
Package: src:linux
Version: 5.6.14-2~bpo10+1
Severity: important
I'm guessing this is isolated to ARM64 targets as I don't see other
reports. I'm having difficulty trying to taget "bindeb-pkg" with
linux-source-5.6.
During the initial phase build was terminating quickly, complaining about
On Mon, Jun 15, 2020 at 10:50:35AM -0400, J. Bruce Fields wrote:
> Honestly I don't think I currently have a regression test for this so
> it's possible I could have missed something upstream. I haven't seen
> any reports, though
>
> ZFS's ACL implementation is very different from any
On Sat, Jun 13, 2020 at 02:54:31PM +0200, Salvatore Bonaccorso wrote:
> indicated this was specifically observed on ZFS on Linux only. Seth
> Arnold's answer seem to be inline with that that the issue is more on
> the ZFS on Linux side and the issue keeps biting people a bit
> unexpectedly. Why
Bit more experimentation on this issue.
I tried a very small C program meant to create files with fewer
permissions bits set. This succeeded which strengthens the theory of
the umask getting ignored.
I haven't seen anything hinting whether this is more a client or server
issue.
I can speculate
Control: tags 962254 +security -unreproducible
Control: severity 962254 grave
On Fri, Jun 05, 2020 at 08:36:31PM +0200, Salvatore Bonaccorso wrote:
> This now let some rings bell, the described scenario is very similar
> to what was reported in https://bugs.debian.org/934160
>
> Respectively
>
I've run into a problem which produces the same behavior as bug #934160,
but attributed it elsewhere due to other observations.
What are the version(s) of the Linux kernel being used on your server and
clients?
I've confirmed using a 4.9 kernel on a client instead of a 4.19 kernel
also works
On Fri, Jun 05, 2020 at 08:36:31PM +0200, Salvatore Bonaccorso wrote:
> This now let some rings bell, the described scenario is very similar
> to what was reported in https://bugs.debian.org/934160
>
> Respectively
> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and
>
On Fri, Jun 05, 2020 at 08:44:26AM +0200, Salvatore Bonaccorso wrote:
>
> On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote:
> > Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
> > linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in partic
Package: src:linux
Version: 4.19.118+2
Severity: important
Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken.
Mounting an appropriate filesystem became unreliable, and once mounted
behavior is unpredictable.
Package: nfs-common
Version: 1:1.3.4-2.1
I'm using NFSv4 over TCP at the moment. If I don't specify rsize and
wsize on the client, either the client negotiates a wsize of 256KB or
defaults to a wsize of 256KB ("wsize=262144").
When dumping large amounts of data (moving 2TB of data around,
I have little option, but to agree with Reuben Thomas. The bottom of
README.Debian.nfsv4 has a date of "Wed, 11 Oct 2006 15:18:03 +0200", more
than 10 years old.
Even for Debian being in the distribution for 10 years no longer
qualifies as "rather new". A 2.6 kernel is no longer "recent" in
It has been quite some time since there was last any activity on #524458.
Is this problem still occuring for the submitter? Might it have been
fixed in one of the update rounds?
If this is still a problem, what version of the NFS protocol is in use?
In theory NFSv2 should be able to handle files
Package: linux-source-4.9
Version: 4.9.110-1
Anyone who was using jumbo frames inside a Xen guest was fine with
4.9.88-1+deb9u1, but a problem suddenly showed up with 4.9.110-1.
Discussion of problem:
https://lists.gt.net/xen/devel/519117
Something which acts like a working patch is here:
Package: src:linux
Version: 3.16.7-ckt25-2+deb8u3
Severity: important
Unfortunately I cannot finger the exact version where it happened, but it
appears one of the updates to linux-source-3.16 *broke* builds where
CONFIG_CGROUPS was left unset. While this may be an unusual
configuration, it
Reads like #696292 might be yet another manifestation of #588675, or
perhaps #588675 is the root cause (or related to the root cause) of
#696292.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
Control: tags -1 patch
On Fri, Jun 17, 2016 at 11:28:27PM +0100, Ben Hutchings wrote:
> On Fri, 2016-06-17 at 12:27 -0700, Elliott Mitchell wrote:
> > Package: linux-source-3.2
> > Version: 3.2.81-1
> > Severity: important
> >
> > SSIA:
> >
> &g
Okay, looked through and not quite the problem I thought. Problem is the
section added to fs/fcntl.c:setfl() depends upon CONFIG_MODULES being
enabled. Certainly turning off kernel modules isn't all that common, but
it is a situation that is actively used for some situations.
I also note the
Package: linux-source-3.2
Version: 3.2.81-1
Severity: important
SSIA:
CC fs/fcntl.o
fs/fcntl.c: In function 'setfl':
fs/fcntl.c:186:31: error: dereferencing pointer to incomplete type
fs/fcntl.c:187:30: error: dereferencing pointer to incomplete type
make[2]: *** [fs/fcntl.o] Error 1
For some time I'd been trying to search for a cause of #588675. Looks
like I finally searched for the right string (problem is "root" occurs in
many places inside the Linux kernel source).
Looks like the key file is linux/init/do_mounts.c:
Appears the line:
ROOT_DEV =
Control: reopen 826999
On Sat, Jun 11, 2016 at 10:06:16AM -0700, Elliott Mitchell wrote:
> On Sat, Jun 11, 2016 at 01:15:18PM +0100, Ben Hutchings wrote:
> > I make no judgement about the significance of that bug. ??But if you
> > refuse to answer a maintainer's reasonable
On Sat, Jun 11, 2016 at 01:15:18PM +0100, Ben Hutchings wrote:
> Control: forcmerge??588675 -1
>
> On Fri, 2016-06-10 at 18:16 -0700, Elliott Mitchell wrote:
> > The kernel build scripts are confused by what the SCSI subsystem produces
> > in /proc/mounts:
>
> This is
Package: src:linux
Version: 3.2.63-2
Control: found -1 linux/2.6.18
Control: found -1 linux/3.16.7-ckt25-2
Control: found -1 linux/3.16.7-ckt20-1+deb8u3
Control: found -1 linux/3.2.78-1
Control: found -1 linux/3.16.7-ckt11-1+deb8u6~bpo70+1
Control: found -1 linux/2.6.32
The kernel build scripts
On Fri, Jun 10, 2016 at 10:19:47PM +0100, Ben Hutchings wrote:
> Are you using LILO? ??Are you specifying the root device by name or
> UUID?
I'm quite certain that is completely irrelevant. Either of those, or
even allowing the rdev field in the kernel image should result in the
device being
Control: retitle 588675 SCSI subsystem loses name of root device on boot
Control: severity 588675 normal
Control: found 588675 3.2.78-1
Control: found 588675 3.16.7-ckt20-1+deb8u3
Control: found 588675 3.16.7-ckt25-2
Control: found 588675 2.6.18
According to the advanced information on the BTS,
On Mon, Apr 11, 2016 at 01:34:56AM +0100, Ben Hutchings wrote:
> On Sun, 2016-04-10 at 14:32 -0700, Elliott Mitchell wrote:
> > On Sun, Apr 10, 2016 at 07:47:28PM +0100, Ben Hutchings wrote:
> > > That in no way contradicts what I said. :-) ??When I backport the linux
> &g
On Sun, Apr 10, 2016 at 07:47:28PM +0100, Ben Hutchings wrote:
> On Sun, 2016-04-10 at 11:09 -0700, Elliott Mitchell wrote:
> > On Sun, Apr 10, 2016 at 10:09:38AM +0100, Ben Hutchings wrote:
> > >
> > > On Sat, 2016-04-09 at 18:31 -0700, Elliott Mitchell wrote:
>
On Sun, Apr 10, 2016 at 10:09:38AM +0100, Ben Hutchings wrote:
> On Sat, 2016-04-09 at 18:31 -0700, Elliott Mitchell wrote:
> > Between 3.16.7-ctk20 and 3.16.7-ctk25 the kexec functionality of the
> > Linux kernel was damaged.The system I'm looking at uses a 3.3 kernel
> &
Package: linux-source-3.16
Version: 3.16.7-ckt25-1~bpo70+1
Between 3.16.7-ctk20 and 3.16.7-ctk25 the kexec functionality of the
Linux kernel was damaged. The system I'm looking at uses a 3.3 kernel
to load the "real" kernel off a filesystem and kexec into that. The 3.3
kernel was able to
On Thu, Dec 03, 2015 at 03:11:45PM -0800, Christian Kujau wrote:
> On 12/02/2015 04:30 PM, Elliott Mitchell wrote:
> > You're thinking of the wrong bug. #588675 is the bug # for /proc/mounts
> > having "/dev/root" listed as the device for the root filesystem. Your
>
Control: found -1 3.16.7-ckt11-1+deb8u6~bpo70+1
Control: found -1 2.6.32
Could you confirm a few things about what you've seen of bug 588675?
Did you observe the behavior prior to Debian wheezy/Linux kernel 3.2?
What type of disk/controller/disk subsystem is on your powerpc system?
>From your
On Wed, Dec 02, 2015 at 02:15:18PM -0800, Christian Kujau wrote:
> On 12/02/2015 01:23 PM, Elliott Mitchell wrote:
> > Could you confirm a few things about what you've seen of bug 588675?
> >
> > Did you observe the behavior prior to Debian wheezy/Linux kernel 3.2?
>
reassign 588675 linux-source 2.6.32
retitle 588675 SCSI subsystem forgets root device on boot
found 588675 2.6.18
found 588675 3.2.63-2
submitter 588675 !
quit
I suspect the list of kernel versions with this bug is rather longer, but
I'm merely including some of those I'm certain it does effect.
On Mon, Jan 05, 2015 at 03:17:28AM +, Ben Hutchings wrote:
Control: reassign -1 src:linux 3.2.63-2
Control: retitle -1 / left as /dev/root with non-initrd kernel
Control: severity -1 wishlist
Control: tag -1 upstream wontfix
On Sun, 2015-01-04 at 16:02 -0800, Elliott Mitchell wrote
#588675 may not be all that severe, but does cause issues with multiple
packages. The issue is sometime between Debian Etch and Debian Lenny the
line for the root filesystem in /proc/mounts stopped listing the actual
device (/dev/sda1) started listing /dev/root instead.
One crucial ingredient
From: Luk Claes l...@debian.org
The users option got broken with the latest release, despite working
correctly in 1:1.0.10-6+etch.1 (old stable). Non-root users can mount
filesystems listed in /etc/fstab that have users specified, but they
will be unable to unmount the filesystem
I should also add that I'm now dealing with nfs-common 1:1.2.2-4, and
mount 2.17.2-9 (current stable).
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) /
\_CS\ | _ -O #include
reopen 589118
quit
From: Ben Hutchings b...@decadent.org.uk
On Thu, 2010-07-15 at 13:48 -0700, Elliott Mitchell wrote:
Bzzzt! While the initrd= kernel command-line option and `rdev` kernel
settings are not completely orthogonal, they are mostly unrelated.
You obviously haven't read
reopen 589118
quit
From: Ben Hutchings b...@decadent.org.uk
On Wed, 2010-07-14 at 18:11 -0700, Elliott Mitchell wrote:
Package: initramfs-tools
Version: 0.92o
Subject tells the story. Appears the images generated by initramfs-tools
completely ignore the `rdev` setting that the kernel
Package: initramfs-tools
Version: 0.92o
Subject tells the story. Appears the images generated by initramfs-tools
completely ignore the `rdev` setting that the kernel was given to the
kernel. While 99% of users may be explicitly passing the root device via
passing root=/dev/foo through the
Package: initramfs-tools
Version: 0.92o
If the running kernel has had module support removed, you'll get a bunch
of errors of:
grep: /proc/modules: No such file or directory
The one place I found was in /usr/share/initramfs-tools/hook-functions,
the function manual_add_modules(). Looks like you
Package: initramfs-tools
Version: 0.92o
Severity: minor
Thankfully pretty harmless, despite the annoyance:
cpio: ./etc/udev/RCS: Cannot stat: No such file or directory
Looks like `/usr/sbin/mkinitramfs` is the culprit. In this case,
/etc/udev/RCS is a symbolic link to ../RCS
--
62 matches
Mail list logo
