Re: initrd sizes mushroomed several months ago

[Felix Miata]

Felix Miata composed on 2022-11-12 01:57 (UTC-0500):

> # grep MODULES= /etc/initramfs-tools/initramfs.conf
> MODULES=dep
> # ls -Ggh /boot/initrd.img-[5,6]*
> -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686

> Does anyone here have an explanation for the mega-change in size of initrds 
> after
> kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> testing/bullseye
> became testing/bookworm.

That was on host 32bit host gx28b with ATI RV516 [Radeon X1300/X1550 Series], 
and
the rest of the follow-up in the past few days was with host gx78b with AMD 
HD6450
(Caicos; Terascale 2). On host fi965 with AMD HD8570 (Oland; GCN1), where all 
was
roughly similar other than specific GPU to gx78b I just did:

1-Installed dracut, and copied /etc/dracut.conf.d/* from TW to Bullseye's
/etc/dracut.conf.d/, which installation left empty:
# ls -gG /etc/dracut.conf.d/
total 3
-rw-r--r-- 1 894 Jan 26 08:01 10-persistent_policy.conf
-rw-r--r-- 1  29 Nov 10 01:35 13-persistent-local.conf
-rw-rw-r-- 1 200 Feb  4 00:25 dmodules.conf
# cat /etc/dracut.conf.d/*f | grep -v ^#
persistent_policy="by-uuid"
persistent_policy="by-label"
compress="zstd"
hostonly="yes"
omit_drivers+=" btrfs dmraid encryptfs i18n iscsi lvm lvm2 plymouth resume
sata_sil uefi-lib usb_storage "
--no-kernel
--no-early-microcode

The installation tried to rebuild all existing initrds, but failed on 
account of
my symlinks in /boot/ that it wasn't prepared to deal with.

2-prepended . to all symlink names in /boot/.

3-apt update

4-time apt-get upgrade
This did not add a new kernel. Dracut rebuilt all existing initrds. I 
noticed no
activity from update-initramfs.

5-rebooted successfully using 6.0x's new initrd.

6-apt-get full-upgrade
... 34 upgraded, 21 newly installed, 0 to remove and 0 not upgraded, 
including
6.1x kernel.

7-rebooted successfully using 6.1x's new initrd.

This is the current state of all initrds. Newest of each exists without leading 
.
or last digit:
# ls -gGh /boot/.ini*
-rw-r--r-- 1 7.3M Apr 20  2022 /boot/.initrd.img-5.16.0-6-amd641
-rw-r--r-- 1  14M Feb  4 00:17 /boot/.initrd.img-5.16.0-6-amd642 # dracut
-rw-r--r-- 1 8.3M Aug  4  2022 /boot/.initrd.img-5.18.0-3-amd641
-rw-r--r-- 1  15M Feb  4 00:18 /boot/.initrd.img-5.18.0-3-amd642 # dracut
-rw-r--r-- 1  33M Sep 13 01:26 /boot/.initrd.img-5.19.0-1-amd641
-rw-r--r-- 1  15M Feb  4 00:18 /boot/.initrd.img-5.19.0-1-amd642 # dracut
-rw-r--r-- 1  33M Oct 20 02:29 /boot/.initrd.img-5.19.0-2-amd641
-rw-r--r-- 1  15M Feb  4 00:19 /boot/.initrd.img-5.19.0-2-amd642 # dracut
-rw-r--r-- 1  27M Dec 27 04:54 /boot/.initrd.img-6.0.0-6-amd641
-rw-r--r-- 1  15M Feb  4 00:20 /boot/.initrd.img-6.0.0-6-amd642 # dracut
-rw--- 1  15M Feb  4 00:46 /boot/.initrd.img-6.1.0-2-amd641 # dracut
# lsinitramfs .initrd.img-6.0.0-6-amd641 | wc -l
1208
# lsinitramfs .initrd.img-6.0.0-6-amd642 | wc -l
881
# lsinitramfs .initrd.img-6.0.0-6-amd641 | grep mwar | wc -l
728
# lsinitramfs .initrd.img-6.0.0-6-amd642 | grep mwar | wc -l
1
# lsinitramfs .initrd.img-6.1.0-2-amd641 | grep box
# lsinitramfs .initrd.img-6.1.0-2-amd641 | wc -l
882
#

So, dracut is building considerably smaller by leaving out firmware, and leaving
out radeon.ko and amdgpu.ko, but adding other things TBD once I have ideas what 
to
look for. I suspect it could be a lot of individual tools instead of (absent) 
busybox.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: kernel errors

[Max Nikulin]

On 03/02/2023 01:47, Richmond wrote:


It might be a good way for someone to reproduce the error on some other
machine. I have no problems with the CD/DVD writer and have used it a
few times recently.


Do you see the same errors if kernel command line is edited from grub to 
pass non-existing UUID specified in the resume=UUID=... argument? It 
might be a quick way to reproduce the issue.


Is it realistic that usually optical drives are skipped during UUID 
searches, but specific driver exposes a wrong property, so the device is 
considered as a regular disk drive?

Re: initrd sizes mushroomed several months ago

[Greg Wooledge]

On Fri, Feb 03, 2023 at 06:45:14PM -0600, David Wright wrote:
> It's useful, as seen in my post, to skip past the early archive in
> order to see how the main archive has been compressed.

If you want to see the contents of the *second* archive in the initrd,
you have to call cpio a second time.


unicorn:~$ { cpio -it ; echo == ; zcat | cpio -it | head; } < 
/boot/initrd.img-5.10.0-21-amd64 
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
9794 blocks
==
.
bin
conf
conf/arch.conf
conf/conf.d
conf/conf.d/resume
conf/initramfs.conf
etc
etc/fstab
etc/ld.so.cache


As it turns out, the second archive in that initrd file is compressed.
Omitting the "zcat |" causes a *massive* slew of error messages containing
binary data.

Or, of course, you could use lsinitramfs which is actually designed to
read these things.

Re: initrd sizes mushroomed several months ago

[David Wright]

On Fri 03 Feb 2023 at 07:49:39 (-0500), Greg Wooledge wrote:
> On Fri, Feb 03, 2023 at 01:45:33AM -0500, Felix Miata wrote:
> > David Wright composed on 2023-02-01 22:39 (UTC-0600):
> > >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
> > 
> > Is that a typo? I copied & pasted that and the screen loaded binary 
> > gibberish.
> 
> GNU cpio(1) says that -t implies -i, so it should work on Debian.
> 
> unicorn:~$ cpio -t < /boot/initrd.img-5.10.0-21-amd64 
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/.enuineIntel.align.0123456789abc
> kernel/x86/microcode/GenuineIntel.bin
> 9794 blocks
> 
> Not sure how *useful* it is, since it only lists the TOC from the first
> cpio archive in the initrd image, and there may be multiple.  But it
> should give a human-readable table of contents.  If it doesn't, then
> either you're not using GNU cpio (try cpio -it for portability), or
> your archive may be corrupt.

It's useful, as seen in my post, to skip past the early archive in
order to see how the main archive has been compressed.

I would assume that Felix's initrd lacks any early archive, and my
command has run up against the compressed main archive itself.

unmkinitramfs, of course, takes account of all this, but tells you
nothing about how the contents on the initrd are arranged. I've read
that binwalk can do this, but installing that is a 43 package waste
for me (with Recommends).

So I was posting a widely used method of hand-dismantling the initrd,
which naturally relies on interactively responding to what's observed.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[David Wright]

On Fri 03 Feb 2023 at 23:59:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> > I don't know a lot about zsh, but I ran it, typed some letters, and
> > pressed Ctrl-U, and they were all erased as expected.
> 
> But the point is multiline, as you did then:
> 
> > One difference that I did notice in zsh is that its handling of Ctrl-U
> > after a bracketed paste is different from bash's.  I used "seq 3 | xclip -i"
> > to load three harmless lines into the paste selection, and then pasted
> > it into zsh, and into bash, and pressed Ctrl-U in each of them.  In the
> > zsh case, only the third line was erased, and the first 2 were still
> > there, and were executed when I pressed Enter.  In bash, all 3 lines
> > were erased, and Enter didn't execute any of them.
> > 
> > Whether that's a bug in zsh, I can't say.
> 
> I would say that's expected and this is actually a bug in bash:
> "kill-whole-line" means to kill the line, not the whole text.

But the whole text /behaves/ as one line containing embedded newlines,
which you will quickly realise if you ever try to edit it before
pressing Enter. If you want to edit something that's apparently
"three lines up", you can't press ↑ to move up three lines:
you have to hold down the ← key and wait until it reaches said
position. And you can add and remove the embedded newlines at will.

When you press Enter, a "transformation" takes place, and the paste
is interpreted in the context in which it finds itself, which can
lead to surprises.

Cheers,
David.

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> > About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> > not really usable in zsh to erase long pastes (unless one changes
> > the default bindings). But Ctrl-C is fine in zsh.
> 
> Ctrl-U is bound to "kill" at the terminal level (e.g. stty(1)).  It's
> more than just a shell feature.  You can use it in any setting where
> a terminal is in "canonical mode", e.g. "cat" with no arguments reading
> from a terminal, or a terminal's login prompt.

Shells do not use "canonical mode". In zsh, Ctrl-U is handled by zle,
bash uses readline, AFAIK, so that it depends on the Ctrl-U binding.
See examples in the readline(3readline) man page.

> I don't know a lot about zsh, but I ran it, typed some letters, and
> pressed Ctrl-U, and they were all erased as expected.

But the point is multiline, as you did then:

> One difference that I did notice in zsh is that its handling of Ctrl-U
> after a bracketed paste is different from bash's.  I used "seq 3 | xclip -i"
> to load three harmless lines into the paste selection, and then pasted
> it into zsh, and into bash, and pressed Ctrl-U in each of them.  In the
> zsh case, only the third line was erased, and the first 2 were still
> there, and were executed when I pressed Enter.  In bash, all 3 lines
> were erased, and Enter didn't execute any of them.
> 
> Whether that's a bug in zsh, I can't say.

I would say that's expected and this is actually a bug in bash:
"kill-whole-line" means to kill the line, not the whole text.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: kernel errors

[John Covici]

sorry, replied to wrong list.

On Fri, 03 Feb 2023 16:55:18 -0500,
John Covici wrote:
> 
> For instance I just got a post from Freedom Scientific which had the
> announcement in the Email and also link to the post.
> On Fri, 03 Feb 2023 15:28:55 -0500,
> David Wright wrote:
> > 
> > On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote:
> > > David Wright  writes:
> > > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote:
> > > >> "Thomas Schmitt"  writes:
> > > >> >
> > > >> > (If not there, then in the /scripts/local-block directory of the 
> > > >> > initrd ?)
> > > >> 
> > > >> I don't know how I would look in that. Is it in RAM at boot time?
> > > >
> > > >Choose your kernel ↓↓Pick any name 
> > > >
> > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> > > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
> > > > $ ls -GlgR /tmp/initrd21/main/scripts/
> > > > /tmp/initrd21/main/scripts/:
> > > > total 48
> > > > -rw-r--r-- 1 11152 Jan 14  2021 functions
> > > > drwxr-xr-x 2  4096 Feb  2 18:45 init-bottom
> > > > drwxr-xr-x 2  4096 Feb  2 18:45 init-top
> > > > -rw-r--r-- 1  5303 Jan 14  2021 local
> > > > drwxr-xr-x 2  4096 Feb  2 18:45 local-block
> > > > drwxr-xr-x 2  4096 Feb  2 18:45 local-bottom
> > > > drwxr-xr-x 2  4096 Feb  2 18:45 local-premount
> > > > drwxr-xr-x 2  4096 Feb  2 18:45 local-top
> > > > -rw-r--r-- 1  3093 Jan 14  2021 nfs
> > > >
> > > > /tmp/initrd21/main/scripts/init-bottom:
> > > > total 8
> > > > -rw-r--r-- 1  77 Jan 23 21:46 ORDER
> > > > -rwxr-xr-x 1 611 Aug  7 08:25 udev
> > > >
> > > > /tmp/initrd21/main/scripts/init-top:
> > > > total 20
> > > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER
> > > > -rwxr-xr-x 1 384 Jan 14  2021 all_generic_ide
> > > > -rwxr-xr-x 1 296 Jan 14  2021 blacklist
> > > > -rwxr-xr-x 1 167 Jan 14  2021 keymap
> > > > -rwxr-xr-x 1 568 Aug  7 08:25 udev
> > > >
> > > > /tmp/initrd21/main/scripts/local-block:
> > > > total 8
> > > > -rw-r--r-- 1  82 Jan 23 21:46 ORDER
> > > > -rwxr-xr-x 1 246 Feb  1  2022 cryptroot
> > > >
> > > > /tmp/initrd21/main/scripts/local-bottom:
> > > > total 20
> > > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER
> > > > -rwxr-xr-x 1 253 Feb  1  2022 cryptgnupg-sc
> > > > -rwxr-xr-x 1 449 Feb  1  2022 cryptopensc
> > > > -rwxr-xr-x 1 307 Feb  1  2022 cryptroot
> > > > -rwxr-xr-x 1 345 Nov  2 16:46 ntfs_3g
> > > >
> > > > /tmp/initrd21/main/scripts/local-premount:
> > > > total 12
> > > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER
> > > > -rwxr-xr-x 1 226 Nov  2 16:46 ntfs_3g
> > > > -rwxr-xr-x 1 863 Jan 14  2021 resume
> > > >
> > > > /tmp/initrd21/main/scripts/local-top:
> > > > total 20
> > > > -rw-r--r-- 1  162 Jan 23 21:46 ORDER
> > > > -rwxr-xr-x 1  757 Feb  1  2022 cryptopensc
> > > > -rwxr-xr-x 1 8630 Feb  1  2022 cryptroot
> > > > $ 
> > > >
> > > > This is a desktop with random-key swap, so no resume.
> > > > There are encrypted partitions present. YMMV.
> > > >
> > > > Cheers,
> > > > David.
> > > 
> > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> > > ~$ find /tmp/initrd21/ -print|grep "local-block"
> > > ~$ find /tmp/initrd21/ -print|grep "local"
> > > 
> > > /tmp/initrd21/usr/local
> > > /tmp/initrd21/usr/local/share
> > > /tmp/initrd21/usr/local/share/fonts
> > > /tmp/initrd21/usr/local/share/fonts/.uuid
> > > /tmp/initrd21/scripts/local-bottom
> > > /tmp/initrd21/scripts/local-bottom/ntfs_3g
> > > /tmp/initrd21/scripts/local-bottom/ORDER
> > > /tmp/initrd21/scripts/local
> > > /tmp/initrd21/scripts/local-premount
> > > /tmp/initrd21/scripts/local-premount/ntfs_3g
> > > /tmp/initrd21/scripts/local-premount/ORDER
> > > /tmp/initrd21/scripts/local-premount/resume
> > > 
> > > No local block. :-?
> > > 
> > > find /tmp/initrd21/ -print|grep local|grep block
> > > 
> > > No output here.
> > 
> > Well, no, but there is a resume sitting there in local-premount,
> > which suggests to me¹ that you perhaps have something in
> > /etc/initramfs-tools/conf.d/resume. Has that been reported?
> > 
> > I'd also be interested to see the output from:
> > 
> > $ ls -lR /dev/disk | grep sr
> > 
> > and
> > 
> > $ grep -e sr -e sw /etc/fstab
> > 
> > The intent of that last pattern is to see the swap lines that you
> > have been commenting out.
> > 
> > Of course, we might not see anything unusual anywhere while the
> > machines are in their "fixed" state (whatever that means).
> > 
> > ¹ This is a guess, based on the fact that I also have that file in
> >   initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume,
> >   and something somewhere has to read the word "none".
> > 
> > Cheers,
> > David.
> > 
> 
> -- 
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
> 
>  John Covici wb2una
>  cov...@ccs.covici.com
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: Correction: Re: Resolved: (was: Re: OT: Auto repeat on key (not a Debian specific question))

[rhkramer]

On Friday, February 03, 2023 04:56:38 PM debian-u...@howorth.org.uk wrote:
> > In my original post, I blamed those pop up texts (warning about an
> > external link) on noscript -- they are actually coming from kmail
> > itself.  (I use an older version so it may not be a problem in more
> > up-to-date versions of kmail.)
> 
> I'm glad you wrote that explanation. I just drove myself nearly mad
> trying to find the bit I was missing in noscript that would allow it to
> do that!

Sorry for the confusion -- glad you didn't drive yourself mad ;-)

-- 
rhk 

(sig revised 20221206)

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking.  (Remember Cicero who did 
not have enough time to write a short missive.)  (That speaker might have been 
"trained" to do this by being interrupted often if he pauses.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'

Re: kernel errors

[John Covici]

For instance I just got a post from Freedom Scientific which had the
announcement in the Email and also link to the post.
On Fri, 03 Feb 2023 15:28:55 -0500,
David Wright wrote:
> 
> On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote:
> > David Wright  writes:
> > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote:
> > >> "Thomas Schmitt"  writes:
> > >> >
> > >> > (If not there, then in the /scripts/local-block directory of the 
> > >> > initrd ?)
> > >> 
> > >> I don't know how I would look in that. Is it in RAM at boot time?
> > >
> > >Choose your kernel ↓↓Pick any name 
> > >
> > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
> > > $ ls -GlgR /tmp/initrd21/main/scripts/
> > > /tmp/initrd21/main/scripts/:
> > > total 48
> > > -rw-r--r-- 1 11152 Jan 14  2021 functions
> > > drwxr-xr-x 2  4096 Feb  2 18:45 init-bottom
> > > drwxr-xr-x 2  4096 Feb  2 18:45 init-top
> > > -rw-r--r-- 1  5303 Jan 14  2021 local
> > > drwxr-xr-x 2  4096 Feb  2 18:45 local-block
> > > drwxr-xr-x 2  4096 Feb  2 18:45 local-bottom
> > > drwxr-xr-x 2  4096 Feb  2 18:45 local-premount
> > > drwxr-xr-x 2  4096 Feb  2 18:45 local-top
> > > -rw-r--r-- 1  3093 Jan 14  2021 nfs
> > >
> > > /tmp/initrd21/main/scripts/init-bottom:
> > > total 8
> > > -rw-r--r-- 1  77 Jan 23 21:46 ORDER
> > > -rwxr-xr-x 1 611 Aug  7 08:25 udev
> > >
> > > /tmp/initrd21/main/scripts/init-top:
> > > total 20
> > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER
> > > -rwxr-xr-x 1 384 Jan 14  2021 all_generic_ide
> > > -rwxr-xr-x 1 296 Jan 14  2021 blacklist
> > > -rwxr-xr-x 1 167 Jan 14  2021 keymap
> > > -rwxr-xr-x 1 568 Aug  7 08:25 udev
> > >
> > > /tmp/initrd21/main/scripts/local-block:
> > > total 8
> > > -rw-r--r-- 1  82 Jan 23 21:46 ORDER
> > > -rwxr-xr-x 1 246 Feb  1  2022 cryptroot
> > >
> > > /tmp/initrd21/main/scripts/local-bottom:
> > > total 20
> > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER
> > > -rwxr-xr-x 1 253 Feb  1  2022 cryptgnupg-sc
> > > -rwxr-xr-x 1 449 Feb  1  2022 cryptopensc
> > > -rwxr-xr-x 1 307 Feb  1  2022 cryptroot
> > > -rwxr-xr-x 1 345 Nov  2 16:46 ntfs_3g
> > >
> > > /tmp/initrd21/main/scripts/local-premount:
> > > total 12
> > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER
> > > -rwxr-xr-x 1 226 Nov  2 16:46 ntfs_3g
> > > -rwxr-xr-x 1 863 Jan 14  2021 resume
> > >
> > > /tmp/initrd21/main/scripts/local-top:
> > > total 20
> > > -rw-r--r-- 1  162 Jan 23 21:46 ORDER
> > > -rwxr-xr-x 1  757 Feb  1  2022 cryptopensc
> > > -rwxr-xr-x 1 8630 Feb  1  2022 cryptroot
> > > $ 
> > >
> > > This is a desktop with random-key swap, so no resume.
> > > There are encrypted partitions present. YMMV.
> > >
> > > Cheers,
> > > David.
> > 
> > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> > ~$ find /tmp/initrd21/ -print|grep "local-block"
> > ~$ find /tmp/initrd21/ -print|grep "local"
> > 
> > /tmp/initrd21/usr/local
> > /tmp/initrd21/usr/local/share
> > /tmp/initrd21/usr/local/share/fonts
> > /tmp/initrd21/usr/local/share/fonts/.uuid
> > /tmp/initrd21/scripts/local-bottom
> > /tmp/initrd21/scripts/local-bottom/ntfs_3g
> > /tmp/initrd21/scripts/local-bottom/ORDER
> > /tmp/initrd21/scripts/local
> > /tmp/initrd21/scripts/local-premount
> > /tmp/initrd21/scripts/local-premount/ntfs_3g
> > /tmp/initrd21/scripts/local-premount/ORDER
> > /tmp/initrd21/scripts/local-premount/resume
> > 
> > No local block. :-?
> > 
> > find /tmp/initrd21/ -print|grep local|grep block
> > 
> > No output here.
> 
> Well, no, but there is a resume sitting there in local-premount,
> which suggests to me¹ that you perhaps have something in
> /etc/initramfs-tools/conf.d/resume. Has that been reported?
> 
> I'd also be interested to see the output from:
> 
> $ ls -lR /dev/disk | grep sr
> 
> and
> 
> $ grep -e sr -e sw /etc/fstab
> 
> The intent of that last pattern is to see the swap lines that you
> have been commenting out.
> 
> Of course, we might not see anything unusual anywhere while the
> machines are in their "fixed" state (whatever that means).
> 
> ¹ This is a guess, based on the fact that I also have that file in
>   initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume,
>   and something somewhere has to read the word "none".
> 
> Cheers,
> David.
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: Correction: Re: Resolved: (was: Re: OT: Auto repeat on key (not a Debian specific question))

[debian-user]

> In my original post, I blamed those pop up texts (warning about an
> external link) on noscript -- they are actually coming from kmail
> itself.  (I use an older version so it may not be a problem in more
> up-to-date versions of kmail.)

I'm glad you wrote that explanation. I just drove myself nearly mad
trying to find the bit I was missing in noscript that would allow it to
do that!

Re: kernel errors

[David Wright]

On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote:
> David Wright  writes:
> > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote:
> >> "Thomas Schmitt"  writes:
> >> >
> >> > (If not there, then in the /scripts/local-block directory of the initrd 
> >> > ?)
> >> 
> >> I don't know how I would look in that. Is it in RAM at boot time?
> >
> >Choose your kernel ↓↓Pick any name 
> >
> > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
> > $ ls -GlgR /tmp/initrd21/main/scripts/
> > /tmp/initrd21/main/scripts/:
> > total 48
> > -rw-r--r-- 1 11152 Jan 14  2021 functions
> > drwxr-xr-x 2  4096 Feb  2 18:45 init-bottom
> > drwxr-xr-x 2  4096 Feb  2 18:45 init-top
> > -rw-r--r-- 1  5303 Jan 14  2021 local
> > drwxr-xr-x 2  4096 Feb  2 18:45 local-block
> > drwxr-xr-x 2  4096 Feb  2 18:45 local-bottom
> > drwxr-xr-x 2  4096 Feb  2 18:45 local-premount
> > drwxr-xr-x 2  4096 Feb  2 18:45 local-top
> > -rw-r--r-- 1  3093 Jan 14  2021 nfs
> >
> > /tmp/initrd21/main/scripts/init-bottom:
> > total 8
> > -rw-r--r-- 1  77 Jan 23 21:46 ORDER
> > -rwxr-xr-x 1 611 Aug  7 08:25 udev
> >
> > /tmp/initrd21/main/scripts/init-top:
> > total 20
> > -rw-r--r-- 1 314 Jan 23 21:46 ORDER
> > -rwxr-xr-x 1 384 Jan 14  2021 all_generic_ide
> > -rwxr-xr-x 1 296 Jan 14  2021 blacklist
> > -rwxr-xr-x 1 167 Jan 14  2021 keymap
> > -rwxr-xr-x 1 568 Aug  7 08:25 udev
> >
> > /tmp/initrd21/main/scripts/local-block:
> > total 8
> > -rw-r--r-- 1  82 Jan 23 21:46 ORDER
> > -rwxr-xr-x 1 246 Feb  1  2022 cryptroot
> >
> > /tmp/initrd21/main/scripts/local-bottom:
> > total 20
> > -rw-r--r-- 1 336 Jan 23 21:46 ORDER
> > -rwxr-xr-x 1 253 Feb  1  2022 cryptgnupg-sc
> > -rwxr-xr-x 1 449 Feb  1  2022 cryptopensc
> > -rwxr-xr-x 1 307 Feb  1  2022 cryptroot
> > -rwxr-xr-x 1 345 Nov  2 16:46 ntfs_3g
> >
> > /tmp/initrd21/main/scripts/local-premount:
> > total 12
> > -rw-r--r-- 1 165 Jan 23 21:46 ORDER
> > -rwxr-xr-x 1 226 Nov  2 16:46 ntfs_3g
> > -rwxr-xr-x 1 863 Jan 14  2021 resume
> >
> > /tmp/initrd21/main/scripts/local-top:
> > total 20
> > -rw-r--r-- 1  162 Jan 23 21:46 ORDER
> > -rwxr-xr-x 1  757 Feb  1  2022 cryptopensc
> > -rwxr-xr-x 1 8630 Feb  1  2022 cryptroot
> > $ 
> >
> > This is a desktop with random-key swap, so no resume.
> > There are encrypted partitions present. YMMV.
> >
> > Cheers,
> > David.
> 
> ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> ~$ find /tmp/initrd21/ -print|grep "local-block"
> ~$ find /tmp/initrd21/ -print|grep "local"
> 
> /tmp/initrd21/usr/local
> /tmp/initrd21/usr/local/share
> /tmp/initrd21/usr/local/share/fonts
> /tmp/initrd21/usr/local/share/fonts/.uuid
> /tmp/initrd21/scripts/local-bottom
> /tmp/initrd21/scripts/local-bottom/ntfs_3g
> /tmp/initrd21/scripts/local-bottom/ORDER
> /tmp/initrd21/scripts/local
> /tmp/initrd21/scripts/local-premount
> /tmp/initrd21/scripts/local-premount/ntfs_3g
> /tmp/initrd21/scripts/local-premount/ORDER
> /tmp/initrd21/scripts/local-premount/resume
> 
> No local block. :-?
> 
> find /tmp/initrd21/ -print|grep local|grep block
> 
> No output here.

Well, no, but there is a resume sitting there in local-premount,
which suggests to me¹ that you perhaps have something in
/etc/initramfs-tools/conf.d/resume. Has that been reported?

I'd also be interested to see the output from:

$ ls -lR /dev/disk | grep sr

and

$ grep -e sr -e sw /etc/fstab

The intent of that last pattern is to see the swap lines that you
have been commenting out.

Of course, we might not see anything unusual anywhere while the
machines are in their "fixed" state (whatever that means).

¹ This is a guess, based on the fact that I also have that file in
  initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume,
  and something somewhere has to read the word "none".

Cheers,
David.

Re: kernel errors

[Richmond]

"Thomas Schmitt"  writes:

> Hi,
>
> Richmond wrote:
>> No local block. :-?
>
> Maybe you can find our from where the message comes:
>
>   grep -r 'Running.*scripts.*local-block' /tmp/initrd21
>
>


grep -r 'Running.*scripts.*local-block' /tmp/initrd21
/tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg 
"Running /scripts/local-block"

This contains:

===

local_block()
{
[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
run_scripts /scripts/local-block "$@"
[ "$quiet" != "y" ] && log_end_msg
}

===


Then later this, which would explain the delays: (The video shows
"waiting for suspend/resume device")

===
# If the root device hasn't shown up yet, give it a little while
# to allow for asynchronous device discovery (e.g. USB).  We
# also need to keep invoking the local-block scripts in case
# there are devices stacked on top of those.
if ! real_dev=$(resolve_device "${dev_id}") ||
   ! get_fstype "${real_dev}" >/dev/null; then
log_begin_msg "Waiting for ${name}"

# Timeout is max(30, rootdelay) seconds (approximately)
slumber=30
if [ "${ROOTDELAY:-0}" -gt $slumber ]; then
slumber=$ROOTDELAY
fi

while true; do
sleep 1
time_elapsed="$(time_elapsed)"

local_block "${dev_id}"

# If mdadm's local-block script counts the
# number of times it is run, make sure to
# run it the expected number of times.
while true; do
if [ -f /run/count.mdadm.initrd ]; then
count="$(cat /run/count.mdadm.initrd)"
elif [ -n "${count}" ]; then
# mdadm script deleted it; put it back
count=$((count + 1))
echo "${count}" >/run/count.mdadm.initrd
else
:

Correction: Re: Resolved: (was: Re: OT: Auto repeat on key (not a Debian specific question))

[rhkramer]

In my original post, I blamed those pop up texts (warning about an external 
link) on noscript -- they are actually coming from kmail itself.  (I use an 
older version so it may not be a problem in more up-to-date versions of 
kmail.)

On Friday, February 03, 2023 12:55:02 PM rhkra...@gmail.com wrote:

-- 
rhk 

(sig revised 20221206)

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking.  (Remember Cicero who did 
not have enough time to write a short missive.)  (That speaker might have been 
"trained" to do this by being interrupted often if he pauses.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'

Resolved: (was: Re: OT: Auto repeat on key (not a Debian specific question))

[rhkramer]

(Intentionally top posting.)

Thanks to all who replied!

Yes, xev shows that  does auto repeat (outside of the Firefox 
browser).

I guess I need to look for a dumb web browser ;-)

On Friday, February 03, 2023 09:12:18 AM Nicolas George wrote:
> rhkra...@gmail.com (12023-02-03):
> > Is there a way to setup auto repeat for the  key?  Or maybe I
> > could assign  to some other key that already has auto repeat?

> Escape has already auto-repeat enabled by default. You can check it with
> xev, or even with a terminal in cooked mode (i.e. not running an
> interactive shell with line editor or a curses program).
> 
> Your problem is probably that the web browser tries to be smart. There
> is usually no solution to programs trying to be smart, alas.

-- 
rhk 

(sig revised 20221206)

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking.  (Remember Cicero who did 
not have enough time to write a short missive.)  (That speaker might have been 
"trained" to do this by being interrupted often if he pauses.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'

Re: kernel errors

[Thomas Schmitt]

Hi,

Richmond wrote:
> No local block. :-?

Maybe you can find our from where the message comes:

  grep -r 'Running.*scripts.*local-block' /tmp/initrd21


Have a nice day :)

Thomas

Re: Completely locking out a user

[The Wanderer]

On 2023-02-03 at 11:12, Greg Wooledge wrote:

> On Fri, Feb 03, 2023 at 04:27:06PM +0100, Nicolas George wrote:
> 
>> - crontabs or atjobs that download instructions from the web;
>> 
>> - .procmailrc or “|something” in .forward;
>> 
>> - probably one or two mechanisms I forgot about.

> Any process currently running under that user's UID.

Wouldn't the 'sudo -u user kill -9 -1' address that?

According to kill(1), passing '-1' as the PID parameter means to kill
"all processes except the kill process itself and init".

The examples section specifically lists 'kill -9 -1' as a way to "kill
all processes you can kill".

I read this as indicating that the given sudo command should result in
having the user kill all processes which are running as that user, which
should leave none of those processes running afterwards.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Completely locking out a user

[Greg Wooledge]

On Fri, Feb 03, 2023 at 04:27:06PM +0100, Nicolas George wrote:
> - crontabs or atjobs that download instructions from the web;
> 
> - .procmailrc or “|something” in .forward;
> 
> - probably one or two mechanisms I forgot about.

systemd --user units and timers.

Any process currently running under that user's UID.

Any files owned by that user's UID which have the setuid bit set
(land mines).

> When there is a suspicious access to a user account, we want to lock
> this account until we made sure. So “:-:” in /etc/shadow and shell to
> /bin/false, and “sudo -u user kill -9 -1”.

I don't know whether that disables ssh logins that use key auth instead
of password auth.

Completely locking out a user

[Nicolas George]

Hi.

When there is a suspicious access to a user account, we want to lock
this account until we made sure. So “:-:” in /etc/shadow and shell to
/bin/false, and “sudo -u user kill -9 -1”.

But, at least with the default configuration, these will not block:

- crontabs or atjobs that download instructions from the web;

- .procmailrc or “|something” in .forward;

- probably one or two mechanisms I forgot about.

PAM might be able to help for some of these, but not all.

I tried to search on the web, but did not find anything relevant, which
is somewhat surprising to me.

Do you know of any extensive discussion about this topic, to help me set
something up without leaving too many holes?

Regards,

-- 
  Nicolas George

Re: ASCII formatting for plain text email

[Cousin Stanley]

> Pierre Willaime posted 
> 
>
> For example I am looking for a convenient way to
> "draw" some ASCII boxes such as
>
> #
> ## some title here ##
> #

  I have a python program that does this 

$ python3 msgbox.py Skunk Bucket from Nan Tucket

 
   Skunk Bucket from Nan Tucket  
 

  Available at 

http://csphx.net/python/msgbox.py

  I'm not an EMACS user so I wouldn't know
  how to interface the program with EMACS 


--
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: initrd sizes mushroomed several months ago

[The Wanderer]

On 2023-02-03 at 09:57, Felix Miata wrote:

> The Wanderer composed on 2023-02-03 07:16 (UTC-0500):
>  
>> FTLIW, my own primary desktop has an AMD graphics card (and has since
>> before the initial Debian install), and doesn't have these large
>> initrds:
> 
> Oh, but it does
> 
>> $ lh /boot/initrd.img-*
>> -rw-r--r-- 1 root root 36M Sep  2 08:27 /boot/initrd.img-5.18.0-4-amd64
>> -rw-r--r-- 1 root root 36M Dec  9 07:53 /boot/initrd.img-6.0.0-4-amd64

...Huh. I must have lost the context of the sizes we were looking at,
for this conversation.

> Maybe you're used to seeing super-mega-bloated 88Ms on Ubuntu or
> Mint? :p

I think it more likely that I'm used to considering the sizes of initrd
etc. for a live-environment ISO, which needs to be able to work on
almost any hardware and so has basically all potentially-driver-ish
modules and all firmware that any of those drivers might need. (It's a
workplace thing.)

Sorry for the false angle, but then at least this seems to confirm the
*opposite* of what I thought it confirmed, although again I still
haven't dug all the way in to see what the actual contents of the initrd
are.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: initrd sizes mushroomed several months ago

[Felix Miata]

The Wanderer composed on 2023-02-03 07:16 (UTC-0500):
 
> FTLIW, my own primary desktop has an AMD graphics card (and has since
> before the initial Debian install), and doesn't have these large
> initrds:

Oh, but it does

> $ lh /boot/initrd.img-*
> -rw-r--r-- 1 root root 36M Sep  2 08:27 /boot/initrd.img-5.18.0-4-amd64
> -rw-r--r-- 1 root root 36M Dec  9 07:53 /boot/initrd.img-6.0.0-4-amd64

Maybe you're used to seeing super-mega-bloated 88Ms on Ubuntu or Mint? :p

# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated 
Graphics Controller
# ls -Gg /disks/deb09/boot/ini*4
-rw-r--r-- 1 18276933 Jan 10  2018 /disks/deb09/boot/initrd.img-4.9.0-5-amd64
-rw-r--r-- 1 18408183 Jun 28  2018 /disks/deb09/boot/initrd.img-4.9.0-6-amd64
-rw-r--r-- 1 18433876 Apr 16  2019 /disks/deb09/boot/initrd.img-4.9.0-8-amd64
-rw-r--r-- 1 18440856 Jul 11  2019 /disks/deb09/boot/initrd.img-4.9.0-9-amd64
-rw-r--r-- 1 18441992 Aug 13  2020 /disks/deb09/boot/initrd.img-4.9.0-11-amd64
-rw-r--r-- 1 18466332 Aug 13  2020 /disks/deb09/boot/initrd.img-4.9.0-13-amd64
# ls -Gg /disks/deb10/boot/ini*4
-rw-r--r-- 1 25922058 Apr 16  2019 /disks/deb10/boot/initrd.img-4.19.0-4-amd64
-rw-r--r-- 1 25949741 Oct 25  2019 /disks/deb10/boot/initrd.img-4.19.0-5-amd64
-rw-r--r-- 1 26082559 Mar  1  2020 /disks/deb10/boot/initrd.img-4.19.0-6-amd64
-rw-r--r-- 1 26113578 Aug 13  2020 /disks/deb10/boot/initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 26129895 Aug 13  2020 /disks/deb10/boot/initrd.img-4.19.0-10-amd64
-rw-r--r-- 1 26151861 Nov 16  2020 /disks/deb10/boot/initrd.img-4.19.0-12-amd64
-rw-r--r-- 1 26256167 Mar  4  2021 /disks/deb10/boot/initrd.img-4.19.0-14-amd64
-rw-r--r-- 1  7562145 Dec  2 22:52 /disks/deb10/boot/initrd.img-4.19.0-17-amd64
-rw-r--r-- 1  7563646 Dec  2 23:07 /disks/deb10/boot/initrd.img-4.19.0-22-amd64
# ls -Gg /disks/deb11/boot/ini*4
-rw-r--r-- 1 28466736 Jul  3  2021 /disks/deb11/boot/initrd.img-5.10.0-7-amd64
-rw-r--r-- 1  7202005 Jan  6  2022 /disks/deb11/boot/initrd.img-5.10.0-8-amd64
-rw-r--r-- 1  7204312 Jan  6  2022 /disks/deb11/boot/initrd.img-5.10.0-10-amd64
-rw-r--r-- 1  7206932 Jun 28  2022 /disks/deb11/boot/initrd.img-5.10.0-15-amd64
-rw-r--r-- 1  7229728 Dec  2 23:33 /disks/deb11/boot/initrd.img-5.10.0-16-amd64
-rw-r--r-- 1  7268292 Dec  2 23:34 /disks/deb11/boot/initrd.img-5.10.0-19-amd64
# ls -Gg /boot/ini*4
-rw-r--r-- 1  7206932 Jun 28  2022 /boot/initrd.img-5.10.0-15-amd64
-rw-r--r-- 1  8298606 Jun 28  2022 /boot/initrd.img-5.18.0-2-amd64
-rw-r--r-- 1 10839185 Dec  3 00:26 /boot/initrd.img-5.19.0-2-amd64
-rw-r--r-- 1  9761664 Dec  3 02:29 /boot/initrd.img-6.0.0-5-amd64

# lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland 
[Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM]
# ls -Gg /disks/deb08/boot/ini*4
-rw-r--r-- 1 15412555 Sep  9  2015 
/disks/deb08/boot/initrd.img-3.16.0-4-amd640804
-rw-r--r-- 1 18063287 Jul  7  2018 
/disks/deb08/boot/initrd.img-4.9.0-0.bpo.3-amd64
-rw-r--r-- 1 18306518 Aug 31  2018 
/disks/deb08/boot/initrd.img-4.9.0-0.bpo.6-amd64
# ls -Gg /disks/deb09/boot/ini*4
-rw-r--r-- 1 27733865 Jun 19  2021 
/disks/deb09/boot/initrd.img-4.19.0-0.bpo.6-amd64
-rw-r--r-- 1 27691107 Jun 19  2021 
/disks/deb09/boot/initrd.img-4.19.0-0.bpo.16-amd64
# ls -Gg /disks/deb10/boot/ini*4
-rw-r--r-- 1 23241848 Dec 14  2018 /disks/deb10/boot/initrd.img-4.18.0-3-amd64
-rw-r--r-- 1 23674941 Jan 16  2019 /disks/deb10/boot/initrd.img-4.19.0-1-amd64
-rw-r--r-- 1 25353945 Mar 21  2019 /disks/deb10/boot/initrd.img-4.19.0-2-amd64
-rw-r--r-- 1 25867391 Jul 24  2019 /disks/deb10/boot/initrd.img-4.19.0-5-amd64
-rw-r--r-- 1  7557702 Dec 27 02:55 /disks/deb10/boot/initrd.img-4.19.0-6-amd64
-rw-r--r-- 1  7559906 Dec 27 02:54 /disks/deb10/boot/initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 26131451 Aug  1  2020 /disks/deb10/boot/initrd.img-4.19.0-10-amd64
-rw-r--r-- 1 26143689 Nov 19  2020 /disks/deb10/boot/initrd.img-4.19.0-11-amd64
-rw-r--r-- 1  7549154 Jun 19  2021 /disks/deb10/boot/initrd.img-4.19.0-16-amd64
-rw-r--r-- 1  7558701 Jan  8  2022 /disks/deb10/boot/initrd.img-4.19.0-18-amd64
-rw-r--r-- 1  7563600 Nov  5 19:12 /disks/deb10/boot/initrd.img-4.19.0-21-amd64
-rw-r--r-- 1  7563946 Dec 27 03:02 /disks/deb10/boot/initrd.img-4.19.0-23-amd64
# ls -Gg /disks/deb11/boot/ini*4
-rw-r--r-- 1 7198759 Jun 19  2021 /disks/deb11/boot/initrd.img-5.10.0-7-amd64
-rw-r--r-- 1 7201221 Jan  9  2022 /disks/deb11/boot/initrd.img-5.10.0-8-amd64
-rw-r--r-- 1 7204241 Jan  9  2022 /disks/deb11/boot/initrd.img-5.10.0-10-amd64
-rw-r--r-- 1 7204191 Mar 11  2022 /disks/deb11/boot/initrd.img-5.10.0-12-amd64
-rw-r--r-- 1 7267715 Nov  5 23:35 /disks/deb11/boot/initrd.img-5.10.0-18-amd64
-rw-r--r-- 1 7267709 Dec 27 03:25 /disks/deb11/boot/initrd.img-5.10.0-20-amd64
# ls -Gg /boot/ini*4
-rw-r--r-- 1  7555717 Apr 20  2022 /boot/initrd.img-5.16.0-6-amd64
-rw-r--r-- 1  8669504 Aug  4  2022 /boot/initrd.img-5.18.0-3-amd64
-rw-r--r-- 1 34590685 Sep 13 01:26 /boot/initrd.img-5.1

Re: OT: Auto repeat on key (not a Debian specific question)

[tomas]

On Fri, Feb 03, 2023 at 03:12:18PM +0100, Nicolas George wrote:

[...]

> Your problem is probably that the web browser tries to be smart. There
> is usually no solution to programs trying to be smart, alas.

How true :-/

I'd one-up that and add: "there is no solution to web browsers".

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: OT: Auto repeat on key (not a Debian specific question)

[Nicolas George]

rhkra...@gmail.com (12023-02-03):
> Is there a way to setup auto repeat for the  key?  Or maybe I could 
> assign  to some other key that already has auto repeat?

Yes, you have to type the following command: "".

Escape has already auto-repeat enabled by default. You can check it with
xev, or even with a terminal in cooked mode (i.e. not running an
interactive shell with line editor or a curses program).

Your problem is probably that the web browser tries to be smart. There
is usually no solution to programs trying to be smart, alas.

Regards,

-- 
  Nicolas George

OT: Auto repeat on key (not a Debian specific question)

[rhkramer]

Is there a way to setup auto repeat for the  key?  Or maybe I could 
assign  to some other key that already has auto repeat?

Background / motivation: I get emails that have a lot of external references, 
and NoScript pops up a warning text box for each one which I must close (kmail 
is frozen until all of them are closed).

I can do things like mouse click on the Cancel or the X in the text box, but I 
have to do that for each text box, and:
 
* they are not aligned or sized equally, so sometimes I have to move the 
mouse slightly to keep hitting the target (Cancel or the X)

   * if I hit the X or cancel one or more too many times, and there happpens 
to be a link in the email underneath the text box, I open that link (one or 
more times)

Using  is nicer because:

   * I don't have to align the mouse at all

   * extra presses of Escape don't do anything, or more specifically, don't 
open any link that happens to be behind the text box.

So, it would be nice to be able to just press and hold the  key until 
all of the text boxes are closed (rather than having to press it multiple 
times, once for each open text box).

Thanks for any suggestions!




-- 
rhk 

(sig revised 20221206)

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking.  (Remember Cicero who did 
not have enough time to write a short missive.)  (That speaker might have been 
"trained" to do this by being interrupted often if he pauses.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'

Re: initrd sizes mushroomed several months ago

[Thomas Schmitt]

Hi,

David Wright wrote:
> > >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64

Felix Miata wrote:
> > Is that a typo? I copied & pasted that and the screen loaded binary
> > gibberish.

Greg Wooledge wrote:
> GNU cpio(1) says that -t implies -i, so it should work on Debian.

Probably the initrd is compressed and the binary stuff was the error
messages of cpio, which are not terminal-safe.

If

  file /boot/initrd.img-6.0.0-6-amd64

says

  ... gzip compressed data ...

then the command to list the file tree would be

  gunzip 

Re: kernel errors

[Richmond]

David Wright  writes:

> On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote:
>> "Thomas Schmitt"  writes:
>> >
>> > (If not there, then in the /scripts/local-block directory of the initrd ?)
>> 
>> I don't know how I would look in that. Is it in RAM at boot time?
>
>Choose your kernel ↓↓Pick any name 
>
> $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
> cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
> $ ls -GlgR /tmp/initrd21/main/scripts/
> /tmp/initrd21/main/scripts/:
> total 48
> -rw-r--r-- 1 11152 Jan 14  2021 functions
> drwxr-xr-x 2  4096 Feb  2 18:45 init-bottom
> drwxr-xr-x 2  4096 Feb  2 18:45 init-top
> -rw-r--r-- 1  5303 Jan 14  2021 local
> drwxr-xr-x 2  4096 Feb  2 18:45 local-block
> drwxr-xr-x 2  4096 Feb  2 18:45 local-bottom
> drwxr-xr-x 2  4096 Feb  2 18:45 local-premount
> drwxr-xr-x 2  4096 Feb  2 18:45 local-top
> -rw-r--r-- 1  3093 Jan 14  2021 nfs
>
> /tmp/initrd21/main/scripts/init-bottom:
> total 8
> -rw-r--r-- 1  77 Jan 23 21:46 ORDER
> -rwxr-xr-x 1 611 Aug  7 08:25 udev
>
> /tmp/initrd21/main/scripts/init-top:
> total 20
> -rw-r--r-- 1 314 Jan 23 21:46 ORDER
> -rwxr-xr-x 1 384 Jan 14  2021 all_generic_ide
> -rwxr-xr-x 1 296 Jan 14  2021 blacklist
> -rwxr-xr-x 1 167 Jan 14  2021 keymap
> -rwxr-xr-x 1 568 Aug  7 08:25 udev
>
> /tmp/initrd21/main/scripts/local-block:
> total 8
> -rw-r--r-- 1  82 Jan 23 21:46 ORDER
> -rwxr-xr-x 1 246 Feb  1  2022 cryptroot
>
> /tmp/initrd21/main/scripts/local-bottom:
> total 20
> -rw-r--r-- 1 336 Jan 23 21:46 ORDER
> -rwxr-xr-x 1 253 Feb  1  2022 cryptgnupg-sc
> -rwxr-xr-x 1 449 Feb  1  2022 cryptopensc
> -rwxr-xr-x 1 307 Feb  1  2022 cryptroot
> -rwxr-xr-x 1 345 Nov  2 16:46 ntfs_3g
>
> /tmp/initrd21/main/scripts/local-premount:
> total 12
> -rw-r--r-- 1 165 Jan 23 21:46 ORDER
> -rwxr-xr-x 1 226 Nov  2 16:46 ntfs_3g
> -rwxr-xr-x 1 863 Jan 14  2021 resume
>
> /tmp/initrd21/main/scripts/local-top:
> total 20
> -rw-r--r-- 1  162 Jan 23 21:46 ORDER
> -rwxr-xr-x 1  757 Feb  1  2022 cryptopensc
> -rwxr-xr-x 1 8630 Feb  1  2022 cryptroot
> $ 
>
> This is a desktop with random-key swap, so no resume.
> There are encrypted partitions present. YMMV.
>
> Cheers,
> David.

~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
~$ find /tmp/initrd21/ -print|grep "local-block"
~$ find /tmp/initrd21/ -print|grep "local"

/tmp/initrd21/usr/local
/tmp/initrd21/usr/local/share
/tmp/initrd21/usr/local/share/fonts
/tmp/initrd21/usr/local/share/fonts/.uuid
/tmp/initrd21/scripts/local-bottom
/tmp/initrd21/scripts/local-bottom/ntfs_3g
/tmp/initrd21/scripts/local-bottom/ORDER
/tmp/initrd21/scripts/local
/tmp/initrd21/scripts/local-premount
/tmp/initrd21/scripts/local-premount/ntfs_3g
/tmp/initrd21/scripts/local-premount/ORDER
/tmp/initrd21/scripts/local-premount/resume

No local block. :-?

find /tmp/initrd21/ -print|grep local|grep block

No output here.

Re: kernel errors

[Richmond]

Michel Verdier  writes:

> Le 2 février 2023 Richmond a écrit :
>
>> There is no such file. Earlier I ran this:
>>
>> find / -print|grep "scripts/local-block"
>>
>> and it found nothing, which led me to believe it is some temporary file...
>>>
>>> (If not there, then in the /scripts/local-block directory of the initrd ?)
>
> its part of initramfs-tools to build initrd when you use cryptsetup,
> mdadm, etc
>
> $ locate local-block
> /usr/share/initramfs-tools/scripts/local-block
> /usr/share/initramfs-tools/scripts/local-block/cryptroot
>
> $ apt-file search /usr/share/initramfs-tools/scripts/local-block
> cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot
> lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2
> mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm
> osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl

sudo locate local-block

produced no output.

sudo apt-file search /usr/share/initramfs-tools/scripts/local-block
cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot
lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2
mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm
osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl

I don't have an encrypted file system.

sudo aptitude show cryptsetup-initramfs|grep State
State: not installed
sudo aptitude show lvm2|grep State
State: not installed
sudo aptitude show mdadm|grep State
State: not installed
sudo aptitude show osk-sdl|grep State
State: not installed

Re: initrd sizes mushroomed several months ago

[Greg Wooledge]

On Fri, Feb 03, 2023 at 01:45:33AM -0500, Felix Miata wrote:
> David Wright composed on 2023-02-01 22:39 (UTC-0600):
> >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
> 
> Is that a typo? I copied & pasted that and the screen loaded binary gibberish.

GNU cpio(1) says that -t implies -i, so it should work on Debian.

unicorn:~$ cpio -t < /boot/initrd.img-5.10.0-21-amd64 
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
9794 blocks

Not sure how *useful* it is, since it only lists the TOC from the first
cpio archive in the initrd image, and there may be multiple.  But it
should give a human-readable table of contents.  If it doesn't, then
either you're not using GNU cpio (try cpio -it for portability), or
your archive may be corrupt.

Re: initrd sizes mushroomed several months ago

[The Wanderer]

On 2023-02-03 at 01:45, Felix Miata wrote:

> David Wright composed on 2023-02-01 22:39 (UTC-0600):


>> FTR, I reinstalled 5.10.0-21-amd64 on another machine with MODULES=dep
>> and for comparison (initrd only):
>  
>> $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/unpacked10-21
>> cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
>> $ du -sh /tmp/unpacked10-21/main/lib/modules/5.10.0-21-amd64/kernel/   # 
>> modules
>> 5.6M/tmp/unpacked10-21/main/lib/modules/5.10.0-21-amd64/kernel/
>> $ du -sh /tmp/unpacked10-21/main/lib/firmware
>> du: cannot access '/tmp/unpacked10-21/main/lib/firmware': No such file or 
>> directory
>> $ 
>  
>> … so zero firmware is required to boot this machine (and the
>> same is true for my production machine).
> 
> That's how it is here on PCs with Intel or NVidia graphics, but apparently
> not so AMD/ATI, going by what's now being packed into initrds.

FTLIW, my own primary desktop has an AMD graphics card (and has since
before the initial Debian install), and doesn't have these large
initrds:

$ lh /boot/initrd.img-*
-rw-r--r-- 1 root root 36M Sep  2 08:27 /boot/initrd.img-5.18.0-4-amd64
-rw-r--r-- 1 root root 36M Dec  9 07:53 /boot/initrd.img-6.0.0-4-amd64

I haven't dug into them any deeper than this, but it may be worth having
the confirmation that it's not something common to all machines with AMD
graphics cards.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Syslog/Rsyslog/Systemctl issue

[debian-user]

> I've tried they sent me back here :/
> 
> Le 02/02/2023 à 17:06, debian-u...@howorth.org.uk a écrit :
> >> On 01/02/2023 21:48, Freyja wrote:  
> >>> Instead of just creating the folders, I've reinstalled some
> >>> packages:  
> >> I would consider complete reinstall (install from scratch). It may
> >> be faster even for a person having experience with systemd
> >> troubleshooting. Something low level is affected.
> >>
> >> However I find the problem interesting: how to get logs if journald
> >> can not start.  
> > Maybe it's worth asking on the systemd-devel mailing list?

You asked about something slightly different. Given what we know now it
might be worth asking again, specifically about this question of how to
diagnose journald not starting given there are no logs as a consequence.

Re: Syslog/Rsyslog/Systemctl issue

[Freyja]

I need to look deeper in your recommendations, I will try them as soon 
as I can.


Le 02/02/2023 à 17:28, songbird a écrit :

debian-u...@howorth.org.uk  wrote:
...

Maybe it's worth asking on the systemd-devel mailing list?

   did you reinstall rsyslog?  did you purge the configs for it
(back them up if needed)?  when i remove a package i have been
having troubles with i often purge it instead of uninstalling
it.

   you may need to reboot after reinstalling systemd and/or
rsyslog or any other parts.

   see my other note about what your /var/log/journal directory
should look like if you have that set up right for permissions.

   back up the files if you want to keep the old ones.  i'm not
sure the subdirectory in /var/log/journal will be recreated or
not but i think it will if it isn't there, if it is there and
empty the journald service should set up a new one.  note this
depends upon what setting you've got in your config files for
systemd.  i'm not sure if you've altered systemd configuration
files or not.

   note that reinstalling without purging will not necessarily
reset your configuration files.

   rsyslog files should show up in /var/log or where ever you
put them.

   these are things i can think of trying.  sorry i've gotta
get going and won't be able to help more until later tonight.
hope you get it figured out before then.  :)


   songbird

Re: Syslog/Rsyslog/Systemctl issue

[Freyja]

I've tried they sent me back here :/

Le 02/02/2023 à 17:06, debian-u...@howorth.org.uk a écrit :

On 01/02/2023 21:48, Freyja wrote:

Instead of just creating the folders, I've reinstalled some
packages:

I would consider complete reinstall (install from scratch). It may be
faster even for a person having experience with systemd
troubleshooting. Something low level is affected.

However I find the problem interesting: how to get logs if journald
can not start.

Maybe it's worth asking on the systemd-devel mailing list?

Re: Syslog/Rsyslog/Systemctl issue

[Freyja]

Hi,

Both are installed but when I try to remove them it want to remove too 
many packages :/


--
❯ dpkg -l |grep selinux
ii  libselinux1:amd64 
3.1-3  amd64 SELinux 
runtime shared libraries

--

--
❯ apt-get remove libselinux1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  debugedit discover-data docutils-doc efibootmgr fonts-lyx 
fonts-urw-base35 geoip-database-extra gsasl-common i965-va-driver 
ienglish-common intel-media-va-driver jo jq liba52-0.7.4 libaacs0
  libaec0 libann0 libao-common libao4 libaom0 libaom3 libapr1 
libarchive13 libaribb24-0 libarmadillo10 libarpack2 libaspell15 
libassuan0 libasyncns0 libatk1.0-data libaudio2 libauparse0
  libavahi-client3 libavahi-common-data libavahi-common3 libavahi-core7 
libavc1394-0 libavresample4 libavutil56 libbcg729-0 libbfio1 libblas3 
libboost-thread1.74.0 libbpf0 libbs2b0 libbsd-dev
  libc-ares2 libc-dev-bin libcaca0 libcbor0 libcdio-cdda2 
libcdio-paranoia2 libcdio19 libcdt5 libcgraph6 libcharls2 libcjson1 
libcodec2-0.9 libconfig-inifiles-perl libcrypt-dev libdaemon0
  libdatrie1 libdav1d4 libdav1d5 libdavs2-16 libdbi1 libdc1394-25 
libdca0 libde265-0 libdiscover2 libdjvulibre-text libdjvulibre21 
libdouble-conversion3 libdrm-amdgpu1 libdrm-common libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libdv4 libdvdnav4 libdw1 
libebml5 libecap3 libedit2 libefiboot1 libefivar1 libegl-mesa0 libegl1 
libenca0 libepoxy0 libepsilon1 libev4 libevent-2.1-7
  libevent-core-2.1-7 libevent-pthreads-2.1-7 libewf2 libexiv2-14 
libexttextcat-2.0-0 libexttextcat-data libfaac0 libfcgi-bin libfcgi0ldbl 
libfdk-aac2 libffi-dev libfftw3-double3 libflite1 libfmt7
  libfontenc1 libfreexl1 libfsplib0 libfstrm0 libfuse2 libfyba0 libgbm1 
libgc1 libgdbm-compat4 libgdbm6 libgdk-pixbuf2.0-common libgeos-3.9.0 
libgeos-c1v5 libgfortran5 libgl1 libgl1-mesa-dri
  libgl1-mesa-glx libglapi-mesa libglib2.0-data libglvnd0 libglx-mesa0 
libglx0 libgme0 libgraphite2-3 libgs9-common libgtk2.0-common libgvpr2 
libhdf4-0-alt libhdf5-103-1 libhdf5-hl-100 libheif1
  libhiredis0.14 libhttp-parser2.9 libiec61883-0 libigdgmm11 
libijs-0.35 libilbc3 libilmbase25 libimagequant0 libinih1 
libjack-jackd2-0 libjargs-java libjbig2dec0 libjq1 libjs-bootstrap4
  libjs-codemirror libjs-jquery libjs-jquery-mousewheel 
libjs-jquery-timepicker libjs-jquery-ui libjs-openlayers libjs-popper.js 
libjs-sphinxdoc libjs-underscore libjson-c5 libjson-glib-1.0-common
  libjsoncpp24 libjxr-tools libjxr0 libk5crypto3 libkmlbase1 libkmldom1 
libkmlengine1 libkrb5support0 libksba8 libkvazaar6 liblab-gamut1 
liblapack3 liblavjpeg-2.2-0 liblbfgsb0 liblcms2-2
  libldap-2.4-2 libldap-common libldb2 liblensfun-data-v1 liblept5 
liblilv-0-0 liblinear4 liblirc-client0 libllvm11 liblmdb0 liblua5.1-0 
liblua5.2-0 liblua5.3-0 liblua5.4-0 libluajit-5.1-2
  libluajit-5.1-common liblz1 libmad0 libmarkdown2 libmatroska7 
libmaxminddb0 libmbedcrypto3 libmbedtls12 libmbedx509-0 libmd-dev 
libmemcached11 libmemcachedutil2 libmfx1 libmilter1.0.1
  libminiupnpc17 libminizip1 libmjpegutils-2.2-0 libmms0 libmng2 
libmono-btls-interface4.0-cil libmp3lame0 libmpdec2 libmpdec3 libmpeg2-4 
libmpeg2encpp-2.2-0 libmpg123-0 libmplex2-2.2-0 libmysofa1
  libnatpmp1 libnftables1 libnghttp2-14 libnorm1 libnpth0 libnspr4 
libnss3 libntlm0 libnuma1 libnutscan1 libobjc4 libodbc1 libogdi4.1 
libonig5 libopenal-data libopenal1 libopendbx1
  libopendbx1-sqlite3 libopenexr25 libopenh264-6 libopenjp2-7 
libopenmpt0 libopts25 libosp5 libossp-uuid16 libostyle1c2 libpathplan4 
libpciaccess0 libpcre2-16-0 libpcre2-posix2 libpcsclite1
  libpgm-5.3-0 libpixman-1-0 libpkgconf3 libpostproc55 libprocps8 
libprotobuf-c1 libproxy1v5 libpugixml1v5 libpython2.7-minimal 
libqhull8.0 libraw1394-11 librbl1 libre2-9 librhash0 librist4 librpm9
  librpmbuild9 librpmio9 librpmsign9 librtmp1 librttopo1 librubberband2 
libsamplerate0 libsasl2-2 libsasl2-modules-db libsbc1 libsecret-common 
libsensors-config libsensors5 libserd-0-0 libshine3
  libsmi2ldbl libsndio7.0 libsnmp-base libsodium23 libsord-0-0 libsoxr0 
libspandsp2 libspeex1 libspeexdsp1 libsqlite0 libsratom-0-0 
libsrt1.4-gnutls libssh2-1 libstemmer0d libsuperlu5 libsvtav1enc1
  libswresample3 libswscale5 libsz2 libtalloc2 libtesseract4 libtevent0 
libtfm1 libthai-data libthai0 libtinyxml2-8 libtirpc-common 
libtokyocabinet9 libtre5 libtwolame0 libudfread0 libunbound8
  libupsclient4 liburing1 liburiparser1 libusb-0.1-4 libutf8proc2 
libuv1 libva-drm2 libva-x11-2 libva2 libvbr2 libvdpau-va-gl1 libvdpau1 
libvhdi1 libvidstab1.1 libvmaf1 libvmdk1 libvo-amrwbenc0
  libvorbisidec1 libvpx6 libvte-2.91-common libvulkan1 
libwayland-client0 libwayland-cursor0 libwayland-egl1 libwayland-server0 
libwebpdemux2 libwebpmux3 libwireshark-data libwmf0.2-7 libx264-164
  libx265-192 libx265-199 libxavs2-13 libxcb-dri2-0 libxcb-dri3-0 
libxcb-glx0 lib