Control: reassign -1 bash-completion 1:2.11-8
Control: close -1 1:2.14.0-1
On Sat, Aug 10, 2024 at 01:52:31PM +0200, Salvatore Bonaccorso wrote:
> JFTR, I cannot reproduce this behaviour right now.
I can (bash 5.2.21-2.1, TERM=st-256color and TERM=dumb),
no ethtool-related aliases.
/usr/share/ba
On Fri, Mar 08, 2024 at 06:43:44PM +0100, Bastian Blank wrote:
> Control: severity -1 minor
> > Because this is an x32 host.
> x32 is multi-arch kernel only architecture. Debian still don't have
> proper support for multi-arch for compilers.
I don't get this. This literally Just fully worked.
gcc
te version and architecture
for Linux on amd64, i386 and x32.
‒ which correctly and expectedly pulled in gcc-13:x32.
Because this is an x32 host.
Please revert this change and pull in the correct compiler again.
Best,
наб
(One has to assume this would be a similar scenario on an i386
misc binfmt_misc
rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /run/user/1000 tmpfs
rw,nosuid,nodev,relatime,size=387924k,nr_inodes=96981,mode=700,uid=1000,gid=1000,inode64
0 0
-- >8 --
Applying Aron's patch succeeds at 434 (offset 60 lines) and generates a valid
initrd.
Best,
наб
-- Packag
tils:cp -pnL
so here we are.
Best,
наб
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.9-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), L
^[[36monboard1
Typing "ethtool -g ^[[36m" in and then tabbing yields nothing,
so this is probably a control sequence?
Indeed, typing control-[, [, 3, 6, m, dupa into cat shows dupa in blue.
Why?
Best,
наб
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT po
Package: nfs-kernel-server
Version: 1:2.6.3-3
Severity: normal
File: /usr/sbin/fsidd
Dear Maintainer,
This makes ss -l output super annoying without grep -v fsidd | column -t again.
I'm assuming it wants to bind to @/run/fsid.sock instead but someone forgor 💀
Best,
наб
-- Package-spe
tka kernel: tg3 :3f:00.0 eth2: RXcsums[1]
LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
Aug 06 14:49:35 szarotka kernel: tg3 :3f:00.0 eth2: dma_rwctrl[7618]
dma_mask[64-bit]
-- >8 --
Best,
наб
-- Package-specific info:
** Version:
Linux version 6.3.0-2-amd64 (debian-kernel@lists.d
0 0 keyring: .builtin_trusted_keys
1022385710: ---lswrv 0 0 keyring: .machine
# keyctl list %:.machine
keyring is empty
# certutil -L sql:secureboot -n 'babtop DB 2023' | grep -iA1 serial
Serial Number:
00:be:fa:ca:a0
$ zfs version
zfs-2.1.9-3
zf
https://salsa.debian.org/kernel-team/linux/-/merge_requests/691
наб
signature.asc
Description: PGP signature
on salsa.
On Fri, Mar 31, 2023 at 01:45:08AM +0200, наб wrote:
> keys-6.0:19c0bfbd I-- 1 perm 1f0f 0 0 keyring
> .secondary_trusted_keys: 1
> keys-6.1:29a13614 I-- 1 perm 1f0f 0 0 keyring
> .secondary_trusted_keys: 2
>
> Note how
m 1f0f 0 0 keyring
.secondary_trusted_keys: 2
keys-6.1:0f6033db I--Q--- 1 perm 0c03 0 65534 keyring
.user_reg: 2
Note how there's somehow a second key in .secondary_trusted_keys.
Whether this means something or is an accounting difference
is unclear to me at this time.
(see stat(2)).
which initially put me onto "this is a kernel bug" rather than
"this is a security tunable", I'll write a blurb there.
Best,
наб
signature.asc
Description: PGP signature
On Sat, Mar 25, 2023 at 05:54:23PM +0100, наб wrote:
> -- >8 --
> /srv# echo /srv/f > f
> /srv# mkdir -m 1777 1777
> /srv# ln -s /srv/f 1777/
> /srv# chown _apt 1777/
>
> /srv$ cat 1777/f
> cat: 1777/f: Permission denied
> /srv$ cat f
> /srv/f
> -- >
link there,
the cat also succeeds.
Naturally, it should succeed in every scenario.
Best,
наб
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: amd64, i386
Kernel: Linux 6.1.0-2-amd64
config, it shouldn't)
change anything if you aren't a MOK user, and I'm not.
Please advise.
наб
signature.asc
Description: PGP signature
Control: found -1 6.1.20-1
Updated to linux-image-6.1.0-7-amd64 (6.1.20-1);
still happens.
наб
Mar 25 01:38:54 babtop kernel: microcode: microcode updated early to revision
0xf4, date = 2022-07-31
Mar 25 01:38:54 babtop kernel: Linux version 6.1.0-7-amd64
(debian-kernel@lists.debian.org) (gcc
5 bug, presumably, so idk. Please advise :)
Best,
наб
-- Journal begins at Sun 2022-08-07 15:25:18 CEST, ends at Sun 2023-02-26
23:52:38 CET. --
Aug 07 15:25:18 ciastko-malinowe kernel: Booting Linux on physical CPU 0x0
Aug 07 15:25:18 ciastko-malinowe kernel: Linux version 6.0.0-0.deb11.6-rpi
(d
SING
("[used, input, pull-up,
both-edges]" in lsgpio parlance)
So, in short, "in usb-host mode, when subscribed to falling edges,
both edges are returned, but labelled as falling" I guess?
Will try to upd
2746f702e6e6162696a61637a6c6577656c692e78797a"
[1.736887] asymmetric_keys:find_asymmetric_key: Request for key
'ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06
27401
035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a'
err -11
[1.736890] Loading of module with unavailable key is rejected
What this means is unclear to me, but it's odd.
наб
signature.asc
Description: PGP signature
dy loaded from before.
Similarly, security/integrity/platform_certs/platform_keyring.c was last
touched in 2019, and the interesting parts of
security/integrity/platform_certs/load_uefi.c
security/integrity/platform_certs/efi_parser.c
are of about the same vintage.
It's very much unclear to me w
Booted with both, hibernated, resumed; full dmesg below.
Best,
-- >8 --
[0.00] Linux version 6.1.0-2-686-pae (debian-kernel@lists.debian.org)
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1
SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)
[0.00] x86/fp
Control: found -1 6.1.7-1
Can repro on the sid kernel, uname -a of
Linux nabtop 6.1.0-2-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1
(2023-01-18) i686 GNU/Linux
Log below. Backtrace is only trivially different.
Best,
наб
-- >8 --
Jan 22 14:06:46 nabtop kernel: OOM killer disabled.
Jan
FILE does
not exist.
-- >8 --
Which is apparently in v6.1-rc1; that, OTOH, cites commit
7572733b84997d23077ebd852703055034b7a1d2 ("perf tools: Fix version
kernel tag"), first seen in v5.18-rc1, so the time-line works out.
This probably means this will be fixed, no intervention req
nter-parts, but nevertheless
shouldn't (effectively) conflict with dracut.
Before I send out patches to the rest, I'd love to know if:
a) I'm not insane for thinking this, and
b) it'd perhaps make sense to encode this in the kernel handbook or
the like to have somethi
y considering that it takes a good second to start up?
Best,
наб
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd6
Hi!
Just hit this, great time, I'd just like to narrow down this regression,
the previous 5.10.0-5 (5.10.24) works fine, but 5.10.26 is broken.
Best,
наб
signature.asc
Description: PGP signature
retitle 971068 linux-image-5.9.0-1-686-pae: Assertion failure in i915
intel_display.c#assert_plane() after resume from hibernation
found 971068 5.9.1-1
thanks
Turns out the delay was because my system was horriby starved for I/O,
switching to an SSD revealed that the display is ready immediately
order of tens of seconds sometimes).
I've expanded the "Kernel log" sexion below to include traces from both
CPUs, and am attaching a full dmesg, I'll be happy to provide more info,
just don't really know what you'd need.
Best,
наб
-- Package-specific info:
** Vers
ket
parameters and error handling [2,3], so shouldn't affect much.
Best,
наб
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/cifs/connect.c?id=a0a3036b81f1f66fa559ecfe18f5bbfa5076#n1787
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torval
30 matches
Mail list logo
