Re: partition reporting full, but not
On 20/2/24 18:11, Keith Bainbridge wrote: On 19/2/24 14:20, Keith Bainbridge wrote: On 19/2/24 10:26, 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. 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. So I'm starting a new thread on that topic. So I'm back to see some more helpful hints. Thanks folk I am convinced that the missing space is used by btrfs snapshot process. But WHY is the used space reporting on my daily driver LESS than that on the spare machine 29G vs 35G? The original install was the same .iso Ah well I could add some of the spare space the the / partition, but how much? Play safe and use the lot, making it 60G compared to 63G on my daily driver. (And create some free space off the data partition before it's too late.) Just as well I have time on my hands Again, thanks to all for your suggestions I am sure I saw a response to comment of mine, where I was misunderstood in the numbers I quoted for used space on my daily driver - 29G; and the space used by the problem machine - 35G. There was a suggestion that I had not updated it as often as daily driver. I had kept problem box as up to date as daily until a few days ago when it refused to update due to lack of space. This is when I discovered I had a problem. It is switched off at present, pending my deciding whether to expand / partition or re-install on the free space on ext4. I will delete a few snapshots before I proceed, just to see what happens - I'll do that shortly, in fact, now I can see that it may have a bigger affect than I figured. Now a minor amendment to my last note, where deleting snapshots has haad no bearing on used space. Before I started, df reported 28G used, compared to 29G used yesterday. Remember my home is sym-linked from another partition. du is reporting /home is 3M which is the original / home/keith and re-named to keep it handy IN CASE I need it some day - like when I did some major surgery on that data partition the other week. I'm trying to say that nothing I've done overnight has changed used space. There were no packages to upgrade today. df is now reporting 27G used on / confirming btrfs seems to take time to reflect changes in snapshots. Back later. Back. On booting up problem machine I was greeted with warnings in disk space low on /. I generally don't log into desktop on this machine. Deleted 4 snapshots. df immediately reported used space 33G (down from 35G) and free space 2.9G, up from ~200M at login. I don't think I've EVER seen used space and free space equal size before. I rebooted just to see if anything changed. 10 mins later df is still reporting Size Used Avail Use% Mounted on 36G 33G 2.9G 92% / apt update/upgrade gave me 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 337 MB of archives. which I reckon is what I got yesterday after I moved my home to my data partition and Quoted from 19Feb at 10:26 (UTC 18Feb at 23:26): 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. And earlier:My
utilisation de nis et nfs pour un réseau de 32 postes
Bonjour, J'ai un réseau totalement avec débian 11 (que je compte mettre à jour avec la version 12), constitué d'un serveur avec deux cartes réseau, l'une reliée à l’extérieur par la fibre (DHCP) et l'autre carte (Adresse IP fixe 192.168.200.0) reliée à un switch. Ce switch est relié à 32 postes (avec IP fixe de 192.168.200.10 à 192.168.200.50, adresse de la passerelle 192.168.200.0, masque de sous réseau 255.255.255.0). Les 32 postes sont utilisés par une classe d'élèves. J'ai 200 élèves à gérer, donc 200 profil différent. Pour que chaque poste accède à internet, j'ai fais iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Est ce judicieux ? J'ai essayé avec NIS avec debian 11, l'authentification à l'air de bien fonctionner. Pour l'authentification, NIS est il bien adapté pour ce genre de configuration ? Par contre au niveau de l'export (NFS), cela rame un peu (je me rend compte que j'exporte l'ensemble du home serveur sur tous les clients et non celui uniquement de l'utilisateur). Comment faire pour exporter sur la machine cliente uniquement le profil de l'utilisateur et non tous les utilisateurs ? Sur le serveur, j'ai mis à la fin dans le fichier /etc/exports /home/NFS_Partage 192.168.200.1/24(rw,sync,no_subtree_check) mais j'hésite avec /home/NFS_Partage 192.168.0.0/24(rw,all_squash,anonuid=1000,anongid=1000,sync,no_subtree_check) Sur le client, j'ai mis à la fin dans le fichier fstab DomaineNFS:/home/NFS_Partage /home nfs defaults 0 0 On m'a parlé de LDAP, mais je ne sais pas trop comment m'y prendre. Est il préférable d'utiliser LDAP ou NIS pour l'authentification ? Existe il un petit manuel simple pour créer 200 utilisateurs. Mon réseau fonctionne, mais rame beaucoup au delà de 4 utilisateurs ? et je n'arrive pas à trouver une solution. Un grand merci pour votre aide. Olivier
Re: Timer doing apt update
Le 20/02/2024 à 01:58, Andy Smith a écrit : Hi, On Mon, Feb 19, 2024 at 08:35:18PM +0100, Erwan David wrote: Sorry il was packagekit, I made a mistake while writing. If it's packagekit then isn't it going to be some part of your desktop environment? Which desktop environment are you using? GNOME will download updates and prompt you to install. To disable this open "GNOME software",m burger menu, "Update Preferences". The default behaviour of GNOME Software is to only download upgrades when on an unmetered connection so if you are using GNOME and this is what is happening, then as Max says telling NetworkManager that your connection is metered should stop it. I disable the timers, thanks I don't think it's any of the systemd timers or unattended-upgrades. Thanks, Andy I use KDE, and I do not know wether discover does an update by itself. I do not thind any setting about this -- Erwan David
Re: Timer doing apt update
Le 20/02/2024 à 03:20, Max Nikulin a écrit : On 20/02/2024 02:35, Erwan David wrote: Le 19/02/2024 à 18:00, Max Nikulin a écrit : systemctl disable --now apt-daily.timer apt-daily-upgrade.timer Perhaps it is possible to write a script that will respect connection.metered property set by NetworkManager. I disable the timers, thanks To avoid confusion, these timers are from the apt package, not from unattended-upgrades. So they are active on most Debian hosts. Desktop environments may display notifications after actions initiated by these timers. Likely desktop environments may do more, e.g. to query GNOME application shop for updates and initiate more frequent updates. I'll have a look at connection.metered Out of curiosity I have queried https://codesearch.debian.net. It seems, apt has no notion of metered connection. Perhaps the effect can be achieved by adding to unit configuration some Condition* mentioned in systemd.directives(7) https://stackoverflow.com/questions/43228973/detect-if-current-connection-is-metered-with-networkmanager busctl get-property \ org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager Metered It would also require to configure NetworkManager to set this correctly. Eg When I use USB tethering. (same NetworkManager connexion may be used at different places, without any way to simply detect this, when you do not use Wifi) -- Erwan David
Re: partition reporting full, but not
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 if you have not aliased df to btrfs filesystem df. -- 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: Banning a user from posting to Debian lists
just checking -- CK
Re: Erreur nvidia suite upgrade noyau 6.1.0-18
Salut, J'avais eu un problème similaire. Sur je ne sais plus quel forum, on préconisait de passer au kernel 6.5.0 via les dépôts backports. Je l'ai fait et les paquets kenel et nvidia se sont bien isntallés et compilés. Pour passer par les backports j'ai ajouter cette ligne dans /etc/apt/sources.list deb http://ftp.fr.debian.org/debian/ bookworm-backports main non-free contrib non-free-firmware J'espère que ça vous aidera. Le 19/02/2024 20:42, ajh-valmer a écrit : On Monday 19 February 2024 19:17:22 Patrick ZAJDA wrote: et epsilon Merci : La mise à jour est déjà disponibles sur les dépôts officiels, si bookworm-updates est bien dans les listes de sources alors la version 525.147.05-7~deb12u1 devrait être disponible à l'installation Il semblerait que la mise à jour du kernel 6.1.0-18-amd64, ne concerne que la version Debian SID. J'ai retenté un apt update => apt upgrade en vain, c'est un échec, ma Debian-12 refuse de dépasser le noyau 6.1.0-17-amd64 : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062932 Pour la partie drivers Nvidia : https://lists.debian.org/debian-stable-announce/2024/02/msg2.html The following packages have been updated to correct the problem: Source package Fixed version nvidia-graphics-drivers525.147.05-7~deb12u1 nvidia-graphics-drivers-tesla 525.147.05-7~deb12u1 nvidia-graphics-drivers-tesla-470 470.223.02-4~deb12u1 nvidia-settings525.147.05-1~deb12u1 Je ne peux rien tester tant que je ne peux upgrader. Bonne soirée. > $ apt policy nvidia-driver > nvidia-driver: > Installé : 525.147.05-7~deb12u1 > Candidat : 525.147.05-7~deb12u1 >Table de version : >*** 525.147.05-7~deb12u1 500 > 500 https://deb.debian.org/debian bookworm-updates/non-free > amd64 Packages > 100 /var/lib/dpkg/status > 525.147.05-4~deb12u1 500 > 500 https://deb.debian.org/debian bookworm/non-free amd64 Packages -- Nicolas + nico...@noisyspoon.net
Re: partition reporting full, but not
On 19/2/24 14:20, Keith Bainbridge wrote: On 19/2/24 10:26, 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. 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. So I'm starting a new thread on that topic. So I'm back to see some more helpful hints. Thanks folk I am convinced that the missing space is used by btrfs snapshot process. But WHY is the used space reporting on my daily driver LESS than that on the spare machine 29G vs 35G? The original install was the same .iso Ah well I could add some of the spare space the the / partition, but how much? Play safe and use the lot, making it 60G compared to 63G on my daily driver. (And create some free space off the data partition before it's too late.) Just as well I have time on my hands Again, thanks to all for your suggestions I am sure I saw a response to comment of mine, where I was misunderstood in the numbers I quoted for used space on my daily driver - 29G; and the space used by the problem machine - 35G. There was a suggestion that I had not updated it as often as daily driver.I had kept problem box as up to date as daily until a few days ago when it refused to update due to lack of space. This is when I discovered I had a problem. It is switched off at present, pending my deciding whether to expand / partition or re-install on the free space on ext4. I will delete a few snapshots before I proceed, just to see what happens - I'll do that shortly, in fact, now I can see that it may have a bigger affect than I figured. Now a minor amendment to my last note, where deleting snapshots has haad no bearing on used space. Before I started, df reported 28G used, compared to 29G used yesterday. Remember my home is sym-linked from another partition. du is reporting /home is 3M which is the original /home/keith and re-named to keep it handy IN CASE I need it some day - like when I did some major surgery on that data partition the other week. I'm trying to say that nothing I've done overnight has changed used space. There were no packages to upgrade today. df is now reporting 27G used on / confirming btrfs seems to take time to reflect changes in snapshots. Back later. -- All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
Re: sshd Match regel
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.
Re: partition reporting full, but not
On 19/2/24 13:00, Max Nikulin wrote: On 19/02/2024 06:26, Keith Bainbridge wrote: So later yesterday afternoon I created a new snapshot with no obvious change is free space. Effect of snapshots is delayed. When you remove a file that does not belong to any snapshot, some disk space is reclaimed. However to restore a file (even a removed later) from a snapshot, it must be stored anywhere. That is why snapshots consume disk space. Try to remove unnecessary snapshots. I have no idea if btrfs requires additional maintenance. I just removed 3 snapshots from my daily driver with no change in used space reported by df Mindful of the fact that somebody considers it may take time to reflect changes within the snapshots, I'll check again tomorrow morning -- All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
Re : Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, Je découvre ce fil de discussion. Je ne comprends pas que l'on puisse encore travailler avec CRON. Alors que ANACRON est indépendant de la période de fonctionnement du PC. Peut-etre que vous pourriez trouver une piste de solution dans l'article de Léa Linux espliquant les fonctionalités de at, cron et anacron. https://lea-linux.org/documentations/Programmation_de_travaux_avec_at_cron_anacron Bon courage Cassis - Mail d'origine - De: Bernard Bass À: Liste Debian Envoyé: Sun, 18 Feb 2024 00:32:25 +0100 (CET) Objet: Comment remplacer l'utilisateur root pour utiliser le service cron ? Bonjour, Voilà ma question : Comment remplacer l'utilisateur root pour utiliser le service cron ? ## ## Utiliser cron et crontab sur Debian 12. Un utilisateur sudoer est créé pour utiliser sudo et administrer le système. *L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer.* Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées : *SERVEUR cron : Authentication failure Password root of that user should be expried.* Le compte utilisateur root est verrouillé et le mot de passe est forcé pour expirer, il ne peut être utilisé pour lancer des tâches cron. *COMMENT CREER UN UTILISATEUR POUR REMPLACER ROOT ET UTILISER SA CRONTAB ?* Créer un utilisateur pour remplacer root : sudo adduser gestionnaire sudo bash echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers Ajouter gestionnaire au groupe cron : gpasswd -a gestionnaire cron Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif. *Comment faire comprendre au système qu'il faut utiliser le nouvel utilisateur pour lancer les tâches cron du système ?* *( la crontab de l'utilisateur sudoer, la crontab de l'utilisateur gestionnaire, les tâches cron.daily . , les tâches des services dans le dossier cron.d ) * ## ## La recherche actuelle : *( Les tâches cron.daily . , les tâches des services dans le dossier cron.d ne fonctionnent pas **" cron **: **Authentication failure " **) * ## Utiliser cron et crontab sur Debian 12. Un utilisateur sudoer est créé pour utiliser sudo et administrer le système. L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer. Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées. ## sudo journalctl -p err févr. 11 16:25:01 SERVEUR CRON[874565]: pam_unix(cron:account): account root has expired (account expired) *févr. 11 16:25:01 SERVEUR cron[874565]: Authentication failure * sudo[874537]: pam_unix(sudo:session): session closed for user root Le compte utilisateur root est verrouillé et ne peut être utilisé pour lancer des tâches cron. *Password root of that user should be expried. * ## *COMMENT CREER UN UTILISATEUR ROOT POUR REMPLACER ROOT ET UTILISER SA CRONTAB ? * Comment exécuter une commande exigeant un plus haut niveau de permission (root ou racine) ? Créer un utilisateur pour remplacer root : sudo adduser gestionnaire sudo bash echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers Ajouter gestionnaire au groupe cron : gpasswd -a gestionnaire cron Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif. *Comment faire comprendre au système qu'il faut utiliser gestionnaire pour lancer les tâches cron ?* ... ... ## sudo systemctl stop cron sudo systemctl start cron sudo systemctl restart cron # Identifier les processus cron : sudo systemctl status cron # Arrêter un processus cron : sudo kill PID
Re: Timer doing apt update
On Tue, Feb 20, 2024 at 03:56:49AM +, Andy Smith wrote: > On Mon, Feb 19, 2024 at 10:21:24PM -0500, Greg Wooledge wrote: > > Does anyone know when these things changed, and why on earth nobody > > knew about it?! Did I miss a section in the release notes or something? > > Why are you shocked by this? Most of it is disabled by default (no > update / upgrade / unattended-upgrade). You have to set things like > APT::Periodic::Update-Package-Lists to 1. > > It's been there since Debian 9 (stretch) IIRC. > > The handbook has stuff about it. > > https://debian-handbook.info/browse/stable/sect.regular-upgrades.html According to this page, the configuration is in /etc/apt/apt.conf.d/10periodic (which does not exist on my system). Also according to this page, there is a script in /usr/lib/apt/apt.systemd.daily which describes the configuration variables (this script does exist). According to the /usr/lib/apt/apt.systemd.daily script, the /etc/apt/apt.conf.d/10periodic file has to be created if you want to change the defaults. OK. Also according to that script, the default values are listed in the comments of said script. These comments include: # APT::Periodic::Enable "1"; # - Enable the update/upgrade script (0=disable) which, if I'm reading this correctly, says that this thing is enabled by default. "This thing" being an "update/upgrade script". Whatever that means. The comments also include: # APT::Periodic::Update-Package-Lists "0"; # - Do "apt-get update" automatically every n-days (0=disable) # # APT::Periodic::Download-Upgradeable-Packages "0"; # - Do "apt-get upgrade --download-only" every n-days (0=disable) I'm not sure how to interpret this combination of things. Do these default settings mean "the update/upgrade script will run, but it won't actually do anything"?
Re: Timer doing apt update
Hi, On Mon, Feb 19, 2024 at 10:21:24PM -0500, Greg Wooledge wrote: > Does anyone know when these things changed, and why on earth nobody > knew about it?! Did I miss a section in the release notes or something? Why are you shocked by this? Most of it is disabled by default (no update / upgrade / unattended-upgrade). You have to set things like APT::Periodic::Update-Package-Lists to 1. It's been there since Debian 9 (stretch) IIRC. The handbook has stuff about it. https://debian-handbook.info/browse/stable/sect.regular-upgrades.html Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: red SATA cables "notoriously bad"?
On 2/19/24 22:15, Andy Smith wrote: Hi, On Mon, Feb 19, 2024 at 10:06:23PM -0500, gene heskett wrote: Andy, look at that CET after my name in the sig, that stands for Certified Electronics Tachnician. There isn't a polite way to say this really but unfortunately I am unable to take you seriously as you've posted so many outright incorrect assertions to this mailing list in the past. I can list off my qualifications and experience and still be told pretty often that I don't know what I am talking about, and sometimes I probably don't, so let's leave it at that. Regards, Andy Thats a good way to cap this Andy, thanks. stay well. 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: red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem)
On 20/2/24 08:48, Andy Smith wrote: Hi, On Mon, Feb 19, 2024 at 04:12:44PM -0300, Eike Lantzsch ZP5CGE / KY4PZ wrote: The notorious red SATA cables - I threw them out long ago. The red pigment eats up the fine copper threads, changing the impedance of the cable and eventually making false contact before failing completely. I've never heard of this. I did a bit of searching around and all I can find is assertions that cable colour doesn't matter for SATA. I can't seem to find anything about red pigment damaging the copper. Have you got a reference so I can learn more? I find it unlikely that the color of the outer sheath of a cable affects the conductors as they have their own individual sheaths usually of a different material to the sheath. It's possible that some manufacturer made cables with faulty individual insulation and their brand used a red outer sheath. In that case the color of the sheath correlates with faulty cables but is not the cause of the faulty cables.
Re: Timer doing apt update
On Tue, Feb 20, 2024 at 09:20:11AM +0700, Max Nikulin wrote: > > > systemctl disable --now apt-daily.timer apt-daily-upgrade.timer > To avoid confusion, these timers are from the apt package, not from > unattended-upgrades. So they are active on most Debian hosts. Holy crap... when did this happen? I tried looking on salsa and it looks like the 1.8.y branch has these files, but the jessie branch does not. But I don't know where the "preset: enabled" thing comes from. So maybe the files were there but not enabled by default until recently? Maybe? Does anyone know when these things changed, and why on earth nobody knew about it?! Did I miss a section in the release notes or something?
Re: red SATA cables "notoriously bad"?
Hi, On Mon, Feb 19, 2024 at 10:06:23PM -0500, gene heskett wrote: > Andy, look at that CET after my name in the sig, that stands for Certified > Electronics Tachnician. There isn't a polite way to say this really but unfortunately I am unable to take you seriously as you've posted so many outright incorrect assertions to this mailing list in the past. I can list off my qualifications and experience and still be told pretty often that I don't know what I am talking about, and sometimes I probably don't, so let's leave it at that. Regards, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: red SATA cables "notoriously bad"?
On 2/19/24 20:29, Andy Smith wrote: Hello, On Mon, Feb 19, 2024 at 08:16:49PM -0500, Felix Miata wrote: I've never heard of this. I did a bit of searching around and all I can find is assertions that cable colour doesn't matter for SATA. I can't seem to find anything about red pigment damaging the copper. Have you got a reference so I can learn more? Don't you ever read Gene Heskett posts? Ah I see: https://lists.debian.org/debian-user/2023/06/msg00103.html Stefan: Can you point to any evidence? Gene: Just my own life [segue to story from 1970] The usual story. Yeah I skipped that thread the first time around owing to its subject line containing "urban legends". consider searching this very list's archives. Moments of my life I will never get back, and no more authoritative sources unfortunately! Thanks, Andy Andy, look at that CET after my name in the sig, that stands for Certified Electronics Tachnician. We teach EE's which there are 1000's of compared to us, what their profs didn't teach them before issuing that sheepskin they hang on the office wall. I'm also a 1st phone, an easy test I didn't crack a book for. And I was familiar enough, having made a living from electronics for 20+ year including the physics of klystrons when I saw the notice that the test was available so I walked into the profs classroom and laid my fee for the test on his desk. Allocated 4 hours, I handed it back to him in 45 minutes. Of 125 questions, I blacked the right box on 123. He I found had been teaching that course for 5 years, I was the first that passed it. Registered as NB-116. 20 some years later I checked to see how many had passed since, they were up to NB-122. That's telling indeed. Now I'm in my 90th year, and with a fading short term memory and a pita on this list, but I'm still here till I miss roll call some morning. Take care and stay well ANDY. 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: red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem)
On 2/19/24 19:49, Andy Smith wrote: Hi, On Mon, Feb 19, 2024 at 04:12:44PM -0300, Eike Lantzsch ZP5CGE / KY4PZ wrote: The notorious red SATA cables - I threw them out long ago. The red pigment eats up the fine copper threads, changing the impedance of the cable and eventually making false contact before failing completely. I've never heard of this. I did a bit of searching around and all I can find is assertions that cable colour doesn't matter for SATA. I can't seem to find anything about red pigment damaging the copper. Have you got a reference so I can learn more? Thanks, Andy Andy, I am the source of that red cable story. Actually it is not technically a red but a magenta that fluoresces reddish to get that brightness. And my history with early failure of cables that used that dye to color the insulation goes back to the 1970's when the majority of the CB radios sold were from japan, not china. Microphone cables that included a push to talk start failing quite rapidly, The hot red wire was used for that about 99% of the time..Open up the plug or the microphone, the red wire had come unsoldered or broken off, attempt to strip it back to good wire wasn't possible. there was no good copper left anyplace in the cable. Cut an inch of it off where there should have been copper, grab it by the end with suture clamps and thump it with a pencil over white copy paper and shake the copper out of it as a reddish, face powder fine dust, the copper had been I assume made into copper oxide. It took every good tech in the country to start returning mike cables back to the makers as defective before they got the message that that die was poison. That took about 9 months before we could order replacement cable specifing that they would be returned for credit if we found any 'hot" red in the cables they were selling us. The shortage at the time forced them to ship whatever they had I guess. If you goto Loews or any electrical supply where they have to sell NEC approved cabling, you will NOT see that red on any wire on the shelf or in the rack. Then about the time sata came out, they found a new market for that plastic dye, and sure as heck, we had cabling problems out the yang in about 3 years. If you have that hot red wire anyplace in you computer, it will fail, order more cables. Tan, Black, Yellow, but not hot red. And sleep better knowing that time bomb has gone out with the trash. 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: Timer doing apt update
On 20/02/2024 02:35, Erwan David wrote: Le 19/02/2024 à 18:00, Max Nikulin a écrit : systemctl disable --now apt-daily.timer apt-daily-upgrade.timer Perhaps it is possible to write a script that will respect connection.metered property set by NetworkManager. I disable the timers, thanks To avoid confusion, these timers are from the apt package, not from unattended-upgrades. So they are active on most Debian hosts. Desktop environments may display notifications after actions initiated by these timers. Likely desktop environments may do more, e.g. to query GNOME application shop for updates and initiate more frequent updates. I'll have a look at connection.metered Out of curiosity I have queried https://codesearch.debian.net. It seems, apt has no notion of metered connection. Perhaps the effect can be achieved by adding to unit configuration some Condition* mentioned in systemd.directives(7) https://stackoverflow.com/questions/43228973/detect-if-current-connection-is-metered-with-networkmanager busctl get-property \ org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager Metered
Re: red SATA cables "notoriously bad"?
Andy Smith composed on 2024-02-20 01:29 (UTC): > On Mon, Feb 19, 2024 at 08:16:49PM -0500, Felix Miata wrote: >>> I've never heard of this. I did a bit of searching around and all I >>> can find is assertions that cable colour doesn't matter for SATA. I >>> can't seem to find anything about red pigment damaging the copper. >>> Have you got a reference so I can learn more? >> Don't you ever read Gene Heskett posts? > Ah I see: > https://lists.debian.org/debian-user/2023/06/msg00103.html > Stefan: Can you point to any evidence? > Gene: Just my own life [segue to story from 1970] > The usual story. Gene's been around quite a while, working electronics longer than most of us have lived, likely finished his schooling and went to work before Roosevelt died. > Yeah I skipped that thread the first time around owing to its > subject line containing "urban legends". >> consider searching this very list's archives. > Moments of my life I will never get back, and no more authoritative > sources unfortunately! My experience with that particular color cables matches Gene's. Cut one open, and out comes a powdery substance instead of clean copper strands. I think most for gen 1.0 SATA 2 decades ago, so there shouldn't be many still around bogging down 3.0 drives. -- 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: red SATA cables "notoriously bad"?
Hello, On Mon, Feb 19, 2024 at 08:16:49PM -0500, Felix Miata wrote: > > I've never heard of this. I did a bit of searching around and all I > > can find is assertions that cable colour doesn't matter for SATA. I > > can't seem to find anything about red pigment damaging the copper. > > Have you got a reference so I can learn more? > > Don't you ever read Gene Heskett posts? Ah I see: https://lists.debian.org/debian-user/2023/06/msg00103.html Stefan: Can you point to any evidence? Gene: Just my own life [segue to story from 1970] The usual story. Yeah I skipped that thread the first time around owing to its subject line containing "urban legends". > consider searching this very list's archives. Moments of my life I will never get back, and no more authoritative sources unfortunately! Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: red SATA cables "notoriously bad"?
Andy Smith composed on 2024-02-20 00:48 (UTC): > On Mon, Feb 19, 2024 at 04:12:44PM -0300, Eike Lantzsch ZP5CGE / KY4PZ wrote: >> The notorious red SATA cables - I threw them out long ago. The red >> pigment eats up the fine copper threads, changing the impedance of the >> cable and eventually making false contact before failing completely. > I've never heard of this. I did a bit of searching around and all I > can find is assertions that cable colour doesn't matter for SATA. I > can't seem to find anything about red pigment damaging the copper. > Have you got a reference so I can learn more? Don't you ever read Gene Heskett posts? I expect he'll be chiming in on this one shortly While you wait, consider searching this very list's archives. -- 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: Erreur nvidia suite upgrade noyau 6.1.0-18
Le 19 février 2024 ajh-valmer a écrit : > Il semblerait que la mise à jour du kernel 6.1.0-18-amd64, > ne concerne que la version Debian SID. Tu as ça ici : https://packages.debian.org/bookworm/linux-image-6.1.0-18-amd64 https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.76+1_changelog
Re: Timer doing apt update
Hi, On Mon, Feb 19, 2024 at 08:35:18PM +0100, Erwan David wrote: > Sorry il was packagekit, I made a mistake while writing. If it's packagekit then isn't it going to be some part of your desktop environment? Which desktop environment are you using? GNOME will download updates and prompt you to install. To disable this open "GNOME software",m burger menu, "Update Preferences". The default behaviour of GNOME Software is to only download upgrades when on an unmetered connection so if you are using GNOME and this is what is happening, then as Max says telling NetworkManager that your connection is metered should stop it. > I disable the timers, thanks I don't think it's any of the systemd timers or unattended-upgrades. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
red SATA cables "notoriously bad"? (Was Re: Orphaned Inode Problem)
Hi, On Mon, Feb 19, 2024 at 04:12:44PM -0300, Eike Lantzsch ZP5CGE / KY4PZ wrote: > The notorious red SATA cables - I threw them out long ago. The red > pigment eats up the fine copper threads, changing the impedance of the > cable and eventually making false contact before failing completely. I've never heard of this. I did a bit of searching around and all I can find is assertions that cable colour doesn't matter for SATA. I can't seem to find anything about red pigment damaging the copper. Have you got a reference so I can learn more? Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Re: GRUB lost graphical terminal mode
> On 18 Feb 2024 21:28 +0100, from borde...@tutanota.com (Borden): > > what the default is when neither of those are set (which doesn't > > work). Is this another "undocumented feature" of GRUB? > > Would you be willing to post your /boot/grub/grub.cfg for a setup where you > get the blank screen GRUB? Yeah, I probably should have opened with that. Sorry: ``` # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="" # If your computer has multiple operating systems installed, then you # probably want to run os-prober. However, if your computer is a host # for guest OSes installed via LVM or raw disk devices, running # os-prober can cause damage to those guest OSes as it mounts # filesystems to look for things. GRUB_DISABLE_OS_PROBER=false # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal #GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries #GRUB_DISABLE_RECOVERY="true" # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1" ``` For what it's worth, my graphics adapter is an ancient Intel HD 4000 series processor (Ivy Bridge era). It's possible that my card is dying or no longer supported. It's just a pain that it worked a few weeks ago and now it doesn't. It would be nice to know why.
Re: Erreur nvidia suite upgrade noyau 6.1.0-18
On Monday 19 February 2024 19:17:22 Patrick ZAJDA wrote: et epsilon Merci : > La mise à jour est déjà disponibles sur les dépôts officiels, si > bookworm-updates est bien dans les listes de sources alors la version > 525.147.05-7~deb12u1 devrait être disponible à l'installation Il semblerait que la mise à jour du kernel 6.1.0-18-amd64, ne concerne que la version Debian SID. J'ai retenté un apt update => apt upgrade en vain, c'est un échec, ma Debian-12 refuse de dépasser le noyau 6.1.0-17-amd64 : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062932 Pour la partie drivers Nvidia : https://lists.debian.org/debian-stable-announce/2024/02/msg2.html The following packages have been updated to correct the problem: Source package Fixed version nvidia-graphics-drivers525.147.05-7~deb12u1 nvidia-graphics-drivers-tesla 525.147.05-7~deb12u1 nvidia-graphics-drivers-tesla-470 470.223.02-4~deb12u1 nvidia-settings525.147.05-1~deb12u1 Je ne peux rien tester tant que je ne peux upgrader. Bonne soirée. > > $ apt policy nvidia-driver > > nvidia-driver: > > Installé : 525.147.05-7~deb12u1 > > Candidat : 525.147.05-7~deb12u1 > >Table de version : > >*** 525.147.05-7~deb12u1 500 > > 500 https://deb.debian.org/debian bookworm-updates/non-free > > amd64 Packages > > 100 /var/lib/dpkg/status > > 525.147.05-4~deb12u1 500 > > 500 https://deb.debian.org/debian bookworm/non-free amd64 Packages
Re: Timer doing apt update
Le 19/02/2024 à 18:00, Max Nikulin a écrit : On 19/02/2024 14:35, Erwan David wrote: After each boot, the equivalent of apt update is automatically done in background, through policykit (apt database is locked by policykitd). So I think there is a timer triggroing this. I'd like to disable this when my laptop is on expensive link (eg 4G link, or abroad). So I'd like to disable this timer, but I did not find it. If someone knws better than me... Perhaps I missed something since I have no idea why policykit (or polkit?) is involved. You may disable apt timers systemctl disable --now apt-daily.timer apt-daily-upgrade.timer Perhaps it is possible to write a script that will respect connection.metered property set by NetworkManager. Sorry il was packagekit, I made a mistake while writing. I disable the timers, thanks I'll have a look at connection.metered
Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords
Well, it appears like most things in life this one was self inflicted. 郎 Yesterday I was working on another project and to verify something was occurring the 'strace' utility was recommended. It dawned on me that this could help me get a clue as to what was happening to the gnome-keyring-daemon. Using strace attached to the PID of the daemon after a reboot showed it was getting the SIGTERM signal at exactly the top of the hour. What?!! 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 When I want to use it next in order to protect other processes. I certainly hope this is resolved. OTOH, it forced me to recall a number of passwords! 藍 - 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: Orphaned Inode Problem
On Montag, 19. Februar 2024 14:20:52 -03 to...@tuxteam.de wrote: > On Mon, Feb 19, 2024 at 10:02:10AM -0500, Stephen P. Molnar wrote: > > I am running up to date Bookworm on my Debian platform: > > > > Processor AMD FX(tm)-8320 Eight-Core Processor > > Memory 8026MB (5267MB used) > > Machine TypeDesktop > > Operating SystemDebian GNU/Linux 12 (bookworm) > > > > I have been plagued with orphaned inodes. Last night the problem > > cane to a head. When I reboot the computer, after an orphaned inode > > incident created stop, it got as far as the user login. After the > > return I got the Windows infamous blue screen. Restarting produced > > the same problem. > > > > Fortunately, I have another SSD used to test Bookworm, before > > updating on the SSD that is having the problem. I can access the > > problem drive and am in the process of backing up files. > > > > I ran sudo e2fsck -f/dev/sdc1 and got: > > > > Script started on 2024-02-19 08:15:52-05:00 [TERM="xterm-256color" > > TTY="/dev/pts/0" COLUMNS="100" LINES="24"] > > [?2004h(base) ]0;comp@AbNormal: > > ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ sudo e2fsck -f > > /dev/sdc1lcaomo[Ksudo e2fsck -f > > /dev/sdc1 [?2004l > > [sudo] password for comp: > > e2fsck 1.47.0 (5-Feb-2023) > > Pass 1: Checking inodes, blocks, and sizes > > Pass 2: Checking directory structure > > Pass 3: Checking directory connectivity > > /lost+found not found. Create? yes > > Pass 4: Checking reference counts > > Pass 5: Checking group summary information > > > > /dev/sdc1: * FILE SYSTEM WAS MODIFIED * > > /dev/sdc1: 7982363/121577472 files (0.3% non-contiguous), > > 421959365/486307328 blocks > > [?2004h(base) ]0;comp@AbNormal: > > ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ [?2004l > > > > Comments and suggestions will be appreciated. > > This session doesn't show anything to worry about. As far as fsck > is concerned, the file system looks clean. Back up its contents as > quickly as you can and treat the disk with suspicion. There are > other candidate suspects for file system corruption (flaky power > supply, software doing silly things, kernel bugs, loose cables), > but the disk would be the pirmary. > > Cheers Just as an aside note: The notorious red SATA cables - I threw them out long ago. The red pigment eats up the fine copper threads, changing the impedance of the cable and eventually making false contact before failing completely. Of course this does not apply to NVME SSDs. -- Eike Lantzsch KY4PZ / ZP5CGE
Re: Erreur nvidia suite upgrade noyau 6.1.0-18
Le 19/02/2024 à 15:13, ajh-valmer a écrit : On Saturday 17 February 2024 10:49:04 Patrick ZAJDA wrote: Quoi qu'il en soit, une mise à jour a été publié dans bookworm-updates (SUA 252-1) pour corriger le problème de compilation lors de la mise à jour vers le kernel 6.1.0-18. apt update puis apt upgrade devrait donc pouvoir se passer sans problème, à la limite un apt -f install si ça ne passe vraiment pas. Je n'ai pas vu qu'une mise à jour a été publiée dans bookworm-updates, (SUA 252-1) correctif de compilation, mise à jour vers le kernel 6.1.0-18. Ou s'agit-il d'une opération de mise à jour en cours ? https://lists.debian.org/debian-stable-announce/2024/02/msg2.html La mise à jour est déjà disponibles sur les dépôts officiels, si bookworm-updates est bien dans les listes de sources alors la version 525.147.05-7~deb12u1 devrait être disponible à l'installation $ apt policy nvidia-driver nvidia-driver: Installé : 525.147.05-7~deb12u1 Candidat : 525.147.05-7~deb12u1 Table de version : *** 525.147.05-7~deb12u1 500 500 https://deb.debian.org/debian bookworm-updates/non-free amd64 Packages 100 /var/lib/dpkg/status 525.147.05-4~deb12u1 500 500 https://deb.debian.org/debian bookworm/non-free amd64 Packages -- Patrick ZAJDA
Re: Orphaned Inode Problem
On Mon, Feb 19, 2024 at 12:30:30PM -0500, Stephen P. Molnar wrote: [...] > Thanks for he reply. It's somewhat reassuring. > > According to my logs the box had its' last major last upgrade in 2014, so I > shouldn't be too surprised. > > My backup is underweight and should be done sometime tomorrow. I have a 2 > TB HDD I'm going to use for the new install. Fingers crossed... Cheers -- t signature.asc Description: PGP signature
Re: Orphaned Inode Problem
On 02/19/2024 12:20 PM, to...@tuxteam.de wrote: On Mon, Feb 19, 2024 at 10:02:10AM -0500, Stephen P. Molnar wrote: I am running up to date Bookworm on my Debian platform: Processor AMD FX(tm)-8320 Eight-Core Processor Memory 8026MB (5267MB used) Machine TypeDesktop Operating SystemDebian GNU/Linux 12 (bookworm) I have been plagued with orphaned inodes. Last night the problem cane to a head. When I reboot the computer, after an orphaned inode incident created stop, it got as far as the user login. After the return I got the Windows infamous blue screen. Restarting produced the same problem. Fortunately, I have another SSD used to test Bookworm, before updating on the SSD that is having the problem. I can access the problem drive and am in the process of backing up files. I ran sudo e2fsck -f/dev/sdc1 and got: Script started on 2024-02-19 08:15:52-05:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="100" LINES="24"] [?2004h(base) ]0;comp@AbNormal: ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ sudo e2fsck -f /dev/sdc1lcaomo[Ksudo e2fsck -f /dev/sdc1 [?2004l [sudo] password for comp: e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity /lost+found not found. Create? yes Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdc1: * FILE SYSTEM WAS MODIFIED * /dev/sdc1: 7982363/121577472 files (0.3% non-contiguous), 421959365/486307328 blocks [?2004h(base) ]0;comp@AbNormal: ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ [?2004l Comments and suggestions will be appreciated. This session doesn't show anything to worry about. As far as fsck is concerned, the file system looks clean. Back up its contents as quickly as you can and treat the disk with suspicion. There are other candidate suspects for file system corruption (flaky power supply, software doing silly things, kernel bugs, loose cables), but the disk would be the pirmary. Cheers Thanks for he reply. It's somewhat reassuring. According to my logs the box had its' last major last upgrade in 2014, so I shouldn't be too surprised. My backup is underweight and should be done sometime tomorrow. I have a 2 TB HDD I'm going to use for the new install. -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: sshd Match regel
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? Mvg, Rik
Re: Orphaned Inode Problem
On Mon, Feb 19, 2024 at 10:02:10AM -0500, Stephen P. Molnar wrote: > I am running up to date Bookworm on my Debian platform: > > Processor AMD FX(tm)-8320 Eight-Core Processor > Memory8026MB (5267MB used) > Machine Type Desktop > Operating System Debian GNU/Linux 12 (bookworm) > > I have been plagued with orphaned inodes. Last night the problem cane to a > head. When I reboot the computer, after an orphaned inode incident created > stop, it got as far as the user login. After the return I got the Windows > infamous blue screen. Restarting produced the same problem. > > Fortunately, I have another SSD used to test Bookworm, before updating on > the SSD that is having the problem. I can access the problem drive and am in > the process of backing up files. > > I ran sudo e2fsck -f/dev/sdc1 and got: > > Script started on 2024-02-19 08:15:52-05:00 [TERM="xterm-256color" > TTY="/dev/pts/0" COLUMNS="100" LINES="24"] > [?2004h(base) ]0;comp@AbNormal: > ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ sudo e2fsck -f > /dev/sdc1lcaomo[Ksudo e2fsck -f /dev/sdc1 > [?2004l > [sudo] password for comp: > e2fsck 1.47.0 (5-Feb-2023) > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > /lost+found not found. Create? yes > Pass 4: Checking reference counts > Pass 5: Checking group summary information > > /dev/sdc1: * FILE SYSTEM WAS MODIFIED * > /dev/sdc1: 7982363/121577472 files (0.3% non-contiguous), > 421959365/486307328 blocks > [?2004h(base) ]0;comp@AbNormal: > ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ [?2004l > > Comments and suggestions will be appreciated. This session doesn't show anything to worry about. As far as fsck is concerned, the file system looks clean. Back up its contents as quickly as you can and treat the disk with suspicion. There are other candidate suspects for file system corruption (flaky power supply, software doing silly things, kernel bugs, loose cables), but the disk would be the pirmary. Cheers -- t signature.asc Description: PGP signature
Banning a user from posting to Debian lists
[Also posted to commun...@debian.org / listmas...@lists.debian.org] Subject: Banning of a user from posting to Debian lists === As noted in the monthly FAQ, among the events that can take place on Debian lists as a result of breach of the Debian Code of Conduct is a temporary or permanent ban from the mailing lists (and other official Debian resources). Following a last attempt to reach out and further consideration, it has been requested to ban Sophie / Michael from the Debian-user mailing lists and other resoures. The mailing list threads have gone on for some years with no resolution and no improvement in engagement with others: taken as a whole, this amounts to misusing the goodwill of those on the list and, potentially, a misuse of Debian resources overall. Such decisions are taken rarely: this is an unusual event. As ever, it is requested that people continue to behave according to the standards expressed in the Debian Code of Conduct - being considerate and constructive and helpful to others. You should appreciate that this decision as final: as ever, the Community Team is there to discuss conduct in Debian channels. With every good wish, as ever, Andrew Cater (amaca...@debian.org) For the Community Team
Re: Timer doing apt update
On 19/02/2024 14:35, Erwan David wrote: After each boot, the equivalent of apt update is automatically done in background, through policykit (apt database is locked by policykitd). So I think there is a timer triggroing this. I'd like to disable this when my laptop is on expensive link (eg 4G link, or abroad). So I'd like to disable this timer, but I did not find it. If someone knws better than me... Perhaps I missed something since I have no idea why policykit (or polkit?) is involved. You may disable apt timers systemctl disable --now apt-daily.timer apt-daily-upgrade.timer Perhaps it is possible to write a script that will respect connection.metered property set by NetworkManager.
Re: sudo udisksctl
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.
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 cat be avoided.
sshd Match regel
Hoi Ik heb sinds een inbraak in 2019 enige simpele (zelfgebouwde) embedded webcameraatjes draaien. Put, koe, inderdaad. Maar dat terzijde. Nou blijken die cameraatjes sinds enige tijd alweer hun filmpjes niet te kopieren naar de file server op zolder. Op die server Debian stable, draait openssh 1:9.2p1-2+deb12u2, en de logs laten zien: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth] ssh dus te oud, op die webcammetjes. Updaten van die cammetjes dat blijkt een heel gedoe.. en... nou leek het me voor de korte termijn een oplossing om op de ssh server voor de webcammetjes een uitzondering te maken. 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 ssh-ed25519 ssh-ed25519-cert-...@openssh.com sk-ssh-ed25...@openssh.com sk-ssh-ed25519-cert-...@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp256-cert-...@openssh.com ecdsa-sha2-nistp384 ecdsa-sha2-nistp384-cert-...@openssh.com ecdsa-sha2-nistp521 ecdsa-sha2-nistp521-cert-...@openssh.com sk-ecdsa-sha2-nistp...@openssh.com sk-ecdsa-sha2-nistp256-cert-...@openssh.com webauthn-sk-ecdsa-sha2-nistp...@openssh.com ssh-dss ssh-dss-cert-...@openssh.com ssh-rsa ssh-rsa-cert-...@openssh.com rsa-sha2-256 rsa-sha2-256-cert-...@openssh.com rsa-sha2-512 rsa-sha2-512-cert-...@openssh.com ssh localhost -Q sig ssh-ed25519 sk-ssh-ed25...@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 sk-ecdsa-sha2-nistp...@openssh.com webauthn-sk-ecdsa-sha2-nistp...@openssh.com ssh-dss ssh-rsa rsa-sha2-256 rsa-sha2-512 daar zie ik toch ssh-dss en ssh-rsa staan. Maar ... niet de "oude"? Wie heeft een tip Dank G
Orphaned Inode Problem
I am running up to date Bookworm on my Debian platform: Processor AMD FX(tm)-8320 Eight-Core Processor Memory 8026MB (5267MB used) Machine TypeDesktop Operating SystemDebian GNU/Linux 12 (bookworm) I have been plagued with orphaned inodes. Last night the problem cane to a head. When I reboot the computer, after an orphaned inode incident created stop, it got as far as the user login. After the return I got the Windows infamous blue screen. Restarting produced the same problem. Fortunately, I have another SSD used to test Bookworm, before updating on the SSD that is having the problem. I can access the problem drive and am in the process of backing up files. I ran sudo e2fsck -f/dev/sdc1 and got: Script started on 2024-02-19 08:15:52-05:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="100" LINES="24"] [?2004h(base) ]0;comp@AbNormal: ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ sudo e2fsck -f /dev/sdc1lcaomo[Ksudo e2fsck -f /dev/sdc1 [?2004l [sudo] password for comp: e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity /lost+found not found. Create? yes Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdc1: * FILE SYSTEM WAS MODIFIED * /dev/sdc1: 7982363/121577472 files (0.3% non-contiguous), 421959365/486307328 blocks [?2004h(base) ]0;comp@AbNormal: ~[01;32mcomp@AbNormal[00m:[01;34m~[00m$ [?2004l Comments and suggestions will be appreciated. Thanks in advance. -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: Erreur nvidia suite upgrade noyau 6.1.0-18
On Saturday 17 February 2024 10:49:04 Patrick ZAJDA wrote: > Le paquet linux-image-6.1.0-18 ne serait-il pas toujours installé ? : Merci. Oui, linux-image-6.1.0-18 est bien purgé. > Quoi qu'il en soit, une mise à jour a été publié dans bookworm-updates > (SUA 252-1) pour corriger le problème de compilation lors de la mise à > jour vers le kernel 6.1.0-18. > apt update puis apt upgrade devrait donc pouvoir se passer sans > problème, à la limite un apt -f install si ça ne passe vraiment pas. Je n'ai pas vu qu'une mise à jour a été publiée dans bookworm-updates, (SUA 252-1) correctif de compilation, mise à jour vers le kernel 6.1.0-18. Ou s'agit-il d'une opération de mise à jour en cours ? Hélas, j'ai bien fait tout ça, mais toujours impossible de passer du noyau 6.1.0-17 vers 6.1.0-18, ainsi qu'un (dist)(full)-upgrade. Bonne journée.
Re: how to downgrade nvidia-graphics-drivers packages?
Harald Dunkel wrote: > Hi folks, > > Looking at a set of installed binary packages built from the same source > package, I would like to keep the version numbers consistent. There might > be exceptions, but in general you won't like to mix unstable and experimental > binary packages from the nvidia-graphics-drivers, for example. > > Question is, how can I tell apt to avoid mixing version numbers? If they come from different repositories (i.e. backports, unstable, experimental) you can set priorities in /etc/apt/preferences.d/ -- read the man page for apt_preferences, because it's not intuitive. Package: * Pin: release a=bookworm Pin-Priority: 900 Package: * Pin: release a=bookworm-backports Pin-Priority: 50 Or you can set things per-package by name, or a variety of other mechanisms. -dsr-
Re: Hard links - How do they work
Keith Bainbridge wrote: > As promised: > I said sometime in this thread that timeshift (and Back in Time) 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. > > So I'm starting a new thread on that topic. > > My understanding is that a hard link (ln with no option) will list the file > in another directory, but the file remains the same no matter where I may > edit it.I use cp -lru as a quick and dirty way to protect me against > accident deleting a file. (Sym-link doesn't give that protection, but does > allow me to keep my home on a separate partition so that a fresh install is > a LOT easier; but that is another topic) A hard link is a name for a file -- it points to the first inode. Most files only have one name, but they can have many. Hard links can be in many directories, but must stay on the same filesystem. If you mv the file by any of its links on the same filesystem, all the links remain valid. When the last name for a file is deleted, the file is deleted. Now you know why deleting a file is sometimes called "unlinking". A symbolic link is a tiny file that contains a path to a file. The kernel reads the path, then looks for the substitute file. This can fail. But -- it can cross filesystems, even filesystems of completely different types. If you move the symbolic link, it continues to point to the same path. If you move the referenced file, the symbolic links are no longer valid. > Snapshots reportedly hard link the directory/ies (generally means / but not > limited ). a new snapshot copies the latest set and then updates any new > files in the base.The more I try to visualise that process the more I > reckon there must be more to it "snapshot" is not a single definition; the software you are using produces different results. rsnapshot/rsync, lvm, btrfs and zfs, for example, each use completely different mechanisms with different semantics. It looks like timeshift uses either rsync or btrfs snapshots, and backintime uses rsync, so first you would need to define which of those you are using and in what mode. -dsr-
how to downgrade nvidia-graphics-drivers packages?
Hi folks, Looking at a set of installed binary packages built from the same source package, I would like to keep the version numbers consistent. There might be exceptions, but in general you won't like to mix unstable and experimental binary packages from the nvidia-graphics-drivers, for example. Question is, how can I tell apt to avoid mixing version numbers? Regards Harri
Re: partition reporting full, but not
David Christensen wrote: > On 2/18/24 19:20, Keith Bainbridge wrote: > > I am convinced that the missing space is used by btrfs snapshot > > process. > > > Perhaps. But, are you re-balancing your btrfs file systems regularly? > > https://manpages.debian.org/bookworm/btrfs-progs/btrfs-balance.8.en.html But does balancing a btrfs system actually recover any space? I think not. It's eternally moving the deckchairs on the Titanic. (though with a more useful purpose) I'd recommend installing snapper if you haven't already. https://wiki.archlinux.org/title/Snapper is helpful for using it.
Re: partition reporting full, but not
Am 19.02.2024 um 04:20 schrieb Keith Bainbridge: > I am convinced that the missing space is used by btrfs snapshot process. First off: I am not a btrfs user (and will never be, i might add). I am using zfs since many years, and - although i read an awful lot of documentation beforehand, and played around with it quite a bit, i had to learn a couple of lessons "the hard way". To me, what i am inferring from your mails, are a couple of conceptual misundestandings of what a COW-filesystem is, and how to best make use of it. Especially the time-machine using snapshots and hardlinks seems very kinky to me. I am using zfs somewhat in a similar way, but it took me some years to set it up in a good way. Apart from a warning and the usual RTFM, i do not have much to offer. Except maybe for this: Snapshots hold space, they are not like hardlinks. (although one can snapshot hardlinks ;-) ) Once, some older filesystem state is snapshotted, its space is taken until the snapshot gets destroyed/removed. This can lead to situations, where a device is full, but in order to free some space, deleting files will NOT help, because in order to do so, a change in the directory needs to be made, but there may not be the room to create a copy of it in the first place. And deleting files from a snapshot is not feasable (at least not in zfs). To my eyes, your handling of the system looks somewhat risky and not well planned. You may go on this way, as long as you consider the whole thing as being part of a longish learning session. But do not trust important data being safe this way! just my 2 cents
Re: Timer doing apt update
Erwan David writes: > Hello, > > After each boot, the equivalent of apt update is automatically done in > background, through policykit (apt database is locked by > policykitd). So I think there is a timer triggroing this. I'd like to > disable this when my laptop is on expensive link (eg 4G link, or > abroad). So I'd like to disable this timer, but I did not find it. If > someone knws better than me... If you're using the package unattended-upgrades (I'm not sure it ties to policykitd), then there are instructions in the Debian wiki at https://wiki.debian.org/UnattendedUpgrades#Modifying_download_and_upgrade_schedules_.28on_systemd.29 The timers in question are apt-daily.timer and apt-daily-upgrade.timer. Come to think of it, just running apt update shouldn't generate much traffic.
