Will my reconstructed fstab work?

[Ken Heard]

A few days ago using vim I added to my desktop fstab file a line for a 
new portable storage device.  in the process I somehow managed to screw 
up fstab.  Unfortunately I saved the screwed up version of fstab before 
I noticed the damage done to it.


As I had no fstab backup  -- to correct later -- I had to reconstruct 
fstab using the information produced by blkid for the missing UUIDs.   I 
think the reconstruction is correct, but I have since been afraid to 
close the computer if because of a faulty fstab I would be unable to 
reopen it


I would consequently appreciate help in verifying  the essential fstab 
lines, numbered 11-20 in the reconstructed fstab quoted below and 
thereby assuage my reopening fears.  (Lines 26-40 relating to portable 
storage devices I checked myself; they all work.)


Basic Information:  two internal hard drives, /dev/sda and /dev/sdb, 
each divided into two small partitions of equal size.  Sda1 is used for 
/boot/efi, lines 13 and 15. Partition sdb1, line 17, is currently 
unused; in time I will copy to it what is in sda1.  Partitions sda2 and 
sdb2 form a RAID1, with the five LVM partitions listed in lines 11, 18, 
19 and 20.  Operating system is Debian Bullseye.


If anybody in interested, following the reconstructed fstab  quoted 
below is quoted further below how the fsab looked right after the screw 
up.


01 # /etc/fstab: static file system information.
02 #
03 # Use 'blkid' to print the universally unique identifier for a
04 # device; this may be used with UUID= as a more robust way to name 
devices

05 # that works even if disks are added and removed. See fstab(5).
06 #
07 # Systemd generates mount units based on this file, see systemd.mount(5).
08 # Please run 'systemctl daemon-reload' after making changes here.
09 #
10 #
11 /dev/mapper/Morcom-ROOT /   ext4errors=remount-ro 0 1
12 # /boot/efi was on /dev/sda1 during installation
13 UUID=3020-1029  /boot/efi   vfatumask=0077  0   1
14 # /dos was on /dev/sda1 during installation
15 UUID=3020-1029  /dosvfatutf80   0
16 # /dos2 was on /dev/sdb1 during installation
17 UUID=2AF2-0A16  /dos2   vfatutf80   0
18 /dev/mapper/Morcom-HOME_crypt /home   ext4defaults 0   2
19 /dev/mapper/Morcom-VAR /varext4defaults0   2
20 /dev/mapper/Morcom-SWAP_crypt noneswapswap0   0
21 /dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
22 tmpfs/tmptmpfs   nodev,nosuid,size=20%   0   0
23 UUID=c577-7f18-4443-a77b-c5827f977449 /media/fdr ext2 
user,noauto,noatime 0	 0
24 UUID=33cebfb3-b568-493f-853b-e1b7ca5cc3a2 /media/fde ext2 
user,noauto,noatime  0 0

25 # -e8b57fb2ac09/media/ssda   ext4user,npauto,noatime 0   0
26 UUID=la449167-8497-4471-ae0c-e8b57fb2ac09 /media/phda ext4 
user,noauto,noatime 0 0
27 UUID=0fee2d01-2441-4699-a4ae-bb45c417b8ee /media/ssda ext4 
user,noauto,noatime 0 0
28 UUID=e26255ab-e6c5-4bcd-941c-7378b7cf4083 /media/ssdb ext4 
user,noauto,noatime 0 0

29 UUID=3DB1-1700   /media/fdg  vfatuser,noauto,noatime 
0   0
30 UUID=5966-5502   /media/fdp  vfatuser,noauto,noatime 
0   0
31 UUID=1170-1657   /media/hca  vfatuser,noauto,noatime 
0   0
32 UUID=0E0A-0F26   /media/hcb  vfatuser,noauto,noatime 
0   0
33 UUID=1E82-122E   /media/hcc  vfatuser,noauto,noatime 
0   0
34 UUID=1D1F-1032/media/xca exfat   user,noauto,noatime 
0   0
35 UUID=1909-1458   /media.xcb  exfat   user,noauto,noatime 
0   0
36 UUID=6238-3434   /media/xcc  exfat   user,noauto,noatime 
0   0
37 UUID=206F-163F   /media/xcd  exfat   user,noauto,noatime 
0   0
38 UUID=3630-6530   /media/xce  exfat   user,noauto,noatime 
0   0
39 UUID=3065-6630   /media/xcf  exfat   user,noauto,noatime 
0   0
40 LABEL=ostree /media/phdc ext4user,noauto,noatime 
0   0

Right after the screw up the fstab looked like this.

01 -e8b57fb2ac09static file system information.
02 -e8b57fb2ac09
03 -e8b57fb2ac09lkid' to print the universally unique identifier for a
04 -e8b57fb2ac09vice; this may be used with UUID= as a more robust way 
to name devices

05 -e8b57fb2ac09at works even if disks are added and removed. See fstab(5).
06-e8b57fb2ac09
07 -e8b57fb2ac09d generates mount units based on this file, see 
systemd.mount(5).

08 -e8b57fb2ac09n 'systemctl daemon-reload' after making changes here.
09 -e8b57fb2ac09
10 -e8b57fb2ac09ile system> 
11 -e8b57fb2ac09ev/mapper/Morcom-ROOT /   ext4 
errors=remount-ro 0   1

12 -e8b57fb2ac09fi was on /dev/sda1 during installation
13 -e8b57fb2ac09020-1029  /boot/efi   vfat

Re: loss of mbmon function

[gene heskett]

On 11/2/22 21:01, David Christensen wrote:

On 11/2/22 12:07, gene heskett wrote:

On 11/2/22 08:19, gene heskett wrote:

All 5 of the samsung SDD's in THIS machine have now been 
-test=long'd, all 5 report
with the -a option that the read test failed as seen below, but a -H 
says they are healthy.


Whats next?



I have found that smartctl(8) version 7.2 has trouble decoding some of 
the statistics for my Intel SSD 520 Series drives (Debian Stable), 
while smartctl(8) version 7.3 does a better job 
(FreeBSD-12.3-RELEASE-amd64). So, perhaps you are seeing bad 
information from smartctl(8) version 7.2.



Debian backports does not seem to offer smartmontools 7.3.


Debian Testing and Unstable have smartmontools 7.3.


Alternatively, Samsung does make software tools for their storage 
products.  Unfortunately, I believe the tools are Windows 
applications; so, they require a Windows installation.



AIUI you have a HBA/RAID card in that computer.  I suspect that you 
also have USB devices and/or other connected hardware.  What happens 
if you disconnect everything?  If the problem goes away, do a search 
and find the problem hardware.


Not a raid card, just another $20 6 port sata card, its software raid. 
There is no drive activity
of any kind when it hangs. The only indication of life at all is a row 
of color changing leds on
the front edge of the mobo are cycling the colors, possibly a little 
slower that they are right now.


I've considered that disconnect as my usb tree looks like a 50 yo 
weeping willow.
Everything but the keyboard and mouse buttons can be disconnected by 
about 6 usb cables.
Getting these 88 yo knees down on the floor to see about plugging them 
back in is a

bit of a chore so they don't get disconnected very often.

This is the main computer of a 7 machine home network that by the time 
they are done arguing
about who won next Teusday's election, might have 4 more bannana pi's to 
connect to.


I'd like to have bought rpi4b's w/8G's but their scarcity has ran the 
price above $300.
Much newer bananna pi's BPI-M5's with 4G are $90. And have faster usb as 
all 4 ports are usb3.1.


Do like I did with the rpi4b running my biggest cnc lathe, and move all 
the high traffic stuff
to a $30 SSD and get uptimes in years. I have an automatic 20kw standby 
and the pi has a small
ups. That made the pi into a workstation, building its own real-time 
kernel AND linuxcnc from a git pull if

the buildbot at linuxcnc.org gets a tummy ache.

Thanks, David.  Take care & stay well,


.



Cheers, Gene Heskett.
--
"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
Genes Web page 

Re: loss of mbmon function

[David Christensen]

On 11/2/22 12:07, gene heskett wrote:

On 11/2/22 08:19, gene heskett wrote:

All 5 of the samsung SDD's in THIS machine have now been -test=long'd, 
all 5 report
with the -a option that the read test failed as seen below, but a -H 
says they are healthy.


Whats next?



I have found that smartctl(8) version 7.2 has trouble decoding some of 
the statistics for my Intel SSD 520 Series drives (Debian Stable), while 
smartctl(8) version 7.3 does a better job (FreeBSD-12.3-RELEASE-amd64). 
So, perhaps you are seeing bad information from smartctl(8) version 7.2.



Debian backports does not seem to offer smartmontools 7.3.


Debian Testing and Unstable have smartmontools 7.3.


Alternatively, Samsung does make software tools for their storage 
products.  Unfortunately, I believe the tools are Windows applications; 
so, they require a Windows installation.



AIUI you have a HBA/RAID card in that computer.  I suspect that you also 
have USB devices and/or other connected hardware.  What happens if you 
disconnect everything?  If the problem goes away, do a search and find 
the problem hardware.



David

Re: loss of mbmon function

[gene heskett]

On 11/2/22 08:19, gene heskett wrote:

All 5 of the samsung SDD's in THIS machine have now been -test=long'd, 
all 5 report
with the -a option that the read test failed as seen below, but a -H 
says they are healthy.


Whats next?

On 11/2/22 07:26, Alexander V. Makartsev wrote:

On 02.11.2022 05:55, gene heskett wrote:

On 11/1/22 16:52, Alexander V. Makartsev wrote:
First step is to find model and make of IC that provides sensor 
functions.

Does this command gives any clues?
$ sudo sensors-detect


answered yes to all the default NO questions and still got only:
# Chip drivers
coretemp
nct6775

Which are now loaded, but still no voltages or fans are reported.


These two has to be sufficient. Just make sure these modules are loaded:
$ lsmod | grep -iE 'coretemp|nct6775'

Now "sensors" utility should be able to output values from every 
available sources of super I/O IC.

    $ sensors

They were not autoloaded, which I'd call a bug, but manually modprobed 
and now present

in an lsmod output, sensors still aren't working except in the bios.

gkrellm and sensors both say essentially the same thing:
ene@coyote:~$ sensors
coretemp-isa-
Adapter: ISA adapter
Package id 0:  +32.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0:    +30.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1:    +30.0°C  (high = +84.0°C, crit = +100.0°C)
Core 2:    +32.0°C  (high = +84.0°C, crit = +100.0°C)
Core 3:    +30.0°C  (high = +84.0°C, crit = +100.0°C)
Core 4:    +32.0°C  (high = +84.0°C, crit = +100.0°C)
Core 5:    +30.0°C  (high = +84.0°C, crit = +100.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:    +27.8°C  (crit = +119.0°C)
temp2:    +29.8°C  (crit = +119.0°C)


And the first disk in the raid fails the read test, 2nd one being 
tested ( -t long) now, in fact s/b done.

And it looks exactly like the first drive

gene@coyote:~$ sudo smartctl /dev/sdf -a
[sudo] password for gene:
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-19-amd64] (local 
build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Device Model: Samsung SSD 870 EVO 1TB
Serial Number:    S626NF0R302502E
LU WWN Device Id: 5 002538 f413394a9
Firmware Version: SVT01B6Q
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:  512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:  2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is:    Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Nov  2 08:03:40 2022 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)    Offline data collection 
activity

                was never started.
                Auto Offline Data Collection: Disabled.
Self-test execution status:  ( 117)    The previous self-test 
completed having

                the read element of the test failed.
Total time to complete Offline
data collection:         (    0) seconds.
Offline data collection
capabilities:              (0x53) SMART execute Offline immediate.
                Auto Offline data collection on/off support.
                Suspend Offline collection upon new
                command.
                No Offline surface scan supported.
                Self-test supported.
                No Conveyance Self-test supported.
                Selective Self-test supported.
SMART capabilities:    (0x0003)    Saves SMART data before 
entering

                power-saving mode.
                Supports SMART auto save timer.
Error logging capability:    (0x01)    Error logging supported.
                General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   2) minutes.
Extended self-test routine
recommended polling time:      (  85) minutes.
SCT capabilities:        (0x003d)    SCT Status supported.
                SCT Error Recovery Control supported.
                SCT Feature Control supported.
                SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE UPDATED  
WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   099   099   010    Pre-fail 
Always   -   1
  9 Power_On_Hours  0x0032   097   097   000    Old_age 
Always   -   10581
 12 Power_Cycle_Count   0x0032   099   099   000    Old_age 
Always   -   58
177 Wear_Leveling_Count 0x0013   099   099   000    Pre-fail 
Always   -   21
179 

Re: Exécuter un fichier exe en ligne de commande

[ajh-valmer]

Pardon, je suis très en retard.

Et avec le conteneur Docker (formaté en FAT32) ?

[HORS SUJET] Plugin Darktable dans Gimp

[benoit]

Bonjour à tou·te·s

Dans gimp 2.10 il y a une fonctionnalité d’interopérabilité avec Darktable qui 
permet d'ouvrir un ficher RAW dans Darktable à partir de Gimp, faire les modifs 
qu'on veut dans darktable, fermer la fenêtre et gimp va ouvrir le fichier RAW 
modifié.

Ma demande d'aide semble hors sujet, mais pas vraiment, car ça fonctionne 
parfaitement en Debian testing et pas en stable, d'où ma question sur la liste 
Debian.

---
GIMP Message :
Calling error for procedure 'gimp-file-load':
Error opening file '/tmp/gimp/2.10/gimp-temp-253451.exr' for reading

GIMP Message
Opening '/home/benoit/RAW/D7100/DCIM/111D7100/NII_2044.NEF' failed:
Raw Nikon plug-in could not open image
---
C'est pas le Raw Nikon plug-in, car j'ai essayé avec le fichier RAW d'un Pentax 
et j'ai le même problème.

Merci d'avance,

--
Benoit

Envoyé avec la messagerie sécurisée [Proton Mail](https://proton.me/).

Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

[Greg Wooledge]

On Wed, Nov 02, 2022 at 12:45:57PM -0500, Nicholas Geovanis wrote:
> > > On 2022-11-02 03:40, Anssi Saari wrote:
> > >> Looks like a linux-5.10 source package was indeed added to Buster in
> > >> August and as you noted, it's getting security updates too.

> I'm just curious if this is the first time that a kernel _version_ bump
> took place within the trajectory of a single Debian version? Or have kernel
> _version_ changes always taken place at debian release boundaries before?

It's important to note that this is an optional, newer kernel image.
Users who've just been running buster from the beginning may not even
know about it, and it will have no effect on them.

It's very much UNlike the version bumps on, say, samba that have happened
mid-stable-release in the past.

I'm fairly certain other releases have had optional kernel packages
added to them, but I can't name any other than "etch-and-a-half" off
the top of my head.

https://wiki.debian.org/EtchAndAHalf

Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

[Nicholas Geovanis]

On Wed, Nov 2, 2022, 9:35 AM Anssi Saari  wrote:

> John Boxall  writes:
>
> > On 2022-11-02 03:40, Anssi Saari wrote:
> >> Looks like a linux-5.10 source package was indeed added to Buster in
> >> August and as you noted, it's getting security updates too. There's some
> >> info on the what and when at https://tracker.debian.org/pkg/linux-5.10
> >> but I don't know the why.
> >>
> >
> > Here is the information on the "why":
> >
> > https://www.debian.org/lts/security/2022/dla-3102
>
> Interesting. I thought it might be that but then as backport users are
> usually left out in the cold as far as security updates are concerned, I
> thought it couldn't be.
>

I'm just curious if this is the first time that a kernel _version_ bump
took place within the trajectory of a single Debian version? Or have kernel
_version_ changes always taken place at debian release boundaries before?

>

swap (nog steeds) is het de lvm boot-volgorde ?

[Gijs Hillenius]

Ik graaf/vraag verder over de raid partitie die niet gemount wordt.

Vooraf: hier al eerder gemeld, NAS raid1 server ge(her)installeerd. Ik
heb een swap raid-partitie die bij het booten niet in werking wordt
gesteld.

Ik probeer uit te vinden waarom niet, en hoe ik het kan fixen.

Ik zie (nu pas) dat de (her)installatie een prima log bijhield (in
/var/log/installer/ ).

Daaruit maak ik op dat de swap partitie goed is aangemaakt:

Bijvoorbeeld in /var/log/installer/syslog

"Adding 1950716k swap on /dev/md1.  Priority:-2 extents:1
across:1950716k FS"

en verderop in de log, zie ik mijn tweede (of derde) installatie poging:

,
| Wiping swap signature on /dev/mapper/md1_crypt.
| partman-lvm: Physical volume "/dev/mapper/md1_crypt" successfully created.
| partman-lvm: Volume group "earplug-raid1-swap-vg" successfully created
| partman-lvm: Logical volume "swap-lv" created.
`

of deze:
"debug: /dev/mapper/earplug--raid1--swap--vg-swap--lv: is active swap"

en dan bijna helemaal onderin, als de installer klaar is:

,
| finish-install: dpkg-divert: warning: diverting file 
'/sbin/start-stop-daemon' from an Essential package with rename is dangerous, 
use --no-rename
| in-target: update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64
| in-target: cryptsetup: WARNING: md1_crypt: couldn't determine device type, 
assuming 
| in-target: default (plain).
| in-target: cryptsetup: WARNING: Resume target md1_crypt uses a key file
| finish-install: info: Running /usr/lib/finish-install.d/15cdrom-detect
`


Maar dan, als de machine "echt" herstart, gaat het mis: 

journalctl -xe

,
| systemd[1]: 
dev-mapper-earplug\x2d\x2draid1\x2d\x2dswap\x2d\x2dvg\x2dswap\x2d\x2dlv.device: 
Job 
dev-mapper-earplug\x2d\x2draid1\x2d\x2dswap\x2d\x2dvg\x2dswap\x2d\x2dlv.device/start
 timed>
| systemd[1]: Timed out waiting for device 
/dev/mapper/earplug--raid1--swap--vg-swap--lv
`

en ook

systemd-cryptsetup[805]: Failed to load LUKS superblock on device /dev/md1: 
Invalid argument

die Luks superblock foutmelding, die wordt veroorzaakt door een commando
dat wordt aangeroepen door systemd. Ik weet inmiddels welke:

Ik doe:
/lib/systemd/system-generators/systemd-cryptsetup-generator

dat schrijft naar /tmp/ een aantal bestanden, waaronder
systemd-cryptsetup@md1_crypt.service

In dat bestand staat (onder meer)
ExecStart=/lib/systemd/systemd-cryptsetup attach 'md1_crypt' '/dev/md1'
'/dev/urandom' 'cipher=aes-xts-plain64,size=256,discard'

dat kan ik dus ook vanaf de commandline herhalen, en dan krijg je dus
die failed Luks superblock melding.

Ik weet niet waar dat commando vandaan komt, maar ik neem aan uit de
Debian installer.

De enige link op het Internet waar ik wat mee kon, tot nog toe, is deze:

https://forums.gentoo.org/viewtopic-t-1103832-start-0.html

die doet vermoeden dat het iets te maken heeft met een race tussen crypt
en het klaar zetten van de raid1. Of de lvm-dinges (zie verder).

Maar helaas, zelfs als ik een langere pauze ingeef dan op dat blog (0.3)

ExecStartPre=/bin/sleep 120

^^ twee minuten, dus komt het niet goed. Ik vind sleep 300 ook ok, maar
ik vermoed dat dit het probleem niet is.





En dan is er nog deze link, waar een Debian user iets dergelijks meldt
https://other.debian.org/debian-user/2020/03/msg00620.html

"It looks like cryptsetup is started before LVM."

helaas gaat die thread niet verder.

Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

[Anssi Saari]

John Boxall  writes:

> On 2022-11-02 03:40, Anssi Saari wrote:
>> Looks like a linux-5.10 source package was indeed added to Buster in
>> August and as you noted, it's getting security updates too. There's some
>> info on the what and when at https://tracker.debian.org/pkg/linux-5.10
>> but I don't know the why.
>> 
>
> Here is the information on the "why":
>
> https://www.debian.org/lts/security/2022/dla-3102

Interesting. I thought it might be that but then as backport users are
usually left out in the cold as far as security updates are concerned, I
thought it couldn't be.

Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

[John Boxall]

On 2022-11-02 03:40, Anssi Saari wrote:


Looks like a linux-5.10 source package was indeed added to Buster in
August and as you noted, it's getting security updates too. There's some
info on the what and when at https://tracker.debian.org/pkg/linux-5.10
but I don't know the why.



Here is the information on the "why":

https://www.debian.org/lts/security/2022/dla-3102

--
Regards,

John Boxall

Re: Éteindre ou redémarrer sa machine à partir de son user

[Alexandre D]

Bonjour,

Problème résolu avec un "apt install polkitd" qui s'était désinstaller 
par erreur.


A++


⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄ ⠀⠀  
Alexandre D.
https://alexbook.fr
alexan...@alexbook.fr

- - - - - - -
System : Debian SID
- - - - - - - -

Le 02/11/2022 à 13:57, Alexandre D a écrit :


Bonjour à tous,

Ma machine tourne sur une Debian SID depuis 2018, voici la 
configuration à ce jour :


  * OS :Debian GNU/Linux bookworm/sid x86_64
  * Kernel : 6.0.0-2-amd64
  * Shell : bash 5.2.2


Depuis une mise à jour installée hier, je ne peux plus reteindre ou 
redémarrer ma machine depuis mon compte utilisateur, voici le retour 
des commandes :


  * systemctl poweroff --> Call to PowerOff failed: Access denied
  * systemctl reboot --> Call to Reboot failed: Access denied

Avez-vous une idée pour résoudre le problème ?
Par avance, merci.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄ ⠀⠀  
Alexandre D.
https://alexbook.fr
alexan...@alexbook.fr

- - - - - - -
System : Debian SID
- - - - - - - -

Éteindre ou redémarrer sa machine à partir de son user

[Alexandre D]

Bonjour à tous,

Ma machine tourne sur une Debian SID depuis 2018, voici la configuration 
à ce jour :


 * OS :Debian GNU/Linux bookworm/sid x86_64
 * Kernel : 6.0.0-2-amd64
 * Shell : bash 5.2.2


Depuis une mise à jour installée hier, je ne peux plus reteindre ou 
redémarrer ma machine depuis mon compte utilisateur, voici le retour des 
commandes :


 * systemctl poweroff --> Call to PowerOff failed: Access denied
 * systemctl reboot --> Call to Reboot failed: Access denied

Avez-vous une idée pour résoudre le problème ?
Par avance, merci.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋
⠈⠳⣄ ⠀⠀  
Alexandre D.
https://alexbook.fr
alexan...@alexbook.fr

- - - - - - -
System : Debian SID
- - - - - - - -

Re: System Font

[Curt]

On 2022-11-02, David Wright  wrote:
>
> Perhaps try https://support.mozilla.org/en-US/questions/1239467
> though I don't understand their "Don't choose a value below 1.0 or
> about [is that above?] 4.0", because the value I have is -1.5
> (ie negative, and I didn't choose it).

My understanding is that an extreme value might render the address bar
unusable, in which case you'd be unable to change the parameter back
again to some more sensible value. 

> But I don't know what this would have to do with i3wm or Plasma,
> or anything else outside FF. (I don't use a DE so I can't check.)
>
> Cheers,
> David.
>
>


-- 

Re: loss of mbmon function

[gene heskett]

On 11/2/22 07:26, Alexander V. Makartsev wrote:

On 02.11.2022 05:55, gene heskett wrote:

On 11/1/22 16:52, Alexander V. Makartsev wrote:
First step is to find model and make of IC that provides sensor 
functions.

Does this command gives any clues?
$ sudo sensors-detect


answered yes to all the default NO questions and still got only:
# Chip drivers
coretemp
nct6775

Which are now loaded, but still no voltages or fans are reported.


These two has to be sufficient. Just make sure these modules are loaded:
$ lsmod | grep -iE 'coretemp|nct6775'

Now "sensors" utility should be able to output values from every 
available sources of super I/O IC.

    $ sensors

They were not autoloaded, which I'd call a bug, but manually modprobed 
and now present

in an lsmod output, sensors still aren't working except in the bios.

gkrellm and sensors both say essentially the same thing:
ene@coyote:~$ sensors
coretemp-isa-
Adapter: ISA adapter
Package id 0:  +32.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0:    +30.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1:    +30.0°C  (high = +84.0°C, crit = +100.0°C)
Core 2:    +32.0°C  (high = +84.0°C, crit = +100.0°C)
Core 3:    +30.0°C  (high = +84.0°C, crit = +100.0°C)
Core 4:    +32.0°C  (high = +84.0°C, crit = +100.0°C)
Core 5:    +30.0°C  (high = +84.0°C, crit = +100.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:    +27.8°C  (crit = +119.0°C)
temp2:    +29.8°C  (crit = +119.0°C)


And the first disk in the raid fails the read test, 2nd one being tested 
( -t long) now, in fact s/b done.

And it looks exactly like the first drive

gene@coyote:~$ sudo smartctl /dev/sdf -a
[sudo] password for gene:
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-19-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model: Samsung SSD 870 EVO 1TB
Serial Number:    S626NF0R302502E
LU WWN Device Id: 5 002538 f413394a9
Firmware Version: SVT01B6Q
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:  512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:  2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is:    Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Nov  2 08:03:40 2022 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)    Offline data collection activity
                was never started.
                Auto Offline Data Collection: Disabled.
Self-test execution status:  ( 117)    The previous self-test 
completed having

                the read element of the test failed.
Total time to complete Offline
data collection:         (    0) seconds.
Offline data collection
capabilities:              (0x53) SMART execute Offline immediate.
                Auto Offline data collection on/off support.
                Suspend Offline collection upon new
                command.
                No Offline surface scan supported.
                Self-test supported.
                No Conveyance Self-test supported.
                Selective Self-test supported.
SMART capabilities:    (0x0003)    Saves SMART data before entering
                power-saving mode.
                Supports SMART auto save timer.
Error logging capability:    (0x01)    Error logging supported.
                General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   2) minutes.
Extended self-test routine
recommended polling time:      (  85) minutes.
SCT capabilities:        (0x003d)    SCT Status supported.
                SCT Error Recovery Control supported.
                SCT Feature Control supported.
                SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE UPDATED  
WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   099   099   010    Pre-fail 
Always   -   1
  9 Power_On_Hours  0x0032   097   097   000    Old_age 
Always   -   10581
 12 Power_Cycle_Count   0x0032   099   099   000    Old_age 
Always   -   58
177 Wear_Leveling_Count 0x0013   099   099   000    Pre-fail 
Always   -   21
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   099   099   010    Pre-fail 
Always   -   1
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age 
Always   -   0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age 
Always   - 

Re: Helium [was: t-bird screwing up]

[gene heskett]

On 11/2/22 01:07, David Wright wrote:

On Tue 01 Nov 2022 at 06:49:09 (+0100), to...@tuxteam.de wrote:

On Mon, Oct 31, 2022 at 06:32:17PM -0400, gene heskett wrote:

[...]


I think, but don't know for sure, that they were also helium filled drives,
a guaranteed disaster.

They used the helium to make the heads fly lower, and when the helium leaked
out, and air leaked in,

Possible.


the heads flew too high to read the disk. I don't know where Seagate
recruited the engineers who thought
up that idea,

Whatever, even I with an 8th grade diploma, knows you cannot keep helium
anyplace for very long. Put it in a monel metal
bottle with walls an inch thick and its molecules's are so small that 10% of
it is gone in 6 or 7 hours.

So the He cylinders that we used after a few months in storage
really contained nothing at all!
We had such large bottles at Stellardyne Labs, in Sandy Eggo in the 
early 1960 time frame, used to test the
ullage pressure regulators that kept the Atlas from collapsing under its 
own weight when it was fully fueled
and ready to give John Glenn his first orbital ride.  The procedure for 
the end of the night shift was to pump
it all into this bank of bottles with a huge cardox 6 stage compressor 
in the back yard, putting them at around
7200 psi. All recorded in an electronic log on rolls of graphic printer 
paper.


These bottles had monel walls about 2" thick, 10 feet tall, a dozen of  
them. Pipes to/from were about 3" in

diameter, monel with a 1" bore.

8 hours later when the day shift clocked in, those bottles were down to 
5800 lbs. That place used 95% of the
US production of Helium at the time, with a new truckload at about $100k 
worth of helium nominally 2 x a

week to keep it operational.

I ran the recorders that logged the tests on those pressure regulators 
for several months. I was that same year,
a bench tech at Oceanographic Engineering with a backyard dock right on 
the bay, building the tv cameras that
were on the navy's Trieste submersible when it went to the bottom of the 
mohole. So my fingerprints were all
over those 2 cameras which worked well at 18,000 psi 37k feet down . So 
I have been there, and done that in

what most would call pretty exotic places.

I spent the last 18+ years of my working life keeping the local CBS 
affiliate on the air, without help other than
min wage tx operators about 80% of that time. The only stuff that got 
shipped to the factory when it broke was
stuff they didn't supply manual's on for proprietary reasons. I did all 
the rest. The work was fun, sometimes the
people weren't. One girl who was legendarily hard on news cameras was 
eventually fired, but I wasn't fire-able.
And I have been accused of walking on electronic water several times. To 
me, its a chuckle, goes with the territory.

And these

jerks thought they could seal it up in a drive housing 1/16" thick?

The operative word is seal, not the thickness of the monel walls.
Seal—and no cracks.
You still don't get it, the helium molecule is so small it wiggles thru 
a steel walls  huge molecules

like they were a layer of felt. Monel alloy is denser but it still leaks.

This is only a half-truth. You know what goes out faster than helium?
Vacuum. And there was a whole glorious epoch in electronics which did
rely on keeping vacuum "in". You should have some fond memories of
that.


I do, and there are still places where a vacuum tube is still the best 
way to do the job.

To be fair, most vacuum tubes aren't bathed in helium, but air, and
then only at a one atmosphere differential pressure. A gas cylinder
might be as high as 500 atmospheres.

And vacuum tubes do contain a getter to deal with outgassing, which
will help mitigate slight leaks.
Or, in the case of a high power beam tube such as the now old technology 
klystron, where
the magnetically focused electron beam catches and carries the 
occasional gas molecule,
and carries it to the collector bucket, a huge copper funnel with at 
least 70 gallons of pure
water a minute to cool it, the gas hitting the copper so hard its buried 
and takes weeks to
escape back into the vacuum. They were very expensive, and I have tested 
more than one
and found it gassy but as long as it didn't arc-over, I could apply the 
beam power slowly and
watch the body current fall over the next few hours until it was making 
90% power out of a
tube a station in New Orleans had starved for coolant and burnt the 
paint off the collector bucket,
and sold it to us for 10k$.  All while 4 state engineers with EE's on 
the wall were claiming
it wouldn't work as it was bent in shipment from bad repacking. I simply 
bent the magnetic

field to match.

To me, they didn't understand the physics involved including E=M*C*C, I 
did and do.
They should have sued the school that issued that EE for a tuition 
refund for not
teaching them right.  Einsteins theory ought to be the first thing they 
teach, not skipped,
Its effects on the transit time of any vacuum tube 

Test ML

[ajh-valmer]

Essai : désolé

Re: loss of mbmon function

[Alexander V. Makartsev]

On 02.11.2022 05:55, gene heskett wrote:

On 11/1/22 16:52, Alexander V. Makartsev wrote:
First step is to find model and make of IC that provides sensor 
functions.

Does this command gives any clues?
$ sudo sensors-detect


answered yes to all the default NO questions and still got only:
# Chip drivers
coretemp
nct6775

Which are now loaded, but still no voltages or fans are reported.


These two has to be sufficient. Just make sure these modules are loaded:
$ lsmod | grep -iE 'coretemp|nct6775'

Now "sensors" utility should be able to output values from every 
available sources of super I/O IC.

    $ sensors


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀https://www.debian.org
⠈⠳⣄

Re: Nettoyage du spam : octobre 2022

[Jean-Pierre Giraud]

Bonjour Fab et à tous,

Le 02/11/2022 à 10:12, Fab a écrit :

Hello la liste,

J'ai noté qu'il faut être au moins 5 relecteurs afin que nos 
notifications de spams soient prises en compte.


C'est super simple/rapide à faire. Encore un tout petit effort ;)

f.


Merci pour ce soutien, et c'est vrai, c'est vraiment simple et rapide : 
en comptant le temps de mise à jour de la page du wiki, cela ne me prend 
qu'environ 15 minutes par mois.




Le 01/11/2022 à 00:23, Jean-Pierre Giraud a écrit :

Bonjour,
Comme nous sommes en novembre, il est désormais possible de
traiter les archives du mois d'octobre 2022 des listes francophones.

N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs


et de modifier le nombre de relecteurs...

pour que nous sachions où nous en sommes.

Détails du processus de nettoyage du spam sur :

https://wiki.debian.org/I18n/FrenchSpamClean



Si vous avez des difficultés pour vous inscrire sur le wiki pour le 
modifier, n'hésitez pas à le signaler.


Amicalement,
jipege


OpenPGP_signature
Description: OpenPGP digital signature

Re: Helium [was: t-bird screwing up]

[Curt]

On 2022-11-02, David Wright  wrote:
>
> To be fair, most vacuum tubes aren't bathed in helium, but air, and
> then only at a one atmosphere differential pressure. A gas cylinder
> might be as high as 500 atmospheres.

I always thought vacuum tubes weren't filled with anything but a "high
vacuum" and electrodes.


Gas-filled tubes, on the other hand, are filled with a gas.

Seems fair to me.

> And vacuum tubes do contain a getter to deal with outgassing, which
> will help mitigate slight leaks.
>
> Cheers,
> David.
>
>


-- 

Re: Nettoyage du spam : octobre 2022

[Fab]

Hello la liste,

J'ai noté qu'il faut être au moins 5 relecteurs afin que nos 
notifications de spams soient prises en compte.


C'est super simple/rapide à faire. Encore un tout petit effort ;)

f.



Le 01/11/2022 à 00:23, Jean-Pierre Giraud a écrit :

Bonjour,
Comme nous sommes en novembre, il est désormais possible de
traiter les archives du mois d'octobre 2022 des listes francophones.

N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs
pour que nous sachions où nous en sommes.

Détails du processus de nettoyage du spam sur :

https://wiki.debian.org/I18n/FrenchSpamClean

Termin spotkania

[Marcin Sobociński]

Szanowni Państwo,

Od ponad 7 lat skutecznie wspieramy naszych partnerów w pozyskiwaniu klientów. 
Świadczymy usługę generowania leadów z kilkoma unikalnymi cechami jak gwarancja 
realnego uruchomienia rozmów lub wymiana kontaktu. Nadmienię także, iż kontakty 
przekazywane są na wyłączność.

Jeśli w chwili obecnej poszukujecie Państwo nowych zapytań i leadów 
sprzedażowych proszę o kontakt lub wskazanie terminu rozmowy.


Pozdrawiam
Marcin Sobociński

Re: qemu ISO Boot Failure (CDROM boot failure code : 0004)

[Charlie Schindler]

Hi

did you solve this? i got this problem, too with qemu 7 and ubuntu 22.04.1

--
--
cordially

Charlie Schindler
+66 9 1083 7897

Re: Helium [was: t-bird screwing up]

[Tim Woodall]

On Wed, 2 Nov 2022, David Wright wrote:


Whatever, even I with an 8th grade diploma, knows you cannot keep helium
anyplace for very long. Put it in a monel metal
bottle with walls an inch thick and its molecules's are so small that 10% of
it is gone in 6 or 7 hours.?


So the He cylinders that we used after a few months in storage
really contained nothing at all!



I assume this is down to the type of metal. Similar to the fact that you
cannot inflate tyres using CO2 other than as an emergency measure as CO2
escapes remarkably quickly. N2, a smaller molecule, has no such
problems.


And these

jerks thought they could seal it up in a drive housing 1/16" thick?


The operative word is seal, not the thickness of the monel walls.
Seal?and no cracks.


This is only a half-truth. You know what goes out faster than helium?
Vacuum. And there was a whole glorious epoch in electronics which did
rely on keeping vacuum "in". You should have some fond memories of
that.


To be fair, most vacuum tubes aren't bathed in helium, but air, and
then only at a one atmosphere differential pressure. A gas cylinder
might be as high as 500 atmospheres.

And vacuum tubes do contain a getter to deal with outgassing, which
will help mitigate slight leaks.



I don't recall ever talking about this in my student days and I cannot
begin to guess how to calculate it now, but I'd expect a porous to He
enclosure but otherwise sealed would only lose He to the point that
there was a partial vacuum. Beyond that point, any He that entered the
walls would return to the enclosure with very high probability.

I did do some vacuum stuff at college, although not about vacuum tubes
specifically, and I'd assume the getter is just there to catch the
outgassing you cannot bake out and even a small leak would quickly
render the tube useless.

I've wondered how CERN deals with outgassing - perhaps the magnets act
as a cold trap.

Re: [SECURITY] [DLA 3173-1] linux-5.10 security update

[Felix Miata]

Anssi Saari composed on 2022-11-02 09:40 (UTC+0200):

> John Boxall wrote:

>> Did I miss something in the last three years? When did buster go to a
>> 5.10 kernel? My buster system is still on kernel 4.19.

> Looks like a linux-5.10 source package was indeed added to Buster in
> August and as you noted, it's getting security updates too. There's some
> info on the what and when at https://tracker.debian.org/pkg/linux-5.10
> but I don't know the why.

> Maybe this is for Buster's LTS lifecycle and 4.19 is expected to go EOL
> before Buster does? Just a guess.

According to https://wiki.debian.org/DebianReleases Buster doesn't have an LTS. 
:p

Projected EOL for 4.19 currently is 2024-12.
https://www.kernel.org/category/releases.html
-- 
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: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

[Anssi Saari]

John Boxall  writes:

> Did I miss something in the last three years? When did buster go to a
> 5.10 kernel? My buster system is still on kernel 4.19.

Looks like a linux-5.10 source package was indeed added to Buster in
August and as you noted, it's getting security updates too. There's some
info on the what and when at https://tracker.debian.org/pkg/linux-5.10
but I don't know the why.

Maybe this is for Buster's LTS lifecycle and 4.19 is expected to go EOL
before Buster does? Just a guess.