Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap

2024-11-29 Thread Stefano Rivera
Hi Bastian (2024.10.19_09:35:21_-0400)
> What you describe here is a headers only library.  It is consensus
> within Debian that those exist and are shipped as arch:all.  They don't
> provide further architecture clues in the dependencies, but you need to
> know or convey this information by failing to build.

I think in most (all?) cases, they don't have architecture-specific
headers.  So that applying that consensus here may be not be that useful
to this case.

In general arch:all packages are preferable to arch:any, for the sake of
the size of the archive. But sometimes violating that is necessary.

It sounds like changing linux-libc-dev to arch:any could be helpful to
the cross-bootstrappers. That's something that happens outside the
archive, but is also part of the lifeblood of the project. Architectures
come and go, and we've been trying to make this process easier. It's one
of our strengths as a distribution.

> > I note that I do not have a good understanding why the change from
> > arch:any to arch:all was done. It does seem to reduce the cumulative
> > size consumed by binary .debs on mirrors and note that a similar effect
> > can be achieved by having a linux-libc-dev-common for the architecture
> > generic headers and a per-arch symlink farm in linux-libc-dev.
> 
> No, it can not.  We can not have arch:any -> arch:all dependencies
> within the same source package this deep in the toolchain, especially as
> those require = dependencies.

Would you expand on that a bit?

I see a concern on a -common package: There are risks of arch:all and
arch:any packages building at different times on the buildds, and
possibly being published in separate mirror pushes. Leaving
build-essential uninstallable if the builds don't all succeed before the
arch-all package publishes.

If so, avoiding a -common package and having linux-libc-dev be pure
arch:any could be a reasonable solution? (At a cost of size)

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Bug#1088682: linux-image-6.11.9-amd64: Abnormal delay at boot time (related to unstable tsc), also on installer image

2024-11-29 Thread Fab Stz
Package: linux-image-6.11.9-amd64
Version: 6.11.9-1
Severity: normal

Dear Maintainer,

Since bookworm which runs kernel 6.1 I have an extended boot delay which can
last for a few minutes. Dmesg showed that the issue is with the clock source.
Setting the kernel parameter 'tsc=unstable' at boot time fixes the issue. I
have the same problem with Trixie which now has kernel 6.11 and of course the
issue is also with the Debian installer media. (Bookworm and Trixie)

The issue is that it is difficult to find out what is really making the boot 
be
stuck for a long time and when booting the installation medium one would
believe that the system is completely frozen since that can last for a few
minutes. The system doesn't react to any user input when in that state.

Moreover if I remove the 'quiet' parameter from the kernel it seems stuck on
detecting USB. This is misleading. It is only by looking at the kernel logs
that I found it was suggested to use tsc=unstable.

How could we prevent users to be stuck at boot time for such a long time
without having a clue on what is happening? Here are a few ideas:

- run the installer by default with tsc=unstable, but maybe this would pass 
the
value to the installed system, even when not appropriate? And if it doesn't
pass it to the installed system, that would just move the problem to 1st boot
time and reveal the delay at that time which isn't ideal either.
- build the kernel for the installer medium with
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK ?
- write a notice in the installation guide?

In the meantime I sent a report to the kernel mailing list.



Regards


-- System Information:
Debian Release: 12.8
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 
'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 
'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 
'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 
'unstable'), (93, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-27-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.11.9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142+deb12u1
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.11.9-amd64 recommends:
ii  apparmor  3.0.8-3

Versions of packages linux-image-6.11.9-amd64 suggests:
pn  debian-kernel-handbook  
ii  firmware-linux-free 20200122-1
ii  grub-efi-amd64  2.06-13+deb12u1
pn  linux-doc-6.11  



Processed: tagging 1088682

2024-11-29 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 1088682 + upstream
Bug #1088682 [src:linux] linux-image-6.11.9-amd64: Abnormal delay at boot time 
(related to unstable tsc), also on installer image
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1088682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088682
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: reassign 1088682 to src:linux

2024-11-29 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 1088682 src:linux 6.11.9-1
Bug #1088682 [linux-image-6.11.9-amd64] linux-image-6.11.9-amd64: Abnormal 
delay at boot time (related to unstable tsc), also on installer image
Bug reassigned from package 'linux-image-6.11.9-amd64' to 'src:linux'.
No longer marked as found in versions linux-signed-amd64/6.11.9+1.
Ignoring request to alter fixed versions of bug #1088682 to the same values 
previously set
Bug #1088682 [src:linux] linux-image-6.11.9-amd64: Abnormal delay at boot time 
(related to unstable tsc), also on installer image
Marked as found in versions linux/6.11.9-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1088682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088682
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: bug 1088682 is forwarded to https://lore.kernel.org/all/10cf96aa-1276-4bd4-8966-c89037703...@yahoo.fr/

2024-11-29 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> forwarded 1088682 
> https://lore.kernel.org/all/10cf96aa-1276-4bd4-8966-c89037703...@yahoo.fr/
Bug #1088682 [src:linux] linux-image-6.11.9-amd64: Abnormal delay at boot time 
(related to unstable tsc), also on installer image
Set Bug forwarded-to-address to 
'https://lore.kernel.org/all/10cf96aa-1276-4bd4-8966-c89037703...@yahoo.fr/'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1088682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088682
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1088733: linux-image-6.1.0-28-amd64: list_del corruption in cifs_put_smb_ses frequently causes system hang

2024-11-29 Thread Michael

Package: src:linux
Version: 6.1.119-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?

We have a CIFS (DFS) infrastructure and after mounting (at some point)
these the kernel on this client reports a BUG and a few minutes later
the whole system hangs:

# TRACE

CIFS: VFS: \\SOME.SERVER.FQDN cifs_put_smb_ses: Session Logoff failure rc=-11
CIFS: VFS: \\(null) cifs_put_smb_ses: Session Logoff failure rc=-11
list_del corruption, 966536fe7800->next is NULL
[ cut here ]
kernel BUG at lib/list_debug.c:49!
invalid opcode:  [#1] PREEMPT SMP PTI
CPU: 6 PID: 2498151 Comm: kworker/6:9 Tainted: G   OE  
6.1.0-23-amd64 #1  Debian 6.1.99-1
Hardware name: Dell Inc. PowerEdge R620/0KCKR5, BIOS 2.9.0 12/06/2019
Workqueue: events delayed_mntput
RIP: 0010:__list_del_entry_valid.cold+0xf/0x6f
Code: c7 c7 88 3c fa a0 e8 90 a0 fe ff 0f 0b 48 c7 c7 60 3c fa a0 e8 82 a0 fe ff 0f 
0b 48 89 fe 48 c7 c7 70 3d fa a0 e8 71 a0 fe ff <0f> 0b 48 89 d1 48 c7 c7 90 3e 
fa a0 48 89 c2 e8 5d a0 fe ff 0f 0b
RSP: 0018:ad83a63f7dd0 EFLAGS: 00010246
RAX: 0033 RBX: 966536fe7800 RCX: 0027
RDX:  RSI: 0001 RDI: 965e7f8e03a0
RBP: 142d66a6 R08:  R09: ad83a63f7c68
R10: 0003 R11: 966ebff11be0 R12: fff5
R13: 966536fe7000 R14: 966536fe7020 R15: a1770b88
FS:  () GS:965e7f8c() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fe35dbcb7b0 CR3: 000f36c10001 CR4: 000606e0
Call Trace:
 
 ? __die_body.cold+0x1a/0x1f
 ? die+0x2a/0x50
 ? do_trap+0xc5/0x110
 ? __list_del_entry_valid.cold+0xf/0x6f
 ? do_error_trap+0x6a/0x90
 ? __list_del_entry_valid.cold+0xf/0x6f
 ? exc_invalid_op+0x4c/0x60
 ? __list_del_entry_valid.cold+0xf/0x6f
 ? asm_exc_invalid_op+0x16/0x20
 ? __list_del_entry_valid.cold+0xf/0x6f
 cifs_put_smb_ses+0xbb/0x3e0 [cifs]
 mount_group_release+0x82/0xa0 [cifs]
 cifs_umount+0x88/0xa0 [cifs]
 deactivate_locked_super+0x2f/0xa0
 cleanup_mnt+0xbd/0x150
 delayed_mntput+0x28/0x40
 process_one_work+0x1c7/0x380
 worker_thread+0x4d/0x380
 ? rescuer_thread+0x3a0/0x3a0
 kthread+0xda/0x100
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 
Modules linked in: bluetooth jitterentropy_rng drbg ansi_cprng ecdh_generic 
rfkill ecc overlay isofs cmac nls_utf8 cifs cifs_arc4 cifs_md4 rpcsec_gss_krb5 
nfsv4 dns_resolver nfs fscache netfs tls beegfs(OE) rpcrdma rdma_ucm ib_iser 
rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi rdma_rxe ib_uverbs 
ip6_udp_tunnel udp_tunnel ib_core nft_chain_nat xt_nat nf_nat nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink intel_rapl_msr 
intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel ipmi_ssif binfmt_misc kvm irqbypass ghash_clmulni_intel sha512_ssse3 
sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel crypto_simd cryptd rapl 
dcdbas mgag200 intel_cstate joydev evdev drm_shmem_helper intel_uncore iTCO_wdt 
ipmi_si drm_kms_helper mei_me intel_pmc_bxt ipmi_devintf iTCO_vendor_support 
pcspkr i2c_algo_bit mei ipmi_msghandler watchdog sg acpi_power_meter button 
nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm fuse loop efi_pstore configfs
 ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod hid_generic usbhid 
hid sd_mod t10_pi sr_mod cdrom crc64_rocksoft crc64 crc_t10dif 
crct10dif_generic ahci libahci crct10dif_pclmul crct10dif_common crc32_pclmul 
libata ehci_pci bnx2x ehci_hcd megaraid_sas usbcore scsi_mod lpc_ich usb_common 
mdio libcrc32c crc32c_generic scsi_common crc32c_intel wmi
---[ end trace  ]---
RIP: 0010:__list_del_entry_valid.cold+0xf/0x6f
Code: c7 c7 88 3c fa a0 e8 90 a0 fe ff 0f 0b 48 c7 c7 60 3c fa a0 e8 82 a0 fe ff 0f 
0b 48 89 fe 48 c7 c7 70 3d fa a0 e8 71 a0 fe ff <0f> 0b 48 89 d1 48 c7 c7 90 3e 
fa a0 48 89 c2 e8 5d a0 fe ff 0f 0b
RSP: 0018:ad83a63f7dd0 EFLAGS: 00010246
RAX: 0033 RBX: 966536fe7800 RCX: 0027
RDX:  RSI: 0001 RDI: 965e7f8e03a0
RBP: 142d66a6 R08:  R09: ad83a63f7c68
R10: 0003 R11: 966ebff11be0 R12: fff5
R13: 966536fe7000 R14: 966536fe7020 R15: a1770b88
FS:  () GS:965e7f8c() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fe35dbcb7b0 CR3: 000f36c10001 CR4: 000606e0
note: kworker/6:9[2498151] exited with preempt_count 1


END TRACE #

This looks fairly similar to what has been reported with
https://security-tracker.debian.org/tracker/CVE-2024-35870 except that
it's not triggered by smb2_reconnect_server, but rather some DFS related
code. I manually backported the fix from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2

Processed: severity of 1088733 is important, tagging 1088733

2024-11-29 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> severity 1088733 important
Bug #1088733 [src:linux] linux-image-6.1.0-28-amd64: list_del corruption in 
cifs_put_smb_ses frequently causes system hang
Severity set to 'important' from 'critical'
> tags 1088733 + upstream
Bug #1088733 [src:linux] linux-image-6.1.0-28-amd64: list_del corruption in 
cifs_put_smb_ses frequently causes system hang
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1088733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088733
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: found 1088733 in 6.1.99-1

2024-11-29 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> # accordng to the version in the backtrace
> found 1088733 6.1.99-1
Bug #1088733 [src:linux] linux-image-6.1.0-28-amd64: list_del corruption in 
cifs_put_smb_ses frequently causes system hang
Marked as found in versions linux/6.1.99-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1088733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088733
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1050256: AppArmor breaks locking non-fs Unix sockets

2024-11-29 Thread Salvatore Bonaccorso
Hi John,

On Sat, Aug 03, 2024 at 09:35:25PM +0200, Salvatore Bonaccorso wrote:
> Hi John,
> 
> On Sun, May 26, 2024 at 01:39:07PM +0200, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > For those watching this bug: John has prepared backports in his tree,
> > with both approaches:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-two-patch-1780227
> > 
> > and
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-backport-1780227
> > 
> > (but with the open question which one will be submitted for stable.
> > >From upstream stable point of view probably the two patch backport
> > approach would be the preferred one).
> 
> We still have tis issue open for 6.1.y upstream TTBOMK. If you are
> confident as maintainer with any of the two approaches, would it be
> possible to submit them for stable? If the preferred one get then
> accepted and queued, we might already cherry-pick the solution for us,
> but at this point we can wait for the respective 6.1.y stable version
> which will include the fix.

Friendly ping. Any news here?

Regards,
Salvatore