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
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
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.
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
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
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
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)
(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
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
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
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
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
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
close 930522
thanks
Salvatore Bonaccorso dixit:
>Is this issue still reproducible with a recent kernel?
I haven’t seen it in a while, indeed.
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
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/
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*
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
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
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
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
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
-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
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
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:
201 - 226 of 226 matches
Mail list logo
