Package: src:linux
Version: 5.10.223-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
In /etc/rc.local I write a text file to /dev/tty11.
I have getty on 1-6 as usual and syslog on 12.
After booting the system, I can confirm this works.
A day or two later (I have not timed this exactly),
I can st
Mike Castle dixit:
>Exactly. In my experience, running swapoff(8) _will_ take a long time
>if the swap area has a lot of content.
Yes.
>It will block until everything is moved out.
Unfortunately not. It will block until *almost* everything is
moved out. I think what we’re seeing is that the re
Helge Deller dixit:
> Maybe sigset_t needs to be removed from
> klibc/include/arch/parisc/klibc/archsignal.h ?
That (with a versioned Depends on the newer kernel headers)
or with a #if LINUX_VERSION_CODE < KERNEL_VERSION(6, 9, 0)
(which will end up causing similar hassle should the change
be back
Package: libklibc-dev
Version: 2.0.13-4
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, Helge Deller
] In file included from /usr/lib/klibc/include/signal.h:14,
] from /usr/lib/klibc/include/sys/select.h:11,
] from /usr/lib/klibc/include/unistd.h:13,
]
Emanuele Rocca dixit:
>The attached patch by Vladimir Petko was sent upstream and fixes the
>FTBFS on armhf/armel.
The patch is catastrophically wrong.
+- snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
++ snprintf(flushtime, sizeof(flushtime), "%lld\n", now);
Change that to:
+
Package: initramfs-tools
Version: 0.142
The update-initramfs manpage documents -k all, and I know I used
that in Kubuntu hardy times several times, but it does not work
any longer, it just does nothing.
Calling without -k of course only updates the image for the current kernel.
Feel free to down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Dixi quod…
>>(I will probably have to see how I can rip ipconfig off initramfs-tools
>>and plug iproute2 in (YY! (NOT!)) since I also got a v6-only machine
>>and the “ip=” kernel parameter is Legacy IP-only. Unless both are solved
>>problems alr
Diederik de Haas dixit:
>So it was present on 5.9.0-2 (5.9.6-1), but no longer on 5.10.X?
Yes to the former, unsure to the latter.
>Do you want to keep the bug open for your other/original system?
If you’d rather not, I can keep a note on my TODO for when the
other system is back up, then repro
Diederik de Haas dixit:
>Is this issue still happening?
Good question. The system currently suffers from fan error and
I don’t have the tuits to repair it, so I switched to a different
X61 Thinkpad, for now.
>The firmware file iwlwifi-4965-2.ucode hasn't been updated since 2009-07-09,
>but maybe
On Fri, 10 Nov 2023, Sven Joachim wrote:
>| 'cp -n' and 'mv -n' now exit with nonzero status if they skip their
>| action because the destination exists, and likewise for 'cp -i',
Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish
between error and declining to copy/move.
Package: src:linux
Version: 5.10.179-3
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
I have this in dmesg:
[0.00] microcode: microcode updated early to revision 0xa4, date =
2010-10-02
It would be very nice if this message also showed the revision *from*
which it was up
Dixi quod…
>My guess here is that it’s, as usual, the fault of qemu-user,
Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:
$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumpe
Hi Helge,
>Can you check if this patch fixes the problem:
>https://patchew.org/QEMU/mvmpm55qnno@suse.de/
>(linux-user: make sure brk(0) returns a page-aligned value, from Andreas
>Schwab)
I doubt it, klibc malloc uses mmap(2) normally.
(And given I tested it on a bullseye system, the mmap
Dixi quod…
>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*
retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks
venkata.p...@toshiba-tsip.com dixit:
>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt
Source: klibc
Version: 2.0.11-1
Severity: serious
Justification: ABI issue on release architecture
Tags: patch
On 64-bit MIPS platforms, struct stat’s members st_{a,m,c}time{,nsec}
and following (st_blksize, st_blocks) are mislayouted. Upstream git
commit 12f259dda1ef59b5f1f2fb67631dcbf94c18c56c f
Package: linux-headers-5.10.0-20-common
Version: 5.10.158-2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I think I reported the same thing against experimental some time ago,
but it now is a regression in stable. Building kernel modules shows:
tglase@tglase-edge:~/lnx/master/janz $ make
make -C
Donald Buczek dixit:
> To be fair, this daemon doesn't use /proc/pid/stat for that, but
> /proc/pid/comm
Yes, and that’s proper. The field in /proc/pid/stat is size-limited
and so not necessarily distinct.
> As /proc/pid/stat is also used in many places, it could as well use
> that to avoid cod
Donald Buczek dixit:
>No, Escaping would break existing programs which parse the line by
>searching for the ')' from the right.
Huh? No!
The format is "(" + string + ") " after all, and only the string
part would get escaped.
The only visible change would be that programs containing a
whitespac
On Sat, 26 Nov 2022, Alexey Dobriyan wrote:
>/proc never escaped "comm" field of /proc/*/stat.
Yes, that’s precisely the bug.
>To parse /proc/*/stat reliably, search for '(' from the beginning, then
>for ')' backwards. Everything in between parenthesis is "comm".
That’s not guaranteed to stay r
(this time with the correct address, sorry)
Hi,
I’ve noticed that sysvinit/sysv-rc start dæmons with a *lot* of
superfluous environment variables compared to manual invocation
with an environment cleaner of mine:
# cleanenv / env | sort
HOME=/
LC_ALL=C.UTF-8
PATH=/bin:/usr/bin:/sbin:/usr/sbin
I
Hi,
I’ve noticed that sysvinit/sysv-rc start dæmons with a *lot* of
superfluous environment variables compared to manual invocation
with an environment cleaner of mine:
# cleanenv / env | sort
HOME=/
LC_ALL=C.UTF-8
PATH=/bin:/usr/bin:/sbin:/usr/sbin
I checked /proc//environ for (exemplarily) cro
severity 1017760 normal
retitle 1017760 linux: possible data corruption on µSD card, might be the
hardware though?
thanks
Dixi quod…
>I have somewhat reason to at least suspect the µSD card this was
>installed on. But there was never anything in syslog/dmesg about
>it, so the Linux kernel clearl
close 930522
thanks
Salvatore Bonaccorso dixit:
>Is this issue still reproducible with a recent kernel?
I haven’t seen it in a while, indeed.
Package: linux-headers-amd64
Version: 6.0.8+1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de
apt-listchanges: Reading changelogs...
Calling ['apt-get', '-qq', 'changelog', 'linux-headers-amd64=6.0.8+1'] to
retrieve changelog
apt-listchanges: Unable to retrieve changelog for package linux-headers-am
Dixi quod…
>The effect is that /proc/[pid]/stat cannot be parsed the way it is
>documented, as it does not escape embedded whitespace characters;
… nor parenthesēs:
tglase@x61w:~ $ ./mk\)sh -c 'echo $$; sleep 10' &
[1] 13375
tglase@x61w:~ $ 13375
tglase@x61w:~ $ cat /proc/13375/stat
13375 (mk)sh
Package: src:linux
Version: 5.10.149-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de, adobri...@gmail.com
tglase@x61w:~ $ cp /bin/mksh mk\ sh
tglase@x61w:~ $ ./mk\ sh -c 'echo $$; sleep 10' &
[1] 12862
tglase@x61w:~ $ 12862
cat /proc/12862/stat
12862 (mk sh) S 12649 12862 12649 3483
Thorsten Glaser dixit:
>I’ve recently been getting filesystem corruption on this system, which,
>incidentally, is a fresh-ish installation since I’ve been hit by the
I have somewhat reason to at least suspect the µSD card this was
installed on. But there was never anything in syslog/dmesg
Package: src:linux
Version: 5.10.136-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
My network just ceased working, and I can’t get it back up,
even with rmmod.
More log follows. Notes (more inline):
• those “Microcode SW error detected” seem to be normal,
I’m getting those all the time (b
On Wed, 31 Aug 2022, S. wrote:
> laptop. It would be great if the 20210818-1 firmware version could be offered
> in Backports.
Backports are not to fix bugs in stable. Issues like this should
be fixed via the normal stable channels if possible and the normal
bugtracker is used to track that.
bye
Package: linux-headers-5.19.0-trunk-amd64
Version: 5.19-1~exp1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
In building an out-of-tree kernel module I wrote on 5.19 (to test
compatibility), I noticed a new error message.
/usr/lib/linux-kbuild-5.19/scripts/Makefile.modfinal emits the
message, and
Package: src:linux
Version: 5.10.136-1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: t...@mirbsd.de
I’ve recently been getting filesystem corruption on this system, which,
incidentally, is a fresh-ish installation since I’ve been hit by the
“forgot LUKS password for the
Diederik de Haas dixit:
>I proposed my patch to expedite things and (much) prefer that Thorsten would
I’m not the author…
>I can do it, but I would like Thorsten to test the patch and confirm it
It’s obviously correct, it moves the nil check to the correct place.
I tested “the reverse” by doin
Diederik de Haas dixit:
>I'm talking here about 4.9, not 4.19 ...
Ah sorry, I can’t keep them distinguished in my head apparently, or
it’s too hot…
>> $ git tag --contains 92833e8b5db6
>> v4.19.221
>> […]
>
>Thanks for that command :-) I usually went through several manual steps to
>figure out
Diederik de Haas dixit:
>In branch 'linux-4.9.y' there is no qdisc_put function, so the above check
>seems rightly in qdisc_destroy there.
Not any more. Since…
$ git tag --contains 92833e8b5db6
v4.19.221
[…]
… qdisc_destroy was renamed to qdisc_put in 4.19, breaking modules (grr).
So yes, thi
Control: tag -1 - moreinfo
Diederik de Haas dixit:
>In Debian, the release before 4.19.235-1 was 4.19.232-1 which should also have
>this bug. The release before that was 4.19.208-1, which shouldn't.
>Can you verify that?
Not easily any more, but I know it worked some weeks ago, and I *think*
I p
Diederik de Haas dixit:
>It's a bit 'above my paygrade', but if qdisk_put() can accept a NULL pointer
>then I'm curious whether that would be allowed for other functions in that file
>as well ... there are several having "struct Qdisc *qdisc" as (only)
>parameter, but only qdisk_put() checks for N
Package: src:linux
Version: 4.19.235-1
Severity: critical
Tags: upstream
Justification: breaks the whole system
A recent upstream “stable” upgrade backported the removal of the
qdisc_destroy() function (which, in itself, is questionable enough
already and caused no small amount of fun) using qdisc
Bastian Blank dixit:
>The pool size for an RPNG is only the size of the state, nothing else.
Yes, and that is the problem. It was small before, it’s ridiculous now.
>might not have had any value before anyway. You just need to reseed on
>a regular interval.
Ugh. I recall reading something abou
Package: src:linux
Version: 5.10.120-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team
/proc/sys/kernel/random/poolsize is now 256 instead of 4096 bits,
which was already small before.
Why was such a change allowed into stable?
This also breaks rngd’s --fill-watermark optio
Diederik de Haas dixit:
>and the patch proposed by Ben, more then 6 years ago, hasn't been merged.
>
>As I don't know the reason it wasn't closed last year, I won't do it, but
>maybe it's time to finally close it?
If the bug persists, it’s still a bug, so don’t close it.
Prod them occasionally.
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
says to use, for example…
$ fakeroot make -f debian/rules.gen binary-indep_amd64_none_real
… to get the -common package, but this doesn’t. You (also?) need:
$ fakeroot make -f debian/rules.gen binary-inde
Package: linux-headers-5.17.0-rc8-common
Version: 5.17~rc8-1~exp1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Trying to build a kernel module against 5.17 shows several warnings:
W: /bin/sh: /usr/src/linux-headers-5.17.0-rc8-common/scripts/pahole-flags.sh:
inaccessible or not found
According
found 1004465 2.0.10-1
thanks
Dixi quod…
>Quite some files are missing:
[…]
>/usr/lib/klibc/include/alloca.h
[…]
>/usr/lib/klibc/include/arpa/inet.h
> /usr/lib/klibc/include/asm
> /usr/lib/klibc/include/asm-generic
>/usr/lib/klibc/include/assert.h
[…]
From this patter
Package: libklibc-dev
Version: 2.0.10-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@mirbsd.de
Quite some files are missing:
$ comm <($bullseye dpkg -L libklibc-dev | sort) <($sid dpkg -L libklibc-dev |
sort)
/.
/usr
/
close 988027
thanks
I guess it works as documented for klibc, even though this is a porting
hindrance so no need to keep this bugreport open. Deliberately closing
per control instead of done as the underlying issue is still present.
) (Closes: #943425)
+
+ -- Thorsten Glaser Thu, 27 May 2021 00:12:10 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp
Hello Ben,
any chance to upload at least the patch for s390x?
This affects a release architrecture, so I’d NMU this if
necessary, so we have it fixed in bullseye.
Thanks,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
,long}jmp always saves the signal mask (Closes: #988027)
+ * [s390x] Fix {set,long}jmp registers to save (Closes: #943425)
+
+ -- Thorsten Glaser Wed, 05 May 2021 21:38:31 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0001-kli
Hi Andreas,
>>> Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>>> other FPU registers not:
>
>I can confirm this. It is f8-f15 for the z/Architecture (64 bit).
thanks!
>It is f1, f3, f5, f7 for the ESA
>architecture (32 bit) which is still supported by Glibc and GCC.
Is this
Dixi quod…
>Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>other FPU registers not:
This needs to be fixed in klibc.
>>• klibc does not really support the FPU anyway
>
>… GCC chooses to allocate an FPU register for a pointer value.
This is a curiosity.
>>• the half of v10 th
Dixi quod…
>So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
>https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
>“the z/Architecture ABI,[11] used in Linux” a page down), while
>glibc’s save f8–f15 instead.
Jessica Clarke brought out docs saying f8‥
Package: libklibc-dev
Version: 2.0.8-6
Severity: serious
Justification: spec violation, affecting release architectures
X-Debbugs-Cc: t...@debian.org
Found during debugging of #943425:
- usr/include/setjmp.h
struct __sigjmp_buf {
jmp_buf __jmpbuf;
sigset_t
retitle 943425 klibc: [s390x] setjmp/longjmp do not save/restore all registers
in use
# because this affects a release architecture
severity 943425 serious
thanks
Recapping for the benefit of d-s390@l.d.o:
> The code in question (where it crashes) is thus:
>1607 */
>160
Package: libklibc-dev
Version: 2.0.8-6
Followup-For: Bug #943425
X-Debbugs-Cc: t...@debian.org
I am able to track this down on the porterbox zelenka.
$ apt-get source mksh
$ cd mksh-59c
$ mkdir -p build/klibc
$ cd build/klibc
$ cp /usr/lib/klibc/bin/mksh .
$ chmod +x mksh # because the x attrib
Hi Salvatore,
>If you can reproduce it with
>
>- the current version in unstable/testing
>- the latest kernel from backports
I still have the occasional freezes or crashes on that machine,
with nouveau, but nothing to reliably reproduce it. Basically,
if Xorg is left running for long, either it o
maximilian attems dixit:
>are there other dangling symlinks besides this three mentioned ones?
adequate reported only these three for this package; you can find
dangling symlinks, generally, with: (thanks XTaran)
find -L . -type l -ls
bye,
//mirabilos
--
FWIW, I'm quite impressed with
Package: firmware-misc-nonfree
Version: 20210208-2
Severity: normal
User: debian...@lists.debian.org
Usertags: adequate broken-symlink
X-Debbugs-Cc: t...@mirbsd.de
firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt ->
configs/t4-config-default.txt
firmware-misc-nonfree: broke
Package: src:linux
Version: 5.9.9-1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc:
t...@mirbsd.de,reply+aagshfu5klm2qb2dozdxppf5z5jydevbnhhcvex...@reply.github.com
A bit of backstory, since this is not the first place I had to
report this to (feels like being sent from P
Package: firmware-iwlwifi
Version: 20200918-1
Followup-For: Bug #934781
X-Debbugs-Cc: t...@mirbsd.de
It still happens.
[583944.226966] iwl4965 :03:00.0: Microcode SW error detected. Restarting
0x200.
[583944.226974] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[583944.2269
Package: firmware-misc-nonfree
Version: 20200918-1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de
I’m getting this during an upgrade in sid:
[…]
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.9.0-2-amd64
W: Possible missing firmware /lib/firmware
On Mon, 3 Aug 2020, Thorsten Glaser wrote:
> keep the code I currently have that compares byte 0 and 3, using
Actually not. I’ve added some debugging code with…
static size_t
cmsg_actual_data_len(const struct cmsghdr *cmsg)
{
union {
const struct cmsghdr *c
Hi Ben,
> For what it's worth, FreeBSD/Darwin and Windows also put 4 bytes of
> data in a IPV6_TCLASS cmsg. So whether or not it's "right", it's
> consistent between three independent implementations.
oh, thank you, I don’t have any of these systems around at the
moment, so checking them was tri
On Sun, 2 Aug 2020, Ben Hutchings wrote:
> The RFC says that the IPV6_TCLASS option's value is an int, and that
for setsockopt (“option's”), not cmsg
> No, the wording is *not* clear.
Agreed.
So perhaps let’s try to find out what’s actually right…
Thanks for helping,
//mirabilos
--
tarent so
Ben Hutchings dixit:
>ip(7) also doesn't document IP_PKTOPIONS.
Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found
the correct place in the kernel for what I do.
On the sending side, I use setsockopt with either
IPPROTO_IP,IP_TOS or IPPROTO_IPV6,IPV6_TCLASS to
set the default tra
Package: src:linux
Version: 5.7.6-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
I’m using setsockopt to set the traffic class on sending and receive
it in control messages on receiving, for both IPv4 and IPv6.
The relevant documentation is the ip(7) manpage and, because the ipv6(
retitle 964681 klibc: FTBFS: ld: cannot use executable file 'usr/klibc/libc.so'
as input to a link
thanks
Lucas Nussbaum dixit:
>> ld -m elf_x86_64 --build-id=sha1 -o usr/kinit/ipconfig/shared/ipconfig -e
>> main usr/klibc/interp.o --start-group usr/kinit/ipconfig/main.o
>> usr/kinit/ipcon
Michael Biebl dixit:
>Is this workaround permanent or will systemd FTBFS again in the future?
I’ve just verified that the upstream-merged fix, appearing in
linux-libc-dev 5.7.6-1 in sid, fixes this permanently.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://ww
Ben Hutchings dixit:
>This is the dpkg bug where it fails to replace a directory with a
>symlink. For some reason that requires workarounds in every other
>package instead of being fixed in dpkg.
Yeah, this is annoying, but AIUI they call it a feature; a local
admin can symlink directories aroun
Package: linux-image-amd64
Version: 5.6.14-2
Severity: serious
Justification: Policy 2.3
tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
total 0
tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
drwxr-xr-x 2 root root 4096 Okt 21 2019 /usr/share/doc/linux-image-amd64/
-- System In
tags 954294 + fixed-upstream
thanks
-- Forwarded message --
From: tip-bot2 for Andy Lutomirski
Message-ID: <159050477082.17951.1414743958663563425.tip-bot2@tip-bot2>
To: linux-tip-comm...@vger.kernel.org
Cc: Thorsten Glaser , Andy Lutomirski ,
Borislav Petkov
Helge Deller dixit:
>On hppa/parisc we still need executable stacks for the signal
>trampoline return code. Might your patch then maybe break fstype on
>hppa? I didn't tested it...
I think it only changed the assembly parts of the library to
signal to the linker that there’s no need for an execut
Package: firmware-realtek
Version: 20190717-2
Followup-For: Bug #953522
Control: forcemerge 947356 953522
Control: retitle 947356 W: Possible missing firmware
/lib/firmware/rtl_nic/rtl8125a-3.fw, rtl8168fp-3.fw for module r8169
The message is now:
update-initramfs: Generating /boot/initrd.img-5.
On Wed, 8 Apr 2020, Andy Lutomirski wrote:
> One might reasonably ask whether it makes sense for syscall nrs to be
> signed at all.
It doesn’t, but it’s probably this way for hysteric raisins.
> But regardless, this breaks userspace and we should fix it. I can
> whip up a patch to split it into
Package: firmware-misc-nonfree
Version: 20190717-2
Severity: normal
Setting up linux-image-5.5.0-1-amd64 (5.5.13-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.4.0-4-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.4.0-4-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5
On Wed, 8 Apr 2020, Ben Hutchings wrote:
> You should not expect me to spend time talking to upstream about non-
> release architectures. That is way down the priority list.
DevRef §5.8.3.(6) is a “must”, but you’re lucky: it turns out that
this is a recent isolated change, so I can write to the
Hello,
I’m writing to you because your name shows up on this:
commit 45e29d119e9923ff14dfb840e3482bef1667bbfb
Author: Andy Lutomirski
Date: Wed Jul 3 13:34:05 2019 -0700
x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long
Currently, it's an int. This is bizarre. Fortunately,
On Wed, 8 Apr 2020, Michael Biebl wrote:
>> Is this workaround permanent or will systemd FTBFS again in the future?
It is not inherently permanent. If a new libseccomp version gets
uploaded it will pop back up. In these cases, I’ll most likely
notice it due to Multi-Arch skew (my x32 system has l
Dear kernel team,
libseccomp uses the __NR_* constants from in its
macro SCMP_SYS() which is designed to return int.
However, on x32 some codes return unsigned long instead, breaking this.
The cause is that this…
> /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT
> 0x400
retitle 941597 linux: [dtb] Raspberry Pi 3B+: does not shut down (regression
against buster)
found 941597 5.2.9-2~bpo10+1
found 941597 5.2.17-1~bpo10+1
found 941597 5.3.9-3
thanks
As I wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939633#29
this is an issue in the DTB shipped with th
On Wed, 20 Nov 2019, Thorsten Glaser wrote:
> Please advice as to a fix ☻
By the advice of the original poster of this bugreport, we tried to
use the DTB from the buster kernel instead:
+ cp /usr/lib/linux-image-4.19.0-6-arm64/broadcom/bcm2837-rpi-3-b.dtb
/boot/firmware/bcm2710-rpi-3-b.
retitle 939633 linux: rpi3b+ hangs with kernels 5.2, 5.3 (device tree issue?)
notfound 939633 4.19.67-2+deb10u1
notfound 939633 4.19.67-2+deb10u2
found 939633 5.2.9-2~bpo10+1
found 939633 5.2.17-1~bpo10+1
found 939633 5.3.9-3
thanks
We’re currently suffering from a similar situation.
Debian buste
Control: block 943425 by 925358
I can’t debug this currently ☹ hitting qemu-user-static bugs.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
tags 925358 - unreproducible
severity 925358 minor
affects 925358 src:mksh
retitle 925358 klibc: [m68k] SIGKILL in mksh testcase mtest-external and others
(in qemu only?)
found 925358 2.0.7-1
affects 943425 src:mksh
thanks
This still happens. I’ll keep the bug so I can track it down.
bye,
//mira
Package: libklibc-dev
Version: 2.0.7-1
When building mksh against klibc on s390x, one testcase positively fails:
FAIL ../../check.t:funsub-2
Description:
You can now reliably use local and return in funsubs
(not exit though)
unexpected exit status 1
Package: linux-image-amd64
Version: 5.3.7-1
Severity: serious
Justification: Policy 12.5
adequate reports the file is missing, and is right. The directory is there,
but not a symbolic link and empty.
tglase@tglase-nb:~ $ ll -d /usr/share/doc/linux-image-amd64
drwxr-xr-x 2 root root 4096 Oct 22 15
On Wed, 2 Oct 2019, Thorsten Glaser wrote:
> With the backports kernel, a Raspberry Pi 3B+ cannot be shut down
The messages when poweroff’ing:
Will now halt.
I: executing reboot "-d" "-f" "-i" "-p" "-h" regardless of check results
Package: src:linux
Version: 5.2.9-2~bpo10+1
Severity: normal
With the backports kernel, a Raspberry Pi 3B+ cannot be shut down
or rebooted; the buster kernel manages that (but does not have sound).
I’ve captured the last couple of lines on the screen: the first two
are from sysvinit, three kernel
Package: firmware-iwlwifi
Version: 20190717-1
Severity: normal
My WLAN just crashed, no load (an ssh session and some chat).
Full dmesg (microcode error shown near bootom) follows:
[0.00] microcode: microcode updated early to revision 0xba, date =
2010-10-03
[0.00] Linux version
On Thu, 18 Jul 2019, Dmitry Bogatov wrote:
> On my system, $x-display-manager is defined in /etc/insserv.conf.d/xdm;
> on headless box there is no display manager, hence warning. Situation
> with $portmap seems similar.
Indeed, I also ran into the $x-display-manager one after having
reported the
On Fri, 14 Jun 2019, Thorsten Glaser wrote:
> Currently hanging processes:
Of course, sending the bug mail also failed, while I could
still do “virsh -c qemu:///system list --all”, which was
almost certainly not in the cache.
13610 ?D 0:00 /usr/sbin/postdrop -r
13615 ?
Package: linux-image-4.19.0-5-amd64
Version: 4.19.37-3
Severity: important
We’re back to tasks hanging, 99% of CPU being in wait.
This is somewhat similar to #913138 but not identical:
HDD reads seem to still work, as do some new writes,
but not all of them (e.g. I can run reportbug, but not
“man
Package: linux-base
Version: 4.5
Severity: important
Control: affects -1 initramfs-tools
Some time between 4.1.0-2 and 4.19.0-3, m68k kernels switched
from vmlinuz-* to vmlinux-*:
-rwxr-xr-x 1 root root 5933276 Feb 11 16:55 vmlinux-4.19.0-3-m68k*
-rwxr-xr-x 1 root root 5933284 Mar 15 02:16 vmlinu
Hi Cesare,
> But, in the meantime, doesn't the workaround of disabling blk_mq work
> for you?
I don’t know, because I have no means to trigger the bug. The three
other virtualisators I’ve upgraded at the same time did not trigger it.
My desktop machine also hits it only occasionally.
I’ve reboot
Hi Debian Linux kernel maintainers,
On Wed, 27 Feb 2019, Dragan Milenkovic wrote:
> > Hello Dragan, do you know if the patch was eventually included upstream and
> > possibly in which version?
>
> Hello, Cesare. It was included in 4.20.11 and 4.19.24.
please do consider uploading 4.19.24 to bust
severity 913119 serious
found 913119 4.19.16-1
thanks
On Wed, 13 Feb 2019, Dragan Milenkovic wrote:
> Jens Axboe has determined that the proper fix is quite different:
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=85bd6e61f34dffa8ec2dc75ff3c02ee7b2f1cbce
>
> This patch is alr
Package: src:linux
Version: 4.19.20-1
Severity: normal
linux-image-4.19.0-3-m68k takes massively longer to boot
than linux-image-4.1.0-2-m68k did (on an ARAnyM VM Atari
using NatFeat network/disc/…):
-BEGIN boot log of linux-image-4.19.0-3-m68k-
Running Aranym headlessly
ARAnyM 1.0.2
Usin
Dixi quod…
>I’ve managed to write 'w' to sysctl during this,
Interestingly enough, the system recovered in the meantime,
but dmesg doesn’t have anything new.
This is really annoying!
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 5
I’ve managed to write 'w' to sysctl during this,
perhaps the extra info helps:
[5441048.401704] sysrq: SysRq : This sysrq operation is disabled.
[5441118.394845] sysrq: SysRq : Show Blocked State
[5441118.394853] taskPC stack pid father
[5441118.394904] md5_raid6
Hi Salvatore,
>p.s.: my earlier reply to you seem to have been rejected and never
> reached you, hope this one does now.
if you sent from Googlemail, it may reach me in the next weeks or
never *shrug* they don’t play nice with greylisting. The -submitter
or @d.o works, though. I’m following
1 - 100 of 232 matches
Mail list logo
