Bug#996397: closed by Luca Boccassi (Re: rpm-common: macros.* are no longer in any package provided in Debian)
This is a curious response.
My report was "this doesn't work any more because no package in Debian has
this," not "you should make rpm-common still have this."
You should probably remove the rpm packages from Debian entirely, at the
point where people need to install a bunch of external packages to get core
functionality to work.
- Rich
On Sat, Apr 20, 2024 at 8:33 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the rpm-common package:
>
> #996397: rpm-common: macros.* are no longer in any package provided in
> Debian
>
> It has been closed by Luca Boccassi .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Luca Boccassi <
> bl...@debian.org> by
> replying to this email.
>
>
> --
> 996397: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996397
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Luca Boccassi
> To: 996397-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 21 Apr 2024 01:31:26 +0100
> Subject: Re: rpm-common: macros.* are no longer in any package provided in
> Debian
> Control: tags -1 wontfix
>
> On Wed, 13 Oct 2021 13:16:03 -0400 Rich Ercolani
> wrote:
> > Package: rpm-common
> > Version: 4.16.1.2+dfsg1-3
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > When debugging why %{python_version} no longer expanded in an alien
> package,
> > I discovered that in bullseye and up, the macros.* packages (and
> their
> > associated macros) seem entirely absent.
> >
> > It seems like upstream RPM stopped including them between 4.14.2.1
> and 4.15.0.
> > The alpha changelog [1] notes:
> > - Remove script language helper macros and associated scripts
> >
> > And the commit [2] explicitly says:
> > yes this will break existing packages and force distros to deal
> > with the fallout, but we believe its for the best:
> > these macros are also best maintained by people closer to the
> languages
> > in question, as has been done with all the newer languages predating
> > perl and python. rpm-extras exists as the place for maintaining and
> > collaborating on such material.
> >
> > - Rich
> >
> > [1] - https://rpm.org/timeline.html
> > [2] -
>
> https://github.com/rpm-software-management/rpm/commit/ba85c95963f9b62f237c0442f6b5aca3e355fa83
>
> That was done intentionally upstream, the macros live in separate
> source packages such as:
>
> https://src.fedoraproject.org/rpms/python-rpm-macros
>
> --
> Kind regards,
> Luca Boccassi
>
>
>
> -- Forwarded message --
> From: Rich Ercolani
> To: Debian Bug Tracking System
> Cc:
> Bcc:
> Date: Wed, 13 Oct 2021 13:16:03 -0400
> Subject: rpm-common: macros.* are no longer in any package provided in
> Debian
> Package: rpm-common
> Version: 4.16.1.2+dfsg1-3
> Severity: normal
>
> Dear Maintainer,
>
> When debugging why %{python_version} no longer expanded in an alien
> package,
> I discovered that in bullseye and up, the macros.* packages (and their
> associated macros) seem entirely absent.
>
> It seems like upstream RPM stopped including them between 4.14.2.1 and
> 4.15.0.
> The alpha changelog [1] notes:
> - Remove script language helper macros and associated scripts
>
> And the commit [2] explicitly says:
> yes this will break existing packages and force distros to deal
> with the fallout, but we believe its for the best:
> these macros are also best maintained by people closer to the languages
> in question, as has been done with all the newer languages predating
> perl and python. rpm-extras exists as the place for maintaining and
> collaborating on such material.
>
> - Rich
>
> [1] - https://rpm.org/timeline.html
> [2] -
> https://github.com/rpm-software-management/rpm/commit/ba85c95963f9b62f237c0442f6b5aca3e355fa83
>
> -- System Information:
> Debian Release: 11.1
> APT prefers stable-updates
> APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000,
> 'stable'), (900, 'oldstable-debug'), (900, 'testing'), (800,
> 'unstable-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
> (500, 'oldstable-proposed-updates-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MOD
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
On Fri, Apr 05, 2024 at 05:04:37AM +, Thorsten Glaser wrote: > Markus Wichmann dixit: > > >can check with readelf -r what the relocation types are. If they are not > >relative, they will not be processed. > > Gotcha! They are all R_390_RELATIVE except for: > > 00045ff0 00110016 R_390_64 00042c58 u_ops + 70 > 00045ff8 00110016 R_390_64 00042c58 u_ops + 0 > 00047020 00110016 R_390_64 00042c58 u_ops + 80 > 00047088 00110016 R_390_64 00042c58 u_ops + 80 > 000470a8 00110016 R_390_64 00042c58 u_ops + b8 > 00047220 00110016 R_390_64 00042c58 u_ops + 80 > 00046900 00260016 R_390_64 00015af8 c_command + 0 > 00046940 00070016 R_390_64 00017238 c_exec + 0 > 00046ab0 00200016 R_390_64 00016a80 c_trap + 0 > 00047090 00250016 R_390_64 000430ac initvsn + 0 > 00047278 00550016 R_390_64 00047438 null_string + 2 > > That’s our missing strings. Is there anything weird about how these objects were declared that might have caused ld not to resolve them statically like it should? It seems odd that these data symbols, but not any other ones, would be left as symbolic relocations. Rich
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie
On Thu, Apr 04, 2024 at 07:50:40PM +, Thorsten Glaser wrote: > Szabolcs Nagy dixit: > > >the next culprit is gcc (each target can have their own > > gcc-13_13.2.0-23 > > >static pie specs) or the way you invoked gcc (not visible > > As I wrote earlier, though with more flags. Dropping all the -D… > and -W… and -I… and other irrelevant ones: > > musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables > -fno-strict-aliasing -fstack-protector-strong -fwrapv -c … > musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables > -fno-strict-aliasing -fstack-protector-strong -fwrapv > -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static -static-pie > -fno-lto -o mksh *.o > > Same for both. You can see the full log by activating the > [64]Installed and [71]Installed links respectively on > https://buildd.debian.org/status/package.php?p=mksh and > skipping to 'compilation of mksh in static-musl' to get to > the beginning of the configure phase for that. > > >are you sure static pie works on these targets? > > No ;-) That’s why I reported this issue. I had just > enabled it for the musl builds, as the security people > like that more than normal static. I seem to recall the musl-gcc wrapper does not handle static-pie right. A real cross toolchain should. If there's an easy fix for the wrapper I'd be happy to merge it. Rich
Bug#1061060: javaws fails to run Supermicro (Aten) iKVM remote consoles
I also encountered this problem after switching from Debian 10.9 to Debian 12.5. The Aten remote KVM provided by Supermicro motherboards relies on JARs compressed by Pack200, so the application no longer works with icedtea-netx and nvidia-openjdk-8-jre: java.lang.UnsupportedOperationException: Pack200 compression is no longer supported, cannot unpack https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz at net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502) at net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400) at net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364) at net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:750) java.lang.UnsupportedOperationException: Pack200 compression is no longer supported, cannot unpack https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz at net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502) at net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400) at net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364) at net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:750) I think the relevant change was implemented in OpenJDK in December 2019: https://hg.openjdk.org/jdk/jdk/rev/f236fd5d0c2c https://bugs.openjdk.org/browse/JDK-8234542 https://bugs.openjdk.org/browse/JDK-8234596 On Wed, 17 Jan 2024 09:15:26 +0100 Christian Schwamborn < c...@mail.architektur.tu-darmstadt.de> wrote: > Package: icedtea-netx > Version: 1.8.8-2 > > In some more recent update of icedtea-netx, I can't determine which > exactly, the pack200 libs must have been removed from javaws.jar > Keeping older java versions around to access such devices can't help if > javaws is unable to fetch the jar files from those as they might be > compressed. > > Even recent system boards from Supermicro ship their jar libs as > *.jar.pack.gz files. I know, it's deprecated for ages, but tell it to > them. Even if they change it now, they won't update older firmwares and > there are plenty around. Not only on server boards but all kind of > enterprise equipment still running somewhere. > > Let me ask a question: Who uses javaws nowadays? > My wild guess: Mostly people having to access hardware equipment, where > 'the industry' even today implements their user interface with java > beside the fact that java is one of the worst ideas someone came up with. > Sure, the more recent versions of Supermicro boards (Fujitsu as well) > also provide a html5 implementations, but sadly they are in some areas > not as 'finished' as they should be, so I still have to rely on their > java counterparts. > I don't want to create a debate about security. Everyone running that > sort of stuff should know not to expose those interfaces anywhere and > has to hack half his java security settings anyway.
Bug#1050429: [musl] musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
On Sat, Feb 03, 2024 at 08:20:28AM +, Thorsten Glaser wrote: > Hi musl maintainers, > > waldi indeed provided a fix for this bug forgot to Cc me, so I missed > it until now. I tested this: > > > > (sid_mips64el-dchroot)tg@eberlin:~$ sh -x $(which musl-gcc) hello.c > + exec mips64el-linux-gnuabi64-gcc hello.c -specs > /usr/lib/mips64el-linux-musl/musl-gcc.specs > mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL' > (sid_mips64el-dchroot)tg@eberlin:~$ mips64el-linux-gnuabi64-gcc hello.c > -specs ~/musl-gcc.specs > (sid_mips64el-dchroot)tg@eberlin:~$ ./a.out > hi > (sid_mips64el-dchroot)tg@eberlin:~$ diff -u > /usr/lib/mips64el-linux-musl/musl-gcc.specs musl-gcc.specs > --- /usr/lib/mips64el-linux-musl/musl-gcc.specs 2023-11-10 19:30:40.0 > + > +++ musl-gcc.specs 2024-02-03 08:07:01.309465472 + > @@ -1,10 +1,11 @@ > %rename cpp_options old_cpp_options > +%rename cc1 old_cc1 > > *cpp_options: > -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s > %(old_cpp_options) > > *cc1: > -%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem > include%s > +%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem > include%s %(old_cc1) > > *link_libgcc: > -L/usr/lib/mips64el-linux-musl -L .%s > > > > This change (to tools/musl-gcc.specs.sh in the source tree) probably > makes sense on all architectures, so perhaps do that even. Upstream > should also consider including this and check which of the original > specs need not be removed and can be kept like this. > > bye, > //mirabilos OK, it's not musl that's unusable, but the gcc wrapper. This is not the recommended way to use musl except as minimal evaluation setup or for compiling very simple programs, and as you've found, it seems it's almost entirely untested except on a couple mainstream archs. This is something we should fix, but there are two issues: 1. On some archs, which I think includes mips, it can work in principle, but has gratuitous bugs keeping it from working. These should be easy to fix. 2. On some archs such as powerpc, the ABI is almost surely mismatched with the existing toolchain on a non-musl system. This should be caught at configure time, since the existing gcc is not able to build musl anyway, but it's possible that with sufficient additions to CFLAGS/CC, it might be possible to get musl to build, but then have a broken wrapper still (or to compile, but fail at link time or produce a broken libc.so due to mismatched libgcc.a). This probably needs attention too. I'll try to take a look at this soon and see if the proposed wrapper fix seems right for the mips situation, but the wrapper is generally low-priority, and there's other stuff I'm trying to get to/finish first. Rich
Bug#1028340: grub-ieee1275-bin: grub 2.06-7 faults on SPARC, 2.06-3 does not
Followup:
Doing grub-install if the partition you install to isn't mounted at /boot
produces a nonworking image.
https://www.dropbox.com/s/74grf6t3hy5lp9t/disk%20diff.png?dl=0 is the diff
of the first few hundred lines of output from hexdump of a disk image that
booted (because it was at /boot) and didn't.
So that's neat.
- Rich
On Mon, Jan 9, 2023 at 12:45 PM Rich Ercolani wrote:
> Package: grub-ieee1275-bin
> Version: 2.06-7
> Severity: normal
> X-Debbugs-Cc: rincebr...@gmail.com
>
> Dear Maintainer,
>
> I decided enough was enough and finally went to migrate my Netra T1 from
> SILO to GRUB.
>
> So I installed grub2 2.06-7, went through the motions, did grub-install
> --skip-fs-probe --force /dev/sdb1 (/boot - well, a copy of the contents of
> it mounted there for the moment, the actual one is /dev/sda1...),
> rebooted...
>
> Executing last command: boot
> Boot device: disk1 File and args:
> GRUB Illegal Instruction
> ok
>
> Cute. So after some tampering and blanking and redoing the disk, it still
> failed the same way.
>
> I have another SPARC that's booting from GRUB fine, so I stole the disk
> image from it and tried booting from that, worked great.
>
> Checked, that machine was using 2.06-3. So I grub-installed 2.06-7 again
> to confirm it broke the same way, grabbed 2.06-3 from snapshot.debian.org,
> installed it, and did the aforementioned grub-install dance...and it boots
> great.
>
> - Rich
>
> -- Package-specific info:
>
> *** BEGIN /proc/mounts
> /dev/mapper/ogami--vgnew-newroot / xfs
> rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
> /dev/sda1 /boot ext4 rw,relatime,errors=remount-ro 0 0
> *** END /proc/mounts
>
> *** BEGIN /boot/grub/grub.cfg
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically generated by grub-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #
>
> ### BEGIN /etc/grub.d/00_header ###
> if [ -s $prefix/grubenv ]; then
> set have_grubenv=true
> load_env
> fi
> if [ "${next_entry}" ] ; then
>set default="${next_entry}"
>set next_entry=
>save_env next_entry
>set boot_once=true
> else
>set default="0"
> fi
>
> if [ x"${feature_menuentry_id}" = xy ]; then
> menuentry_id_option="--id"
> else
> menuentry_id_option=""
> fi
>
> export menuentry_id_option
>
> if [ "${prev_saved_entry}" ]; then
> set saved_entry="${prev_saved_entry}"
> save_env saved_entry
> set prev_saved_entry=
> save_env prev_saved_entry
> set boot_once=true
> fi
>
> function savedefault {
> if [ -z "${boot_once}" ]; then
> saved_entry="${chosen}"
> save_env saved_entry
> fi
> }
> function load_video {
> if [ x$feature_all_video_module = xy ]; then
> insmod all_video
> else
> insmod efi_gop
> insmod efi_uga
> insmod ieee1275_fb
> insmod vbe
> insmod vga
> insmod video_bochs
> insmod video_cirrus
> fi
> }
>
> if [ x$feature_default_font_path = xy ] ; then
>font=unicode
> else
> insmod part_sun
> insmod part_sun
> insmod lvm
> insmod xfs
> set
> root='lvmid/x0ezap-Oaqe-VVmf-PtRs-0aQk-hWN4-XJx5vi/Kqfrwr-7OFw-qaTA-R91O-6iLJ-lQDB-TToQaj'
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root
> --hint='lvmid/x0ezap-Oaqe-VVmf-PtRs-0aQk-hWN4-XJx5vi/Kqfrwr-7OFw-qaTA-R91O-6iLJ-lQDB-TToQaj'
> ef48c129-1368-4b94-b7a8-fc40302d2179
> else
> search --no-floppy --fs-uuid --set=root
> ef48c129-1368-4b94-b7a8-fc40302d2179
> fi
> font="/usr/share/grub/unicode.pf2"
> fi
>
> if loadfont $font ; then
> set gfxmode=auto
> load_video
> insmod gfxterm
> set locale_dir=$prefix/locale
> set lang=en_US
> insmod gettext
> fi
> terminal_output gfxterm
> if [ "${recordfail}" = 1 ] ; then
> set timeout=30
> else
> if [ x$feature_timeout_style = xy ] ; then
> set timeout_style=menu
> set timeout=5
> # Fallback normal timeout code in case the timeout_style feature is
> # unavailable.
> else
> set timeout=5
> fi
> fi
> ### END /etc/grub.d/00_header ###
>
> ### BEGIN /etc/grub.d/05_debian_theme ###
> set menu_color_normal=cyan/blue
> set menu_color_highlight=white/blue
> ### END /etc/grub.d/05_debian_theme ###
>
> ### BEGIN /etc/grub.d/10_linux ###
> function gfxmode {
> set gfxpayload="${1}"
> }
> set linux_gfx_mode=
> export linux_gfx_mode
> menuentry 'Debian GNU/Lin
Bug#1028340: grub-ieee1275-bin: grub 2.06-7 faults on SPARC, 2.06-3 does not
Package: grub-ieee1275-bin
Version: 2.06-7
Severity: normal
X-Debbugs-Cc: rincebr...@gmail.com
Dear Maintainer,
I decided enough was enough and finally went to migrate my Netra T1 from SILO
to GRUB.
So I installed grub2 2.06-7, went through the motions, did grub-install
--skip-fs-probe --force /dev/sdb1 (/boot - well, a copy of the contents of it
mounted there for the moment, the actual one is /dev/sda1...), rebooted...
Executing last command: boot
Boot device: disk1 File and args:
GRUB Illegal Instruction
ok
Cute. So after some tampering and blanking and redoing the disk, it still
failed the same way.
I have another SPARC that's booting from GRUB fine, so I stole the disk image
from it and tried booting from that, worked great.
Checked, that machine was using 2.06-3. So I grub-installed 2.06-7 again to
confirm it broke the same way, grabbed 2.06-3 from snapshot.debian.org,
installed it, and did the aforementioned grub-install dance...and it boots
great.
- Rich
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/ogami--vgnew-newroot / xfs
rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
/dev/sda1 /boot ext4 rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_sun
insmod part_sun
insmod lvm
insmod xfs
set
root='lvmid/x0ezap-Oaqe-VVmf-PtRs-0aQk-hWN4-XJx5vi/Kqfrwr-7OFw-qaTA-R91O-6iLJ-lQDB-TToQaj'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/x0ezap-Oaqe-VVmf-PtRs-0aQk-hWN4-XJx5vi/Kqfrwr-7OFw-qaTA-R91O-6iLJ-lQDB-TToQaj'
ef48c129-1368-4b94-b7a8-fc40302d2179
else
search --no-floppy --fs-uuid --set=root ef48c129-1368-4b94-b7a8-fc40302d2179
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-ef48c129-1368-4b94-b7a8-fc40302d2179' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_sun
insmod ext2
set root='hd0,sun1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-ieee1275='ieee1275//pci@1f\,0/pci@1\,1/scsi@2/disk@0\,0,sun1'
--hint-bios=hd0,sun1 --hint-efi=hd0,sun1 --hint-baremetal=ahci0,sun1
f8017784-364b-442c-943d-e19fb5d1b7e5
else
search --no-floppy --fs-uuid --set=root
f8017784-364b-442c-943d-e19fb5d1b7e5
fi
echo'Loading Linux 5.10.0-8-sparc64 ...'
linux /vmlinux-5.10.0-8-sparc64 root=/dev/mapper/ogami--vgnew-newroot
ro quiet
echo'Loading initial ramdisk ...'
initrd /initrd.img-5.10.0-8-sparc64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-ef48c129-1368-4b94-b7a8-fc40302d2179' {
menuentry 'Debian GNU/Linux, with
Bug#1024382: seabios: Unable to boot KVM ISA guest with "-device isa-vga"
Package: seabios Version: 1.14.0-2 Severity: normal X-Debbugs-Cc: rsahlen...@gmail.com Dear Maintainer, Attempting to launch a KVM with "-machine isapc" and "-device isa-vga" produces "Could not open option rom 'vgabios.bin': No such file or directory" from QEMU / KVM and "Guest has not initialized the display (yet)." in the KVM vconsole. This is easy to workaround by creating the following symlink in /usr/share/seabios: ln -s vgabios-isavga.bin vgabios.bin Thanks and regards, Rich -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1013205: samba-common: samba no longer installable on sparc64 due to impossible version conflict
Package: samba-common Version: 2:4.13.5+dfsg-2 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, Pretty simple report - since samba-common is only offered at 2:4.16.2+dfsg-1 in sid currently, and all the binary samba packages for sparc64 are at 2:4.13.14+dfsg-1+b4, it's impossible to install right now without either reaching into the archive snapshots or building yourself. It would be nice if this wasn't breaking "apt upgrade". - Rich -- Package-specific info: * /etc/samba/smb.conf present, but not attached * /var/lib/samba/dhcp.conf present, and attached -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc64 Kernel: Linux 5.10.0-8-sparc64 Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages samba-common depends on: ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.9 ii ucf3.0043 Versions of packages samba-common recommends: ii samba-common-bin 2:4.13.5+dfsg-2 samba-common suggests no packages. -- debconf information: samba-common/title: samba-common/do_debconf: true samba-common/workgroup: WORKGROUP samba-common/dhcp: false dhcp.conf Description: inode/empty
Bug#999485: FYI
FYI to anyone with a Pi 400, stealing the raspi-firmware from sid (raspi-firmware_1.20220331+ds-1 as of this writing) and rebooting results in working wifi on bullseye. Cherrypicking these three files on their own from upstream rpi-firmware didn't, so still something to be debugged about what needs to change... - Rich
Bug#998739:
I was just going to report a similar bug to this, after attempting to
migrate a package from using distutils.sysconfig to sysconfig (due to 3.10
now screaming about distutils being removed Soon(tm)), and discovering that
distutils.sysconfig does report dist-packages, while sysconfig reports
site-packages, just as described in [1].
>>> distutils.sysconfig.get_python_lib(0,0)
/usr/lib/python3/dist-packages
>>> sysconfig.get_path('platlib')
'/usr/lib/python3.9/site-packages'
So I'd recommend changing _something_ so that these become at least
consistent, or people are just going to start having to add Debian-specific
hacks everywhere or just ignoring Debian's intended locations, and neither
strikes me as great for anyone.
- Rich
[1] -
https://ffy00.github.io/blog/02-python-debian-and-the-install-locations/
Bug#1004255: linux-image-5.14.0-1-sparc64-smp: Debian kernels > 5.14.3-1~exp1 fail to boot on SPARC T4-1 with Fast Data Access MMU Miss
At least on my old Netra T1, SILO has never believed in booting vmlinuz, only vmlinux, and faults similarly if you try. So if it just recently started faulting that way for you, perhaps any glue that knew to unpack vmlinuz into vmlinux isn't working? - Rich On Sun, Jan 23, 2022 at 1:30 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello Tom! > > On 1/23/22 17:39, Tom Turelinckx wrote: > > Boot device: disk0 File and args: > > SILO Version 1.4.14 > > boot: > > Allocated 64 Megs of memory at 0x4000 for kernel > > Uncompressing image... > > Loaded kernel version 5.14.6 > > Loading initial ramdisk (25723814 bytes at 0x2480 phys, 0x40C0 > virt)... > > ERROR: Last Trap: Fast Data Access MMU Miss > > This looks more like an issue with your bootloader. I haven't used SILO > for a > long time, so I don't have a track what currently works and what not. > > Can you try booting the current ISO snapshot image? [1] > > Adrian > > > [1] > https://cdimage.debian.org/cdimage/ports/snapshots/2021-10-20/debian-11.0.0-sparc64-NETINST-1.iso > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
On Thu, Jan 6, 2022 at 5:22 AM Aurelien Jarno wrote: > On 2022-01-06 03:36, Rich wrote: > > Hi Aurelien, > > It's a VM running in qemu on an amd64 Debian bullseye system, no KVM > > acceleration to be found here. > > Ok, that might be a QEMU issue then. Which CPU do you emulate with QEMU? > I don't explicitly specify a -M or -cpu, so whatever it defaults to, which according to -M help seems to be "pseries" mapping to pseries-6.1 here. - Rich - Rich > > Regards, > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net >
Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
https://www.dropbox.com/s/k117zefr83k6b11/ppc64%20bt.png?dl=0 is the backtrace gdb reports from that core, helpful as it is. I actually originally had this happen on qemu 5.2, then I upgraded to 6.1 to see if it went away (it does not, and it happily reproduces on fresh upgrade each time). - Rich On Thu, Jan 6, 2022 at 3:36 AM Rich wrote: > Hi Aurelien, > It's a VM running in qemu on an amd64 Debian bullseye system, no KVM > acceleration to be found here. > > dmesg doesn't have any backtraces - the two messages that show up are > py3compile segfaulting with all the addresses printed as instead, > and a couple of programs (like mandb) reporting getting a pointer of > 0xfff1 or similar and dying in a fire. > > The first ones after the upgrade: > Jan 6 01:30:39 encrepro kernel: [ 6715.078626] mandb[1903]: User access > of kernel address (8408) - exploit attempt? (uid: 6) > Jan 6 01:30:39 encrepro kernel: [ 6715.093977] mandb[1903]: segfault (11) > at 8408 nip 7fffb37f5f28 lr 7fffb37f5f08 code 1 in > libseccomp.so.2.5.3[7fffb37f+3] > Jan 6 01:30:39 encrepro kernel: [ 6715.100149] mandb[1903]: code: > fbe10078 3880 7c7f1b78 4bffddfd e8410028 2c03 41800030 ebe10078 > Jan 6 01:30:39 encrepro kernel: [ 6715.100308] mandb[1903]: code: > 3860 38210080 6000 e8010010 <906283f8> 7c6307b4 7c0803a6 4e800020 > Jan 6 01:31:31 encrepro kernel: [ 6767.287646] reportbug[1982]: segfault > (11) at 34c8 nip 34c8 lr 34c8 code 1 in python3.9[1000+5d] > Jan 6 01:31:31 encrepro kernel: [ 6767.293334] reportbug[1982]: code: > > Jan 6 01:31:31 encrepro kernel: [ 6767.293545] reportbug[1982]: code: > > > And later: > > Jan 6 01:35:30 encrepro systemd[2290]: free(): invalid pointer > > and > > Jan 6 01:42:53 encrepro systemd[1]: Created slice User Slice of UID 1000. > Jan 6 01:42:53 encrepro systemd[1]: Starting User Runtime Directory > /run/user/1000... > Jan 6 01:42:53 encrepro systemd[1]: Finished User Runtime Directory > /run/user/1000. > Jan 6 01:42:53 encrepro systemd[1]: Starting User Manager for UID 1000... > Jan 6 01:42:53 encrepro systemd[2370]: free(): invalid pointer > Jan 6 01:42:54 encrepro systemd[1]: user@1000.service: Main process > exited, code=killed, status=6/ABRT > Jan 6 01:42:54 encrepro systemd[1]: user@1000.service: Failed with > result 'signal'. > Jan 6 01:42:54 encrepro systemd[1]: Failed to start User Manager for UID > 1000. > > I've got a core dump from mandb: > https://www.dropbox.com/s/4z6bfbuluwub29r/ppc64_libc?dl=0 > > I don't have a stacktrace from it, though, since I didn't already have gdb > on the VM, and it wants to upgrade libc to install. (I know I could go find > an appropriately old section of snapshots.debian.org, but haven't done > that yet...) > > - Rich > > On Thu, Jan 6, 2022 at 3:13 AM Aurelien Jarno > wrote: > >> control: tag -1 + help >> control: user debian-powe...@lists.debian.org >> control: usertag -1 ppc64 >> >> On 2022-01-06 01:45, Rich Ercolani wrote: >> > Package: libc6 >> > Version: 2.33-1 >> > Severity: important >> > X-Debbugs-Cc: rincebr...@gmail.com >> > >> > Dear Maintainer, >> > >> > (I marked this as serious because it's "just" ppc64, but the system is >> permaneantly unusable if this upgrade is installed.) >> >> I have added the powerpc list in Cc: as the ppc64 porters are the people >> who can help you there. >> >> > I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30 >> packages in, it died horribly >> > with Python3 packages erroring out with "Cannot get content of >> [whatever package]". >> >> Is it a VM running with KVM or is it using QEMU emulation? >> >> > Trying to log into a shell over ssh or at a tty after this happens dies >> with an error that flashes fast, but >> > but seems to be "free(): invalid pointer" >> > >> > Random applications will now just crash out, in addition to the >> obvious. (I'm writing this from a session >> > spawned before the upgrade, which can still spawn children successfully >> until I log out.) >> > >> > If I reboot after upgrading, all services fail to start on boot, and it >> never spawns a login prompt or rescue >> > prompt, it just sits forever on a list of failed service starts. >> > >> > Anything that would be helpful to debug this? I have a snapshot of the >> VM before this began, so I can >> > just roll it back and repeat the exercise. >> >> Ideally a backtrace would help, dmesg outputs can also be useful, >> however given the state of you system, they might be difficult to get. >> >> Regards, >> Aurelien >> >> -- >> Aurelien Jarno GPG: 4096R/1DDD8C9B >> aurel...@aurel32.net http://www.aurel32.net >> >
Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
Hi Aurelien,
It's a VM running in qemu on an amd64 Debian bullseye system, no KVM
acceleration to be found here.
dmesg doesn't have any backtraces - the two messages that show up are
py3compile segfaulting with all the addresses printed as instead,
and a couple of programs (like mandb) reporting getting a pointer of
0xfff1 or similar and dying in a fire.
The first ones after the upgrade:
Jan 6 01:30:39 encrepro kernel: [ 6715.078626] mandb[1903]: User access of
kernel address (8408) - exploit attempt? (uid: 6)
Jan 6 01:30:39 encrepro kernel: [ 6715.093977] mandb[1903]: segfault (11)
at 8408 nip 7fffb37f5f28 lr 7fffb37f5f08 code 1 in
libseccomp.so.2.5.3[7fffb37f+3]
Jan 6 01:30:39 encrepro kernel: [ 6715.100149] mandb[1903]: code: fbe10078
3880 7c7f1b78 4bffddfd e8410028 2c03 41800030 ebe10078
Jan 6 01:30:39 encrepro kernel: [ 6715.100308] mandb[1903]: code: 3860
38210080 6000 e8010010 <906283f8> 7c6307b4 7c0803a6 4e800020
Jan 6 01:31:31 encrepro kernel: [ 6767.287646] reportbug[1982]: segfault
(11) at 34c8 nip 34c8 lr 34c8 code 1 in python3.9[1000+5d]
Jan 6 01:31:31 encrepro kernel: [ 6767.293334] reportbug[1982]: code:
Jan 6 01:31:31 encrepro kernel: [ 6767.293545] reportbug[1982]: code:
And later:
Jan 6 01:35:30 encrepro systemd[2290]: free(): invalid pointer
and
Jan 6 01:42:53 encrepro systemd[1]: Created slice User Slice of UID 1000.
Jan 6 01:42:53 encrepro systemd[1]: Starting User Runtime Directory
/run/user/1000...
Jan 6 01:42:53 encrepro systemd[1]: Finished User Runtime Directory
/run/user/1000.
Jan 6 01:42:53 encrepro systemd[1]: Starting User Manager for UID 1000...
Jan 6 01:42:53 encrepro systemd[2370]: free(): invalid pointer
Jan 6 01:42:54 encrepro systemd[1]: user@1000.service: Main process
exited, code=killed, status=6/ABRT
Jan 6 01:42:54 encrepro systemd[1]: user@1000.service: Failed with result
'signal'.
Jan 6 01:42:54 encrepro systemd[1]: Failed to start User Manager for UID
1000.
I've got a core dump from mandb:
https://www.dropbox.com/s/4z6bfbuluwub29r/ppc64_libc?dl=0
I don't have a stacktrace from it, though, since I didn't already have gdb
on the VM, and it wants to upgrade libc to install. (I know I could go find
an appropriately old section of snapshots.debian.org, but haven't done that
yet...)
- Rich
On Thu, Jan 6, 2022 at 3:13 AM Aurelien Jarno wrote:
> control: tag -1 + help
> control: user debian-powe...@lists.debian.org
> control: usertag -1 ppc64
>
> On 2022-01-06 01:45, Rich Ercolani wrote:
> > Package: libc6
> > Version: 2.33-1
> > Severity: important
> > X-Debbugs-Cc: rincebr...@gmail.com
> >
> > Dear Maintainer,
> >
> > (I marked this as serious because it's "just" ppc64, but the system is
> permaneantly unusable if this upgrade is installed.)
>
> I have added the powerpc list in Cc: as the ppc64 porters are the people
> who can help you there.
>
> > I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30
> packages in, it died horribly
> > with Python3 packages erroring out with "Cannot get content of [whatever
> package]".
>
> Is it a VM running with KVM or is it using QEMU emulation?
>
> > Trying to log into a shell over ssh or at a tty after this happens dies
> with an error that flashes fast, but
> > but seems to be "free(): invalid pointer"
> >
> > Random applications will now just crash out, in addition to the obvious.
> (I'm writing this from a session
> > spawned before the upgrade, which can still spawn children successfully
> until I log out.)
> >
> > If I reboot after upgrading, all services fail to start on boot, and it
> never spawns a login prompt or rescue
> > prompt, it just sits forever on a list of failed service starts.
> >
> > Anything that would be helpful to debug this? I have a snapshot of the
> VM before this began, so I can
> > just roll it back and repeat the exercise.
>
> Ideally a backtrace would help, dmesg outputs can also be useful,
> however given the state of you system, they might be difficult to get.
>
> Regards,
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>
Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
Package: libc6 Version: 2.33-1 Severity: important X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, (I marked this as serious because it's "just" ppc64, but the system is permaneantly unusable if this upgrade is installed.) I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30 packages in, it died horribly with Python3 packages erroring out with "Cannot get content of [whatever package]". Trying to log into a shell over ssh or at a tty after this happens dies with an error that flashes fast, but but seems to be "free(): invalid pointer" Random applications will now just crash out, in addition to the obvious. (I'm writing this from a session spawned before the upgrade, which can still spawn children successfully until I log out.) If I reboot after upgrading, all services fail to start on boot, and it never spawns a login prompt or rescue prompt, it just sits forever on a list of failed service starts. Anything that would be helpful to debug this? I have a snapshot of the VM before this began, so I can just roll it back and repeat the exercise. - Rich -- System Information: Debian Release: bookworm/sid Architecture: powerpc64 (ppc64) Kernel: Linux 5.15.0-2-powerpc64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1000551: elfutils: Segfault in read_addrs
Package: elfutils Version: 0.183-1 Severity: normal Dear Maintainer, While experimenting with drgn [1], I ran into a crash[3], which seems to be from a bug introduced in elfutils 0.183 and fixed in 0.186[2]. I don't know if said bug meets the threshold for a backport on stable, but figured I'd ask, since the alternative is that I carry my own elfutils packages until bookworm... - Rich [1] - https://github.com/osandov/drgn [2] - https://sourceware.org/git/?p=elfutils.git;a=commit;h=828024afc517e266f3226b469ba33f372b401821 [3] - https://github.com/osandov/drgn/issues/130 -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000, 'stable-debug'), (1000, 'stable'), (901, 'proposed-updates'), (900, 'oldstable-proposed-updates-debug'), (900, 'oldstable-debug'), (900, 'testing'), (800, 'unstable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elfutils depends on: ii libasm1 0.183-1 ii libc6 2.31-13+deb11u2 ii libdw1 0.183-1 ii libelf1 0.183-1 ii libstdc++6 10.2.1-6 elfutils recommends no packages. elfutils suggests no packages. -- debconf-show failed
Bug#985632:
One more addendum - just the clm_blob alone from https://github.com/RPi-Distro/firmware-nonfree/commit/dc406650e840705957f8403efeacf71d2d7543b3, not even the sdio.bin with it, on top of the stock bullseye firmware-brcm80211, works for me. - Rich On Sun, Nov 21, 2021 at 1:16 PM Rich wrote: > > I appear to have just been burned by this setting up my new Pi 4B 4GB. > > I likewise found that stealing just cyfmac43455-sdio.clm_blob (which > brcmfmac43455-sdio.clm_blob is a symlink to on my system) from > 20210315-3+rpt3 and reloading the driver made everything happy and > functional... > > - Rich
Bug#985632:
I appear to have just been burned by this setting up my new Pi 4B 4GB. I likewise found that stealing just cyfmac43455-sdio.clm_blob (which brcmfmac43455-sdio.clm_blob is a symlink to on my system) from 20210315-3+rpt3 and reloading the driver made everything happy and functional... - Rich
Bug#999820:
Ah, no, using this patch is a bad idea.
It worked fine for most of the day, but then I tried pushing a TB over
NFS, and it died with watchdog timeouts and indefinite hangs.
That's sad. I guess I'll go for the backup option...
- Rich
On Fri, Nov 19, 2021 at 3:19 AM Rich wrote:
>
> I forgot to include context on my own bug.
>
> Bisecting this brought me to
> https://github.com/torvalds/linux/commit/7d5ec3d3612396dc6d4b76366d20ab9fc06f399f
> .
>
> After a few attempts of varying partly-broken-or-panic, I concluded
> that it seemed nearly correctly initialized at the point that we
> called niu_try_msix(), at least on my hardware, and so added an escape
> hatch to avoid the parts that step on the existing setup in a way that
> breaks.
>
> Not having any hardware but the one this broke on, or any familiarity
> with the hardware or stack involved, I make no promises that it won't
> come to life and scribble on your face with sharpie while you sleep,
> just that I'm running it at the moment without such fires yet.
>
> - Rich
>
> On Fri, Nov 19, 2021 at 2:59 AM Rich wrote:
> >
> > I found the following patch generated against 5.14.0 helps and hasn't
> > burned the house down in testing so far.
> >
> > ---
> >
> > diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
> > index 860644d182ab..70c08acd3ee5 100644
> > --- a/drivers/net/ethernet/sun/niu.c
> > +++ b/drivers/net/ethernet/sun/niu.c
> > @@ -9034,16 +9034,20 @@ static void niu_try_msix(struct niu *np, u8
> > *ldg_num_map)
> > msi_vec[i].entry = i;
> > }
> >
> > - num_irqs = pci_enable_msix_range(pdev, msi_vec, 1, num_irqs);
> > + if (np->num_ldg == 0)
> > + num_irqs = pci_enable_msix_range(pdev, msi_vec, 1,
> > num_irqs);
> > +
> > if (num_irqs < 0) {
> > np->flags &= ~NIU_FLAGS_MSIX;
> > return;
> > }
> >
> > np->flags |= NIU_FLAGS_MSIX;
> > - for (i = 0; i < num_irqs; i++)
> > - np->ldg[i].irq = msi_vec[i].vector;
> > - np->num_ldg = num_irqs;
> > + if (np->num_ldg == 0) {
> > + for (i = 0; i < num_irqs; i++)
> > + np->ldg[i].irq = msi_vec[i].vector;
> > + np->num_ldg = num_irqs;
> > + }
> > }
> >
> > static int niu_n2_irq_init(struct niu *np, u8 *ldg_num_map)
> >
> > ---
> >
> > (I obviously haven't tested it on hardware other than the broken setup.)
> >
> > I'll try using this for a bit and see if it unexpectedly burns the house
> > down.
Bug#999820:
I forgot to include context on my own bug.
Bisecting this brought me to
https://github.com/torvalds/linux/commit/7d5ec3d3612396dc6d4b76366d20ab9fc06f399f
.
After a few attempts of varying partly-broken-or-panic, I concluded
that it seemed nearly correctly initialized at the point that we
called niu_try_msix(), at least on my hardware, and so added an escape
hatch to avoid the parts that step on the existing setup in a way that
breaks.
Not having any hardware but the one this broke on, or any familiarity
with the hardware or stack involved, I make no promises that it won't
come to life and scribble on your face with sharpie while you sleep,
just that I'm running it at the moment without such fires yet.
- Rich
On Fri, Nov 19, 2021 at 2:59 AM Rich wrote:
>
> I found the following patch generated against 5.14.0 helps and hasn't
> burned the house down in testing so far.
>
> ---
>
> diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
> index 860644d182ab..70c08acd3ee5 100644
> --- a/drivers/net/ethernet/sun/niu.c
> +++ b/drivers/net/ethernet/sun/niu.c
> @@ -9034,16 +9034,20 @@ static void niu_try_msix(struct niu *np, u8
> *ldg_num_map)
> msi_vec[i].entry = i;
> }
>
> - num_irqs = pci_enable_msix_range(pdev, msi_vec, 1, num_irqs);
> + if (np->num_ldg == 0)
> + num_irqs = pci_enable_msix_range(pdev, msi_vec, 1, num_irqs);
> +
> if (num_irqs < 0) {
> np->flags &= ~NIU_FLAGS_MSIX;
> return;
> }
>
> np->flags |= NIU_FLAGS_MSIX;
> - for (i = 0; i < num_irqs; i++)
> - np->ldg[i].irq = msi_vec[i].vector;
> - np->num_ldg = num_irqs;
> + if (np->num_ldg == 0) {
> + for (i = 0; i < num_irqs; i++)
> + np->ldg[i].irq = msi_vec[i].vector;
> + np->num_ldg = num_irqs;
> + }
> }
>
> static int niu_n2_irq_init(struct niu *np, u8 *ldg_num_map)
>
> ---
>
> (I obviously haven't tested it on hardware other than the broken setup.)
>
> I'll try using this for a bit and see if it unexpectedly burns the house down.
Bug#999820:
I found the following patch generated against 5.14.0 helps and hasn't
burned the house down in testing so far.
---
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 860644d182ab..70c08acd3ee5 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -9034,16 +9034,20 @@ static void niu_try_msix(struct niu *np, u8
*ldg_num_map)
msi_vec[i].entry = i;
}
- num_irqs = pci_enable_msix_range(pdev, msi_vec, 1, num_irqs);
+ if (np->num_ldg == 0)
+ num_irqs = pci_enable_msix_range(pdev, msi_vec, 1, num_irqs);
+
if (num_irqs < 0) {
np->flags &= ~NIU_FLAGS_MSIX;
return;
}
np->flags |= NIU_FLAGS_MSIX;
- for (i = 0; i < num_irqs; i++)
- np->ldg[i].irq = msi_vec[i].vector;
- np->num_ldg = num_irqs;
+ if (np->num_ldg == 0) {
+ for (i = 0; i < num_irqs; i++)
+ np->ldg[i].irq = msi_vec[i].vector;
+ np->num_ldg = num_irqs;
+ }
}
static int niu_n2_irq_init(struct niu *np, u8 *ldg_num_map)
---
(I obviously haven't tested it on hardware other than the broken setup.)
I'll try using this for a bit and see if it unexpectedly burns the house down.
Bug#999820: linux-image-5.14.0-4-sparc64-smp: kernel fails to boot with niu driver enabled on recent kernels
[<0042a740>] sun4v_nonresum_error+0xe0/0x100 [ 52.672616] [<00406eb8>] sun4v_nonres_mondo+0xc8/0xd8 [ 52.672699] [<0093798c>] __pci_enable_msix_range+0x38c/0x6c0 [ 52.672770] [<00937ce0>] pci_enable_msix_range+0x20/0x40 [ 52.672840] [<108a7a08>] niu_try_msix+0xc8/0x1a0 [niu] [ 52.672962] [<108af1f8>] niu_get_invariants+0x478/0x28a0 [niu] [ 52.673087] [<108b1878>] niu_pci_init_one+0x258/0x420 [niu] [ 52.673211] [<0092dfcc>] pci_device_probe+0xcc/0x180 [ 52.673284] [<009cd404>] really_probe+0xc4/0x480 [ 52.673351] [<009cd8e4>] __driver_probe_device+0x124/0x180 [ 52.673422] [<009cd968>] driver_probe_device+0x28/0xe0 [ 52.673493] [<009ce1c4>] __driver_attach+0xc4/0x200 [ 52.673564] [<009caa98>] bus_for_each_dev+0x58/0xa0 [ 52.673645] [<009cca3c>] driver_attach+0x1c/0x40 [ 52.677868] Press Stop-A (L1-A) from sun keyboard or send break [ 52.677868] twice on console to return to the boot prom [ 52.677967] ---[ end Kernel panic - not syncing: Non-resumable error. ]--- (The above is from manually loading the driver having moved it out of /lib/modules to avoid any chance of automatic load on boot, but the error /output is the same, as far as I can tell.) It turns out this is a relatively recent phenomenon - 5.6.0-1-sparc64-smp doesn't do it, for example. Also interesting and complicating for bisecting, if you boot a kernel version that "works", and then warm reboot, even "bad" kernel revisions will function normally until a cold power cycle, so presumably there's some state initialization that is no longer being done (correctly) in recent kernels? Will continue to investigate... System otherwise functions as expected if you apply module_blacklist="niu". (Didn't include network state b/c it's currently booted with the module blacklisted...) - Rich -- Package-specific info: ** Version: Linux version 5.14.0-4-sparc64-smp (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.3.0-12) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 5.14.16-1 (2021-11-03) ** Command line: BOOT_IMAGE=/vmlinux-5.14.0-4-sparc64-smp root=/dev/mapper/neeeo-root ro ** Tainted: E (8192) * unsigned module was loaded ** Kernel log: [ 18.693480] RPC: Registered named UNIX socket transport module. [ 18.693638] RPC: Registered udp transport module. [ 18.693730] RPC: Registered tcp transport module. [ 18.693822] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 18.711013] systemd[1]: Starting Coldplug All udev Devices... [ 18.730848] systemd[1]: Mounted Huge Pages File System. [ 18.732630] systemd[1]: Mounted POSIX Message Queue File System. [ 18.733981] systemd[1]: Mounted RPC Pipe File System. [ 18.735905] systemd[1]: Mounted Kernel Debug File System. [ 18.737170] systemd[1]: Mounted Kernel Trace File System. [ 18.740584] systemd[1]: Finished Create List of Static Device Nodes. [ 18.743651] systemd[1]: modprobe@configfs.service: Deactivated successfully. [ 18.746077] md5_sparc64: sparc64 md5 opcode not available. [ 18.746288] systemd[1]: Finished Load Kernel Module configfs. [ 18.749361] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 18.751924] systemd[1]: Finished Load Kernel Module drm. [ 18.755041] systemd[1]: modprobe@fuse.service: Deactivated successfully. [ 18.757550] systemd[1]: Finished Load Kernel Module fuse. [ 18.767813] systemd[1]: Finished Load Kernel Modules. [ 18.771323] systemd[1]: Finished Remount Root and Kernel File Systems. [ 18.783778] systemd[1]: Mounting FUSE Control File System... [ 18.794858] systemd[1]: Mounting Kernel Configuration File System... [ 18.809653] systemd[1]: Starting pNFS block layout mapping daemon... [ 18.811392] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [ 18.823521] systemd[1]: Starting Load/Save Random Seed... [ 18.835902] systemd[1]: Starting Apply Kernel Variables... [ 18.849246] systemd[1]: Starting Create System Users... [ 18.862312] systemd[1]: Finished Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. [ 18.884833] systemd[1]: Mounted FUSE Control File System. [ 18.886723] systemd[1]: Mounted Kernel Configuration File System. [ 18.889177] systemd[1]: Started pNFS block layout mapping daemon. [ 18.899730] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 18.907790] systemd[1]: Finished Apply Kernel Variables. [ 18.925146] systemd[1]: Mounted NFSD configuration filesystem. [ 18.961192] systemd[1]: Finished Create System Users. [ 18.973694] systemd[1]: Starting Create Static Device Nodes in /dev... [ 19.065725] systemd[1]: Finished Create Static Device Nodes in /dev. [ 19.067465] systemd[1]: Reached target Preparation for Local File Systems. [
Bug#998078:
I see, so "kernel package in oldstable-backports is unusable" is not a bug. Is there any way I can view why it's been sitting for so long that this happened, or any estimate on how much longer it'll be broken?
Bug#998078: reportbug: linux-headers-cloud-arm64 from buster-backports can't be satisfied
Package: linux-headers-cloud-arm64 Severity: normal Dear Maintainer, linux-headers-cloud-arm64 and linux-image-cloud-arm64 point to -5.10.0-0.bpo.8-cloud-arm64, except... while linux-image-5.10.0-0.bpo.8-cloud-arm64 is still around, linux-headers-... is not. So you can't install the headers for the cloud-arm64 image without reaching out to snapshot.debian.org. Presumably because the bpo.9 version hasn't produced a signed image yet, but the old one got expired because the new headers package made it in? You can see this if you check out: https://packages.debian.org/search?keywords=5.10.0-0.bpo.8-cloud-arm64 https://packages.debian.org/search?keywords=5.10.0-0.bpo.9-cloud-arm64 Thanks, - Rich -- System Information: Debian Release: 10.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-18-arm64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-headers-cloud-arm64 depends on: pn linux-headers-5.10.0-0.bpo.8-cloud-arm64 linux-headers-cloud-arm64 recommends no packages. linux-headers-cloud-arm64 suggests no packages.
Bug#996961: Acknowledgement (bpfcc-tools: biosnoop fails to print the SIZE field correctly on bullseye)
(Well, the column is labeled BYTES, but you get the point, I imagine.) On Thu, Oct 21, 2021 at 9:45 AM Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 996961: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996961. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > rincebr...@gmail.com > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Ritesh Raj Sarraf > > If you wish to submit further information on this problem, please > send it to 996...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 996961: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996961 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#996961: bpfcc-tools: biosnoop fails to print the SIZE field correctly on bullseye
Package: bpfcc-tools
Version: 0.18.0+ds-2
Severity: normal
Dear Maintainer,
Pretty simple - it looks like the internal field that biosnoop-bpfcc reads
to get the size of the IO started being cleared on IO completion at some point,
so it prints as always 0 now.
Upstream fixed this by stashing the size and timestamp before the IO starts;
since
that's really the only delta between the two, I'd probably just take that
wholesale (the
patch attached is a delta between what's currently in 0.18.0 and git master).
(Don't mind the debsums error, I went and tinkered with my copy to try a couple
of
solutions; it's broken on unmodified biosnoop.)
- Rich
-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000,
'stable'), (901, 'proposed-updates'), (900, 'oldstable-debug'), (900,
'testing'), (800, 'unstable-debug'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'oldstable-proposed-updates-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bpfcc-tools depends on:
ii python3 3.9.2-3
ii python3-bpfcc0.18.0+ds-2
ii python3-netaddr 0.7.19-5
bpfcc-tools recommends no packages.
bpfcc-tools suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/sbin/biosnoop-bpfcc (from bpfcc-tools package)
--- tools/biosnoop.py.old 2021-10-21 09:38:53.626276801 -0400
+++ tools/biosnoop.py 2021-10-21 09:39:03.354295218 -0400
@@ -39,6 +39,12 @@
#include
#include
+// for saving the timestamp and __data_len of each request
+struct start_req_t {
+u64 ts;
+u64 data_len;
+};
+
struct val_t {
u64 ts;
u32 pid;
@@ -57,7 +63,7 @@
char name[TASK_COMM_LEN];
};
-BPF_HASH(start, struct request *);
+BPF_HASH(start, struct request *, struct start_req_t);
BPF_HASH(infobyreq, struct request *, struct val_t);
BPF_PERF_OUTPUT(events);
@@ -80,42 +86,43 @@
// time block I/O
int trace_req_start(struct pt_regs *ctx, struct request *req)
{
-u64 ts;
-ts = bpf_ktime_get_ns();
-start.update(, );
+struct start_req_t start_req = {
+.ts = bpf_ktime_get_ns(),
+.data_len = req->__data_len
+};
+start.update(, _req);
return 0;
}
// output
int trace_req_completion(struct pt_regs *ctx, struct request *req)
{
-u64 *tsp;
+struct start_req_t *startp;
struct val_t *valp;
struct data_t data = {};
u64 ts;
// fetch timestamp and calculate delta
-tsp = start.lookup();
-if (tsp == 0) {
+startp = start.lookup();
+if (startp == 0) {
// missed tracing issue
return 0;
}
ts = bpf_ktime_get_ns();
-data.delta = ts - *tsp;
+data.delta = ts - startp->ts;
data.ts = ts / 1000;
data.qdelta = 0;
valp = infobyreq.lookup();
+data.len = startp->data_len;
if (valp == 0) {
-data.len = req->__data_len;
data.name[0] = '?';
data.name[1] = 0;
} else {
if (##QUEUE##) {
-data.qdelta = *tsp - valp->ts;
+data.qdelta = startp->ts - valp->ts;
}
data.pid = valp->pid;
-data.len = req->__data_len;
data.sector = req->__sector;
bpf_probe_read_kernel(, sizeof(data.name), valp->name);
struct gendisk *rq_disk = req->rq_disk;
Bug#996397:
Just to be clear, my actual problem is that things like:
rpm --eval '%{python_version}'
rpm --eval '%{__python}'
Do not do either what they do on recent RPM-based distros:
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
Or on, say, older Debian:
2.7
/usr/bin/python
But instead just:
%{python_version}
%{__python}
I could be entirely off-base about why this is. I only spent so long on it.
But it certainly broke some expectations.
- Rich
Bug#996397: rpm-common: macros.* are no longer in any package provided in Debian
Package: rpm-common
Version: 4.16.1.2+dfsg1-3
Severity: normal
Dear Maintainer,
When debugging why %{python_version} no longer expanded in an alien package,
I discovered that in bullseye and up, the macros.* packages (and their
associated macros) seem entirely absent.
It seems like upstream RPM stopped including them between 4.14.2.1 and 4.15.0.
The alpha changelog [1] notes:
- Remove script language helper macros and associated scripts
And the commit [2] explicitly says:
yes this will break existing packages and force distros to deal
with the fallout, but we believe its for the best:
these macros are also best maintained by people closer to the languages
in question, as has been done with all the newer languages predating
perl and python. rpm-extras exists as the place for maintaining and
collaborating on such material.
- Rich
[1] - https://rpm.org/timeline.html
[2] -
https://github.com/rpm-software-management/rpm/commit/ba85c95963f9b62f237c0442f6b5aca3e355fa83
-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000,
'stable'), (900, 'oldstable-debug'), (900, 'testing'), (800, 'unstable-debug'),
(500, 'stable-debug'), (500, 'proposed-updates-debug'), (500,
'oldstable-proposed-updates-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages rpm-common depends on:
ii libaudit11:3.0-2
ii libc62.31-13+deb11u2
ii libdbus-1-3 1.12.20-2
ii librpm9 4.16.1.2+dfsg1-3
ii librpmio94.16.1.2+dfsg1-3
ii libselinux1 3.1-3
rpm-common recommends no packages.
rpm-common suggests no packages.
-- no debconf information
Bug#993966: linux-image-5.10.0-8-sparc64: Kernel panic while copying a bunch of files over NFS
]: alloc_skb_with_frags+0x34/0x1a0 [101124.086209] Caller[00a048a4]: sock_alloc_send_pskb+0x1e4/0x220 [101124.173363] Caller[00b5ee24]: unix_stream_sendmsg+0x224/0x440 [101124.259244] Caller[009fd95c]: sock_sendmsg+0x3c/0x80 [101124.334839] Caller[009feeb4]: sys_sendmsg+0x1d4/0x200 [101124.416158] Caller[00a00848]: ___sys_sendmsg+0x48/0x80 [101124.494045] Caller[00a00920]: __sys_sendmsg+0x40/0x80 [101124.570789] Caller[00a00978]: sys_sendmsg+0x18/0x40 [101124.645245] Caller[00406174]: linux_sparc_syscall+0x34/0x44 [101124.728846] Caller[f80100e0826c]: 0xf80100e0826c [101124.799859] Instruction DUMP: [101124.799868] c277a7f7 [101124.839996] c4076028 [101124.872127] d85f60b0 [101124.904259] [101124.936391] 82004002 [101124.968524] 8f52 [101125.000656] 8411e00e [101125.032789] 9190a000 [101125.064921] c45f4000 [101125.097049] [101125.158631] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [101125.260523] Press Stop-A (L1-A) from sun keyboard or send break [101125.260523] twice on console to return to the boot prom [101125.409302] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 ]--- I've done this workload a bunch, so I'm not really sure why it happened now and not any time before, but here we are. If you've got any suggested debugging info you'd like to see, I'm all ears - kdump doesn't fly on sparc, kgdb+kdb might be but then I'd probably sacrifice my local serial console for it... If this crops up again, I'll go try cutting a custom kernel with kgdb and see what can be done. - Rich -- Package-specific info: ** Version: Linux version 5.10.0-8-sparc64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 Debian 5.10.46-4 (2021-08-03) ** Command line: root=/dev/mapper/ogami--vg-root ro ** Tainted: E (8192) * unsigned module was loaded ** Kernel log: [ 60.255994] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [ 60.463831] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 60.669232] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 60.899766] systemd[1]: Reached target Local Encrypted Volumes. [ 61.055997] systemd[1]: Reached target Paths. [ 61.183683] systemd[1]: Reached target Slices. [ 61.304702] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 61.484438] systemd[1]: Listening on LVM2 poll daemon socket. [ 61.686087] systemd[1]: Listening on RPCbind Server Activation Socket. [ 61.864512] systemd[1]: Listening on Syslog Socket. [ 62.000391] systemd[1]: Listening on fsck to fsckd communication Socket. [ 62.183825] systemd[1]: Listening on initctl Compatibility Named Pipe. [ 62.365315] systemd[1]: Listening on Journal Audit Socket. [ 62.516245] systemd[1]: Listening on Journal Socket (/dev/log). [ 62.684599] systemd[1]: Listening on Journal Socket. [ 62.840690] systemd[1]: Listening on udev Control Socket. [ 62.988375] systemd[1]: Listening on udev Kernel Socket. [ 63.145402] systemd[1]: Mounting Huge Pages File System... [ 63.304669] systemd[1]: Mounting POSIX Message Queue File System... [ 63.495532] systemd[1]: Mounting NFSD configuration filesystem... [ 63.719732] systemd[1]: Mounting RPC Pipe File System... [ 63.995686] RPC: Registered named UNIX socket transport module. [ 64.087266] RPC: Registered udp transport module. [ 64.165812] RPC: Registered tcp transport module. [ 64.244395] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 64.349705] systemd[1]: Mounting Kernel Debug File System... [ 64.526057] systemd[1]: Mounting Kernel Trace File System... [ 64.635247] md5_sparc64: sparc64 md5 opcode not available. [ 64.773913] systemd[1]: Condition check resulted in Kernel Module supporting RPCSEC_GSS being skipped. [ 64.930735] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 65.023535] systemd[1]: Finished Availability of block devices. [ 65.203960] systemd[1]: Starting Set the console keyboard layout... [ 65.385674] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 65.655474] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... [ 66.182428] systemd[1]: Starting Load Kernel Module configfs... [ 66.504381] systemd[1]: Starting Load Kernel Module drm... [ 66.785123] systemd[1]: Starting Load Kernel Module fuse... [ 66.988639] fuse: init (API version 7.32) [ 67.151463] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 67.391250] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 67.666104] systemd[1]: Starting Journal Service... [ 67.959146] systemd[1]: Starting Load Kernel Modules... [ 68.308553] systemd[1]: Starting Remoun
Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot
Hi Michael, First, my apologies, I hadn't noticed you were one of the maintainers of the package when I wrote my response, so it was written thinking I was talking to someone uninvolved in the process who had offered suggestions while stating a lack of familiarity with the problem domain, not someone who every well-informed person in the discussion would know was quite familiar with qemu a priori, and is just stating they have no experience in this one area. (I have no particular insight into why I reached this conclusion, but somehow I did.) I very much appreciate that you've done everything you can reasonably do at the moment to provide a reasonably recent and patched set of software - I know the freeze meant that 6.0 couldn't turn up in unstable, much less bullseye, which in turn means that buster-backports wasn't going to see anything, and buster is, as you say, obviously a complete nonstarter. I'm no stranger to building and running my own packages, so that's not really the issue, it just seems unfortunate to keep shipping a program that has a nontrivial chance of crashing and burning every time it's run, and there being no real potential for that changing. (Of course, you might not know that's the case until well after it's in stable, at which point it's not getting dropped short of earth-shattering catastrophe...) I'm not claiming to have a good idea for how to resolve or even mitigate this, other than perhaps a breakdown somewhere easily discoverable of "we expect these tools to work reliably, these few usually work for most people, and these forsaken ones may torch the crops and salt the earth while laughing". (A warning on first run of any of the more exciting options in qemu-user-static or if any of qemu-system-* fit the bill would probably be troublesome, at least in the common former case of being used to run non-native binaries...) I had not asked upstream for help because they pretty clearly state [1] that they don't provide support for older or distro-provided versions, and as I mentioned before, when I tried building 6.0 against buster, it blew up spectacularly. (Of course, with bullseye out and 6.1 sitting happily in unstable, this becomes much more accessible...once I take the plunge on my main systems, at least. And it seems moot anyway, because I've been hanging out in their IRC channel, and nobody seems to be getting turned away for running older or distro versions, just gently suggested that it might be resolved already.) Thank you again for your work, and I'm sorry that I came across as an ungrateful entitled person. - Rich [1] - https://www.qemu.org/support/ On Wed, Aug 25, 2021 at 10:46 AM Michael Tokarev wrote: > > 04.07.2021 15:02, Rich wrote: > > When I tried building qemu 6.0 or git on buster, as I recall it > > errored out on dependencies not available in sufficiently new > > incarnations, even in backports. > > > > If the answer to "this is quite buggy" is "just run a version not even > > in unstable yet", that's...quite unfortunate. > > > > If you're just saying this because it's qemu upstream's opinion, well, > > I knew that. :) > > Hi Rich! > > I'm sorry to disappoint you, but this was all I was able to offer. > It is not "qemu upstream's opinion", it is my opinion, - it fells > like riscv64 in 3.1 was quite buggy and there's nothing I can do > about it, - I definitely wont backport changes from 6.0 to buster's > 3.1 version. > > Usually qemu builds quite well on current distributions, including > debian buster. I backported 5.2 version (from bullseye) for buster > together with 2 or 3 new dependencies which were not in buster. > > I can not, at the time, provide a more recent version of qemu > (6.0) even for unstable since - at the time - debian was frozen > before bullseye release. However, I did provide 6.0 version > in experimental - this is the only way I know to actually > provide a new upstream version for debian during freeze. > Ofcourse I can't provide backport of 6.0 for buster since it > wasn't in bullsyeye or instable. > > So your disapproval of my answer stays solely with you - I did > everything I was able to do. And I definitely suggested you the > only realistic - to my opinion - way to go forward - which is to > try either latest stable version or even the current development > version. Because this is the only way to ensure if the bug you're > seeing is already fixed. > > Meanwhile, 6.1 has been released (yesterday) and it is already > available on debian unstable today. > > /mjt
Bug#992830: udevadm trigger produces inconsistent by-id entries
LVM, MD, direct mounted, or anything more exciting * I've also seen this on up-to-date Debian buster, but in that case, the vanishing /dev/sda was a SATA disk, and was not / or mounted. - Rich -- Package-specific info: -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.48-vanilla1 (SMP w/6 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udev depends on: ii adduser 3.118 ii dpkg 1.20.9 ii libacl1 2.2.53-10 ii libblkid1 2.36.1-8 ii libc6 2.31-13 ii libkmod2 28-1 ii libselinux1 3.1-3 ii libudev1 247.3-6 ii systemd-sysv 247.3-6 ii util-linux2.36.1-8 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 247.3-6 -- no debconf information P: /devices/LNXSYSTM:00 L: 0 E: DEVPATH=/devices/LNXSYSTM:00 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXSYSTM: E: USEC_INITIALIZED=3205273 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXCPU:00 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXCPU: E: USEC_INITIALIZED=3205850 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXCPU:01 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXCPU: E: USEC_INITIALIZED=3206620 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXCPU:02 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXCPU: E: USEC_INITIALIZED=3205819 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXCPU:03 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXCPU: E: USEC_INITIALIZED=3205857 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXCPU:04 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:04 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXCPU: E: USEC_INITIALIZED=3206606 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXCPU:05 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:05 E: SUBSYSTEM=acpi E: MODALIAS=acpi:LNXCPU: E: USEC_INITIALIZED=3206535 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXPWRBN:00 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00 E: SUBSYSTEM=acpi E: DRIVER=button E: MODALIAS=acpi:LNXPWRBN: E: USEC_INITIALIZED=3205721 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 E: SUBSYSTEM=input E: PRODUCT=19/0/1/0 E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PROP=0 E: EV=3 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: USEC_INITIALIZED=1526601 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: TAGS=:seat: E: CURRENT_TAGS=:seat: P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2/event1 N: input/event1 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2/event1 E: SUBSYSTEM=input E: DEVNAME=/dev/input/event1 E: MAJOR=13 E: MINOR=65 E: USEC_INITIALIZED=3338213 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: LIBINPUT_DEVICE_GROUP=19/0/1:LNXPWRBN/button E: TAGS=:power-switch: E: CURRENT_TAGS=:power-switch: P: /devices/LNXSYSTM:00/LNXPWRBN:00/wakeup/wakeup4 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/wakeup/wakeup4 E: SUBSYSTEM=wakeup P: /devices/LNXSYSTM:00/LNXSLPBN:00 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSLPBN:00 E: SUBSYSTEM=acpi E: DRIVER=button E: MODALIAS=acpi:LNXSLPBN: E: USEC_INITIALIZED=3206239 E: ID_VENDOR_FROM_DATABASE=The Linux Foundation P: /devices/LNXSYSTM:00/LNXSLPBN:00/input/input5 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSLPBN:00/input/input5 E: SUBSYSTEM=input E: PRODUCT=19/0/3/0 E: NAME="Sleep Button" E: PHYS="LNXSLPBN/button/input0" E: PROP=0 E: EV=3 E: KEY=4000 0 0 E: MODALIAS=input:b0019vp0003e-e0,1,k8E,ramlsfw E: USEC_INITIALIZED=1526650 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXSLPBN:00 E: ID_PATH_TAG=acpi-LNXSLPBN_00 E: ID_FOR_SEAT=input-acpi-LNXSLPBN_00 E: TAGS=:seat: E: CURRENT_TAGS=:seat: P: /devices/LNXSYSTM:00/LNXSLPBN:00/input/input5/event3 N: input/event3 L: 0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSLPBN:00/input/input5/event3 E: SUBSYSTEM=input E: DEVNAME=/dev/input/event3 E: MAJOR=13 E: MINOR=67 E: USEC_INITIALIZED=3341068 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXSLPBN:00 E: ID_PATH_TAG=acpi-LNXSLPBN_00 E: LIBINPUT_DEVICE_GROUP=19/0/3:LNXSLPBN/button E: TAGS=:power-switch: E:
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
Hm, minor note, I think I confused myself about convincing GRUB to work, I accidentally stuck nomodeset back in the boot list from GRUB while tinkering. It works without nomodeset on rEFInd, though, that's still true. I should try force-loading the saved vbios from booting that way in GRUB and see if anything else burns down... Also, I found https://lists.gnu.org/archive/html/help-grub/2011-03/msg00036.html, so this has been broken for a long time. https://lists.gnu.org/archive/html/grub-devel/2009-02/msg00130.html seems to suggest GRUB was unlikely to fix this in a timely fashion, which seems to still be true. So...don't use GRUB, I guess? - Rich On Sun, Aug 22, 2021 at 4:03 AM Rich wrote: > > ...well that's _fascinating_. > # grep -C3 nouveau /var/log/Xorg.0.log > [30.712] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. > [30.712] (==) modeset(0): DPMS enabled > [30.713] (II) modeset(0): [DRI2] Setup complete > [30.713] (II) modeset(0): [DRI2] DRI driver: nouveau > [30.713] (II) modeset(0): [DRI2] VDPAU driver: nouveau > [30.713] (II) Initializing extension Generic Event Extension > [30.713] (II) Initializing extension SHAPE > [30.714] (II) Initializing extension MIT-SHM > -- > [30.728] (II) Initializing extension SELinux > [30.729] (II) SELinux: Disabled on system > [30.729] (II) Initializing extension GLX > [30.745] (II) AIGLX: Loaded and initialized nouveau > [30.745] (II) GLX: Initialized DRI2 GL provider for screen 0 > [30.745] (II) Initializing extension XFree86-VidModeExtension > [30.746] (II) Initializing extension XFree86-DGA > # journalctl -k -b 0 | grep -B10 nouveau | head -n [mumble] > Aug 22 02:54:24 struth kernel: scsi host4: ahci > Aug 22 02:54:24 struth kernel: ata1: SATA max UDMA/133 abar > m2048@0xdb504000 port 0xdb504100 irq 30 > Aug 22 02:54:24 struth kernel: ata2: DUMMY > Aug 22 02:54:24 struth kernel: ata3: DUMMY > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: enabling device > (0002 -> 0003) > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: vgaarb: > deactivate vga console > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: NVIDIA G84 (084700a2) > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: pci: MSI enabled > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PRAMIN... > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: ... not enabled > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PROM... > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: : > ROM signature (0201) unknown > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: image 0 invalid > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: scored 0 > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying ACPI... > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying ACPI... > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PCIROM... > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: Invalid PCI ROM > header signature: expecting 0xaa55, got 0x0001 > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PLATFORM... > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: 00f0: > NPDE signature (30303638) unknown > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: : > type 00, 53248 bytes > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: scored 4 > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: using image > from PLATFORM > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: 00f0: > NPDE signature (30303638) unknown > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: 00f0: > NPDE signature (30303638) unknown > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: BIT signature found > Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: version > 60.84.49.03.00 > [...] > > What changed? I didn't lob a vbios manually in or anything, if the > output there didn't make that clear... > > The bootloader changed. I had the system booting from grubx64.efi > directly, but when trying to reboot into macOS, I found that the > autogenerated "boot macOS" GRUB entries just panicked, so I used alt > on boot to tell it to boot macOS without passing through GRUB or > rEFInd, and reconfigured it to launch rEFInd on boot instead. > > Then I directly booted vmlinuz-5.10.0-8-amd64 from rEFInd, without > passing through GRUB, and it didn't steal my nomodeset from the grub > parameters... > > ...but instead of dying on switching, it happily booted. > > Womp, and I say this advisedly, womp. > > (GRUB chainloaded from rEFInd breaks the same.) > > Curiously, when I cha
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
...well that's _fascinating_. # grep -C3 nouveau /var/log/Xorg.0.log [30.712] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. [30.712] (==) modeset(0): DPMS enabled [30.713] (II) modeset(0): [DRI2] Setup complete [30.713] (II) modeset(0): [DRI2] DRI driver: nouveau [30.713] (II) modeset(0): [DRI2] VDPAU driver: nouveau [30.713] (II) Initializing extension Generic Event Extension [30.713] (II) Initializing extension SHAPE [30.714] (II) Initializing extension MIT-SHM -- [30.728] (II) Initializing extension SELinux [30.729] (II) SELinux: Disabled on system [30.729] (II) Initializing extension GLX [30.745] (II) AIGLX: Loaded and initialized nouveau [30.745] (II) GLX: Initialized DRI2 GL provider for screen 0 [30.745] (II) Initializing extension XFree86-VidModeExtension [30.746] (II) Initializing extension XFree86-DGA # journalctl -k -b 0 | grep -B10 nouveau | head -n [mumble] Aug 22 02:54:24 struth kernel: scsi host4: ahci Aug 22 02:54:24 struth kernel: ata1: SATA max UDMA/133 abar m2048@0xdb504000 port 0xdb504100 irq 30 Aug 22 02:54:24 struth kernel: ata2: DUMMY Aug 22 02:54:24 struth kernel: ata3: DUMMY Aug 22 02:54:24 struth kernel: nouveau :01:00.0: enabling device (0002 -> 0003) Aug 22 02:54:24 struth kernel: nouveau :01:00.0: vgaarb: deactivate vga console Aug 22 02:54:24 struth kernel: nouveau :01:00.0: NVIDIA G84 (084700a2) Aug 22 02:54:24 struth kernel: nouveau :01:00.0: pci: MSI enabled Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PRAMIN... Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: ... not enabled Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PROM... Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: : ROM signature (0201) unknown Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: image 0 invalid Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: scored 0 Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying ACPI... Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying ACPI... Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PCIROM... Aug 22 02:54:24 struth kernel: nouveau :01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0001 Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: trying PLATFORM... Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: 00f0: NPDE signature (30303638) unknown Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: : type 00, 53248 bytes Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: scored 4 Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: using image from PLATFORM Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: 00f0: NPDE signature (30303638) unknown Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: 00f0: NPDE signature (30303638) unknown Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: BIT signature found Aug 22 02:54:24 struth kernel: nouveau :01:00.0: bios: version 60.84.49.03.00 [...] What changed? I didn't lob a vbios manually in or anything, if the output there didn't make that clear... The bootloader changed. I had the system booting from grubx64.efi directly, but when trying to reboot into macOS, I found that the autogenerated "boot macOS" GRUB entries just panicked, so I used alt on boot to tell it to boot macOS without passing through GRUB or rEFInd, and reconfigured it to launch rEFInd on boot instead. Then I directly booted vmlinuz-5.10.0-8-amd64 from rEFInd, without passing through GRUB, and it didn't steal my nomodeset from the grub parameters... ...but instead of dying on switching, it happily booted. Womp, and I say this advisedly, womp. (GRUB chainloaded from rEFInd breaks the same.) Curiously, when I changed it from debug=debug to debug=info, this started appearing on successive boots from rEFInd-only: [ 66.323195] nouveau :01:00.0: firmware: failed to load nouveau/nv84_xuc00f (-2) [ 66.323210] nouveau :01:00.0: Direct firmware load for nouveau/nv84_xuc00f failed with error -2 [ 66.323218] nouveau :01:00.0: vp: unable to load firmware nouveau/nv84_xuc00f [ 66.323223] nouveau :01:00.0: vp: init failed, -2 [ 66.323273] nouveau :01:00.0: firmware: failed to load nouveau/nv84_xuc103 (-2) [ 66.323278] nouveau :01:00.0: Direct firmware load for nouveau/nv84_xuc103 failed with error -2 [ 66.323284] nouveau :01:00.0: bsp: unable to load firmware nouveau/nv84_xuc103 [ 66.323288] nouveau :01:00.0: bsp: init failed, -2 Video accel still works fine, but it's definitely not in my log for the first time this worked. Curious. Even better, if you disable gfxterm, it works with GRUB, too... Seems GRUB screws up the world when it makes the pretty menu. - Rich On Sat, Aug 21, 2021 at 1:29 PM Rich wrote: > > https://forums.developer.nvidia.com/t/error-lo
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
https://forums.developer.nvidia.com/t/error-loading-nvidia-kernel-module-with-macbookpro3-1/39313 I found other threads, but apparently this is just a thing people have found happens with nouveau or nvidia.ko if you're booting in EFI mode? That user said they booted in BIOS emu and smuggled their vBIOS out that way, I'll see what I can do... On Sat, Aug 21, 2021, 6:00 AM Rich wrote: > Okay, so, I did just reboot and verify this... > > * kernel command line "... ro quiet": > displays a blinking cursor in the top-left for a couple seconds and > then abruptly cuts to full black, no response to VT switching or any > other keyboard input, waited 5 minutes to see if this ever changed > > * kernel command line "...ro" > displays normal output up to the aforementioned EFI VGA lines, then > just...stops ever updating again, waited for 5m on this one too, also > doesn't respond to VT switching or anything else > > https://i.imgur.com/jmcHHhm.jpg is a photo > > * kernel command line "...quiet nomodeset" > We get all the way to X and are cooking > > As far as it's concerned, it keeps going normally after it stops > outputting, and isn't sure why I hard power cycled it. > > Here's the first lines after that divergence on the "...ro" case: > > Aug 21 04:57:09 struth kernel: checking generic (c003 71) vs > hw (c000 1000) > Aug 21 04:57:09 struth kernel: fb0: switching to nouveaufb from EFI VGA > Aug 21 04:57:09 struth kernel: hub 6-0:1.0: 2 ports detected > Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: UHCI Host Controller > Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: new USB bus > registered, assigned bus number 7 > Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: detected 2 ports > Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: irq 21, io base > 0x6040 > Aug 21 04:57:09 struth kernel: Console: switching to colour dummy device > 80x25 > Aug 21 04:57:09 struth kernel: nouveau :01:00.0: vgaarb: > deactivate vga console > Aug 21 04:57:09 struth kernel: usb usb7: New USB device found, > idVendor=1d6b, idProduct=0001, bcdDevice= 5.10 > Aug 21 04:57:09 struth kernel: usb usb7: New USB device strings: > Mfr=3, Product=2, SerialNumber=1 > Aug 21 04:57:09 struth kernel: usb usb7: Product: UHCI Host Controller > Aug 21 04:57:09 struth kernel: usb usb7: Manufacturer: Linux > 5.10.0-8-amd64 uhci_hcd > Aug 21 04:57:09 struth kernel: usb usb7: SerialNumber: :00:1d.2 > Aug 21 04:57:09 struth kernel: nouveau :01:00.0: NVIDIA G84 (084700a2) > Aug 21 04:57:09 struth kernel: hub 7-0:1.0: USB hub found > Aug 21 04:57:09 struth kernel: hub 7-0:1.0: 2 ports detected > Aug 21 04:57:09 struth kernel: ata4.00: ATAPI: HL-DT-ST DVDRW > GSA-S10N, AP09, max UDMA/33 > Aug 21 04:57:09 struth kernel: nouveau :01:00.0: Invalid PCI ROM > header signature: expecting 0xaa55, got 0x > Aug 21 04:57:09 struth kernel: nouveau :01:00.0: bios: unable to > locate usable image > Aug 21 04:57:09 struth kernel: nouveau :01:00.0: bios ctor failed, -22 > Aug 21 04:57:09 struth kernel: nouveau: probe of :01:00.0 failed > with error -22 > Aug 21 04:57:09 struth kernel: scsi 1:0:0:0: CD-ROM > HL-DT-ST DVDRW GSA-S10N AP09 PQ: 0 ANSI: 5 > Aug 21 04:57:09 struth kernel: random: fast init done > Aug 21 04:57:09 struth kernel: ata1: SATA link up 1.5 Gbps (SStatus > 113 SControl 300) > Aug 21 04:57:09 struth kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 > (SET FEATURES) filtered out > Aug 21 04:57:09 struth kernel: ata1.00: ATA-8: WDC WD2500LPVT-00G33T0, > 01.01A01, max UDMA/133 > Aug 21 04:57:09 struth kernel: ata1.00: 488397168 sectors, multi 0: > LBA48 NCQ (depth 32), AA > Aug 21 04:57:09 struth kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 > (SET FEATURES) filtered out > Aug 21 04:57:09 struth kernel: ata1.00: configured for UDMA/133 > Aug 21 04:57:09 struth kernel: scsi 0:0:0:0: Direct-Access ATA > WDC WD2500LPVT-0 1A01 PQ: 0 ANSI: 5 > Aug 21 04:57:09 struth kernel: sr 1:0:0:0: [sr0] scsi3-mmc drive: > 24x/24x writer cd/rw xa/form2 cdda caddy > Aug 21 04:57:09 struth kernel: cdrom: Uniform CD-ROM driver Revision: 3.20 > Aug 21 04:57:09 struth kernel: clocksource: tsc: mask: > 0x max_cycles: 0x1fa284fbd4e, max_idle_ns: > 440795223138 ns > Aug 21 04:57:09 struth kernel: clocksource: Switched to clocksource tsc > Aug 21 04:57:09 struth kernel: sr 1:0:0:0: Attached scsi CD-ROM sr0 > Aug 21 04:57:09 struth kernel: sd 0:0:0:0: [sda] 488397168 512-byte > logical blocks: (250 GB/233 GiB) > > > When we check out why Xorg doesn't ever spawn if the system keeps > running when this happens, the Xorg.0.log diff says... > (EE) open /dev/fb0: No such file or directory &g
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
Okay, so, I did just reboot and verify this... * kernel command line "... ro quiet": displays a blinking cursor in the top-left for a couple seconds and then abruptly cuts to full black, no response to VT switching or any other keyboard input, waited 5 minutes to see if this ever changed * kernel command line "...ro" displays normal output up to the aforementioned EFI VGA lines, then just...stops ever updating again, waited for 5m on this one too, also doesn't respond to VT switching or anything else https://i.imgur.com/jmcHHhm.jpg is a photo * kernel command line "...quiet nomodeset" We get all the way to X and are cooking As far as it's concerned, it keeps going normally after it stops outputting, and isn't sure why I hard power cycled it. Here's the first lines after that divergence on the "...ro" case: Aug 21 04:57:09 struth kernel: checking generic (c003 71) vs hw (c000 1000) Aug 21 04:57:09 struth kernel: fb0: switching to nouveaufb from EFI VGA Aug 21 04:57:09 struth kernel: hub 6-0:1.0: 2 ports detected Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: UHCI Host Controller Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 7 Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: detected 2 ports Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: irq 21, io base 0x6040 Aug 21 04:57:09 struth kernel: Console: switching to colour dummy device 80x25 Aug 21 04:57:09 struth kernel: nouveau :01:00.0: vgaarb: deactivate vga console Aug 21 04:57:09 struth kernel: usb usb7: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.10 Aug 21 04:57:09 struth kernel: usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Aug 21 04:57:09 struth kernel: usb usb7: Product: UHCI Host Controller Aug 21 04:57:09 struth kernel: usb usb7: Manufacturer: Linux 5.10.0-8-amd64 uhci_hcd Aug 21 04:57:09 struth kernel: usb usb7: SerialNumber: :00:1d.2 Aug 21 04:57:09 struth kernel: nouveau :01:00.0: NVIDIA G84 (084700a2) Aug 21 04:57:09 struth kernel: hub 7-0:1.0: USB hub found Aug 21 04:57:09 struth kernel: hub 7-0:1.0: 2 ports detected Aug 21 04:57:09 struth kernel: ata4.00: ATAPI: HL-DT-ST DVDRW GSA-S10N, AP09, max UDMA/33 Aug 21 04:57:09 struth kernel: nouveau :01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x Aug 21 04:57:09 struth kernel: nouveau :01:00.0: bios: unable to locate usable image Aug 21 04:57:09 struth kernel: nouveau :01:00.0: bios ctor failed, -22 Aug 21 04:57:09 struth kernel: nouveau: probe of :01:00.0 failed with error -22 Aug 21 04:57:09 struth kernel: scsi 1:0:0:0: CD-ROM HL-DT-ST DVDRW GSA-S10N AP09 PQ: 0 ANSI: 5 Aug 21 04:57:09 struth kernel: random: fast init done Aug 21 04:57:09 struth kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Aug 21 04:57:09 struth kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out Aug 21 04:57:09 struth kernel: ata1.00: ATA-8: WDC WD2500LPVT-00G33T0, 01.01A01, max UDMA/133 Aug 21 04:57:09 struth kernel: ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 32), AA Aug 21 04:57:09 struth kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out Aug 21 04:57:09 struth kernel: ata1.00: configured for UDMA/133 Aug 21 04:57:09 struth kernel: scsi 0:0:0:0: Direct-Access ATA WDC WD2500LPVT-0 1A01 PQ: 0 ANSI: 5 Aug 21 04:57:09 struth kernel: sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda caddy Aug 21 04:57:09 struth kernel: cdrom: Uniform CD-ROM driver Revision: 3.20 Aug 21 04:57:09 struth kernel: clocksource: tsc: mask: 0x max_cycles: 0x1fa284fbd4e, max_idle_ns: 440795223138 ns Aug 21 04:57:09 struth kernel: clocksource: Switched to clocksource tsc Aug 21 04:57:09 struth kernel: sr 1:0:0:0: Attached scsi CD-ROM sr0 Aug 21 04:57:09 struth kernel: sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB) When we check out why Xorg doesn't ever spawn if the system keeps running when this happens, the Xorg.0.log diff says... (EE) open /dev/fb0: No such file or directory vesa: Refusing to run on UEFI (EE) Screen 0 deleted because of no matching config section. (II) UnloadModule: "modesetting" (EE) Screen 0 deleted because of no matching config section. (II) UnloadModule: "fbdev" (II) UnloadSubModule: "fbdevhw" (EE) Device(s) detected, but none match those in the config file. (EE) error: (EE) no screens found(EE) (EE) (Full logs attached, .old is the one from "...ro" boot that didn't display, the other is from a boot with nomodeset) Can provide other information as useful. - Rich On Sat, Aug 21, 2021 at 4:28 AM Rich wrote: > > Also (I've never used this before, so I might be holding it wrong, but...): > $ isenkram-lookup > cheese > ethtool > pcscd > scdaemon > $ > > On Sat, Aug 21, 2021 at 4:15 AM Rich wrot
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
Also (I've never used this before, so I might be holding it wrong, but...): $ isenkram-lookup cheese ethtool pcscd scdaemon $ On Sat, Aug 21, 2021 at 4:15 AM Rich wrote: > > Hi Salvatore, > I used firmware-11.0.0-amd64-netinst.iso. And yes, I did not manually > install firmware-misc-nonfree since this initially failed, and I still > got a black screen which did not ever resolve or respond to VT > switching unless I used nomodeset and deleted quiet. (With quiet > removed, it doesn't black out, but it does stop ever responding after > it prints the "switching from EFI VGA" line.) > > I'll reboot in a bit and wait longer and see what happens... > > grep -C3 nouveau on syslog for, I believe, one of the failed boots says: > Aug 21 02:28:06 struth kernel: [2.209185] TSC found unstable after > boot, most likely due to broken BIOS. Use 'tsc=unstable'. > Aug 21 02:28:06 struth kernel: [2.209187] sched_clock: Marking > unstable (2208942206, 241638)<-(2215089173, -5905242) > Aug 21 02:28:06 struth kernel: [2.221262] clocksource: Switched to > clocksource hpet > Aug 21 02:28:06 struth kernel: [2.305362] nouveau :01:00.0: > enabling device (0002 -> 0003) > Aug 21 02:28:06 struth kernel: [2.305517] checking generic > (c003 71) vs hw (d200 100) > Aug 21 02:28:06 struth kernel: [2.305519] checking generic > (c003 71) vs hw (c000 1000) > Aug 21 02:28:06 struth kernel: [2.305521] fb0: switching to > nouveaufb from EFI VGA > Aug 21 02:28:06 struth kernel: [2.305686] Console: switching to > colour dummy device 80x25 > Aug 21 02:28:06 struth kernel: [2.305783] nouveau :01:00.0: > vgaarb: deactivate vga console > Aug 21 02:28:06 struth kernel: [2.305843] nouveau :01:00.0: > NVIDIA G84 (084700a2) > Aug 21 02:28:06 struth kernel: [2.306955] nouveau :01:00.0: > Invalid PCI ROM header signature: expecting 0xaa55, got 0x0001 > Aug 21 02:28:06 struth kernel: [2.306966] nouveau :01:00.0: > bios: unable to locate usable image > Aug 21 02:28:06 struth kernel: [2.306975] nouveau :01:00.0: > bios ctor failed, -22 > Aug 21 02:28:06 struth kernel: [2.306984] nouveau: probe of > :01:00.0 failed with error -22 > Aug 21 02:28:06 struth kernel: [2.324639] random: fast init done > Aug 21 02:28:06 struth kernel: [2.385518] ata1.00: ATAPI: HL-DT-ST > DVDRW GSA-S10N, AP09, max UDMA/33 > Aug 21 02:28:06 struth kernel: [2.457249] usb 4-1: new high-speed > USB device number 2 using ehci-pci > -- > > On Sat, Aug 21, 2021 at 4:03 AM Salvatore Bonaccorso > wrote: > > > > Control: tags -1 + moreinfo > > > > Hi Rich, > > > > On Sat, Aug 21, 2021 at 02:45:26AM -0400, Rich Ercolani wrote: > > > Package: src:linux > > > Version: 5.10.46-4 > > > Severity: normal > > > X-Debbugs-Cc: rincebr...@gmail.com > > > > > > Dear Maintainer, > > > > > > (I have no idea how many people might run into this, but...) > > > > > > I just had occasion to set up bullseye on an old Macbook Pro. After > > > convincing it to boot the installer > > > in the first place (which was "exciting"), the installer worked > > > fine... > > > > > > ...then on first boot, I selected the top GRUB option, it booted, > > > and very shortly the display blanked and the system stopped > > > responding to any input that I could see. > > > > > > I left it for a minute or two to see if it would come back, but no, > > > nothing visibly occurred. So I rebooted. > > > > > > Drop the quiet from the kernel parameters, it goes up to something > > > mentioning nouveau and switching from EFI VGA to modesetting, and > > > then...stops, entirely, no response to VT switching or any other > > > commands, for at least the few minutes I waited. (I'll reboot and > > > take a photo shortly.) > > > > > > So I try nomodeset, and we get all the way to X happily (in much > > > less time than I let it sit to see if it would come back, so I don't > > > think it would have come back...) > > > > > > Slightly inconvenient. Fortunate that I didn't try the graphical > > > installer, I suppose. > > > > > > I'll try fiddling with kdump and non-journald logging so I can get a > > > better idea what might be happening when it stops outputting... > > > > #991941 and > > https://www.debian.org/releases/bullseye/amd64/ch06s04#completing-installed-system > > Do you have needed firmware installed, which installer image did you > > use? > > > > Regards, > > Salvatore
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
Hi Salvatore, I used firmware-11.0.0-amd64-netinst.iso. And yes, I did not manually install firmware-misc-nonfree since this initially failed, and I still got a black screen which did not ever resolve or respond to VT switching unless I used nomodeset and deleted quiet. (With quiet removed, it doesn't black out, but it does stop ever responding after it prints the "switching from EFI VGA" line.) I'll reboot in a bit and wait longer and see what happens... grep -C3 nouveau on syslog for, I believe, one of the failed boots says: Aug 21 02:28:06 struth kernel: [2.209185] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. Aug 21 02:28:06 struth kernel: [2.209187] sched_clock: Marking unstable (2208942206, 241638)<-(2215089173, -5905242) Aug 21 02:28:06 struth kernel: [2.221262] clocksource: Switched to clocksource hpet Aug 21 02:28:06 struth kernel: [2.305362] nouveau :01:00.0: enabling device (0002 -> 0003) Aug 21 02:28:06 struth kernel: [2.305517] checking generic (c003 71) vs hw (d200 100) Aug 21 02:28:06 struth kernel: [2.305519] checking generic (c003 71) vs hw (c000 1000) Aug 21 02:28:06 struth kernel: [2.305521] fb0: switching to nouveaufb from EFI VGA Aug 21 02:28:06 struth kernel: [2.305686] Console: switching to colour dummy device 80x25 Aug 21 02:28:06 struth kernel: [2.305783] nouveau :01:00.0: vgaarb: deactivate vga console Aug 21 02:28:06 struth kernel: [2.305843] nouveau :01:00.0: NVIDIA G84 (084700a2) Aug 21 02:28:06 struth kernel: [2.306955] nouveau :01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0001 Aug 21 02:28:06 struth kernel: [2.306966] nouveau :01:00.0: bios: unable to locate usable image Aug 21 02:28:06 struth kernel: [2.306975] nouveau :01:00.0: bios ctor failed, -22 Aug 21 02:28:06 struth kernel: [2.306984] nouveau: probe of :01:00.0 failed with error -22 Aug 21 02:28:06 struth kernel: [2.324639] random: fast init done Aug 21 02:28:06 struth kernel: [2.385518] ata1.00: ATAPI: HL-DT-ST DVDRW GSA-S10N, AP09, max UDMA/33 Aug 21 02:28:06 struth kernel: [2.457249] usb 4-1: new high-speed USB device number 2 using ehci-pci -- On Sat, Aug 21, 2021 at 4:03 AM Salvatore Bonaccorso wrote: > > Control: tags -1 + moreinfo > > Hi Rich, > > On Sat, Aug 21, 2021 at 02:45:26AM -0400, Rich Ercolani wrote: > > Package: src:linux > > Version: 5.10.46-4 > > Severity: normal > > X-Debbugs-Cc: rincebr...@gmail.com > > > > Dear Maintainer, > > > > (I have no idea how many people might run into this, but...) > > > > I just had occasion to set up bullseye on an old Macbook Pro. After > > convincing it to boot the installer > > in the first place (which was "exciting"), the installer worked > > fine... > > > > ...then on first boot, I selected the top GRUB option, it booted, > > and very shortly the display blanked and the system stopped > > responding to any input that I could see. > > > > I left it for a minute or two to see if it would come back, but no, > > nothing visibly occurred. So I rebooted. > > > > Drop the quiet from the kernel parameters, it goes up to something > > mentioning nouveau and switching from EFI VGA to modesetting, and > > then...stops, entirely, no response to VT switching or any other > > commands, for at least the few minutes I waited. (I'll reboot and > > take a photo shortly.) > > > > So I try nomodeset, and we get all the way to X happily (in much > > less time than I let it sit to see if it would come back, so I don't > > think it would have come back...) > > > > Slightly inconvenient. Fortunate that I didn't try the graphical > > installer, I suppose. > > > > I'll try fiddling with kdump and non-journald logging so I can get a > > better idea what might be happening when it stops outputting... > > #991941 and > https://www.debian.org/releases/bullseye/amd64/ch06s04#completing-installed-system > Do you have needed firmware installed, which installer image did you > use? > > Regards, > Salvatore
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
Sorry, as was pointed out to me, MacBookPro3,1 - not Macbook3,1. Whoops. - Rich On Sat, Aug 21, 2021 at 2:48 AM Rich Ercolani wrote: > > Package: src:linux > Version: 5.10.46-4 > Severity: normal > X-Debbugs-Cc: rincebr...@gmail.com > > Dear Maintainer, > > (I have no idea how many people might run into this, but...) > > I just had occasion to set up bullseye on an old Macbook Pro. After > convincing it to boot the installer > in the first place (which was "exciting"), the installer worked fine... > > ...then on first boot, I selected the top GRUB option, it booted, and very > shortly the display blanked > and the system stopped responding to any input that I could see. > > I left it for a minute or two to see if it would come back, but no, nothing > visibly occurred. So I rebooted. > > Drop the quiet from the kernel parameters, it goes up to something mentioning > nouveau and switching from EFI VGA to modesetting, > and then...stops, entirely, no response to VT switching or any other > commands, for at least the few minutes I waited. (I'll reboot and take a > photo shortly.) > > So I try nomodeset, and we get all the way to X happily (in much less time > than I let it sit to see if it would come back, so I don't think it would > have come back...) > > Slightly inconvenient. Fortunate that I didn't try the graphical installer, I > suppose. > > I'll try fiddling with kdump and non-journald logging so I can get a better > idea what might be happening when it stops outputting... > > - Rich > > -- Package-specific info: > ** Version: > Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian > 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP > Debian 5.10.46-4 (2021-08-03) > > ** Command line: > BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 > root=UUID=b7ef62b9-b2c6-41d6-bd34-194a3d0faea4 ro nomodeset > > ** Not tainted > > ** Kernel log: > > ** Model information > [9.244969] systemd[1]: Condition check resulted in File System Check on > Root Device being skipped. > [9.249526] systemd[1]: Starting Journal Service... > [9.277479] systemd[1]: Starting Load Kernel Modules... > [9.282882] systemd[1]: Starting Remount Root and Kernel File Systems... > [9.288458] systemd[1]: Starting Coldplug All udev Devices... > [9.295469] systemd[1]: Mounted Huge Pages File System. > [9.297701] systemd[1]: Mounted POSIX Message Queue File System. > [9.301662] systemd[1]: Mounted Kernel Debug File System. > [9.305718] systemd[1]: Mounted Kernel Trace File System. > [9.308375] systemd[1]: Finished Create list of static device nodes for > the current kernel. > [9.310974] systemd[1]: modprobe@configfs.service: Succeeded. > [9.313400] systemd[1]: Finished Load Kernel Module configfs. > [9.317719] systemd[1]: modprobe@drm.service: Succeeded. > [9.318076] systemd[1]: Finished Load Kernel Module drm. > [9.323336] systemd[1]: modprobe@fuse.service: Succeeded. > [9.323716] systemd[1]: Finished Load Kernel Module fuse. > [9.330305] systemd[1]: Mounting FUSE Control File System... > [9.334002] systemd[1]: Mounting Kernel Configuration File System... > [9.338273] systemd[1]: Mounted FUSE Control File System. > [9.343526] systemd[1]: Mounted Kernel Configuration File System. > [9.465531] EXT4-fs (sda4): re-mounted. Opts: errors=remount-ro > [9.470135] systemd[1]: Finished Remount Root and Kernel File Systems. > [9.497968] systemd[1]: Condition check resulted in Rebuild Hardware > Database being skipped. > [9.499930] systemd[1]: Condition check resulted in Platform Persistent > Storage Archival being skipped. > [9.509833] systemd[1]: Starting Load/Save Random Seed... > [9.515184] systemd[1]: Starting Create System Users... > [9.521029] systemd[1]: Started Journal Service. > [9.658788] systemd-journald[227]: Received client request to flush > runtime journal. > [ 13.045883] ACPI: AC Adapter [ADP1] (on-line) > [ 13.060236] smbus_hc ACPI0001:00: SBS HC: offset = 0x20, query_bit = 0x10 > [ 13.088567] ACPI: Smart Battery System [SBS0]: AC Adapter [AC0] (on-line) > [ 13.167363] sd 0:0:0:0: Attached scsi generic sg0 type 0 > [ 13.180562] sr 2:0:0:0: Attached scsi generic sg1 type 5 > [ 13.366764] cfg80211: Loading compiled-in X.509 certificates for > regulatory database > [ 13.372366] at24 0-0050: supply vcc not found, using dummy regulator > [ 13.374806] cfg80211: Loaded X.509 cert 'b...@debian.org: > 577e021cb980e0e820821ba7b54b4961b8b4fadf' > [ 13.376829] at24 0-0050: 256 byte spd EEPROM, read-only > [ 13.379164] cfg80211: Loaded X.509 cert 'romain.
Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau
Package: src:linux Version: 5.10.46-4 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, (I have no idea how many people might run into this, but...) I just had occasion to set up bullseye on an old Macbook Pro. After convincing it to boot the installer in the first place (which was "exciting"), the installer worked fine... ...then on first boot, I selected the top GRUB option, it booted, and very shortly the display blanked and the system stopped responding to any input that I could see. I left it for a minute or two to see if it would come back, but no, nothing visibly occurred. So I rebooted. Drop the quiet from the kernel parameters, it goes up to something mentioning nouveau and switching from EFI VGA to modesetting, and then...stops, entirely, no response to VT switching or any other commands, for at least the few minutes I waited. (I'll reboot and take a photo shortly.) So I try nomodeset, and we get all the way to X happily (in much less time than I let it sit to see if it would come back, so I don't think it would have come back...) Slightly inconvenient. Fortunate that I didn't try the graphical installer, I suppose. I'll try fiddling with kdump and non-journald logging so I can get a better idea what might be happening when it stops outputting... - Rich -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=b7ef62b9-b2c6-41d6-bd34-194a3d0faea4 ro nomodeset ** Not tainted ** Kernel log: ** Model information [9.244969] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [9.249526] systemd[1]: Starting Journal Service... [9.277479] systemd[1]: Starting Load Kernel Modules... [9.282882] systemd[1]: Starting Remount Root and Kernel File Systems... [9.288458] systemd[1]: Starting Coldplug All udev Devices... [9.295469] systemd[1]: Mounted Huge Pages File System. [9.297701] systemd[1]: Mounted POSIX Message Queue File System. [9.301662] systemd[1]: Mounted Kernel Debug File System. [9.305718] systemd[1]: Mounted Kernel Trace File System. [9.308375] systemd[1]: Finished Create list of static device nodes for the current kernel. [9.310974] systemd[1]: modprobe@configfs.service: Succeeded. [9.313400] systemd[1]: Finished Load Kernel Module configfs. [9.317719] systemd[1]: modprobe@drm.service: Succeeded. [9.318076] systemd[1]: Finished Load Kernel Module drm. [9.323336] systemd[1]: modprobe@fuse.service: Succeeded. [9.323716] systemd[1]: Finished Load Kernel Module fuse. [9.330305] systemd[1]: Mounting FUSE Control File System... [9.334002] systemd[1]: Mounting Kernel Configuration File System... [9.338273] systemd[1]: Mounted FUSE Control File System. [9.343526] systemd[1]: Mounted Kernel Configuration File System. [9.465531] EXT4-fs (sda4): re-mounted. Opts: errors=remount-ro [9.470135] systemd[1]: Finished Remount Root and Kernel File Systems. [9.497968] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [9.499930] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [9.509833] systemd[1]: Starting Load/Save Random Seed... [9.515184] systemd[1]: Starting Create System Users... [9.521029] systemd[1]: Started Journal Service. [9.658788] systemd-journald[227]: Received client request to flush runtime journal. [ 13.045883] ACPI: AC Adapter [ADP1] (on-line) [ 13.060236] smbus_hc ACPI0001:00: SBS HC: offset = 0x20, query_bit = 0x10 [ 13.088567] ACPI: Smart Battery System [SBS0]: AC Adapter [AC0] (on-line) [ 13.167363] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 13.180562] sr 2:0:0:0: Attached scsi generic sg1 type 5 [ 13.366764] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 13.372366] at24 0-0050: supply vcc not found, using dummy regulator [ 13.374806] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 13.376829] at24 0-0050: 256 byte spd EEPROM, read-only [ 13.379164] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 13.386275] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 13.393790] ACPI: Smart Battery System [SBS0]: Battery Slot [BAT0] (battery present) [ 13.510117] usbcore: registered new device driver apple-mfi-fastcharge [ 13.560578] iTCO_vendor_support: vendor-support=0 [ 13.598529] appletouch 7-2:1.1: Geyser mode initialized. [ 13.600463] input: appletouch as /devices/pci:00/:00:1d.2/usb7/7-2/7-2:1.1/input/input10 [ 13.604404] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 13.606464] iTCO_wdt: Found a ICH8M
Bug#992001: zfs-dkms: ZFS_META_GITREV is "unknown"
Package: zfs-dkms Version: 2.0.3-8~bpo10+1 Severity: minor Dear Maintainer, I was curious what versions of ZFS I had imported a given pool with, so I asked zpool history -i, and to my surprise, its log entries had "software version unknown". Specifically (note that I believe the entries with "5000/5" were the 0.7.X behavior, as the commit to change it to report this only landed in 0.8.0): [...] 2019-10-05.17:12:02 [txg:7593983] open pool version 5000; software version 5000/5; uts steamer 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 [on steamer] 2019-10-05.17:12:03 [txg:7593985] import pool version 5000; software version 5000/5; uts steamer 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 [on steamer] 2019-10-05.17:32:29 [txg:7593993] open pool version 5000; software version unknown; uts steamer 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 [on steamer] 2019-10-05.17:32:30 [txg:7593995] import pool version 5000; software version unknown; uts steamer 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 [on steamer] 2020-01-18.19:19:01 [txg:9253815] open pool version 5000; software version unknown; uts steamer 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 [on steamer] 2020-01-18.19:19:01 [txg:9253817] import pool version 5000; software version unknown; uts steamer 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 [on steamer] 2020-02-18.21:05:14 [txg:9613049] open pool version 5000; software version unknown; uts steamer 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 [on steamer] [...] 2021-07-12.17:28:29 [txg:16603822] import pool version 5000; software version unknown; uts steamer 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 [on steamer] 2021-08-01.00:19:47 [txg:16905495] open pool version 5000; software version unknown; uts steamer 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 [on steamer] 2021-08-01.00:19:47 [txg:16905497] import pool version 5000; software version unknown; uts steamer 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 [on steamer] I swapped over from backports-provided 0.8.X to 2.0.X approximately May 15th, with no change in that output. (I also just filed a bug upstream about some releases having incorrect values in include/zfs_gitrev.h - including 2.0.3. Oops.) A value that conveys the package version (or, at least, the upstream version, if that's not feasible) would be useful for answering things like "did this pool ever see X buggy version?" after the fact, perhaps after historical syslogs are no longer available to infer from module load. - Rich -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (1000, 'stable-updates'), (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfs-dkms depends on: ii debconf [debconf-2.0] 1.5.71 ii dkms 2.6.1-4 ii file 1:5.35-4+deb10u2 ii libc6-dev [libc-dev] 2.28-10 ii libpython3-stdlib 3.7.3-1 ii lsb-release10.2019051400 ii perl 5.28.1-6+deb10u1 ii python3-distutils 3.7.3-1 Versions of packages zfs-dkms recommends: ii linux-libc-dev 5.10.24-1~bpo10+1 ii zfs-zed 2.0.3-8~bpo10+1 ii zfsutils-linux 2.0.3-8~bpo10+1 Versions of packages zfs-dkms suggests: ii debhelper 12.1.1 -- debconf information excluded
Bug#991263: libparted2: libparted assertion fails on resizing a certain sun partition table
Package: libparted2 Version: 3.4-1 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Like it says on the tin - I noticed my drive's partition table was smaller than the drive, tried to resizepart, and boom. I'm assuming I input a somehow invalid value, but an assertion failure was not the outcome I expected. Entire chain of events: $ sudo parted /dev/sda GNU Parted 3.4 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Warning: The disk CHS geometry (139476,255,2) reported by the operating system does not match the geometry stored on the disk label (2549,255,63). Ignore/Cancel? i Model: SEAGATE ST336704LC (scsi) Disk /dev/sda: 36.4GB Sector size (logical/physical): 512B/512B Partition Table: sun Disk Flags: Number Start End SizeFile system Flags 1 0.00B 98.7MB 98.7MB ext2 boot 2 98.7MB 21.0GB 20.9GB lvm (parted) r align-check TYPE N check partition N for TYPE(min|opt) alignment help [COMMAND] print general help, or help on COMMAND mklabel,mktable LABEL-TYPE create a new disklabel (partition table) mkpart PART-TYPE [FS-TYPE] START END make a partition name NUMBER NAME name partition NUMBER as NAME print [devices|free|list,all|NUMBER] display the partition table, available devices, free space, all found partitions, or a particular partition quit exit program rescue START END rescue a lost partition near START and END resizepart NUMBER ENDresize partition NUMBER rm NUMBERdelete partition NUMBER select DEVICEchoose the device to edit disk_set FLAG STATE change the FLAG on selected device disk_toggle [FLAG] toggle the state of FLAG on selected device set NUMBER FLAG STATEchange the FLAG on partition NUMBER toggle [NUMBER [FLAG]] toggle the state of FLAG on partition NUMBER unit UNITset the default unit to UNIT version display the version number and copyright information of GNU Parted (parted) resizepart 2 36.4GB Error: Unable to satisfy all constraints on the partition. (parted) resizepart 2 36.4G Backtrace has 1 calls on stack: 1: /lib/sparc64-linux-gnu/libparted.so.2(ped_assert+0x20) [0xf801001fa548] You found a bug in GNU Parted! Here's what you have to do: Don't panic! The bug has most likely not affected any of your data. Help us to fix this bug by doing the following: Check whether the bug has already been fixed by checking the last version of GNU Parted that you can find at: http://ftp.gnu.org/gnu/parted/ Please check this version prior to bug reporting. If this has not been fixed yet or if you don't know how to check, please visit the GNU Parted website: http://www.gnu.org/software/parted for further information. Your report should contain the version of this release (3.4) along with the error message below, the output of parted DEVICE unit co print unit s print and the following history of commands you entered. Also include any additional information about your setup you consider important. Assertion (bios_geom->cylinders == (PedSector) (dev->length / cyl_size)) at ../../../libparted/labels/sun.c:191 in function sun_alloc() failed. Aborted - Rich -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc64 Kernel: Linux 5.10.0-8-sparc64 Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libparted2 depends on: ii libblkid1 2.36.1-7 ii libc6 2.31-13 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libuuid12.36.1-7 libparted2 recommends no packages. Versions of packages libparted2 suggests: pn libparted-dev pn libparted-i18n ii parted 3.4-1 -- no debconf information
Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot
When I tried building qemu 6.0 or git on buster, as I recall it errored out on dependencies not available in sufficiently new incarnations, even in backports. If the answer to "this is quite buggy" is "just run a version not even in unstable yet", that's...quite unfortunate. If you're just saying this because it's qemu upstream's opinion, well, I knew that. :) On Sun, Jul 4, 2021 at 7:18 AM Michael Tokarev wrote: > > 04.07.2021 02:45, Rich Ercolani wrote: > > Package: qemu-system-misc > > Version: 1:5.2+dfsg-9~bpo10+1 > [..]> [1726926.715475] cc1[66416]: segfault at 2ad48a0 ip 004857e0 sp > 7ffc9ef97948 error 4 in qemu-riscv64-static[401000+2cc000] > > [1726926.715488] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff > > ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 > > <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b > > [1726967.092517] cc1[71234]: segfault at 2ad58a0 ip 004857e0 sp > > 7ffc23573a18 error 4 in qemu-riscv64-static[401000+2cc000] > > [1726967.092530] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff > > ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 > > <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b > > > > (There's a couple more.) > > First of all, please try the current version of qemu, which is 6.0. > Riscv is a very rapidly developing system and it received a LOT of > changes since 5.2 and even after 6.0. I suggest you to try current > upstream git. > > Myself, I don't have any expirience in this area, I never used any > riscv system or tools and know nothing about qemu emulation of it. > If the more recent version shows the same issue, it is much better > to ask upstream for more help. > > I'm sorry if this seems unhelpful, - but I can't pretend to be > competent and just do nothing, either. > > Thanks! > > /mjt
Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot
Package: qemu-system-misc Version: 1:5.2+dfsg-9~bpo10+1 Severity: normal I was assembling a Debian riscv64 (and therefore, currently, sid) root FS to test something, ultimately in a VM, and building OpenZFS git master chrooted into that root to that end. I did the ./autogen.sh && ./configure --with-linux=.../source --with-linux-obj=.../build && make dance, left it alone for a bit, and came to curiously find it errored out with no error output printed that I saw. Ran make again, it did not immediately error. I then noticed in dmesg: [1726926.715475] cc1[66416]: segfault at 2ad48a0 ip 004857e0 sp 7ffc9ef97948 error 4 in qemu-riscv64-static[401000+2cc000] [1726926.715488] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b [1726967.092517] cc1[71234]: segfault at 2ad58a0 ip 004857e0 sp 7ffc23573a18 error 4 in qemu-riscv64-static[401000+2cc000] [1726967.092530] Code: 00 e9 24 fc 18 00 0f 1f 40 00 64 83 2c 25 60 ff ff ff 01 74 05 c3 0f 1f 40 00 48 8d 3d c9 6f 77 00 e9 74 0a 19 00 0f 1f 40 00 <64> 8b 04 25 60 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b (There's a couple more.) (Much later on, gcc ICEd, on something it hadn't tried building before, but that didn't reproduce on running it again...) I have a core, from doing this dance a second time, from yet another source file that built fine on successive runs, but I'm not sure how readily useful it is. I'll upload it if it would be helpful. - Rich -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (1000, 'stable-updates'), (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-16-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-misc depends on: ii libaio1 0.3.112-3 ii libasound2 1.1.8-1 ii libbrlapi0.6 5.6-10+deb10u1 ii libc62.28-10 ii libcacard0 1:2.6.1-1 ii libcapstone4 4.0.2-3 ii libepoxy01.5.3-0.1 ii libfdt1 1.6.0-1~bpo10+1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libgcc1 1:8.3.0-6 ii libglib2.0-0 2.58.3-2+deb10u3 ii libgnutls30 3.6.7-4+deb10u7 ii libibverbs1 22.1-1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libncursesw6 6.1+20181013-2+deb10u2 ii libnettle6 3.4.1-1+deb10u1 ii libnuma1 2.0.12-1 ii libpixman-1-00.36.0-1 ii libpmem1 1.5.1-1 ii libpng16-16 1.6.36-6 ii librdmacm1 22.1-1 ii libsasl2-2 2.1.27+dfsg-1+deb10u1 ii libseccomp2 2.3.3-4 ii libslirp04.4.0-1 ii libspice-server1 0.14.0-1.3+deb10u1 ii libtinfo66.1+20181013-2+deb10u2 ii libudev1 241-7~deb10u7 ii liburing10.7-3 ii libusb-1.0-0 2:1.0.22-2 ii libusbredirparser1 0.8.0-1 ii libvdeplug2 2.3.2+r586-2.2 ii libvirglrenderer00.7.0-2 ii qemu-system-common 1:5.2+dfsg-9~bpo10+1 ii qemu-system-data 1:5.2+dfsg-9~bpo10+1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages qemu-system-misc recommends: ii ipxe-qemu1.0.0+git-20190125.36a4c85-1 ii qemu-system-gui 1:5.2+dfsg-9~bpo10+1 ii qemu-utils 1:5.2+dfsg-9~bpo10+1 ii seabios 1.12.0-1 Versions of packages qemu-system-misc suggests: pn qemu-block-extra ii samba 2:4.9.5+dfsg-5+deb10u1 ii vde2 2.3.2+r586-2.2 -- no debconf information
Bug#990090: linux-source-4.19: Cannot install buster mips64el in qemu, panics
Package: linux-source-4.19 Severity: normal Dear Maintainer, Trying to boot the buster installer inside qemu-system-mips64el with my setup kernel panics almost instantly with the message "No memory area to place a bootmap bitmap". Using the incantation: qemu-system-mips64el -M malta -cpu 5KEc -drive file=mips64el_buster_disk,format=raw -m 2048 -nographic -no-reboot -net nic,model=virtio-net-pci -net user -kernel mips64el_buster/installer_old/vmlinux-4.19.0-5-5kc-malta -initrd mips64el_buster/installer_old/initrd.gz -append "console=ttyS0" it panics, while the same with mips64el_disk and the 5.10.0-6-5kc-malta kernel+initrd from bullseye works fine. I first tried this with the 4.19.0-17-5kc-malta from 10.10, then I tried it with the older installer kernel+initrd to see if it was a regression from earlier buster or e.g. stretch. (As you can see from how I'm reporting it, it appears to have been broken all buster.) - Rich
Bug#942579: What is wrong?
I come bearing data! After a kind of long bisect, the bad commit was: commit 1e886639791762e89b51aa0507f523c6a1448831 Author: Paolo Bonzini Date: Thu Jun 29 15:27:41 2017 +0200 vdi: make it thread-safe And then, when I went to verify it on git master before reporting it against qemu upstream, I couldn't reproduce it against 894fc4fd670aaf04a67dc7507739f914ff4bacf2. Another round of bisecting points to commit 050de36b13f7a841b7805391bca44f36370e86e4 Author: Paolo Bonzini Date: Thu Mar 25 12:29:39 2021 +0100 coroutine-lock: Reimplement CoRwlock to fix downgrade bug as the first commit where it works reliably. Which is unfortunate, as cherrypicking that looks a bit more invasive than is probably reasonable. - Rich
Bug#989746: [musl] What is the status of musl and fts.h?
On Fri, Jun 11, 2021 at 08:35:08PM +0200, Helmut Grohne wrote: > Dear musl developers, > > As I proceeded to building libselinux, I ran into the well-known issue > that musl does not include a fts.h header. This is documented in the > musl faq at: > https://wiki.musl-libc.org/faq.html#Q:-Why-is-%3Ccode%3Efts.h%3C/code%3E-not-included? > > Unfortunately, the answer seems slightly out of date. For one thing, > glibc does include a fts64 variant these days. For another, most > embedded distributions that do use musl seem to have set on an extra > implementation: > https://github.com/void-linux/musl-fts > > So it seems like everyone has agreed that there should be a fts > implementation and that it can be bolted onto musl. That gives rise to > the obvious question: Can musl-fts be merged into musl? > > Please Cc me in replies as I am not subscribed. Also please update the > FAQ entry. I haven't really looked at it since, so I don't have any immediate opinion. I think it's something we could revisit for evaluation. Rich
Bug#989716: kdump-tools: kdump produces useless "dumps" on i386
Package: kdump-tools Version: 1:1.6.5-1 Severity: important Dear Maintainer, Installed kdump-tools appear to work, echo 'c' | sudo tee /proc/sysrq-trigger boots the crashkernel and takes a dump and reboots, but attempting to use "crash" on the dump in a way that works in other configurations (e.g. crash /usr/lib/debug/boot/vmlinux-1234 /var/crash/1234/dump.1234) reports (in this example, on buster, with -d1): crash: page excluded: kernel virtual address: c19546a4 type: "possible" WARNING: cannot read cpu_possible_map crash: page excluded: kernel virtual address: c195469c type: "present" WARNING: cannot read cpu_present_map crash: page excluded: kernel virtual address: c19546a0 type: "online" WARNING: cannot read cpu_online_map crash: page excluded: kernel virtual address: c1954698 type: "active" WARNING: cannot read cpu_active_map crash: page excluded: kernel virtual address: c18c769c type: "pv_init_ops" crash: page excluded: kernel virtual address: c1a92268 type: "shadow_timekeeper xtime_sec" xtime timespec.tv_sec: 9aee2b: Tue Apr 28 08:25:15 1970 crash: page excluded: kernel virtual address: c18bb1c4 type: "init_uts_ns" utsname: sysname: nodename: release: version: machine: domainname: base kernel version: 0.0.0 crash: page excluded: kernel virtual address: c16a9160 type: "accessible check" crash: /usr/lib/debug/vmlinux-4.19.0-16-686-pae and /var/crash/202106110101/dump.202106110101 do not match! And: # ls -al /var/crash/202106110101/dump.202106110101;file /var/crash/202106110101/dump.202106110101; -rw--- 1 root root 21422351 Jun 11 01:01 /var/crash/202106110101/dump.202106110101 /var/crash/202106110101/dump.202106110101: Kdump compressed dump v6, system Linux, node debian32, release 4.19.0-16-686-pae, version #1 SMP Debian 4.19.181-1 (2021-03-19), machine i686, domain (none) crashkernel=512M-:192M, on here, changes the behavior to what #989714 describes on x86_64 - no printouts from a crashkernel or anything else, no dump ever saved, just an indefinite hang. crashkernel=384M-:192M (or 256M) does not hang, but produces an equally useless "dump". According to the console output when this happens, "makedumpfile Completed" both times, and dmesg's output appears intact and complete. (I neglected to mention this in #989714, but these are all on VirtualBox-backed VMs.) Please let me know if there's anything further I can do to help debug this. - Rich -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-16-686-pae (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdump-tools depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii file 1:5.35-4+deb10u2 ii kexec-tools1:2.0.18-1 ii linux-base 4.6 ii lsb-base 10.2019051400 ii makedumpfile 1:1.6.5-1 ii ucf3.0038+nmu1 Versions of packages kdump-tools recommends: ii initramfs-tools-core 0.133+deb10u1 kdump-tools suggests no packages. -- debconf information: * kdump-tools/use_kdump: true
Bug#989714: kdump-tools is broken out of the box
Package: kdump-tools Version: 1:1.6.5-1 Severity: important Dear Maintainer, (This part also applies to jessie/x86_64 and bullseye/x86_64, in addition to buster/x86_64.) I installed kdump-tools to take a crash dump, rebooted, verified the crashkernel was configured, triggered the problem I wanted to examine and a dump...the machine became entirely unresponsive over ssh or local console (kind of expected) but didn't print any sign it was doing anything like booting the crashkernel (bad). I left it for 15 minutes, and nothing changed, so I hard rebooted it, and tried again, same result. So I tried installing kdump-tools and then using echo 'c' | sudo tee /proc/syrq-trigger on bullseye, same outcome. Same on jessie/x86_64 (with manual configuration of crashkernel= in the grub config). So I booted Ubuntu 20.04/x86_64 and tried this experiment, to make sure my expectations weren't off-base - nope, works as expected. So I looted part of the crashkernel= setting from the Ubuntu system (crashkernel=512M-:192M was theirs, I used 384M-:192M) - no change. Tried 384M-:256M, and it worked. So I tried theirs verbatim, and it also worked every time. So maybe we need different defaults on at least x86_64 systems? (I specify x86_64 because using 512M-:192M breaks crashkernel more on my i386 testbeds.) - Rich -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (1000, 'stable-updates'), (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-16-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdump-tools depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii file 1:5.35-4+deb10u2 ii kexec-tools1:2.0.18-1 ii linux-base 4.6 ii lsb-base 10.2019051400 ii makedumpfile 1:1.6.5-1 ii ucf3.0038+nmu1 Versions of packages kdump-tools recommends: ii initramfs-tools-core 0.133+deb10u1 kdump-tools suggests no packages. -- Configuration Files: /etc/default/kdump-tools changed [not included] -- debconf information: * kdump-tools/use_kdump: true
Bug#989371: Update
I have learned after someone else pointed it out to me that this bug got a CVE - CVE-2019-13045.
Bug#942579:
Lest anyone think this is resolved, I just experienced it on buster, running kernel 4.19.0-16-amd64 and 5.2+dfsg-9~bpo10+1 from buster-backports. In my case, though, I've used qemu-nbd without difficulty for raw files on the order of 40G before without difficulty - but this time, with a VDI of actual size ~19G and...let's call it "virtual" size 100GB, I wrote around a GB of data to it and then suddenly [2005064.948700] block nbd0: Connection timed out [2005064.951474] block nbd0: shutting down sockets [2005064.951479] print_req_error: I/O error, dev nbd0, sector 39028592 [2005064.954230] block nbd0: Connection timed out [2005064.956982] print_req_error: I/O error, dev nbd0, sector 39029104 [2005064.958271] block nbd0: Connection timed out [2005064.959345] print_req_error: I/O error, dev nbd0, sector 39029360 [2005064.960527] block nbd0: Connection timed out [2005064.961608] print_req_error: I/O error, dev nbd0, sector 39029616 [2005064.962677] block nbd0: Connection timed out [2005064.963726] print_req_error: I/O error, dev nbd0, sector 39029872 (I presume if I hadn't noticed and had waited long enough I too would see "task blocked for xyz seconds") The fact that the original report on this particular bug was using a VDI as well makes me suspect it might be a problem with handling VDIs - I'm going to try converting it and report back... - Rich
Bug#989371: irssi has a UAF causing unexpected behavior with SASL
Package: irssi Version: 1.2.0-2.1 Severity: normal Dear Maintainer, Today, I ran across a problem in irssi - for me, it manifested as /reload causing my SASL connections to fail auth on (re)connects until I restarted irssi. The problem turns out to be a use-after-free in the SASL handling code; the fix[1] is in 1.2.1 and newer, but it'd be nice if people using buster weren't stuck with this until they upgraded. (Nevermind the slightly off Version string; I quickly shoved the patch from 1058 into the package and rebuilt it to confirm the problem went away.) - Rich [1] - https://github.com/irssi/irssi/pull/1058 -- System Information: Debian Release: 10.9 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-16-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages irssi depends on: ii libc6 2.28-10 ii libglib2.0-02.58.3-2+deb10u2 ii libperl5.28 5.28.1-6+deb10u1 ii libssl1.1 1.1.1d-0+deb10u6 ii libtinfo6 6.1+20181013-2+deb10u2 ii perl5.28.1-6+deb10u1 ii perl-base [perlapi-5.28.1] 5.28.1-6+deb10u1 irssi recommends no packages. Versions of packages irssi suggests: pn irssi-scripts -- no debconf information
Bug#989020: linux-image-5.9.0-5-sh7751r entirely fails to boot in qemu-system-sh4
Package: src:linux Version: 5.9.15-1 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, On a lark, I decided to try and get a sh4 boot environment running. So I tried downloading the oldest (2019-11-21, with vmlinuz-4.19.0-5-sh7751r) and newest (2021-04-17, with vmlinuz-5.9.0-5-sh7751r) debian-installer tarballs, and they both did the same thing in qemu - no serial output, no graphical output. So I found https://people.debian.org/~aurel32/qemu/sh4/, and tried booting that kernel and initrd with my qemu command, and that worked fine. So next I tried a debootstrap --arch=sh4 sh4_chroot, chrooted in, installed the kernel (linux-image-5.9.0-5-sh7751r), generated an initrd, partitioned the disk image file I made before, mkfs.ext4, rsync -avx everything over, try booting with the kernel+initrd from the chroot...same result. The qemu line I used is: qemu-system-sh4 -M r2d -serial null -serial mon:stdio -m 1024 -usb -usbdevice keyboard -kernel sh4_chroot/boot/vmlinuz-5.9.0-5-sh7751r -initrd sh4_chroot/boot/initrd.img-5.9.0-5-sh7751r -drive file=sh4_disk,format=raw -append "root=/dev/sda1 console=tty0 noiotrap" -vnc :30 The qemu version is 5.2+dfsg-9~bpo10+1. It's certainly possible that I could be holding it wrong, and something has changed between 2.6.32 and 4.19.0 that means I need a different command line, but I'm kind of surprised if the same command doesn't at least produce _some_ output, and unsurprisingly it's quite difficult to find documentation on how to do this properly. - Rich -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: sh4 Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory /usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages linux-image-5.9.0-5-sh7751r depends on: ii initramfs-tools [linux-initramfs-tool] 0.140 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.9.0-5-sh7751r recommends: ii apparmor 2.13.6-10 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.9.0-5-sh7751r suggests: pn debian-kernel-handbook pn linux-doc-5.9 Versions of packages linux-image-5.9.0-5-sh7751r is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor
Bug#988843: qemu-user-static: qemu-hppa-static completely breaks arguments to programs
Package: qemu-user-static Version: 1:6.0+dfsg-1~exp0 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, I have a Debian sid hppa VM, and I wanted to try using qemu-hppa-static to build things faster than running the full VM. So I tried this with 5.2[mumble] and encountered #988842, and then tried 6.0. It's completely broken. Passing arguments to programs is just ignored, so attempting "ls /doesnotexist /orthiseither" or "apt update" act like you ran "ls" or "apt". It did not behave this way on 5.2, and does not behave this way in qemu-system-hppa 5.2 (I cannot readily upgrade the buster server running the VM to running 6.0). - Rich -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.12.0ppq (SMP w/6 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.1-1 Versions of packages qemu-user-static suggests: ii sudo 1.9.6-1~exp2 -- no debconf information
Bug#988842: qemu-user-static: qemu-hppa-static breaks some networking
Package: qemu-user-static
Version: 1:5.2+dfsg-10
Severity: normal
X-Debbugs-Cc: rincebr...@gmail.com
Dear Maintainer,
(I'm reporting this from my bullseye/sid testbed, but I originally encountered
it
on 5.2+dfsg-9~bpo10+1 on buster, and subsequently reproduced it here.)
I have a Debian sid hppa VM, which functions normally, but is quite slow.
To speed things up, I tried shutting it down, mounting the FS, and chrooting in,
using qemu-hppa-static. And it even mostly worked...
...except that some networking is somewhat broken in the chroot.
'wget -O /dev/null http://www.debian.org' works great, 'ping www.debian.org'
works,
'{host,dig,nslookup} www.debian.org' will hang indefinitely until you kill -9
(not
just -TERM) the process.
Needless to say, all of this works normally on the same FS in qemu-system-hppa.
(I tried qemu-user-static 6.0, but that broke differently, so I'll be reporting
that next.)
- Rich
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500,
'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.12.0ppq (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
qemu-user-static depends on no packages.
Versions of packages qemu-user-static recommends:
ii binfmt-support 2.2.1-1
Versions of packages qemu-user-static suggests:
ii sudo 1.9.6-1~exp2
-- no debconf information
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Sure. https://bugzilla.kernel.org/show_bug.cgi?id=213143 - Rich On Thu, May 20, 2021 at 1:16 AM Salvatore Bonaccorso wrote: > > Hi Rich, > > On Wed, May 19, 2021 at 12:14:49AM -0400, Rich wrote: > > So it reproduces identically on 5.10.28 and 5.12.4 vanilla, but > > 5.13.0-rc2 fails differently, so I'm going to report that. > > Thanks, can you then point us to the upstream report once you got to > it? > > Regards, > Salvatore
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
So it reproduces identically on 5.10.28 and 5.12.4 vanilla, but 5.13.0-rc2 fails differently, so I'm going to report that. On Sun, May 16, 2021 at 11:13 AM Rich wrote: > > Sure, I'll try 5.12.4 once I'm done with the build I'm running. (I > have no idea how long that'll be, though, I've never built it > before...) > > - Rich > > On Sun, May 16, 2021 at 11:08 AM Salvatore Bonaccorso > wrote: > > > > Control: tags -1 + moreinfo > > > > Hi, > > > > On Sat, May 15, 2021 at 10:01:32PM -0400, Rich wrote: > > > Package: src:linux > > > Version: 5.10.28-1 > > > Severity: normal > > > X-Debbugs-Cc: rincebr...@gmail.com > > > > > > Dear Maintainer, > > > > > > (This might also affect upstream, I haven't built a vanilla kernel to > > > experiment.) > > > > > > On my (qemu-provided) alpha system, attempting to boot with the SMP kernel > > > yields the following message during boot: > > > > > > > > > [ 17.538076] Unable to handle kernel paging request at virtual address > > > > > > [ 17.539053] CPU 3 > > > [ 17.539053] kworker/3:1(39): Oops -1 > > > [ 17.539053] pc = [<>] ra = [<>] ps = > > > Tainted: GE > > > [ 17.539053] pc is at 0x0 > > > [ 17.541983] ra is at 0x0 > > > [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = > > > > > > [ 17.542959] t2 = 0002 t3 = t4 = > > > 644e > > > [ 17.543936] t5 = 4000 t6 = 0001 t7 = > > > fc0004aac000 > > > [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = > > > fc0002731290 > > > [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = > > > fc00026b9178 > > > [ 17.545889] s6 = fc00010c9b80 > > > [ 17.545889] a0 = a1 = a2 = > > > 0040 > > > [ 17.546866] a3 = 0040 a4 = a5 = > > > > > > [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= > > > 0a546000 > > > [ 17.548819] t11= b938 pv = fc000193c640 at = > > > 0001 > > > [ 17.550772] gp = fc0002721290 sp = 9468c7b6 > > > [ 17.550772] Disabling lock debugging due to kernel taint > > > [ 17.550772] Trace: > > > [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 > > > [ 17.551748] [] process_one_work+0x20c/0x520 > > > [ 17.552725] [] worker_thread+0x90/0x770 > > > [ 17.552725] [] kthread+0x1c4/0x1e0 > > > [ 17.553701] [] worker_thread+0x0/0x770 > > > [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 > > > [ 17.554678] [] kthread+0x0/0x1e0 > > > [ 17.555655] > > > [ 17.555655] Code: > > > [ 17.555655] > > > [ 17.555655] > > > [ 17.556631] 00063301 > > > [ 17.556631] 13d5 > > > [ 17.556631] > > > [ 17.556631] 52a3 > > > [ 17.556631] > > > > > > which is not especially informative. I _suspect_ this may be somewhere in > > > the network stack, because the boot process shortly thereafter blocks > > > indefinitely on systemd-timesyncd starting... > > > > > > Since it could conceivably be relevant, my qemu command line for spawning > > > this VM is: > > > > > > qemu-system-alpha -m 4096 -vnc :12 -net nic,model=virtio-net-pci -net > > > user,hostfwd=tcp::2-:22 -drive file=alpha,format=raw -smp 4 -kernel > > > vmlinux-5.10.0-6-alpha-generic -initrd initrd.img-5.10.0-6-alpha-generic > > > -append console=ttyS0 root=UUID=f5487547-65eb-4330-8644-39e494b5d972 > > > -nographic > > > > > > (with s/-generic/-smp/g for when it breaks) > > > > > > (I also have tried nic,model=e1000 and nic,model=ne2k_pci, it does not > > > change the printout.) > > > > > > The qemu version is qemu-system misc 5.2+dfsg-9~bpo10+1 from > > > buster-backports, on an x86_64 buster host. > > > > Can you please try to verify upstream as well and then report the > > issue directly to upstream (keep the Debian bug in the loop). > > > > Regards, > > Salvatore
Bug#988655: qemu-user-static: qemu-sparc64-static often coredumps running a sid chroot
Package: qemu-user-static Version: 1:5.2+dfsg-9~bpo10+1 Severity: normal Dear Maintainer, I am trying to debug an issue with an external kernel module on sparc64, so I wanted to rebuild said module faster than my poor (real) UltraSPARC IIi would permit. For bisecting reasons on another problem, I needed to try a kernel from the past, so I debootstrapped (from the real SPARC) a chroot environment over NFSv4 pointed at https://snapshot.debian.org/archive/debian-ports/20180331T141542Z. So I bootstrapped that, verified that it worked by chrooting in from the SPARC and installing the various development packages I needed, everything worked fine, then I thought I'd try qemu-sparc64-static to build on my much faster server. I was already running qemu-user-static from buster-backports, so I thought this would likely work well. Instead, during ./autogen.sh, I got back several "Assertion failure (core dumped)", and the compile did not continue. (This does not happen on native hardware.) I also tried and observed the same behavior on the qemu-user-static from experimental, albeit in a bullseye VM because it didn't install particularly readily on buster. Please LMK if I can do anything to be helpful in further investigating this. - Rich -- System Information: Debian Release: 10.9 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-16-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.0-2 Versions of packages qemu-user-static suggests: ii sudo 1.8.27-1+deb10u3 -- no debconf information
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Sure, I'll try 5.12.4 once I'm done with the build I'm running. (I have no idea how long that'll be, though, I've never built it before...) - Rich On Sun, May 16, 2021 at 11:08 AM Salvatore Bonaccorso wrote: > > Control: tags -1 + moreinfo > > Hi, > > On Sat, May 15, 2021 at 10:01:32PM -0400, Rich wrote: > > Package: src:linux > > Version: 5.10.28-1 > > Severity: normal > > X-Debbugs-Cc: rincebr...@gmail.com > > > > Dear Maintainer, > > > > (This might also affect upstream, I haven't built a vanilla kernel to > > experiment.) > > > > On my (qemu-provided) alpha system, attempting to boot with the SMP kernel > > yields the following message during boot: > > > > > > [ 17.538076] Unable to handle kernel paging request at virtual address > > > > [ 17.539053] CPU 3 > > [ 17.539053] kworker/3:1(39): Oops -1 > > [ 17.539053] pc = [<>] ra = [<>] ps = > > Tainted: GE > > [ 17.539053] pc is at 0x0 > > [ 17.541983] ra is at 0x0 > > [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = > > > > [ 17.542959] t2 = 0002 t3 = t4 = > > 644e > > [ 17.543936] t5 = 4000 t6 = 0001 t7 = > > fc0004aac000 > > [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = > > fc0002731290 > > [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = > > fc00026b9178 > > [ 17.545889] s6 = fc00010c9b80 > > [ 17.545889] a0 = a1 = a2 = > > 0040 > > [ 17.546866] a3 = 0040 a4 = a5 = > > > > [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= > > 0a546000 > > [ 17.548819] t11= b938 pv = fc000193c640 at = > > 0001 > > [ 17.550772] gp = fc0002721290 sp = 9468c7b6 > > [ 17.550772] Disabling lock debugging due to kernel taint > > [ 17.550772] Trace: > > [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 > > [ 17.551748] [] process_one_work+0x20c/0x520 > > [ 17.552725] [] worker_thread+0x90/0x770 > > [ 17.552725] [] kthread+0x1c4/0x1e0 > > [ 17.553701] [] worker_thread+0x0/0x770 > > [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 > > [ 17.554678] [] kthread+0x0/0x1e0 > > [ 17.555655] > > [ 17.555655] Code: > > [ 17.555655] > > [ 17.555655] > > [ 17.556631] 00063301 > > [ 17.556631] 13d5 > > [ 17.556631] > > [ 17.556631] 52a3 > > [ 17.556631] > > > > which is not especially informative. I _suspect_ this may be somewhere in > > the network stack, because the boot process shortly thereafter blocks > > indefinitely on systemd-timesyncd starting... > > > > Since it could conceivably be relevant, my qemu command line for spawning > > this VM is: > > > > qemu-system-alpha -m 4096 -vnc :12 -net nic,model=virtio-net-pci -net > > user,hostfwd=tcp::2-:22 -drive file=alpha,format=raw -smp 4 -kernel > > vmlinux-5.10.0-6-alpha-generic -initrd initrd.img-5.10.0-6-alpha-generic > > -append console=ttyS0 root=UUID=f5487547-65eb-4330-8644-39e494b5d972 > > -nographic > > > > (with s/-generic/-smp/g for when it breaks) > > > > (I also have tried nic,model=e1000 and nic,model=ne2k_pci, it does not > > change the printout.) > > > > The qemu version is qemu-system misc 5.2+dfsg-9~bpo10+1 from > > buster-backports, on an x86_64 buster host. > > Can you please try to verify upstream as well and then report the > issue directly to upstream (keep the Debian bug in the loop). > > Regards, > Salvatore
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Package: src:linux Version: 5.10.28-1 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, (This might also affect upstream, I haven't built a vanilla kernel to experiment.) On my (qemu-provided) alpha system, attempting to boot with the SMP kernel yields the following message during boot: [ 17.538076] Unable to handle kernel paging request at virtual address [ 17.539053] CPU 3 [ 17.539053] kworker/3:1(39): Oops -1 [ 17.539053] pc = [<>] ra = [<>] ps = Tainted: GE [ 17.539053] pc is at 0x0 [ 17.541983] ra is at 0x0 [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = [ 17.542959] t2 = 0002 t3 = t4 = 644e [ 17.543936] t5 = 4000 t6 = 0001 t7 = fc0004aac000 [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = fc0002731290 [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = fc00026b9178 [ 17.545889] s6 = fc00010c9b80 [ 17.545889] a0 = a1 = a2 = 0040 [ 17.546866] a3 = 0040 a4 = a5 = [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= 0a546000 [ 17.548819] t11= b938 pv = fc000193c640 at = 0001 [ 17.550772] gp = fc0002721290 sp = 9468c7b6 [ 17.550772] Disabling lock debugging due to kernel taint [ 17.550772] Trace: [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 [ 17.551748] [] process_one_work+0x20c/0x520 [ 17.552725] [] worker_thread+0x90/0x770 [ 17.552725] [] kthread+0x1c4/0x1e0 [ 17.553701] [] worker_thread+0x0/0x770 [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 [ 17.554678] [] kthread+0x0/0x1e0 [ 17.555655] [ 17.555655] Code: [ 17.555655] [ 17.555655] [ 17.556631] 00063301 [ 17.556631] 13d5 [ 17.556631] [ 17.556631] 52a3 [ 17.556631] which is not especially informative. I _suspect_ this may be somewhere in the network stack, because the boot process shortly thereafter blocks indefinitely on systemd-timesyncd starting... Since it could conceivably be relevant, my qemu command line for spawning this VM is: qemu-system-alpha -m 4096 -vnc :12 -net nic,model=virtio-net-pci -net user,hostfwd=tcp::2-:22 -drive file=alpha,format=raw -smp 4 -kernel vmlinux-5.10.0-6-alpha-generic -initrd initrd.img-5.10.0-6-alpha-generic -append console=ttyS0 root=UUID=f5487547-65eb-4330-8644-39e494b5d972 -nographic (with s/-generic/-smp/g for when it breaks) (I also have tried nic,model=e1000 and nic,model=ne2k_pci, it does not change the printout.) The qemu version is qemu-system misc 5.2+dfsg-9~bpo10+1 from buster-backports, on an x86_64 buster host. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information system type : Tsunami system variation: Clipper system revision : 0 platform string : N/A ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback allow-hotplug enp0s1 iface enp0s1 inet dhcp ** PCI devices: 00:00.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:02.0 IDE interface [0101]: Silicon Image, Inc. PCI0646 [1095:0646] (rev 07) (prog-if 8f [PCI native mode controller, supports both channels switched to ISA compatibility mode, supports bus mastering]) Subsystem: Red Hat, Inc. PCI0646 [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- pn fdutils pn linux-doc-5.10 Versions of packages linux-image-5.10.0-6-alpha-smp is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn
Bug#964803: dbus-daemon: unaligned trap on alpha
I can't find a setting to do that in Linux sysctl or kernel-parameters; or searching around, do you have a pointer? I tried just telling /etc/systemd/system.conf DefaultLimitCORE=infinity, setting a non-default path in kernel.core_pattern in sysctl.conf, restarting, restarting dbus after boot, and running find after systemctl status dbus reported dying with SEGV, but I don't see any cores, in the path I set with core_pattern or otherwise. :( - Rich On Sat, May 15, 2021 at 11:31 AM Simon McVittie wrote: > > On Sat, 15 May 2021 at 10:42:55 -0400, Rich wrote: > > I came here to report this very problem, but "reportbug" suggested I > > try the dbus from experimental(!), so I did, and the problem (in my > > very limited experimenting) seems to have gone away... > > Are you able to configure the system to dump core on misalignment, and > get a backtrace from the situation(s) where it crashes? > > If 1.12.x crashes and 1.13.x does not, this might mean that commit 26d5d97d > "Don't cast user-supplied pointers to DBusBasicValue *" is what solved it > for you. > > smcv
Bug#964803: FWIW...
I came here to report this very problem, but "reportbug" suggested I try the dbus from experimental(!), so I did, and the problem (in my very limited experimenting) seems to have gone away... $ sudo systemctl status dbus ● dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static) Active: active (running) since Sat 2021-05-15 10:41:05 EDT; 5s ago TriggeredBy: ● dbus.socket Docs: man:dbus-daemon(1) Main PID: 1599 (dbus-daemon) Tasks: 1 (limit: 4810) Memory: 768.0K CPU: 83ms CGroup: /system.slice/dbus.service └─1599 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only May 15 10:41:05 alphatest systemd[1]: Starting D-Bus System Message Bus... May 15 10:41:05 alphatest systemd[1]: Started D-Bus System Message Bus. $ uname -a Linux alphatest 5.10.0-6-alpha-generic #1 Debian 5.10.28-1 (2021-04-09) alpha GNU/Linux $ dpkg -l | grep dbus ii dbus 1.13.18-2 alphasimple interprocess messaging system (system message bus) [...] - Rich
Bug#985835: alien incorrectly replicates filepaths
Package: alien
Version: 8.95.3
Severity: important
Tags: patch
X-Debbugs-Cc: rincebr...@gmail.com
Dear Maintainer,
alien incorrectly copies files when it's generating packages on my system,
resulting in packages
where instead of, say, /usr/include/... and /usr/sbin/..., it puts things in
/include/... and
/sbin/...
I've created a patch, which I'm not entirely happy with, that fixes it for the
test case I was
reproducing it on (generating deb packages from the upstream zfsonlinux source
packages, which
use alien to turn their generated rpms into debs).
Thanks,
- Rich Ercolani
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.11.8 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages alien depends on:
ii cpio 2.13+dfsg-4
ii debhelper 13.3.4
ii dpkg-dev 1.20.7.1
ii make 4.3-4
ii perl 5.32.1-3
ii rpm4.16.1.2+dfsg1-0.4
ii rpm2cpio 4.16.1.2+dfsg1-0.4
alien recommends no packages.
Versions of packages alien suggests:
ii bzip21.0.8-4
pn lintian
ii patch2.7.6-7
ii xz-utils [lzma] 5.2.5-1.0
-- no debconf information
--- Alien/Package/Deb.pm.aside 2021-03-24 12:46:48.445705086 -0400
+++ Alien/Package/Deb.pm2021-03-24 12:46:54.829597635 -0400
@@ -482,9 +482,11 @@
override_dh_auto_build:
override_dh_auto_install:
+ mkdir -p debian/\$(PACKAGE)
# Copy the packages's files.
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \\
- xargs -0 -r -i cp -a {} debian/\$(PACKAGE)
+ sed -e s#'./'##g | \\
+ xargs -0 -r -i cp -a ./{} debian/\$(PACKAGE)/{}
#
# If you need to move files around in debian/\$(PACKAGE) or do some
# binary patching, do it here
Bug#983492: Whoops
Whoops, applied the patch to blib/lib/Alien/Package/Deb.pm when it should have been Alien/Package/Deb.pm. Oh well, it's a two character patch, I'm sure whoever fixes this can apply it correctly, unlike me. :)
Bug#983492: alien incorrectly generates debian/rules
Package: alien Version: 8.95.3 Severity: important Dear Maintainer, It appears, sometime between 8.95 and 8.95.3, alien started generating incorrect debian/rules output, resulting in it being unable to convert at least RPMs[1] into DEBs successfully (though I'm guessing it broke everything.) In particular, it generates debian/rules that look like: %: dh when the clear intention from reading the source is to generate: %: dh $@ The patch below corrects this behavior, and allows alien to correctly generate DEBs in at least the RPM packages I was testing with. --- ./blib/lib/Alien/Package/Deb.pm.old 2021-02-24 20:25:49.896411306 -0500 +++ ./blib/lib/Alien/Package/Deb.pm 2021-02-24 20:26:06.868446646 -0500 @@ -472,7 +472,7 @@ PACKAGE=\$(shell dh_listpackages) %: - dh $@ + dh \$\@ override_dh_clean: dh_clean -d Hopefully someone will apply this at some point, though I'm aware alien is currently unmaintained. - Rich [1] - cf. https://github.com/openzfs/zfs/issues/11650 -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages alien depends on: ii cpio 2.12+dfsg-9 ii debhelper 12.1.1 ii dpkg-dev 1.19.7 ii make 4.2.1-1.2 ii perl 5.28.1-6+deb10u1 ii rpm4.14.2.1+dfsg1-1 ii rpm2cpio 4.14.2.1+dfsg1-1 alien recommends no packages. Versions of packages alien suggests: ii bzip21.0.6-9.2~deb10u1 ii lintian 2.15.0 ii lzma 9.22-2.1 ii patch2.7.6-3+deb10u1 ii xz-utils [lzma] 5.2.4-1 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/perl5/Alien/Package/Deb.pm (from alien package)
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#928497: Order Request
Hello Sales, My name is Maxwell Rich and i would like to know if you carry exit devices in stock for sale. Please contact me back with the models and pricing for the exit devices.Thank you and will wait to hear from you soon... Best Regards Maxwell Rich...
Bug#931573: gufw: protocol pane not functioning, showing no activity, copying to clipboard results in no data
Package: gufw Version: 17.04.1-1.1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gufw depends on: ii gir1.2-gtk-3.0 3.22.11-1 ii gir1.2-webkit2-4.0 2.18.6-1~deb9u1 ii net-tools 1.60+git20161116.90da8a0-1 ii policykit-1 0.105-18+deb9u1 ii python3 3.5.3-1 ii python3-gi 3.22.0-2 ii ufw 0.35-4 gufw recommends no packages. gufw suggests no packages. -- no debconf information
Bug#931510: gdebi asks for root passwort for installing simple packages; seems an error.
Package: gdebi Version: 0.9.5.7+nmu1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdebi depends on: ii gdebi-core0.9.5.7+nmu1 ii gir1.2-gtk-3.03.22.11-1 ii gir1.2-vte-2.91 0.46.1-1 ii gksu 2.0.2-9+b1 ii gnome-icon-theme 3.12.0-2 ii python3 3.5.3-1 ii python3-gi3.22.0-2 Versions of packages gdebi recommends: ii libgtk2-perl 2:1.2499-1 ii lintian 2.5.50.4 ii shared-mime-info 1.8-1+deb9u1 gdebi suggests no packages. -- no debconf information
Bug#915886:
Ben, I'm pretty sure you're not having the same problem as the original person. They were reporting getting a Perl error out of the enum-extract script, you're reporting that it's passing the wrong location to the enum-extract script to try and find the header. - Rich
Bug#915831: [Pkg-zfsonlinux-devel] Bug#915831: Fwd: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
TBH I personally think clever conditional logic in the package install for
if (systemd installed) { systemd scripts, sysvinit scripts get
diverted to /dev/null }
elsif (sysvinit for real) { install sysvinit scripts, divert systemd
scripts to /dev/null }
else { print that you're doing neither of the above b/c the world is
confusing }
would be my default idea, but that seems like a lot of moving parts
where just breaking things out has many fewer things to go wrong, and
has precedent in fanning out into e.g. zfs-initramfs, zfs-test,
zfs-zed...
Also, while I support the idea of permitting sysvinit scripts to be
used for some users, I think "just" adding a Conflicts: systemd-sysv
anywhere but in an optional part of the packaging would be a drastic
user experience problem - they'd just get a sudden prompt to rip out
part of their system (a part that popcon suggests over 50% have
installed, and 42% have used parts of recently, in the case of
insserv) on trying to upgrade a minor version.
- Rich
On Tue, Jan 1, 2019 at 2:22 PM Richard Laager wrote:
>
> On 12/31/18 6:34 PM, Rich wrote:
> > It seems like what we might want is an OR dependency on two child
> > zfs-{systemd,sysvinit} packages - and for those two packages to
> > conflict with each other (and require the appropriate respective init
> > packages)?
>
> I don't think that's desirable. If this is actually required, then
> wouldn't every package trying to support systemd and sysvinit need to do
> that same? That would be a lot of work. No other packages are doing
> this; there should be some other solution.
>
> If systemd-sysv and insserv are not co-installable, that conflict should
> be expressed in those packages.
>
> --
> Richard
Bug#915831: Fwd: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
-- Forwarded message -
From: Rich
Date: Mon, Dec 31, 2018 at 8:16 AM
Subject: Re: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
To: Mo Zhou
Heh. It being installed was not, AFAIK, a deliberate choice.
Attempting to remove it, though, looks...frought.
$ sudo apt remove -V insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
init (1.48)
initscripts (2.88dsf-59.9)
insserv (1.14.0-5.4+b1)
systemd-sysv (232-25+deb9u6)
sysv-rc (2.88dsf-59.9)
sysvinit (2.88dsf-59)
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
init
systemd-sysv (due to init)
0 upgraded, 0 newly installed, 6 to remove and 39 not upgraded.
After this operation, 735 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?]
I'm reasonably confident doing this will break any sort of sysvinit
script usage on the whole system, which (presumably) would defeat the
purpose of ever shipping the sysvinit scripts?
It seems like what we might want is an OR dependency on two child
zfs-{systemd,sysvinit} packages - and for those two packages to
conflict with each other (and require the appropriate respective init
packages)? I think that's the right dependency interlock - exactly one
of {zfs-sysvinit,zfs-systemd} installed with the zfsutils-linux
package, probably with Breaks (zfsutils-linux < $NEW_SHINY_VERSION) in
the new children so that zfsutils-linux's new version shows up first,
and we don't have the two new packages trying to step on the old one's
files?
I don't actually know what a "reasonable" Debian system still using
sysvinit and not transitional bits looks like, so I don't know ATM how
to express the appropriate kind of conflict, but since I think(?) it's
still reasonable to have sysvinit compat hooks installed on stretch,
and I think it's also reasonable to not force people to remove all
sysvinit compat packages to install zfsutils-linux, it seems like
breaking the mutually exclusive bits out might be the best option?
(I think there's also a way to just do this with one new sysvinit
child package, that diverts all the systemd service scripts to
/dev/null or similar when it's installed and reverts it when not, but
since it's not clear to me that it'd be simpler to do that,
particularly if you're still having to include enumeration of the
systemd service files you're overriding in the sysvinit package, I
started with breaking them both out.)
Does that all make sense and/or seem correct? I don't think I made any
unreasonable assumptions about what a "correct" transition path to
having sysvinit and/or systemd files around given the prior states and
that having both enabled is probably impractical, but please tell me
if my pants are on my head. :)
(Also, thanks a lot for spending the time digging into this, I had
been hoping to doso over my short winter vacation, but other things
topped the priority queue.)
- Rich
On Mon, Dec 31, 2018 at 5:28 AM Mo Zhou wrote:
>
> Hi Rich,
>
> I investigated into this issue a bit and it looks like a result of
> messy system where systemd-sysv and insserv are co-installed.
> In insserv/sid, the postinst process will nolonger fail even if the
> same error occurs. The error will disappear if you remove insserv.
> And in your initial bug report, meta infomation told me that you
> use systemd. So please don't co-install systemd-sysv and insserv.
>
> From zfs's side we can do mostly nothing to prevent user from
> co-installing systemd-sysv and insserv, except for a simple
> suggestion.
>
> Does the issue you reported persist even after removing insserv?
>
>
>
> I tried to install zfs tens of times in different virtual machines
> setup in differrent settings. And my conclusion is simply don't
> co-install them.
Bug#915886: Workaround
So, yes, the workaround Ben posted will work, but that's fixing the symptom, not the problem. I'd still like to know what the enum-extract.pl script says for you (Ben) if you try invoking it (or what's in config.log when it fails). Because the problem with the common/amd64 headers location should be fixed already [1], it's possible you're having a separate problem; that error output is just what happens when enum-extract.pl doesn't output what's expected. - Rich [1] - https://github.com/zfsonlinux/zfs/issues/7358
Bug#915886:
Well, the PUMPIN MUD just means enum-extract.pl didn't do the right thing. config.log.gz says: configure:26532: ./scripts/enum-extract.pl zone_stat_item /lib/modules/4.18.0-3-amd64/source/include/linux/mmzone.h | egrep -qx NR_SLAB_RECLAIMABLE Can't locate Getopt/Std.pm in @INC (you may need to install the Getopt::Std module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/ share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at ./scripts/enum-extract.pl line 13. BEGIN failed--compilation aborted at ./scripts/enum-extract.pl line 13. So that is claiming it doesn't think you have Getopt/Std.pm, which should be provided by perl-modules-$(PERL_MAJOR_MINOR_VERSION) (e.g. in your case, 5.28). What do dpkg -l | egrep '^ii perl-' and ls -l /usr/share/perl/5.28*/Getopt/Std.pm have to say? (Regardless of what they have to say, there should definitely be an explicit perl dep in zfs-dkms now, since that definitely won't work without it.) - Rich
Bug#915831: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
Package: zfsutils-linux
Version: 0.7.12-1
Severity: normal
Dear Maintainer,
Tried upgrading from stretch-backports 0.7.11 to testing 0.7.12, because
the package hadn't landed in backports yet, and discovered it broke on
dpkg --configure :
Setting up zfsutils-linux (0.7.12-1) ...
insserv: Service zfs-zed has to be enabled to start service zfs-share
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package zfsutils-linux (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of zfs-zed:
zfs-zed depends on zfsutils-linux (>= 0.7.12-1); however:
Package zfsutils-linux is not configured yet.
Someone else had reported a similar problem upstream to ZoL from Ubuntu's
packages, at:
https://github.com/zfsonlinux/zfs/issues/8127
I worked up a terrible hackjob of a patch to work around this long enough to
install it and then reverted the patch (attached), but there's probably a better
way to handle this.
(Don't mind the arc_summary changed warning; I've been testing improvements to
it.)
-- System Information:
Debian Release: 9.6
APT prefers stable-debug
APT policy: (1000, 'stable-debug'), (1000, 'stable'), (900, 'testing-debug'),
(900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500,
'stable-updates'), (500, 'proposed-updates-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages zfsutils-linux depends on:
ii libblkid12.29.2-1+deb9u1
ii libc62.24-11+deb9u3
ii libnvpair1linux 0.7.12-1
ii libuuid1 2.29.2-1+deb9u1
ii libuutil1linux 0.7.12-1
ii libzfs2linux 0.7.12-1
ii libzpool2linux 0.7.12-1
ii python3 3.5.3-1
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages zfsutils-linux recommends:
ii lsb-base9.20161125
ii zfs-dkms [zfs-modules] 0.7.12-1
ii zfs-zed 0.7.12-1
Versions of packages zfsutils-linux suggests:
ii nfs-kernel-server 1:1.3.4-2.1
ii samba-common-bin 2:4.5.12+dfsg-2+deb9u4
ii zfs-initramfs 0.7.12-1
-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'
-- debconf-show failed
-- debsums errors found:
debsums: changed file /usr/sbin/arc_summary (from zfsutils-linux package)
diff --git a/init.d/zfs-share b/init.d/zfs-share
index 6564720..2e800d1 100755
--- a/init.d/zfs-share
+++ b/init.d/zfs-share
@@ -9,8 +9,8 @@
#
### BEGIN INIT INFO
# Provides: zfs-share
-# Required-Start:$local_fs $network $remote_fs zfs-mount zfs-zed
-# Required-Stop: $local_fs $network $remote_fs zfs-mount zfs-zed
+# Required-Start:$local_fs $network $remote_fs zfs-mount
+# Required-Stop: $local_fs $network $remote_fs zfs-mount
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Should-Start: iscsi iscsitarget istgt scst nfs-kernel-server samba
samba4 zfs-mount zfs-zed
@@ -34,7 +34,7 @@
do_depend()
{
- after sysfs zfs-mount zfs-zed
+ after sysfs zfs-mount
keyword -lxc -openvz -prefix -vserver
}
Bug#909228: RFP: loop -- "UNIX's missing loop command!"
Package: wnpp Severity: RFP loop lets you write powerful, intuitive looping one-liners in your favorite shell! For example: loop './do_thing.sh' --every 15s --until-success --num 5 ..And lots more! MIT licensed, written in Rust. Source here: https://github.com/Miserlou/Loop/ Related issue: https://github.com/Miserlou/Loop/issues/36 I'm the author of this tool which I find extremely handy, and I'd love it if I could (eventually) use it on my servers without having to import any external keys! Would anybody be interested in stepping up to help polish the application enough to make an official Debian package? :) Thanks! Rich
Bug#909062: kexec-tools: Want man page for kdump
Package: kexec-tools Version: 1:2.0.14-1 Severity: wishlist Tags: patch Dear Maintainer, I was mildly annoyed by the lack of a real man page for kdump (not that it needs much of one), so I wrote a slightly better one than the stub. I'd love to see it included here or upstream, and thought that requesting its inclusion here might be a decent way to shake out any objections first. If you have any suggestions for improvement or would like to see me just submit it to upstream, I'd be happy to. Thanks, - Rich -- System Information: Debian Release: 9.5 APT prefers stable-debug APT policy: (1000, 'stable-debug'), (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-updates'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kexec-tools depends on: ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u3 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-5 kexec-tools recommends no packages. kexec-tools suggests no packages. -- debconf information excluded .\" Hey, EMACS: -*- nroff -*- .\" First parameter, NAME, should be all caps .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection .\" other parameters are allowed: see man(7), man(1) .TH KDUMP 8 "Sep 17, 2018" .\" Please adjust this date whenever revising the manpage. .\" .\" Some roff macros, for reference: .\" .nhdisable hyphenation .\" .hyenable hyphenation .\" .ad l left justify .\" .ad b justify to both left and right margins .\" .nfdisable filling .\" .fienable filling .\" .brinsert line break .\" .sp insert n+1 empty lines .\" for manpage-specific macros, see man(7) .SH NAME kdump \- Tool to take a Linux kernel dump .SH SYNOPSIS .B kdump .RI [ options ] " start_address" ... .SH DESCRIPTION .PP .\" TeX users may be more comfortable with the \fB\fP and .\" \fI\fP escape sequences to invode bold face and italics, .\" respectively. \fBkdump\fP is a tool to take a crash dump of a formerly-running kernel after kexec into a reserved area of memory with a tiny Linux environment. .SH OPTIONS None. .PP .SH USAGE .PP You almost never want to invoke this directly; see .BR kdump-tools (5) or .BR kexec (8) for what you likely want to know. .SH SEE ALSO .BR makedumpfile (8), .BR crash (8), .BR kdump-tools (5), .BR kexec (8), .BR vmcore-dmesg (8) .SH AUTHOR kdump was written by Eric Biederman. .PP This manual page was initially written by Khalid Aziz , for the Debian project (but may be used by others). Additional content was added by Rich Ercolani .
Bug#908636: htop: Feature request: enable delayacct support in htop build
Package: htop
Version: 2.2.0-1.1
Severity: wishlist
Dear Maintainer,
I recently learned about the fascinating delayacct feature hooks added in htop
2.1, enabled with --enable-delayacct to configure.
Enabling this feature requires libnl-genl-3-dev (and presumably the associated
libnl-3-dev) at buildtime and libnl{-genl,}-3-200 at runtime, but is quite
useful sometimes.
(The package version is because I cut a local package build with the above
changes to be sure it was that simple and functioned appropriately.)
Thanks,
- Rich Ercolani
-- System Information:
Debian Release: 9.5
APT prefers stable-debug
APT policy: (1000, 'stable-debug'), (1000, 'stable'), (900, 'testing-debug'),
(900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500,
'stable-updates'), (500, 'proposed-updates-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages htop depends on:
ii libc6 2.24-11+deb9u3
ii libncursesw5 6.0+20161126-1+deb9u2
ii libnl-3-200 3.2.27-2
ii libnl-genl-3-200 3.2.27-2
ii libtinfo5 6.0+20161126-1+deb9u2
htop recommends no packages.
Versions of packages htop suggests:
ii lsof4.89+dfsg-0.1
ii strace 4.15-2
-- debconf-show failed
Bug#907063: fetchmail: sslcertck fails with GMAIL
Package: fetchmail
Version: 6.3.26-3
Severity: important
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
When using sslcertck with a GMAIL server, the check fails since GMAIL now
requires a Server Name Indication (SNI). This is fixed in Experimental
(6.4.0~beta4-1) but you may want to include it in Sid (6.3.26-3) due to the
wide impact.
The following worked for me as a temporary fix:
- --- a/socket.c
+++ b/socket.c
@@ -1041,6 +1041,8 @@
SSL_use_RSAPrivateKey_file(_ssl_context[sock], mykey,
SSL_FILETYPE_PEM);
}
+ SSL_set_tlsext_host_name(_ssl_context[sock],servercname);
+
if (SSL_set_fd(_ssl_context[sock], sock) == 0
|| (ssle_connect = SSL_connect(_ssl_context[sock])) < 1) {
int e = errno;
- -- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500,
'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fetchmail depends on:
ii adduser 3.117
ii debianutils 4.8.6
ii libc6 2.27-5
ii libcom-err2 1.44.4-1
ii libgssapi-krb5-2 1.16-2
ii libk5crypto3 1.16-2
ii libkrb5-3 1.16-2
ii libssl1.1 1.1.1~~pre9-1
ii lsb-base 9.20170808
Versions of packages fetchmail recommends:
ii ca-certificates 20180409
Versions of packages fetchmail suggests:
ii exim4-daemon-heavy [mail-transport-agent] 4.91-6
pn fetchmailconf
ii resolvconf 1.79
- -- Configuration Files:
/etc/logcheck/ignore.d.server/fetchmail [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.server/fetchmail'
/etc/logcheck/ignore.d.workstation/fetchmail [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.workstation/fetchmail'
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQJHBAEBCAAxFiEEOexxovf7Ie4VsjV8e6VjMYfM+fsFAlt+4jMTHHdocmF2ZW4y
QGdtYWlsLmNvbQAKCRB7pWMxh8z5+xqBEAC6LIv4IQGKVOFJxxFjzt++QrF6sU5j
WrFMobrN5Iv0lwAhHRki3JiLDb5m2I9Bzo1K1ECOakn3QBMCsxf3MTy+98qFgkJb
WSyA/TpOFP8a1hpXGlgLd6cKQFr5GzSFC6GylXqa5PVHcsHZpx5OjfbaTymoo6jf
v+iVbxp/cJyIJjxkUWy+yR1Dff6kWYIJ0AfI5k38uVEJggjITcoEbRSo7qWypBzp
DfS4IYxsoytWbR4165C/lDl6yU+O/zKYeRhY9g6KrMM7X4C4j+Mb5lApYAS31WWi
Vri4x6Y76VYuSPf7sN86xq7ylM/r3VS12ZQSdC06QAG9QbAiQMti/24GZ0CK9PMS
ZIZUVzCCnmxUUvtXpPbcJ57QttKypXjX7158qEV0aZzZ9pOg6f/J7j/i1iCgcKnJ
kEo5lpuWncUIIKVo1RaAS29UMmXlaSkYxPmx63UMm+ggizti5N1lC8NSZm7Lq6DO
1ytXgN69y14dEfLmSWbV3YnWJlOYOD50e4T/8fIGU5rkvBQuBgQ4pk2mH639t4iZ
AY4ABO4lrliW5FZpnyCCNuidINyCIm4fEQr5RyJhTtFfdDagfWam8qVg06LKsUeZ
igM8mpRL0fkfTN7E0/UZrhMZeOrpuR9PFcmfTCo4agwZT0mrNLxVNoO+VW4ehSzR
d+Tpg2eS/oggug==
=VJM7
-END PGP SIGNATURE-
--- a/socket.c
+++ b/socket.c
@@ -1041,6 +1041,8 @@
SSL_use_RSAPrivateKey_file(_ssl_context[sock], mykey,
SSL_FILETYPE_PEM);
}
+ SSL_set_tlsext_host_name(_ssl_context[sock],servercname);
+
if (SSL_set_fd(_ssl_context[sock], sock) == 0
|| (ssle_connect = SSL_connect(_ssl_context[sock])) < 1) {
int e = errno;
Bug#900326: nvidia-driver: Nvidia 390.48.3 install erroneously enables Orca screen reader.
Package: nvidia-driver Version: 390.48-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installed Nvidia driver 390.48.3 and dependencies from Debian non free repos. Reboot. Orca screen reader spontaneously enabled itself for log in screen and there is no way to turn it off. * What exactly did you do (or not do) that was effective (or ineffective)? Uninstalled Orca via Synaptic. * What was the outcome of this action? System would not boot. Grub screen comes up, select Debian and screen blinks grey/black/grey/black. Also tried to boot to Debian recovery mode. Same problem. Lots of verbose verbage rolls past and then the system fails to boot. Eventually reinstalled Debian via netinstall cd, same issue. Open source video driver, no Orca. Installed Nvidia, Orca starts yapping but only at the login screen. * What outcome did you expect instead? That Orca would shut up. *** End of the template - remove these template lines *** -- Package-specific info: uname -a: Linux Debian 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux /proc/version: Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.48 Thu Mar 22 00:42:57 PDT 2018 GCC version: gcc version 7.3.0 (Debian 7.3.0-19) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208 [GeForce GT 730] [10de:1287] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ZOTAC International (MCO) Ltd. GK208B [GeForce GT 730] [19da:730b] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 May 28 16:47 /dev/dri/card0 crw-rw+ 1 root video 226, 128 May 28 16:47 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 May 28 16:47 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 May 28 16:47 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 May 28 16:47 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 May 28 16:47 pci-:01:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 May 28 16:47 pci-:01:00.0-render -> ../renderD128 video:x:44:rich OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 May 28 15:12 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 51 May 28 15:12 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1 lrwxrwxrwx 1 root root 50 May 28 15:12 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 May 28 15:12 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 54 May 28 15:12 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 May 28 15:12 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 51 May 28 15:12 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 May 28 15:12 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 May 28 15:12 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 May 28 15:12 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 May 28 15:12 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 May 28 15:12 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 May 28 15:12 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 May 28 15:12 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 May 28 15:11 /etc/alternatives/nvidia -> /usr/lib/nvidia/current lrwxrwxrwx 1 root root 59 May 28 15:11 /etc/alternatives/nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0 lrwxrwxrwx 1 root root 62 May 28 15:11 /etc/alternatives/nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu -> /usr/lib/x86_64
Bug#899171: cdrom: after cdrom-install: spectre v2 mitigation: lfence not serializing. switching to generic retpoline
Package: cdrom Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? i did install Debian Wheezy on a AMD APU A10-9700 APU; installation process went correctly, booting process is ok, shows this bootmessage spectre v2 mitigation: lfence not serializing. switching to generic retpoline * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.11 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#893578: 0.7.8
This should probably get changed to 0.7.8, because nobody[1] should use 0.7.7. [1] - https://github.com/zfsonlinux/zfs/issues/7401 - Rich
Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
I'm not sure I understand what you mean by symbol files for the libraries,
here - I know what symbols are, and usually I'd expect symbol files to
refer to something like external debug symbols, but it sounds like you're
suggesting something else?
I'd pretty strongly suggest depending on identically versioned module,
since AFAIK the guarantee for what happens if you replace the userland and
not the kernel module even across point versions is "nothing".
Of course, then you still have the problem of needing to reload the module
after replacing the userland, which you don't always get to do if you're
doing ZFS root...
Maybe it'd be a reasonable thing to do to try and get a patch upstream to
notice when userland and module version disagree and print a notice that
all bets are off. But then you'd need text processing to understand the
module versioning in each for anything but exact matching e.g. 0.7.3-1
versus 0.7.3.
At a minimum, you'd want to depend on the same point version (e.g. 0.7.3-1
and 0.7.3-2 should be fine to mix, unless we start integrating really
disruptive changes that aren't planned to go into the mainline version),
though we might want to just opt for exact version so we don't have to
worry about overlooking a change that would break this, but trying to do
that string processing wouldn't necessarily be portable or accepted
upstream (e.g. consider the versions emitted by git, IIRC of the form
0.X.Y-g[git shorthash], and you _definitely_ don't want to mix across
those).
Maybe just exact version matching for now (for both module/userland and
userland/dependent libraries) and an upstream enhancement request to notify
people they might set their house on fire if they mix differing
module/userland versions?
- Rich
On Thu, Nov 16, 2017 at 9:40 AM, Fabian Grünbichler <
f.gruenbich...@proxmox.com> wrote:
> On Sat, Nov 04, 2017 at 12:17:48AM -0400, Rich Ercolani wrote:
> > Package: zfsutils-linux
> > Version: 0.7.3-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > As the subject says, if you just install
> > {zfsutils-linux,spl-dkms,zfs-dkms}/unstable,
> you can end up with libuutil1linux from stable or testing, and get back:
> > zpool: symbol lookup error: /lib/libzpool.so.2: undefined symbol:
> spl_pagesize
> > Explicitly installing libuutil1linux >= 0.7.3 resolves this, so the
> package should probably have an explicit version dependency listed.
> >
> > (As you can see, I commonly configure stable > testing > unstable
> pinning preferences, so booting a new stretch machine and installing the
> above with those pinnings will result in this.)
> >
> > - Rich
>
> I see two ways to go forward here:
> - add symbols files for the libraries and keep them uptodate
> - require libraries and utilities to have the exact same version
> (upstream does not guarantuee ABI/API stability yet AFAIK, only
> on-disk-format stability).
>
> I'll evaluate the symbols route tomorrow to see how much work it is
> (starting from 0.6.5.11-1).
>
> furthermore, the question of how to handle the userspace -> module
> dependency needs to be solved somehow. again, there are two basic
> possibilities:
>
> - add a versioned dependency to the same major version now, and bump it
> whenever incompatibilities are known
> - always depend on an identically versioned module
>
> thoughts?
>
>
Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
Package: zfsutils-linux
Version: 0.7.3-1
Severity: important
Dear Maintainer,
As the subject says, if you just install
{zfsutils-linux,spl-dkms,zfs-dkms}/unstable, you can end up with libuutil1linux
from stable or testing, and get back:
zpool: symbol lookup error: /lib/libzpool.so.2: undefined symbol: spl_pagesize
Explicitly installing libuutil1linux >= 0.7.3 resolves this, so the package
should probably have an explicit version dependency listed.
(As you can see, I commonly configure stable > testing > unstable pinning
preferences, so booting a new stretch machine and installing the above with
those pinnings will result in this.)
- Rich
-- System Information:
Debian Release: 9.2
APT prefers stable
APT policy: (1000, 'stable'), (900, 'testing'), (800, 'unstable'), (500,
'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages zfsutils-linux depends on:
ii libblkid12.29.2-1
ii libc62.24-11+deb9u1
ii libnvpair1linux 0.7.3-1
ii libuuid1 2.29.2-1
ii libuutil1linux 0.6.5.9-5
ii libzfs2linux 0.7.3-1
ii libzpool2linux 0.7.3-1
ii python3 3.5.3-1
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages zfsutils-linux recommends:
ii lsb-base9.20161125
ii zfs-dkms [zfs-modules] 0.7.3-1
ii zfs-zed 0.7.3-1
Versions of packages zfsutils-linux suggests:
pn nfs-kernel-server
pn samba-common-bin
pn zfs-initramfs | zfs-dracut
-- no debconf information
Bug#880564: nvidia-driver: Hello i am using Debian Wheezy ;
Package: nvidia-driver Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? installed debian wheezy on imac * What exactly did you do (or not do) that was effective (or ineffective)? could not install nvidia-driver withouth resorting to debian-backports; however, version 340.x seems unstable for graphic card nvidia gt 130; * What was the outcome of this action? * What outcome did you expect instead? install nvidia-driver and nvidia-glfx via wheezy repositories *** End of the template - remove these lines *** -- System Information: Debian Release: 7.11 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#865873: Bug 865873
Same problem for me. I also tried to install GC 3.4 unsuccessfully. Seems to be related to this issue: https://github.com/GoldenCheetah/GoldenCheetah/issues/437 so maybe fix referenced in https://github.com/GoldenCheetah/GoldenCheetah/issues/452 got dropped somewhere for GC 4.0? Looking forward to a solution. Rich Stegura
Bug#846061: amule crashes / stretch
i am running debian stable / gnome / stretch and amule package crashes, whereas if i use amule from oldstable /jessie , it runs fine.
Bug#849357: REPORTING-BUGS solution
Thanks to Santiago José López Borrazás Just like to confirm that your solution in /usr/share/kernel-package/ruleset/targets/headers.mk work very well for my compile of kern-4.10 under Stretch Thank you very much! Rich
Bug#849295: denyhosts with iptables enabled fails to remove entries from iptables
Package: denyhosts Version: 2.10-2 Severity: normal Dear Maintainer, If you have IPTABLES support enabled in denyhosts, then it will happily add hosts to the iptables DROP rules, but it does not remove those entries when it garbage collects old blocks from hosts.deny (and friends), leaving them infinitely accruing. -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages denyhosts depends on: ii init-system-helpers 1.22 ii lsb-base 4.1+Debian13+nmu1 ii python 2.7.9-1 pn python:any denyhosts recommends no packages. denyhosts suggests no packages. -- Configuration Files: /etc/denyhosts.conf [Errno 13] Permission denied: u'/etc/denyhosts.conf' -- no debconf information
Bug#842854: general: Lenovo X220T rotate screen key works in Debian8/Gnome but not KDE
Package: general Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** Hello, i am using Debian on an acquired Lenovo X220T . #found out that on Gnome Desktop starting with Jessie the Function Keys on the Computer are activate, eg. by pressing the dedicated key i am able to rotate the screen 90 degree. This is awesome. Unfortunately this functionaltiy is not found when installing Base Jessie System with KDE instead of Gnome. Would someon please implement this function also for KDE? Thank you very much. Anchors Rich -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#838706: [Pkg-zfsonlinux-devel] Bug#838706: spl-dkms should require dkms > 2.2.0 as of 0.6.5.8
If the issue is that only POST_INSTALL runs on DKMS < 2.2.1 and both run on
DKMS >= 2.2.1, couldn't we modify POST_INSTALL to include an existence
check for the build dir before attempting the cp, and then include both
POST_INSTALL and POST_BUILD steps?
That way, the POST_INSTALL step will silently bail on DKMS >= 2.2.1
(because the existence check for
${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build
would fail), and POST_BUILD would copy the files over, while on DKMS <
2.2.1, POST_INSTALL would happily succeed?
Something like
POST_INSTALL="if [ -d \"${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build\"
]; then cp ...;fi"
POST_BUILD="cp ..."
?
- Rich
On Sat, Sep 24, 2016 at 1:20 AM, Petter Reinholdtsen <p...@hungry.com>
wrote:
>
> Hi, and thank you for bringing up this issue.
>
> [Rich]
> > I tried building and installing the new spl-dkms from testing/unstable
> on my
> > Jessie system, which built fine, and reportedly installed fine.
> >
> > Unfortunately, the fix for #836578 breaks the package for DKMS < 2.2.1.0,
> > resulting in an apparently successful install, but the zfs-dkms package
> will
> > spin forever waiting for .../module/spl_config.h to exist.
> >
> > Please either include a workaround for DKMS < 2.2.1.0 (I'd offer one but
> I
> > don't know enough about how these systems function to guess how it might
> > work) or mark the package as requiring DKMS > 2.2.1.0.
>
> I expected the small change applied to fix
> https://bugs.debian.org/836578 > to work also on older dkms
> versions, but I do not really know the inner workings of dkms.
>
> Perhaps one of the dkms maintainers can explain how the following patch
> can be made to work with both new and old dkms versions?
>
> --- usr/src/spl-0.6.5.7/dkms.conf 2016-05-25 15:42:03.0 +1000
> +++ usr/src/spl-0.6.5.7/dkms.conf.orig 2016-09-09 10:37:43.482388086
> +1000
> @@ -20,7 +20,7 @@
> esac)
>--with-linux-obj=${kernel_source_dir}
> "
> -POST_INSTALL="cp
> +POST_BUILD="cp
>${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/spl_config.h
>${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/
> module/Module.symvers
>${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/${kernelver}/${arch}/
> --
> Happy hacking
> Petter Reinholdtsen
>
Bug#838706: spl-dkms should require dkms > 2.2.0 as of 0.6.5.8
Package: spl-dkms Version: 0.6.5.8-1 Severity: normal Dear Maintainer, I tried building and installing the new spl-dkms from testing/unstable on my Jessie system, which built fine, and reportedly installed fine. Unfortunately, the fix for #836578 breaks the package for DKMS < 2.2.1.0, resulting in an apparently successful install, but the zfs-dkms package will spin forever waiting for .../module/spl_config.h to exist. Please either include a workaround for DKMS < 2.2.1.0 (I'd offer one but I don't know enough about how these systems function to guess how it might work) or mark the package as requiring DKMS > 2.2.1.0. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-0.bpo.2-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages spl-dkms depends on: ii dkms 2.2.0.3-2 ii file 1:5.22+15-2+deb8u1 ii libc6-dev [libc-dev] 2.19-18+deb8u4 ii lsb-release 4.1+Debian13+nmu1 Versions of packages spl-dkms recommends: ii spl 0.6.5.8-1 spl-dkms suggests no packages. -- no debconf information
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
I am not sure what to suggest. This conversation is bouncing across two ticket systems and is all about a legacy certificate format that is, what, outdated since 2002? I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what Richard proposed.
Bug#829272: Missing accessors
I am not sure what to suggest. This conversation is bouncing across two ticket systems and is all about a legacy certificate format that is, what, outdated since 2002? I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what Richard proposed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted
