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 Linux 5.10.0-8-sparc64' --class
debian --class gnu-linux --class gnu --class os $menuentry_id_option
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#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#999820: linux-image-5.14.0-4-sparc64-smp: kernel fails to boot with niu driver enabled on recent kernels
Package: src:linux Version: 5.14.16-1 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, Trying to boot a recent sparc64 disc on this T5140, it dies on boot with something like: [ 52.521656] niu: niu.c:v1.1 (Apr 22, 2010) [ 52.529379] niu: niu0: Found PHY 002063b0 type MII at phy_port 26 [ 52.529877] niu: niu0: Found PHY 002063b0 type MII at phy_port 27 [ 52.530374] niu: niu0: Found PHY 002063b0 type MII at phy_port 28 [ 52.530857] niu: niu0: Found PHY 002063b0 type MII at phy_port 29 [ 52.531737] niu: niu0: Port 0 [4 RX chans] [6 TX chans] [ 52.531833] niu: niu0: Port 1 [4 RX chans] [6 TX chans] [ 52.531888] niu: niu0: Port 2 [4 RX chans] [6 TX chans] [ 52.531944] niu: niu0: Port 3 [4 RX chans] [6 TX chans] [ 52.531997] niu: niu0: Port 0 RDC tbl(0) [ 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ] [ 52.532308] niu: niu0: Port 0 RDC tbl(1) [ 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ] [ 52.532512] niu: niu0: Port 1 RDC tbl(2) [ 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 ] [ 52.532666] niu: niu0: Port 1 RDC tbl(3) [ 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 ] [ 52.532820] niu: niu0: Port 2 RDC tbl(4) [ 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11 ] [ 52.532981] niu: niu0: Port 2 RDC tbl(5) [ 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11 ] [ 52.533140] niu: niu0: Port 3 RDC tbl(6) [ 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15 ] [ 52.533306] niu: niu0: Port 3 RDC tbl(7) [ 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15 ] [ 52.668746] NON-RESUMABLE ERROR: Reporting on cpu 39 [ 52.668893] NON-RESUMABLE ERROR: TPC [0x0093798c] <__pci_enable_msix_range+0x38c/0x6c0> [ 52.669062] NON-RESUMABLE ERROR: RAW [02710001:00227ebd18ff:00020280: [ 52.669220] NON-RESUMABLE ERROR: 0008:::] [ 52.669338] NON-RESUMABLE ERROR: handle [0x02710001] stick [0x00227ebd18ff] [ 52.669413] NON-RESUMABLE ERROR: type [precise nonresumable] [ 52.669474] NON-RESUMABLE ERROR: attrs [0x0280] < ASI sp-faulted priv > [ 52.669566] NON-RESUMABLE ERROR: raddr [0x] [ 52.669629] NON-RESUMABLE ERROR: insn effective address [0x00c5002c] [ 52.669694] NON-RESUMABLE ERROR: size [0x8] [ 52.669738] NON-RESUMABLE ERROR: asi [0x00] [ 52.669784] CPU: 39 PID: 1906 Comm: insmod Tainted: GE 5.14.0-4-sparc64-smp #1 Debian 5.14.16-1 [ 52.669888] TSTATE: 004411001607 TPC: 0093798c TNPC: 00937990 Y: Tainted: GE [ 52.669986] TPC: <__pci_enable_msix_range+0x38c/0x6c0> [ 52.670055] g0: 0001 g1: 0020 g2: 00c50020 g3: [ 52.670132] g4: 800024cf3d80 g5: 8007fc8d8000 g6: 80003036c000 g7: 00e2 [ 52.670210] o0: 8007fe6b0f00 o1: 0001 o2: o3: 00c5002c [ 52.670286] o4: 002a o5: 800016c650c8 sp: 80003036e3c1 ret_pc: 8080 [ 52.670363] RPC: <0x8080> [ 52.670410] l0: 80003036ee14 l1: 800016c652f0 l2: 8007fe6b0f00 l3: [ 52.670487] l4: l5: l6: 800016c650c8 l7: 800016c65000 [ 52.670563] i0: 000d i1: 80003036ee10 i2: 0001 i3: 000d [ 52.670638] i4: i5: 00c50020 i6: 80003036e4b1 i7: 00937ce0 [ 52.670713] I7: [ 52.670767] Call Trace: [ 52.670807] [<00937ce0>] pci_enable_msix_range+0x20/0x40 [ 52.670879] [<108a7a08>] niu_try_msix+0xc8/0x1a0 [niu] [ 52.671008] [<108af1f8>] niu_get_invariants+0x478/0x28a0 [niu] [ 52.671133] [<108b1878>] niu_pci_init_one+0x258/0x420 [niu] [ 52.671258] [<0092dfcc>] pci_device_probe+0xcc/0x180 [ 52.671335] [<009cd404>] really_probe+0xc4/0x480 [ 52.671404] [<009cd8e4>] __driver_probe_device+0x124/0x180 [ 52.671474] [<009cd968>] driver_probe_device+0x28/0xe0 [ 52.671545] [<009ce1c4>] __driver_attach+0xc4/0x200 [ 52.671614] [<009caa98>] bus_for_each_dev+0x58/0xa0 [ 52.671698] [<009cca3c>] driver_attach+0x1c/0x40 [ 52.671778] [<009cc450>] bus_add_driver+0x1d0/0x240 [ 52.671858] [<009cee28>] driver_register+0x88/0x140 [ 52.671929] [<0092c528>] __pci_register_driver+0x48/0x60 [ 52.672001] [<108be070>] niu_init+0x70/0x94 [niu] [ 52.672123] [<00427cf0>] do_one_initcall+0x30/0x220 [ 52.672202] Kernel panic - not syncing: Non-resumable error. [ 52.672264] CPU: 39 PID: 1906 Comm: insmod Tainted: GE 5.14.0-4-sparc64-smp #1 Debian 5.14.16-1 [ 52.672362] Call Trace: [ 52.672400] [<00c878e0>] dump_stack+0x8/0x18 [ 52.672471] [<00c839d8>] panic+0xf4/0x350 [ 52.672540] [<0042a740>] sun4v_nonresum_error+0xe0/0x100 [ 52.672616] [<00406eb8>] sun4v_nonres_mondo+0xc8/0xd8 [ 52.672699]
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: 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: 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
Package: src:linux
Version: 5.10.46-4
Severity: normal
X-Debbugs-Cc: rincebr...@gmail.com
Dear Maintainer,
I was copying a bunch of 1-10M compressed logfiles (~2000 of them, to be
exact) over NFS to another machine with rsync, and suddenly my SSH session
stopped responding entirely.
Looking on the local serial console of my Netra T1, I was greeted with:
[101062.932142] Kernel unaligned access at TPC[640598] __kmalloc+0xf8/0x3c0
[101063.086881] Unable to handle kernel paging request in mna handler
[101063.086892] at virtual address 3030464b02930e86
[101063.230074] current->{active_,}mm->context = 0c4d
[101063.306803] current->{active_,}mm->pgd = f8002d894000
[101063.378956] \|/ \|/
[101063.378956] "@'/ .. \`@"
[101063.378956] /_| \__/ |_\
[101063.378956] \__U_/
[101063.576993] kworker/u3:1(371): Oops [#1]
[101063.629700] CPU: 0 PID: 371 Comm: kworker/u3:1 Tainted: P OE
5.10.0-8-sparc64 #1 Debian 5.10.46-4
[101063.763997] Workqueue: xprtiod rpc_async_schedule [sunrpc]
[101063.837362] TSTATE: 004480001604 TPC: 00640598 TNPC:
0064059c Y: Tainted: P OE
[101063.986257] TPC: <__kmalloc+0xf8/0x3c0>
[101064.037844] g0: 00e22ee0 g1: 3030464b02930a86 g2: 0400
g3:
[101064.153482] g4: f80003ea3c60 g5: 00e3cc10 g6: f800092b
g7: 063a4df0
[101064.269116] o0: o1: 0cc0 o2: 00c8
o3: f8003fe20180
[101064.384749] o4: 3988abdc02649278 o5: f8000812 sp: f800092b2e21
ret_pc: 006404f0
[101064.504977] RPC: <__kmalloc+0x50/0x3c0>
[101064.556532] l0: 102666b4 l1: 80001603 l2: 004832d0
l3: 0400
[101064.672172] l4: l5: l6:
l7: 0008
[101064.787805] i0: 00e1bc00 i1: 0cc0 i2: 00b39067
i3: 07f0
[101064.903439] i4: i5: f80002005500 i6: f800092b2ee1
i7: 102666b4
[101065.019197] I7:
[101065.084472] Call Trace:
[101065.117875] [<102666b4>] xdr_alloc_bvec+0x54/0xc0 [sunrpc]
[101065.200454] [<102445cc>] xprt_sock_sendmsg+0x14c/0x5a0 [sunrpc]
[101065.288738] [<10245b98>] xs_tcp_send_request+0xd8/0x280 [sunrpc]
[101065.378170] [<102439e0>] xprt_transmit+0x160/0x340 [sunrpc]
[101065.461877] [<1023d828>] call_transmit+0x68/0xa0 [sunrpc]
[101065.543296] [<10250a08>] __rpc_execute+0x68/0x480 [sunrpc]
[101065.625865] [<10250e3c>] rpc_async_schedule+0x1c/0x40 [sunrpc]
[101065.712886] [<00482e18>] process_one_work+0x198/0x480
[101065.789619] [<0048325c>] worker_thread+0x15c/0x560
[101065.862939] [<00488cc8>] kthread+0x108/0x120
[101065.929389] [<00405fc8>] ret_from_fork+0x1c/0x2c
[101066.000399] [<>] 0x0
[101066.048669] Caller[102666b4]: xdr_alloc_bvec+0x54/0xc0 [sunrpc]
[101066.136964] Caller[102445cc]: xprt_sock_sendmsg+0x14c/0x5a0 [sunrpc]
[101066.230969] Caller[10245b98]: xs_tcp_send_request+0xd8/0x280
[sunrpc]
[101066.326122] Caller[102439e0]: xprt_transmit+0x160/0x340 [sunrpc]
[101066.415546] Caller[1023d828]: call_transmit+0x68/0xa0 [sunrpc]
[101066.502685] Caller[10250a08]: __rpc_execute+0x68/0x480 [sunrpc]
[101066.590972] Caller[10250e3c]: rpc_async_schedule+0x1c/0x40 [sunrpc]
[101066.683707] Caller[00482e18]: process_one_work+0x198/0x480
[101066.766164] Caller[0048325c]: worker_thread+0x15c/0x560
[101066.845203] Caller[00488cc8]: kthread+0x108/0x120
[101066.917365] Caller[00405fc8]: ret_from_fork+0x1c/0x2c
[101066.994101] Caller[]: 0x0
[101067.047956] Instruction DUMP:
[101067.047965] c277a7f7
[101067.088094] c4076028
[101067.120226] d85f60b0
[101067.152358]
[101067.184490] 82004002
[101067.216623] 8f52
[101067.248755] 8411e00e
[101067.280886] 9190a000
[101067.313018] c45f4000
[101067.345148]
[101117.443898] Kernel unaligned access at TPC[640598] __kmalloc+0xf8/0x3c0
[101117.532149] Unable to handle kernel paging request in mna handler
[101117.532159] at virtual address 3030464b02930e86
[101117.675369] current->{active_,}mm->context = 01ce
[101117.752125] current->{active_,}mm->pgd = f800029f
[101117.824281] \|/ \|/
[101117.824281] "@'/ .. \`@"
[101117.824281] /_| \__/ |_\
[101117.824281] \__U_/
[101118.022297] nmbd(358): Oops [#2]
[101118.065854] CPU: 0 PID: 358 Comm: nmbd Tainted: P DOE
5.10.0-8-sparc64 #1 Debian 5.10.46-4
[101118.190651] TSTATE: 004411001601 TPC: 00640598 TNPC:
0064059c Y: Tainted: P DOE
[101118.339453] TPC: <__kmalloc+0xf8/0x3c0>
[101118.391014] g0: f800029c4000 g1: 3030464b02930a86 g2: 0400
g3:
Bug#992830: udevadm trigger produces inconsistent by-id entries
Package: udev Version: 247.3-6 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, I had the following unexpected behavior happen: $ ls -al /dev/[sv]d* /dev/disk/by-id/;sudo udevadm trigger;sleep 5;ls -al /dev/[sv]d* /dev/disk/by-id/; brw-rw 1 root disk 8, 0 Aug 23 19:25 /dev/sda brw-rw 1 root disk 8, 1 Aug 23 19:25 /dev/sda1 brw-rw 1 root disk 8, 2 Aug 23 19:25 /dev/sda2 brw-rw 1 root disk 8, 5 Aug 23 19:25 /dev/sda5 brw-rw 1 root disk 8, 16 Aug 23 19:25 /dev/sdb brw-rw 1 root disk 8, 17 Aug 23 19:25 /dev/sdb1 brw-rw 1 root disk 8, 25 Aug 23 19:25 /dev/sdb9 brw-rw 1 root disk 8, 32 Aug 23 19:25 /dev/sdc /dev/disk/by-id/: total 0 drwxr-xr-x 2 root root 200 Aug 23 19:25 . drwxr-xr-x 8 root root 160 Aug 23 19:23 .. lrwxrwxrwx 1 root root 9 Aug 23 19:25 ata-VBOX_CD-ROM_VB2-01700376 -> ../../sr0 lrwxrwxrwx 1 root root 9 Aug 23 19:25 ata-VBOX_HARDDISK_VB45a6558e-09921cfc -> ../../sdb lrwxrwxrwx 1 root root 10 Aug 23 19:25 ata-VBOX_HARDDISK_VB45a6558e-09921cfc-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Aug 23 19:25 ata-VBOX_HARDDISK_VB45a6558e-09921cfc-part9 -> ../../sdb9 lrwxrwxrwx 1 root root 9 Aug 23 19:25 ata-VBOX_HARDDISK_VBeae766ae-471697aa -> ../../sdc lrwxrwxrwx 1 root root 10 Aug 23 19:25 scsi-3-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Aug 23 19:25 scsi-3-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Aug 23 19:25 scsi-3-part5 -> ../../sda5 brw-rw 1 root disk 8, 0 Aug 23 19:25 /dev/sda brw-rw 1 root disk 8, 1 Aug 23 19:25 /dev/sda1 brw-rw 1 root disk 8, 2 Aug 23 19:25 /dev/sda2 brw-rw 1 root disk 8, 5 Aug 23 19:25 /dev/sda5 brw-rw 1 root disk 8, 16 Aug 23 19:25 /dev/sdb brw-rw 1 root disk 8, 17 Aug 23 19:25 /dev/sdb1 brw-rw 1 root disk 8, 25 Aug 23 19:25 /dev/sdb9 brw-rw 1 root disk 8, 32 Aug 23 19:25 /dev/sdc /dev/disk/by-id/: total 0 drwxr-xr-x 2 root root 160 Aug 23 19:25 . drwxr-xr-x 8 root root 160 Aug 23 19:23 .. lrwxrwxrwx 1 root root 9 Aug 23 19:25 ata-VBOX_CD-ROM_VB2-01700376 -> ../../sr0 lrwxrwxrwx 1 root root 9 Aug 23 19:25 ata-VBOX_HARDDISK_VB45a6558e-09921cfc -> ../../sdb lrwxrwxrwx 1 root root 10 Aug 23 19:25 ata-VBOX_HARDDISK_VB45a6558e-09921cfc-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Aug 23 19:25 ata-VBOX_HARDDISK_VB45a6558e-09921cfc-part9 -> ../../sdb9 lrwxrwxrwx 1 root root 9 Aug 23 19:25 ata-VBOX_HARDDISK_VBeae766ae-471697aa -> ../../sdc lrwxrwxrwx 1 root root 9 Aug 23 19:25 scsi-3 -> ../../sda $ dmesg doesn't log any lines between runs here. udevadm monitor -u reports, when it goes from 0 to all 4 scsi-3-FOO entries: UDEV [606.912495] change /devices/pci:00/:00:0d.0/ata3/host3/target3:0:0/3:0:0:0/block/sdb (block) UDEV [606.914872] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda (block) UDEV [606.918658] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda/sda2 (block) UDEV [606.920552] change /devices/pci:00/:00:0d.0/ata4/host4/target4:0:0/4:0:0:0/block/sdc (block) UDEV [606.921600] change /devices/pci:00/:00:0d.0/ata3/host3/target3:0:0/3:0:0:0/block/sdb/sdb9 (block) UDEV [606.922792] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda/sda1 (block) UDEV [606.922870] change /devices/pci:00/:00:0d.0/ata3/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) UDEV [606.926090] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda/sda5 (block) UDEV [607.143542] change /devices/pci:00/:00:01.1/ata2/host2/target2:0:0/2:0:0:0/block/sr0 (block) and likewise when it has 0 entries before and after: UDEV [762.978683] change /devices/pci:00/:00:0d.0/ata3/host3/target3:0:0/3:0:0:0/block/sdb (block) UDEV [762.981237] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda (block) UDEV [762.983966] change /devices/pci:00/:00:0d.0/ata4/host4/target4:0:0/4:0:0:0/block/sdc (block) UDEV [762.987058] change /devices/pci:00/:00:0d.0/ata3/host3/target3:0:0/3:0:0:0/block/sdb/sdb9 (block) UDEV [762.987994] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda/sda2 (block) UDEV [762.989098] change /devices/pci:00/:00:0d.0/ata3/host3/target3:0:0/3:0:0:0/block/sdb/sdb1 (block) UDEV [762.989763] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda/sda1 (block) UDEV [762.990816] change /devices/pci:00/:00:0f.0/virtio1/host1/target1:0:0/1:0:0:0/block/sda/sda5 (block) UDEV [763.210887] change /devices/pci:00/:00:01.1/ata2/host2/target2:0:0/2:0:0:0/block/sr0 (block) Not sure what other information would be useful here, other than: * This is a VirtualBox VM * sda is virtio (and the root filesystme), sdb and sdc are SATA * sdb and sdc are not in use in LVM, MD, direct mounted, or anything more
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 TCO device
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
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#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: 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#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#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: 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#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#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#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#813764: linux-source-3.16: "Dazed and confused, but trying to continue" on X10SDV-TLN4F while using perf top
Package: linux-source-3.16 Version: 3.16.0-4 Severity: normal Dear Maintainer, I was going about my business, using perf top to see what I was spending a bunch of my time in on this system, when suddenly, I got this written to console: [2425302.546957] Uhhuh. NMI received for unknown reason 11 on CPU 1. [2425302.547625] Do you have a strange power saving mode enabled? [2425302.548291] Dazed and confused, but trying to continue I've been running this system for several months at this point, and have not seen this issue at any point prior. I can't easily reproduce it again, so it may have been something other than "perf top" that resulted in the behavior, but that's the only unusual thing I can think of. Supermicro X10SDV-TLN4F, which is a Xeon D-1540 board. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-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)
Bug#792088: apt-get install segfaults with certain repository configurations
Package: apt Version: 1.0.9.10 Severity: important Dear Maintainer, I tried adding the Mono third-party repositories and doing an apt-get update; apt-get install -y mono-runtime apt-get install mono-runtime refused with an unmet dependency, which I include below only because of what happened after that: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: monodoc-http : Depends: mono-xsp4 but it is not going to be installed or mono-apache-server4 but it is not going to be installed or mono-fastcgi-server4 but it is not going to be installed N: Ignoring file 'core' in directory '/etc/apt/sources.list.d/' as it has no filename extension N: Ignoring file 'core' in directory '/etc/apt/sources.list.d/' as it has no filename extension E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. So I tried apt-get install mono-runtime monodoc-http, to see what would result. Reading package lists... Done Building dependency tree Reading state information... Done monodoc-http is already the newest version. monodoc-http set to manually installed. Segmentation fault (core dumped) I tried bumping from 1.0.9.8 to the testing version (1.0.9.10), behavior persists. I can include the core dump and any additional information that would be useful. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^linux-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16\.0-0\.bpo\.4-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.2\.0-4-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Architectures
