Re: Orphaned Inode Problem

[Henning Follmann]

On Wed, Feb 21, 2024 at 05:15:55PM +0100, Jörg-Volker Peetz wrote:
> Henning Follmann wrote on 21/02/2024 14:16:
> > On Wed, Feb 21, 2024 at 12:00:17PM +0100, Jörg-Volker Peetz wrote:
> 
> > > Somewhere I read, for maintainance of an SSD all it's cells should be read
> > > from time to time like this
> > > 
> > > sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress
> > 
> > Where did you read that? That seems like a huge waste of time.
> > 
> As far as I remember, the idea behind this suggestion is to help the SSD
> firmware detect bad blocks or cells early on and to mask them out. Of
> course, a good firmware with it's wear leveling algorithm
> (https://en.wikipedia.org/wiki/Wear_leveling) should do this by itself.
> 
You didn't answer where you read that. I would be interested in that. I do
not claim to be an expert on this and I would like to understand it better.

-H


-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: Thank you Debian

[Andre Rodier]

On 21/02/2024 22:58, Jeffrey Walton wrote:

On Wed, Feb 21, 2024 at 5:47 PM Andre Rodier  wrote:

[...]

A few years ago, I created a set of Ansible scripts to code what I was
already doing manually, so I could rebuild my server from scratch.

The solution is on GitHub, and while there was already a plethora of
existing solutions, none of them implemented everything I wanted and
needed. It was apparently challenging:

1. A DNS server included, with DNSSEC implemented, and SSHFP.
2. Everything from Debian packages, so upgrade can be automatic.
3. No git clone and no zip download for any service.
4. The usual LetsEncrypt, but also the extra like CAA, DANE, etc...
5. All services should be running under AppArmor.
6. No PHP, no RoundCube, NextCloud, OwnCloud, etc please.
7. Jabber server, with c2s and s2s.
8. CardDAV and CalDAV server.
9. WebDAV server.
10. LDAP for authentication, not a MySQL database.
11. IPv6 support

The points #2 and #3 are particularly interesting. I seriously cannot
understand why or how people could trust a server exposed on internet,
without automatic updates from a serious community like Debian. Are they
suppose to receive alerts from GitHub releases to manually download them
as they happen ? How can this be done while they are on vacation ?
Excuse my naive question, if it is, please.

I precise, I am using unattended upgrades, and automatic reboot, and
never had any issue, thanks to Debian packages quality. I just sometimes
receive a nice email saying the server rebooted.

This wouldn't have been possible with the Debian community, so, again,
thank you for that.

We have been happy with this solution, for myself, and a few friends and
family members, but I would like the opinion from the security experts
on this list.

- What is the best approach to check if there is any vulnerability in
the packages configuration ?
- Is there any service that could audit the deployment code or the
configuration files ?


You will probably need to stitch together several different solutions,
based on the context. For example, use an Ansible Linter for your
Ansible scripts, .

Jeff



Thanks, Jeff.

Yes, Ansible lint is configured as a git hook in the distribution.

Kind regards,
André

Re: How to find system configuration vulnerabilities; was: Thank you Debian

[Andre Rodier]

On 21/02/2024 21:08, Michael Kjörling wrote:

On 21 Feb 2024 19:03 +, from an...@rodier.me (Andre Rodier):

- What is the best approach to check if there is any vulnerability in the
packages configuration ?
- Is there any service that could audit the deployment code or the
configuration files ?


My understanding is that both Lynis and Vuls are popular for
already-installed systems. If you have your configuration packaged as
Ansible scripts, then deploying that onto a disposable VM based on a
minimal Debian installation should be a reasonably practical way of
auditing the deployment process itself for vulnerabilities.
Thanks, I will try this approach, this is a good idea. Yes, using a VM 
is easy, that's the approach I used for the development.



A web search for something like "linux local vulnerability scanner"
will provide you with additional leads.
I tried the debsecan package, which is good as well. I will see if I can 
make this more readable and integrated with the distribution.



Note that any automated tool will use some kind of heuristics so (a)
may find things that are not actually vulnerabilities in your setup,
and (b) might not find something which _is_ a vulnerability in your
setup

Of course, as usual with this kind of tools.

Thanks for your insights.

André

Re: Orphaned Inode Problem

[tomas]

On Wed, Feb 21, 2024 at 05:15:55PM +0100, Jörg-Volker Peetz wrote:
> Henning Follmann wrote on 21/02/2024 14:16:
> > On Wed, Feb 21, 2024 at 12:00:17PM +0100, Jörg-Volker Peetz wrote:
> 
> > > Somewhere I read, for maintainance of an SSD all it's cells should be read
> > > from time to time like this
> > > 
> > > sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress
> > 
> > Where did you read that? That seems like a huge waste of time.
> > 
> As far as I remember, the idea behind this suggestion is to help the SSD
> firmware detect bad blocks or cells early on and to mask them out. Of
> course, a good firmware with it's wear leveling algorithm
> (https://en.wikipedia.org/wiki/Wear_leveling) should do this by itself.

Actually... you only have to read regularly those blocks which are
known to have stuff in them. The file system should know which those
are, that's its job.

And then, this is a backup, at least in my book, and yes, you should
do that regularly, even on spinning rust ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Orphaned Inode Problem

[gene heskett]

On 2/21/24 08:17, Henning Follmann wrote:

On Wed, Feb 21, 2024 at 12:00:17PM +0100, Jörg-Volker Peetz wrote:

Hi,

did you take a look at the smartctl output?

Somewhere I read, for maintainance of an SSD all it's cells should be read
from time to time like this

sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress


Where did you read that? That seems like a huge waste of time.



where device is something like sda or nvme0n1, especially if it was switched
off for a longer period. At least, it shows the current read performance of
the device.
An SSD should regularly be trimmed, if in use. This is to assist it's wear
leveling process.


If you should manually kick off trim is a hotly debated issue.
It mainly depends on the use of the drive.
In most cases however do not alter any of how the system was install by
your friendly installer.


That actually might be a good idea, as it will force a read of 
everything, which will trigger a fixit it for any cell that does read 
right on the first try.


OTOH, my pi's only get powered down for maintenance, so they've got lots 
of spare time to do their thing when you are not looking, And i've not 
lost a pi u-sd in quite a few years. So even though the system, with all 
the trash collected over a decade might amount to 10G's, they have 64G 
to play with. I must be doing something right.

What's your opinion?

How much time do you have :)


-H





Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: unsuscribe

[Byunghee HWANG]

Hellow Moisés,

On Wed, 2024-02-21 at 20:28 -0500, Moises Alberto Lindo Gutarra wrote:
> 
> unsuscribe
> -- 

Just see here:
https://www.debian.org/MailingLists/index.en.html#subunsub


Thanks, Byunghee from South Korea


signature.asc
Description: This is a digitally signed message part

unsuscribe

[Moises Alberto Lindo Gutarra]

unsuscribe
-- 
Atte.
Moisés Alberto Lindo Gutarra
Asesor - Desarrollador Java / Open Source
Linux Registered User #431131 - http://linuxcounter.net/
Cel: (511) 995081720 - Rpm: *548913
EMail: mli...@gmail.com

Re: Thank you Debian

[Jeffrey Walton]

On Wed, Feb 21, 2024 at 5:47 PM Andre Rodier  wrote:
> [...]
>
> A few years ago, I created a set of Ansible scripts to code what I was
> already doing manually, so I could rebuild my server from scratch.
>
> The solution is on GitHub, and while there was already a plethora of
> existing solutions, none of them implemented everything I wanted and
> needed. It was apparently challenging:
>
> 1. A DNS server included, with DNSSEC implemented, and SSHFP.
> 2. Everything from Debian packages, so upgrade can be automatic.
> 3. No git clone and no zip download for any service.
> 4. The usual LetsEncrypt, but also the extra like CAA, DANE, etc...
> 5. All services should be running under AppArmor.
> 6. No PHP, no RoundCube, NextCloud, OwnCloud, etc please.
> 7. Jabber server, with c2s and s2s.
> 8. CardDAV and CalDAV server.
> 9. WebDAV server.
> 10. LDAP for authentication, not a MySQL database.
> 11. IPv6 support
>
> The points #2 and #3 are particularly interesting. I seriously cannot
> understand why or how people could trust a server exposed on internet,
> without automatic updates from a serious community like Debian. Are they
> suppose to receive alerts from GitHub releases to manually download them
> as they happen ? How can this be done while they are on vacation ?
> Excuse my naive question, if it is, please.
>
> I precise, I am using unattended upgrades, and automatic reboot, and
> never had any issue, thanks to Debian packages quality. I just sometimes
> receive a nice email saying the server rebooted.
>
> This wouldn't have been possible with the Debian community, so, again,
> thank you for that.
>
> We have been happy with this solution, for myself, and a few friends and
> family members, but I would like the opinion from the security experts
> on this list.
>
> - What is the best approach to check if there is any vulnerability in
> the packages configuration ?
> - Is there any service that could audit the deployment code or the
> configuration files ?

You will probably need to stitch together several different solutions,
based on the context. For example, use an Ansible Linter for your
Ansible scripts, .

Jeff

Re: How can we change the keyboard layout?

[hw]

On Wed, 2024-02-21 at 12:55 -0600, David Wright wrote:
> On Tue 13 Feb 2024 at 08:09:40 (+0100), hw wrote:
> > On Sun, 2024-02-11 at 10:35 -0600, David Wright wrote:
> > > On Wed 07 Feb 2024 at 06:58:39 (+0100), hw wrote:
> > > > [...]
> > I'd use multiple keyboards if I had to do that and just change between
> > keyboards.
> 
> Do it if you like. That's what I have on my computer in the basement:
> a GB-layout M keyboard and a US-layout Microsoft Pro.

And is their layout identical?  If isn't, do all the keys on both
keyboards what you expect them to do?

> In my case, the layout difference is incidental: the M sits on the
> table, the other sits on a shelf, for standing use. (There are two
> screens, set to mirroring.)
> 
> > > > > My 2014 keyboard appears to identify itself correctly as a K520. My
> > > > > old IBM M says it's an "AT Translated Set 2 keyboard", which seems
> > > > > reasonable for a keyboard dating from 1988.
> > > > 
> > > > I can see USB keyboards identifying themselves, but keyboards with
> > > > PS/2 or DIN connectors?  How does your keyboard from 1988 connect?
> > > 
> > > PS/2. IIRC it came with a genuine IBM PS/2 computer.
> > 
> > Where does it show up?  Where does the information originate from?
> > Perhaps the information is merely an assumption some of the involved
> > the software makes and not something the keyboard tells it.
> 
> I get it from xinput, which I assume gets it from udev, as the ID's
> description string occurs in /lib/udev/hwdb.d/60-keyboard.hwdb.

Does that mean it doesn't come form the keyboard itself?

> > > > 10% more keys isn't considerably more.  Can you show me a keyboard
> > > > with 122 keys that has all keys usable and unique rather than sending
> > > > key combinations instead?
> > > 
> > > That would be difficult:
> 
> I think some etiquette might be appropriate. You shouldn't quote half
> a sentence just to change the meaning to suit yourself. I wrote:

I have no intention of doing something like that.

>  "That would be difficult: I've never had a 122 key keyboard, or
>   even seen one. You have one. In terms of xev output, are there
>   duplicate keys?"
> 
> That difficulty has nothing to do with the one you wrote about here:
> 
> > That's what I've been saying :)  Years ago I read an article about
> > keyboards and it said that due to hardware restrictions, only so many
> > keys can be handled so that keyboards with 122 keys don't really work:
> > Either the controller in the keyboard key combinations, or the keys do
> > nothing.  Apparently such keyboards seem to come from terminals that
> > could use all the keys while PC hardware can not.
> 
> I've not heard of that. The keyboard files in the kernel source and in
> udev seem to have far more keys available than 122.

Perhaps what I have been reading wasn't true, or things have changed
and it is now possible to have more keys.  It was sufficiently long
ago for things to have been changed.

But then, how many manufacturers nowadays make keyboards with 122 keys
like these terminal keyboards for PCs?  The only one I know of is
Unicomp, and they have adjusted the keyboard controller to deliver
substitutes for keys PCs don't know (or usually don't have) in order
to make the keyobard usable for PCs.

Why would the kernel developers make provisions for keyboards that
don't exist (for PCs)?

> > > I've never had a 122 key keyboard, or even seen one. You have
> > > one. In terms of xev output, are there duplicate keys? Which ones,
> > > and how does xev identify them?
> > 
> > I don't know if there are duplicate keys.  I didn't try out all the
> > key to find any, and I haven't noticed any.
> 
> It can't take that long to press 122 keys in turn, can it.
> 
> > When I press F18, for example, wev says: [ … lengthy output snipped … ]
> 
> Does wl signify wayland output? I can't decode it. However, you appear
> to have your NumLock on, which could change things considerably.

You mean wev?  What are trying to decode?

I usually NumLock enabled; if it's ever turned off, it's usually only
by accidident.

> > For the backtab key it says:
> 
> Looking at 911QQZnUFrL.jpg, I don't know which key that is. But again,
> NumLock appears to be on.

It's the key to the left to the Delete key which is below the key
labeled Dup/Insert.

> > These keys don't exist on PCs, so the keyboards converts them.  IIRC,
> > Unicomp used to have a version that was suited for terminals like IBM
> > made them, i. e. with all 122 keys working and not converted.
> 
> That's odd—911QQZnUFrL.jpg shows function keys as high as F24.
> Why would it not be able to send a keycode for F18?

It's because PCs have no more than 12 function keys.

Maybe they can have more nowadays, but where do you find a keyboard
for PCs that has more than 12 "true" function keys?

> > > The keyboards I have access to all send usable keycodes, even where
> > > the engravings are the same, eg, Return/36 and KP_Enter/104 are both
> > > engraved with "Enter", 

Re: How to find system configuration vulnerabilities; was: Thank you Debian

[Timothy Butterworth]

On February 21, 2024, at 4:08 PM, Michael Kjörling <2695bd53d...@ewoof.net> 
wrote:

>On 21 Feb 2024 19:03 +, from an...@rodier.me (Andre Rodier):
>> - What is the best approach to check if there is any vulnerability in the
>> packages configuration ?
>> - Is there any service that could audit the deployment code or the
>> configuration files ?
>My understanding is that both Lynis and Vuls are popular for
>already-installed systems. If you have your configuration packaged as
>Ansible scripts, then deploying that onto a disposable VM based on a
>minimal Debian installation should be a reasonably practical way of
>auditing the deployment process itself for vulnerabilities.
>A web search for something like "linux local vulnerability scanner"
>will provide you with additional leads.
>Note that any automated tool will use some kind of heuristics so (a)
>may find things that are not actually vulnerabilities in your setup,
>and (b) might not find something which _is_ a vulnerability in your
>setup.
>-- 

You can install and run Tenable Nessus Vulnerability scanner. The free version 
can scan like 10 IPs. I use Nessus and it works well. 

Security Blanket is a Security hardening tool suite which is nice and not too 
expensive.


>Michael Kjörling  https://michael.kjorling.se
>“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Booten vanaf USB steeds trager

[Geert Stappers]

On Wed, Feb 21, 2024 at 04:02:59PM +0100, Paul van der Vlis wrote:
> Op 20-02-2024 om 21:02 schreef Geert Stappers:
> > On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote:
> > > Hallo,
> > > 
> > > Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat 
> > > dit
> > > steeds trager wordt, op dezelfde machine:
> > > 
> > > Debian10:  18 seconden
> > > Debian11:  60 seconden
> > > Debian12:  ruim 120 seconden

zestig gedeeld door achttien is dik drie
ruim honderdtwing gedeeld door zes is net geen twee


> > > Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan 
> > > reuze
> > > hard aan het knipperen. Het gaat verder allemaal wel goed.
> > > 
> > > Op een snellere machine is het wel wat sneller, maar het blijft 
> > > onacceptabel
> > > traag.
> > > 
> > > Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een 
> > > log.
> > > Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang
> > > duurt. Dmesg geeft wel tijden, maar ik kom er niet uit.
> > > 
> > > Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian
> > > installer of livestick, dat gaat wel goed. Maar als ik echt Debian
> > > installeer op een USB device start het traag, dezelfde SSD aan SATA gaat 
> > > wel
> > > goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat
> > > lijkt ook niet het probleem.
> > > 
> > > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg?
> > 
> > Ja, ik heb wel een idee.
> > En dat idee wil ik ruilen voor de output van `ls -l /boot`
> > op de getestde versies.
> 
> Dit is op Debian 10:
> -- knip --
> -rw-r--r-- 1 root root 52343097 jun  3  2021 initrd.img-4.19.0-16-amd64
> -- knip --
> -rw-r--r-- 1 root root  5287168 mrt 19  2021 vmlinuz-4.19.0-16-amd64
 
52 miljoen plus 5 miljoen is 57 miljoen.


> Dit is op Debian 11:
> -- knip --
> -rw-r--r-- 1 root root 57863143 21 feb 15:58 initrd.img-5.10.0-28-amd64
> -- knip --
> drwx-- 2 root root12288 19 feb 21:24 lost+found
> -rw-r--r-- 1 root root  7039552 31 jan 22:14 vmlinuz-5.10.0-28-amd64

57m + 7m = 64m

64/57=1,12En 1,12 is echt geen factor drie.
 

> Dit is op Debian 12:
> -- knip --
> -rw-r--r-- 1 root root 87651238 19 feb 17:48 initrd.img-6.1.0-15-amd64
> -- knip --
> drwx-- 2 root root12288 19 feb 16:22 lost+found
> -rw-r--r-- 1 root root  8140672  9 dec 16:48 vmlinuz-6.1.0-15-amd64

87m + 8m = 95m
95/64 is ongeveer anderhalf.
Die anderhalf komt wel in de buurt van factor twee.


Terug naar
> > > Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg?
> > 
> > Ja, ik heb wel een idee.


Het idee is de kernel en initrd kleiner maken.


De bijvangst van de `ls -l /boot` is dat "de snelste" geen 'lost+found'
heeft. Over verschil in disk partities is nog geen informatie gegeven.


 
> Nou, ik hoop dat je een goed tip hebt. De initrd is wat groter inderdaad,
> maar 87MB is niet zo heel groot, met USB3 is dat zo over toch?


 
> Groet,
> Paul
> 



Groeten
Geert Stappers



Verzoek: Meer nieuwsgierigheid, minder mening en nog minder verwachtingen


Doe ons allemaal een plezier en ga voor meer nieuwsgierigheid.
Stel vragen als "Waar kijk ik tegen aan?", "Hoe het verder te onderzoeken?",
"Welk aspect van dichtbij bekijken?".

Laat meningen op de achtergrond. Verwoord "steeds trager" als "duurt steeds 
langer".
Mocht je wel een mening hebben, laat dan jouw ego dan aan jouw karma vragen
waar die mening "for the greater good" te ventileren.

Verwachtingen zijn helemaal van je zelf. Daar moet ik dan zelf ook
het meeste mee doen. Zo als geen verwachtingen hebben.
-- 
Silence is hard to parse

Re: Orphaned Inode Problem

[Gremlin]

On 2/21/24 13:14, David Christensen wrote:

On 2/21/24 03:00, Jörg-Volker Peetz wrote:

Hi,

did you take a look at the smartctl output?

Somewhere I read, for maintainance of an SSD all it's cells should be 
read from time to time like this


sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress

where device is something like sda or nvme0n1, especially if it was 
switched off for a longer period. At least, it shows the current read 
performance of the device.
An SSD should regularly be trimmed, if in use. This is to assist it's 
wear leveling process.


What's your opinion?

Regards,
Jörg.



I prefer to run a SMART long test periodically.  This should read every 
cell, including those that are reserved and not visible to the OS.



AIUI So long as the SSD can maintain a supply of erased cells via 
manufacturer over-provisioning, trim is not required to maintain 
performance.  If you have workload that does a lot of writes in a short 
period of time and exhausts the manufacturer over-provisioning, leaving 
free space on the SSD and trimming can be a work-around.



If you are using strong encryption, not trimming will leave crypttext on 
disk that creates more work for an attacker.  If you are using weak 
encryption, not trimming will leave crypttext on disk that an attacker 
can recover.



For imaging/ cloning, trimming will zero blocks freed by the OS and 
facilitate compression of the image file.



I have a SOHO network with about two dozen disks.  Running smartctl by 
hand is a PITA.  Running fstrim(8) by hand is easy enough.  I try to do 
both once a month.  I need to figure out smartd(8).



David




#!/usr/bin/dash -
drives="$(lsblk|grep '^sd')"
for i in $drives;do
case $i in
sd*) sudo smartctl -a /dev/"$i" ;;
*)   : ;;
esac
done

Re: How to find system configuration vulnerabilities; was: Thank you Debian

[Michael Kjörling]

On 21 Feb 2024 19:03 +, from an...@rodier.me (Andre Rodier):
> - What is the best approach to check if there is any vulnerability in the
> packages configuration ?
> - Is there any service that could audit the deployment code or the
> configuration files ?

My understanding is that both Lynis and Vuls are popular for
already-installed systems. If you have your configuration packaged as
Ansible scripts, then deploying that onto a disposable VM based on a
minimal Debian installation should be a reasonably practical way of
auditing the deployment process itself for vulnerabilities.

A web search for something like "linux local vulnerability scanner"
will provide you with additional leads.

Note that any automated tool will use some kind of heuristics so (a)
may find things that are not actually vulnerabilities in your setup,
and (b) might not find something which _is_ a vulnerability in your
setup.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector

[Andy Smith]

Hi,

On Tue, Feb 20, 2024 at 07:53:38PM -0500, Default User wrote:
> Note: I occurs to me that another idea would be to simply delete all
> files from the "bad" drive, then rsync everything fresh from the "good"
> drive back onto the "bad" drive.  

You can do it in one step with rsync --delete … which will delete
anything that doesn't exist on the source.

> IIUC, that would the cause the "bad" sector to be retired, and replaced
> by a "good" sector. 

Yes, a lot of the time a new write is successful and when it's not
it will be remapped. As long as the remapped sector count doesn't
keep going up I'd be fairly comfortable in continuing to use the
drive (assuming backups exist) s while longer.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Thank you Debian

[Andre Rodier]

Dear Debian community,

I love Debian, used it since Potato, both desktop and server, and I'm 
not planning to change.


I have been using it to host personal servers, especially emails, since 
about 20 years.


A few years ago, I created a set of Ansible scripts to code what I was 
already doing manually, so I could rebuild my server from scratch.


The solution is on GitHub, and while there was already a plethora of 
existing solutions, none of them implemented everything I wanted and 
needed. It was apparently challenging:


1. A DNS server included, with DNSSEC implemented, and SSHFP.
2. Everything from Debian packages, so upgrade can be automatic.
3. No git clone and no zip download for any service.
4. The usual LetsEncrypt, but also the extra like CAA, DANE, etc...
5. All services should be running under AppArmor.
6. No PHP, no RoundCube, NextCloud, OwnCloud, etc please.
7. Jabber server, with c2s and s2s.
8. CardDAV and CalDAV server.
9. WebDAV server.
10. LDAP for authentication, not a MySQL database.
11. IPv6 support

The points #2 and #3 are particularly interesting. I seriously cannot 
understand why or how people could trust a server exposed on internet, 
without automatic updates from a serious community like Debian. Are they 
suppose to receive alerts from GitHub releases to manually download them 
as they happen ? How can this be done while they are on vacation ? 
Excuse my naive question, if it is, please.


I precise, I am using unattended upgrades, and automatic reboot, and 
never had any issue, thanks to Debian packages quality. I just sometimes 
receive a nice email saying the server rebooted.


This wouldn't have been possible with the Debian community, so, again, 
thank you for that.


We have been happy with this solution, for myself, and a few friends and 
family members, but I would like the opinion from the security experts 
on this list.


- What is the best approach to check if there is any vulnerability in 
the packages configuration ?
- Is there any service that could audit the deployment code or the 
configuration files ?


Source code: https://github.com/progmaticltd/homebox
Docs: https://www.homebox.space/index-en.html

Kind regards,
André Rodier

Re: rec recording, Re: Upgrade to Bookworm, now GNOME keyring dies …

[Nate Bargmann]

* On 2024 21 Feb 12:42 -0600, David Wright wrote:
> On Mon 19 Feb 2024 at 13:26:17 (-0600), Nate Bargmann wrote:
> > 
> > After seeing this twice this morning I recalled that I have a cron entry
> > to kill the 'rec' program.  This was to break up audio files into hourly
> > segments when recording an amateur radio event.  This was the cron
> > command:
> > 
> > # Rotate sound recorder files
> > 00 * * * * /usr/bin/pkill -f rec > /dev/null 2> /dev/null
> > 
> > On a hunch I commented that line and Voila! the daemon ran through the
> > next hour change and is still running as expected.  The man page states
> > that the '-f' option matches against the full command line, not just the
> > process name.  So, looking at the gnome-keyring-daemon command line:
> > 
> >1857 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
> > --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
> > 
> > I see that the 'rec' in 'directory' provided the match!  Confirmed with
> > pgrep:
> > 
> > $ pgrep -f rec
> > 1857
> > 
> > It looks like the solution for the future will be to change the cron
> > line to:
> > 
> > 00 * * * * /usr/bin/pkill -f /usr/bin/rec > /dev/null 2> /dev/null
> 
> I can't get that to work here. When I kill rec, it just dies. Is pkill
> sending SIGTERM, which appears to be the default? Nor can I find this
> documented—though the sox docs are lengthy, so I might have missed it.
> 
> I can use SIGUSR1 with arecord, and that works perfectly.

It gets restarted by a script called by the 'tlf' amateur radio logging
program.  The script is:

https://github.com/Tlf/tlf/blob/master/scripts/soundlog

It's a hack!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: How can we change the keyboard layout?

[David Wright]

On Tue 13 Feb 2024 at 08:09:40 (+0100), hw wrote:
> On Sun, 2024-02-11 at 10:35 -0600, David Wright wrote:
> > On Wed 07 Feb 2024 at 06:58:39 (+0100), hw wrote:
> > > [...]
> I'd use multiple keyboards if I had to do that and just change between
> keyboards.

Do it if you like. That's what I have on my computer in the basement:
a GB-layout M keyboard and a US-layout Microsoft Pro.

In my case, the layout difference is incidental: the M sits on the
table, the other sits on a shelf, for standing use. (There are two
screens, set to mirroring.)

> > > > My 2014 keyboard appears to identify itself correctly as a K520. My
> > > > old IBM M says it's an "AT Translated Set 2 keyboard", which seems
> > > > reasonable for a keyboard dating from 1988.
> > > 
> > > I can see USB keyboards identifying themselves, but keyboards with
> > > PS/2 or DIN connectors?  How does your keyboard from 1988 connect?
> > 
> > PS/2. IIRC it came with a genuine IBM PS/2 computer.
> 
> Where does it show up?  Where does the information originate from?
> Perhaps the information is merely an assumption some of the involved
> the software makes and not something the keyboard tells it.

I get it from xinput, which I assume gets it from udev, as the ID's
description string occurs in /lib/udev/hwdb.d/60-keyboard.hwdb.

> > > 10% more keys isn't considerably more.  Can you show me a keyboard
> > > with 122 keys that has all keys usable and unique rather than sending
> > > key combinations instead?
> > 
> > That would be difficult:

I think some etiquette might be appropriate. You shouldn't quote half
a sentence just to change the meaning to suit yourself. I wrote:

 "That would be difficult: I've never had a 122 key keyboard, or
  even seen one. You have one. In terms of xev output, are there
  duplicate keys?"

That difficulty has nothing to do with the one you wrote about here:

> That's what I've been saying :)  Years ago I read an article about
> keyboards and it said that due to hardware restrictions, only so many
> keys can be handled so that keyboards with 122 keys don't really work:
> Either the controller in the keyboard key combinations, or the keys do
> nothing.  Apparently such keyboards seem to come from terminals that
> could use all the keys while PC hardware can not.

I've not heard of that. The keyboard files in the kernel source and in
udev seem to have far more keys available than 122.

> > I've never had a 122 key keyboard, or even seen one. You have
> > one. In terms of xev output, are there duplicate keys? Which ones,
> > and how does xev identify them?
> 
> I don't know if there are duplicate keys.  I didn't try out all the
> key to find any, and I haven't noticed any.

It can't take that long to press 122 keys in turn, can it.

> When I press F18, for example, wev says: [ … lengthy output snipped … ]

Does wl signify wayland output? I can't decode it. However, you appear
to have your NumLock on, which could change things considerably.

> For the backtab key it says:

Looking at 911QQZnUFrL.jpg, I don't know which key that is. But again,
NumLock appears to be on.

> These keys don't exist on PCs, so the keyboards converts them.  IIRC,
> Unicomp used to have a version that was suited for terminals like IBM
> made them, i. e. with all 122 keys working and not converted.

That's odd—911QQZnUFrL.jpg shows function keys as high as F24.
Why would it not be able to send a keycode for F18?

> > The keyboards I have access to all send usable keycodes, even where
> > the engravings are the same, eg, Return/36 and KP_Enter/104 are both
> > engraved with "Enter", KP_Subtract/82 and minus/20 are both engraved
> > with "-".
> 
> I get usable keycodes, too.  It looks pretty much like this, only the
> symbols on the two keys in the bottom row on the very left look nicer
> on mine: https://m.media-amazon.com/images/I/911QQZnUFrL.jpg

But without shifts, locks, and key redefinitions, do all your keys
produce unique keycodes? (Whether the last point is possible might
depend on how wayland inserts itself into the process.) Also note that
when keys have been redefined, you can't see what keycodes they would
originally have produced.

> > The only key on this K520 that doesn't send a keycode on its own is
> > the gold FN key, which behaves more like a laptop's Fn key, sending
> > "control functions" like Sleep; plus a battery charge indicator.
> 
> I guess that's useful for laptops --- and one example of how it's
> great to have more keys.  Why is there still no 'Hibernate' key on
> every keyboard?  That's not only useful laptops ...  I could use like
> F20 for it if I could configure that, but unfortunately, my
> workstation doesn't really hibernate, so I haven't tried.

This AiO desktop computer, with a wireless keyboard, obeys FN-F11
(engraved ⏻ with PC underneath) happily, and promptly falls asleep.

> > > > > We're still trying to figure out keyboards manually.  Instead of
> > > > > improvements, we now have come so far that we even 

rec recording, Re: Upgrade to Bookworm, now GNOME keyring dies …

[David Wright]

On Mon 19 Feb 2024 at 13:26:17 (-0600), Nate Bargmann wrote:
> 
> After seeing this twice this morning I recalled that I have a cron entry
> to kill the 'rec' program.  This was to break up audio files into hourly
> segments when recording an amateur radio event.  This was the cron
> command:
> 
> # Rotate sound recorder files
> 00 * * * * /usr/bin/pkill -f rec > /dev/null 2> /dev/null
> 
> On a hunch I commented that line and Voila! the daemon ran through the
> next hour change and is still running as expected.  The man page states
> that the '-f' option matches against the full command line, not just the
> process name.  So, looking at the gnome-keyring-daemon command line:
> 
>1857 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
> --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
> 
> I see that the 'rec' in 'directory' provided the match!  Confirmed with
> pgrep:
> 
> $ pgrep -f rec
> 1857
> 
> It looks like the solution for the future will be to change the cron
> line to:
> 
> 00 * * * * /usr/bin/pkill -f /usr/bin/rec > /dev/null 2> /dev/null

I can't get that to work here. When I kill rec, it just dies. Is pkill
sending SIGTERM, which appears to be the default? Nor can I find this
documented—though the sox docs are lengthy, so I might have missed it.

I can use SIGUSR1 with arecord, and that works perfectly.

Cheers,
David.

Re: sudo udisksctl

[David Wright]

On Mon 19 Feb 2024 at 23:53:41 (+0700), Max Nikulin wrote:
> David, feel free to stop discussion if you find me annoying. My
> problem in some sense is close to your one and I am trying to figure
> out if missed some udisks feature and the result is some
> inconvenience.
> 
> On 19/02/2024 11:26, David Wright wrote:
> > On Sun 18 Feb 2024 at 12:41:29 (+0700), Max Nikulin wrote:
> > > On 18/02/2024 11:40, David Wright wrote:
> > > > $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01
> > 
> > > When sudo is
> > > involved, I still do not see any advantage of udisk[s]ctl over
> > > "cryptsetup open".
> > 
> > I'd be more worried about disadvantages. About the only difference
> > I see is that   cryptsetup open   requires a name.
> 
> I find it convenient to have a meaningful name in /dev/mapper in
> addition to /dev/dm-X. So I would not call it pure disadvantage.

True, it makes the NAME in lsblk shorter. But the only time I've
defined a name is when opening the partition tocreate the filesystem:

  # cryptsetup --align-payload 2048 luksFormat /dev/sdz9

  WARNING!
  
  This will overwrite data on /dev/sdb1 irrevocably.

  Are you sure? (Type uppercase yes): YES
  Enter passphrase:
  Verify passphrase:
  # cryptsetup luksAddKey /dev/sdz9
  Enter any existing passphrase:
  Enter new passphrase for key slot:
  Verify passphrase:
  # cryptsetup open --type luks /dev/sdz9 thename
  Enter passphrase for /dev/sdz9:
  # ls -l /dev/mapper/
  total 0
  crw--- 1 root root 10, 236 Aug 18 10:35 control
  lrwxrwxrwx 1 root root   7 Aug 18 10:35 thename -> ../dm-0
  # ls -l /dev/dm-0
  brw-rw 1 root disk 254, 0 Aug 18 10:35 /dev/dm-0
  # mkfs.ext4 -L name09 /dev/mapper/thename
  mke2fs 1.44.5 (15-Dec-2018)
  Creating filesystem with 10598 4k blocks and 26492928 inodes
  Filesystem UUID: 3c832120-d40a-4998-b927-1318eb1e17f8
  Superblock backups stored on blocks:
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 
2654208,
  4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968,
  10240

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (262144 blocks): done
  Writing superblocks and filesystem accounting information: done

  # e2label /dev/mapper/thename name09 (if forgotten above).
  # 

[ … creating, chown-ing, chmod-ing top-level directories ]

  # cryptsetup luksClose thename
  # 

> > > As third option, if I remember it correctly, pmount
> > 
> > That would be pointless for me. After udev creates correctly-named
> > mountpoints using my rules, entries in fstab set the appropriate
> > flags for each individual device. That contradicts the expressed main
> > purpose of pmount: "permits normal users to mount removable devices
> > without a matching /etc/fstab entry." — precisely what I don't want.
> 
> I consider pmount as a tool does not need separate unlock and mount
> commands, so a shell function becomes unnecessary. In respect to
> permissions (for removable drives) it acts as a substitute for sudo.
> 
> I expected that you need to mount a partition under /media into the
> directory with name taken from filesystem LABEL. If so then udisksd
> can do it and /etc/fstab entry is unnecessary. You anyway added an
> udev rule. The following one should change mountpoint from
> /media/$USER/lulu01 to /media/lulu01
> 
> SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="lulu01",
> ENV{UDISKS_FILESYSTEM_SHARED}="1"
> 
> It seems that mixing of udisksctl and non-udisksctl commands can be avoided.

I hadn't thought about that as an issue. I've just chosen, for
each step, the method that's most convenient (for me). See:

  https://lists.debian.org/debian-user/2024/01/msg00737.html

for some details of the first step, which I won't duplicate here.
I group-control the directory /etc/udev/rules.d/my-mountpoints,
hence all the 59 entries.

For decrypting, I use either the PARTLABEL or the device-ID. The
latter's useful for sticks and cards that I wipe more frequently,
which makes the other symlinks variable over time.

For mounting, I use fstab entries because they have the flags defined,
rather than putting them in the mount command. When I need to mount
with sudo, the flags include a private x-mysudo flag, which is picked
up by my wrapper around mount. (The bash function that started this
discussion doesn't say "mount /media/lulu01" but "mmm /media/lulu01".)

Unmounting is also wrapped, not just for sudo, but because it contains
a script to updatedb (for locate), ls -lR (for mc), and create a
listing (using find) that lists modification time, size and filename
in a customised format. After any locking, the three products are
automatically transferred to my other hosts to keep them up-to-date.

It probably all looks hackish to someone running a multiuser system.

Cheers,
David.

Re: partition reporting full, but not

[David Wright]

On Tue 20 Feb 2024 at 17:14:41 (+), debian-u...@howorth.org.uk wrote:
> Felix Miata  wrote:
> > Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
> > 
> > > I just removed 3 snapshots from my daily driver with no change in
> > > used space reported by df  
> > 
> > df doesn't know how to calculate freespace on btrfs. You need to be
> > typing
> > 
> > btrfs filesystem df
> 
> df [options] 
>Show a terse summary information about allocation of block
>group types of a given mount point. The original purpose of
>this command was a debugging helper. The output needs to be
>further interpreted and is not suitable for quick overview.
> 
> 
> FWIW my root filesystem is btrfs and I use the normal df command all the
> time without a problem. I've never used btrfs filesystem df

Would it matter if you're not running your filesystem close to full?

Cheers,
David.

Re: partition reporting full, but not

[David Wright]

On Mon 19 Feb 2024 at 10:26:05 (+1100), Keith Bainbridge wrote:
> On 18/2/24 14:49, Keith Bainbridge wrote:
> > On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:
> > > Keith Bainbridge wrote:
> > > > Yes the / partitions are btrfs
> > > 
> > > So the apparently missing space is perhaps taken up by btrfs snapshots.
> > > 
> > 
> > Seems to be the prime suspect.   If that's the case, btrfs is NOT
> > hard- linking the snapshots as timeshift claims it does. The only
> > way to check is install on ext4 and compare. I have saves enough
> > free space to do this.
> > 
> > My effort to date is to move my home to /mnt/data and sim-link it
> > into / home. df is now showing 2.3GB free on /.  df showed /home
> > as 2.2GB yesterday.  At least there is a little space to play
> > with; and give me time to consider. A fresh install may be worth
> > checking in snapshots are as big as this all makes them look.
> > 
> > a few brief answer to other comments will follow
> 
> 
> So later yesterday afternoon I created a new snapshot with no obvious
> change is free space.

That would seem reasonable, as there's not much more to do than note
which files the snapshot contains.

> I then update/upgrade.   The initial attempt told me
> 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
> Need to get 337 MB of archives.
> After this operation, 473 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
> 
> But the 3 kernel related packages failed to install a couple of times.
> When I finally figured I should check space, there was none.   I
> rolled back to prior to the upgrade, but still no free space.
> 
> I said sometime in this thread that timeshift (and BiT) use hard links
> to create progressive copies of the system. The more I think about how
> hard links reportedly work, I reckon it can't be simply hard links.

Reading a tiny bit of the BTRFS docs, I would suggest that you're not
taking Block Groups into account. If BTRFS allocates data chunks in
blocks of 1GB, then it's conceivable that an upgrade involving 473MB
of data, plus the consequential increase in the size of the snapshot,
could all reside in a very recently created Block Group.

Put another way, df would see no change in Used and Available (as no
new Block Group allocation), whereas I would expect   btrfs filesystem df
to report a change here (because it knows what's within its Block
Groups):

> Data, single: total=32.80GiB, used=31.94GiB
> Tue 20Feb2024@20:57:45

Cheers,
David.

Re: Booten vanaf USB steeds trager

[Richard Lucassen]

On Wed, 21 Feb 2024 15:42:36 +0100
Paul van der Vlis  wrote:

> > Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de
> > root device niet kan vinden en dat duurt dan een tijdje. IIRC helpt
> > een
> > 
> > update-initramfs -u
> 
> Dit had ik al geprobeerd, maar hielp niet.

Ik bedacht me later dat dat met md devices is. Als de mdadm.conf niet
overeenkomt met wat er in de initramdisk zit dan gaat-ie md127, md126
etc aanmaken en dan krijg je dat. Nooit uitgezocht waarom. En dan helpt
de update-initramfs -u wel uiteraard.

> > console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02
> > rootfstype=ext4 fsck.repair=yes rootwait
> 
> Dit is geen Pi, dus ook geen cmdline.txt

Het gaat niet zozeer om de RPi, maar om de kernel opties die de kernel
meekrijgt als-ie vanaf USB boot

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: Orphaned Inode Problem

[David Christensen]

On 2/21/24 03:00, Jörg-Volker Peetz wrote:

Hi,

did you take a look at the smartctl output?

Somewhere I read, for maintainance of an SSD all it's cells should be 
read from time to time like this


sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress

where device is something like sda or nvme0n1, especially if it was 
switched off for a longer period. At least, it shows the current read 
performance of the device.
An SSD should regularly be trimmed, if in use. This is to assist it's 
wear leveling process.


What's your opinion?

Regards,
Jörg.



I prefer to run a SMART long test periodically.  This should read every 
cell, including those that are reserved and not visible to the OS.



AIUI So long as the SSD can maintain a supply of erased cells via 
manufacturer over-provisioning, trim is not required to maintain 
performance.  If you have workload that does a lot of writes in a short 
period of time and exhausts the manufacturer over-provisioning, leaving 
free space on the SSD and trimming can be a work-around.



If you are using strong encryption, not trimming will leave crypttext on 
disk that creates more work for an attacker.  If you are using weak 
encryption, not trimming will leave crypttext on disk that an attacker 
can recover.



For imaging/ cloning, trimming will zero blocks freed by the OS and 
facilitate compression of the image file.



I have a SOHO network with about two dozen disks.  Running smartctl by 
hand is a PITA.  Running fstrim(8) by hand is easy enough.  I try to do 
both once a month.  I need to figure out smartd(8).



David

Re: Orphaned Inode Problem

[Jörg-Volker Peetz]

Henning Follmann wrote on 21/02/2024 14:16:

On Wed, Feb 21, 2024 at 12:00:17PM +0100, Jörg-Volker Peetz wrote:



Somewhere I read, for maintainance of an SSD all it's cells should be read
from time to time like this

sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress


Where did you read that? That seems like a huge waste of time.

As far as I remember, the idea behind this suggestion is to help the SSD 
firmware detect bad blocks or cells early on and to mask them out. Of course, a 
good firmware with it's wear leveling algorithm 
(https://en.wikipedia.org/wiki/Wear_leveling) should do this by itself.


Regards,
Jörg.

Re: sshd Match regel

[Roland Clobus]

Hallo Paul,

On 21/02/2024 16:08, Paul van der Vlis wrote:

Wie heeft een tip


Ik heb nog een (zeer) oude Linksys WRT staan, die kan ik benaderen met:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 
-oHostKeyAlgorithms=+ssh-rsa username@mylocalip


Ik heb met ssh -v username@mylocalip de waarde voor -oKexAlgorithms 
gevonden.


Met vriendelijke groeten,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: sshd Match regel

[Paul van der Vlis]

Hoi Gijs en anderen,

Op 20-02-2024 om 21:18 schreef Geert Stappers:

On Tue, Feb 20, 2024 at 08:06:22AM +0100, Gijs Hillenius wrote:

On 19 February 2024 18:26 Rik Theys, wrote:


Beste,

On Mon, Feb 19, 2024 at 5:53 PM Gijs Hillenius  wrote:




Iets als, onderaan sshd_config dit:

,
| Match User webcams
| PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
`

ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde
foutmelding in auth.log. De clients bevestigen: "unable to exchange
encryption keys."

Als ik op de server doe:

ssh localhost -Q HostKeyAlgorithms


daar zie ik toch ssh-dss en ssh-rsa staan.

Maar ... niet de "oude"?

Wie heeft een tip





De -Q optie geeft een lijst van ondersteunde algorithms, daarom niet
degene die actief zijn? Ik zou eens proberen met een Match op het IP
adres ipv de gebruikersnaam. Mogelijk is de uitwisseling van de
gebruikersnaam pas na het tot stand komen van de encryptie?


Ow! dank voor het meedenken, dat helpt.

Idd, ik zie in de ssh logs niet die username.

Maar

,
| Match Address 192.168.123.42
|   PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
`

geeft helaas dezelfde melding in de log.




sudo /usr/sbin/sshd -d


Dat is inderdaad een heel goede tip om ssh problemen te debuggen. Maar 
je moet het op de server draaien, en wellicht op een andere poort omdat 
je jezelf anders buitensluit. En die poort moet uiteraard wel openstaan.


Soms kun je wel even de poort van een andere applicatie gebruiken als je 
die applicatie sluit, bijvoorbeeld poort 80 als je een aanwezige 
webserver sluit.


Groet,
Paul

--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Booten vanaf USB steeds trager

[Paul van der Vlis]

Hoi Geert en anderen,

Op 20-02-2024 om 21:02 schreef Geert Stappers:

On Tue, Feb 20, 2024 at 09:31:02AM +0100, Paul van der Vlis wrote:

Hallo,

Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op dat dit
steeds trager wordt, op dezelfde machine:

Debian10:  18 seconden
Debian11:  60 seconden
Debian12:  ruim 120 seconden

Wat vooral lang duurt is "loading initial ramdisk", het lichtje is dan reuze
hard aan het knipperen. Het gaat verder allemaal wel goed.

Op een snellere machine is het wel wat sneller, maar het blijft onacceptabel
traag.

Ik heb ook al de kernel-optie "debug" gegeven, dan maakt initramfs een log.
Maar omdat er geen tijden bij staan zegt het me weinig over wat nu zo lang
duurt. Dmesg geeft wel tijden, maar ik kom er niet uit.

Ik zie hetzelfde ook op andere machines. Overigens niet bij een Debian
installer of livestick, dat gaat wel goed. Maar als ik echt Debian
installeer op een USB device start het traag, dezelfde SSD aan SATA gaat wel
goed. Ik heb al verschillende USB naar SATA kabels geprobeerd, maar dat
lijkt ook niet het probleem.

Hebben jullie ideeën hoe ik dit booten vanaf USB sneller krijg?


Ja, ik heb wel een idee.
En dat idee wil ik ruilen voor de output van `ls -l /boot`
op de getestde versies.


Dit is op Debian 10:
-rw-r--r-- 1 root root   206143 okt 18  2020 config-4.19.0-12-amd64
-rw-r--r-- 1 root root   206269 nov 28  2020 config-4.19.0-13-amd64
-rw-r--r-- 1 root root   206242 mrt 19  2021 config-4.19.0-16-amd64
-rw-r--r-- 1 root root   206118 mrt 15  2019 config-4.19.0-4-amd64
-rw-r--r-- 1 root root   206361 nov 11  2019 config-4.19.0-6-amd64
drwxr-xr-x 5 root root 4096 jun  3  2021 grub
-rw-r--r-- 1 root root 51780082 nov 30  2020 initrd.img-4.19.0-12-amd64
-rw-r--r-- 1 root root 51874209 dec 28  2020 initrd.img-4.19.0-13-amd64
-rw-r--r-- 1 root root 52343097 jun  3  2021 initrd.img-4.19.0-16-amd64
-rw-r--r-- 1 root root 25616128 okt 29  2019 initrd.img-4.19.0-4-amd64
-rw-r--r-- 1 root root 51705982 nov 30  2020 initrd.img-4.19.0-6-amd64
-rw-r--r-- 1 root root   182704 jun 25  2015 memtest86+.bin
-rw-r--r-- 1 root root   184840 jun 25  2015 memtest86+_multiboot.bin
-rw-r--r-- 1 root root  3415048 okt 18  2020 System.map-4.19.0-12-amd64
-rw-r--r-- 1 root root  3419998 nov 28  2020 System.map-4.19.0-13-amd64
-rw-r--r-- 1 root root  3421023 mrt 19  2021 System.map-4.19.0-16-amd64
-rw-r--r-- 1 root root  3365519 mrt 15  2019 System.map-4.19.0-4-amd64
-rw-r--r-- 1 root root  3410671 nov 11  2019 System.map-4.19.0-6-amd64
-rw-r--r-- 1 root root  5278960 okt 18  2020 vmlinuz-4.19.0-12-amd64
-rw-r--r-- 1 root root  5283056 nov 28  2020 vmlinuz-4.19.0-13-amd64
-rw-r--r-- 1 root root  5287168 mrt 19  2021 vmlinuz-4.19.0-16-amd64
-rw-r--r-- 1 root root  5213424 mrt 15  2019 vmlinuz-4.19.0-4-amd64
-rw-r--r-- 1 root root  5270768 nov 11  2019 vmlinuz-4.19.0-6-amd64

Dit is op Debian 11:
-rw-r--r-- 1 root root   236286  2 sep  2022 config-5.10.0-18-amd64
-rw-r--r-- 1 root root   236364 31 jan 22:14 config-5.10.0-28-amd64
drwxr-xr-x 5 root root 1024 21 feb 15:58 grub
-rw-r--r-- 1 root root 50620656 19 feb 21:39 initrd.img-5.10.0-18-amd64
-rw-r--r-- 1 root root 57863143 21 feb 15:58 initrd.img-5.10.0-28-amd64
drwx-- 2 root root12288 19 feb 21:24 lost+found
-rw-r--r-- 1 root root   83  2 sep  2022 System.map-5.10.0-18-amd64
-rw-r--r-- 1 root root   83 31 jan 22:14 System.map-5.10.0-28-amd64
-rw-r--r-- 1 root root  6962016  2 sep  2022 vmlinuz-5.10.0-18-amd64
-rw-r--r-- 1 root root  7039552 31 jan 22:14 vmlinuz-5.10.0-28-amd64

Dit is op Debian 12:
-rw-r--r-- 1 root root   259455  9 dec 16:48 config-6.1.0-15-amd64
drwxr-xr-x 5 root root 1024 19 feb 16:50 grub
-rw-r--r-- 1 root root 87651238 19 feb 17:48 initrd.img-6.1.0-15-amd64
drwx-- 2 root root12288 19 feb 16:22 lost+found
-rw-r--r-- 1 root root   83  9 dec 16:48 System.map-6.1.0-15-amd64
-rw-r--r-- 1 root root  8140672  9 dec 16:48 vmlinuz-6.1.0-15-amd64

Nou, ik hoop dat je een goed tip hebt. De initrd is wat groter 
inderdaad, maar 87MB is niet zo heel groot, met USB3 is dat zo over toch?


Groet,
Paul

--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Booten vanaf USB steeds trager

[Paul van der Vlis]

Hoi Richard en anderen,

Op 20-02-2024 om 12:27 schreef Richard Lucassen:

On Tue, 20 Feb 2024 09:31:02 +0100
Paul van der Vlis  wrote:


Ik heb een setup waarbij ik boot vanaf USB met grub. Het valt me op
dat dit steeds trager wordt, op dezelfde machine:

Debian10:  18 seconden
Debian11:  60 seconden
Debian12:  ruim 120 seconden


Ik heb ook zoiets gehad, tijdens het booten geeft-ie aan dat-ie de root
device niet kan vinden en dat duurt dan een tijdje. IIRC helpt een

update-initramfs -u


Dit had ik al geprobeerd, maar hielp niet.


dan, maar zeker weet ik dat niet ('t is alweer een tijdje terug). Met
een monitor erop kun je die meldingen zien. Ik sloop trouwens altijd de
"quiet" optie uit /etc/default/grub (en daarna update-grub). Heb je wel
"rootwait" als kerneloptie meegegeven? Volgens mij moet dat ook. Dit
staat in de cmdline.txt file op mijn Raspberry Pi:

console=serial0,115200 console=tty1 root=PARTUUID=3fc93f64-02
rootfstype=ext4 fsck.repair=yes rootwait


Dit is geen Pi, dus ook geen cmdline.txt


Ben geen guru op dat gebied trouwens.


Ik ook niet...

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Orphaned Inode Problem

[Henning Follmann]

On Wed, Feb 21, 2024 at 12:00:17PM +0100, Jörg-Volker Peetz wrote:
> Hi,
> 
> did you take a look at the smartctl output?
> 
> Somewhere I read, for maintainance of an SSD all it's cells should be read
> from time to time like this
> 
> sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress

Where did you read that? That seems like a huge waste of time.

> 
> where device is something like sda or nvme0n1, especially if it was switched
> off for a longer period. At least, it shows the current read performance of
> the device.
> An SSD should regularly be trimmed, if in use. This is to assist it's wear
> leveling process.
> 
If you should manually kick off trim is a hotly debated issue.
It mainly depends on the use of the drive.
In most cases however do not alter any of how the system was install by
your friendly installer.


> What's your opinion?
How much time do you have :)


-H



-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: Orphaned Inode Problem

[Jörg-Volker Peetz]

Hi,

did you take a look at the smartctl output?

Somewhere I read, for maintainance of an SSD all it's cells should be read from 
time to time like this


sudo dd if=/dev/DEVICE of=/dev/null bs=8M status=progress

where device is something like sda or nvme0n1, especially if it was switched off 
for a longer period. At least, it shows the current read performance of the device.
An SSD should regularly be trimmed, if in use. This is to assist it's wear 
leveling process.


What's your opinion?

Regards,
Jörg.

Re: OT (Muy, muy OT): Barra herramientas MS-Excel

[Camaleón]

El 2024-02-20 a las 10:15 -0300, Javier ArgentinaBBAR escribió:

(...)

> El problema, es la cinta de herramientas de porquería que tiene 3cms
> de alto en la pantalla; la muestro y la oculto con el consabido
> "Ctrl+F1", pero
> ...pero quiero recuperar mi vieja (soy viejo) y súper eficiente "Barra
> de herramientas" estándar.
> Esa porquería de cinta tiene no más de 6 o 7 comandos, en el espacio
> que estoy acostumbrado a tener más de 30 con botones chiquitos.
> 
> La pregunta: ¿alguno conoce de algún "mod" que reemplace la maldita
> cinta por la vieja y eficiente Barra de herramientas en Excel?

Supongo que te refieres a la versión de MS Office instalable en disco, 
no la que se ejecuta en la web.

Puedes seguir dos vías:

1. Usar un complemento o programa (mod) instalable para que te devuelva 
el menú clásico o semi-clásico;

2. Ajustar la cinta a tu gusto (modo simplificado, reducido, no 
mostrar, personalizar botones y órdenes...).

Para la opción 1), Internet devuelve varias opciones¹²³.

Aunque no soy partidaria de instalar este tipo de modificadores, si el
ansia/necesidad del menú clásico es grande, mejor probarlos en una 
máquina virtual antes ver cuál se adapta visualmente mejor a lo que se 
busca, comprobar que no vienen con bicho dentro, que no dejan 
colgado/interfieren con el programa, etc...

Para la opcíón 2):

Use the Simplified Ribbon
https://support.microsoft.com/en-us/office/use-the-simplified-ribbon-44bef9c3-295d-4092-b7f0-f471fa629a98

Show or hide the ribbon in Office
https://support.microsoft.com/en-gb/office/show-or-hide-the-ribbon-in-office-d946b26e-0c8c-402d-a0f7-c6efa296b527#ID0EBBD=Newer_Versions

¹https://www.ubit.ch/software/ubitmenu-languages/
²https://gregmaxey.com/word_tip_pages/ribbon_menu_control.html
³https://www.officeclassicmenu.com/en/index.php

Saludos,

-- 
Camaleón