libkrb5-3 on trixie break foreign-architectures installation
Hi, I use a Debian trixie container for testing using amd64 architecture. I use cross compilation to arm64. When I try to create the container I get this error: libgssapi-krb5-2 : Breaks: libgssapi-krb5-2:arm64 (!= 1.20.1-5+b1) but 1.20.1-5 is to be installed Looking on https://packages.debian.org/trixie/libkrb5-3, I see amd64 uses a maintainer version, while arm64 does not. I tried to use preferences and pin the version, but it seems the maintainer version is pinned as well. What can I do? Erez Geva
Re: Problemas con el controlador no libre de NVidia en la 12.5
El 2024-02-12 a las 01:04 +0100, Parodper escribió: > Aviso a navegantes, la última versión 12.5 parece que causa problemas al > compilar el controlador no libre de NVidia para Linux 6.1.0-18. Gracias por el aviso. Hace años que uso nouveau, pero seguro que a más de uno le has salvado el lunes :-) > Existe un hilo en el foro[1], pero me pareció curioso que no se mencionara > nada en las listas. > > [1]: https://forums.debian.net/viewtopic.php?t=158200 Por aquí añaden más información: Debian 12 linux-image-6.1.0-18-amd64 dist-upgrade fails on nvidia GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' https://unix.stackexchange.com/questions/769026/debian-12-linux-image-6-1-0-18-amd64-dist-upgrade-fails-on-nvidia-gpl-incompatib Moraleja: si alguien usa el driver propietarario de nvidia en Debian 12 (actual estable) que espere a que lo resuelvan antes de actualizar el sistema. Saludos, -- Camaleón
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour Hugues, Dans les logs il ressort le message "failed to write (No space left on device)" qui signifie qu'il n'y a plus d'espace libre. Peux-tu nous transmettre le retour des commandes suivantes : df -TPh df -i Cordialement, Alban Le 12 février 2024 08:00:00 GMT+01:00, Hugues MORIN-TRENEULE a écrit : >Bonjour a tous > > >Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer un >crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. > >Il y a quelques temps vos conseils et explications mon permis de de mettre >a jours mon Stretch afin de le préparer à l'upgrade vers Bullseye (cf "Mise >à jours et Update Stretch - Problème de dépôt" sur la liste => >https://lists.debian.org/debian-user-french/2023/08/msg00289.html) > >En résumé, j'ai oublié de faire l'upgrade de mon stretch en temps et en >heure. Quand j'ai voulu le faire, les dépôts de mon sources.list n'étaient >plus valide. Votre aide m'a permis d'avoir les bons dépôts et de mettre a >jours mon Stretch à sa dernière version avant de lancer l'upgrade. >Jusque là aucun probleme. > >Une fois a jour, j'ai lancé la procédure d'upgrade de Stretch à Bullseye en >suivant pas à pas la procedure decrite par debian.org: >https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html > >Tout s'est bien passé jusqu'au apt full-upgrade (paragraphe 4.4.6). >J'ai fait les contrôles demandés, fait les sauvegardes. >J'ai utilisé a plusieurs reprises les procédures d'upgrade de debian.org >sans jamais rencontrer de probleme, c'est la 1ere fois que j'ai un crash >lors de celle-ci et je ne sais pas trop que faire car je ne maitrise pas du >tout le sujet. >J'ai bien entendu tenté de faire quelques recherches mais cela ne m'a >conduit a rien de concluant, soit ça n'a rien à voir, soit je ne comprends >pas ce que je lis... > >Le probleme est survenu à environ 45% de l'installation. >Voila le dernier message en console: >[...] >Selecting previously unselected package libnss-systemd:amd64. >Preparing to unpack .../345-libnss-systemd_241-7~deb10u10_amd64.deb ... >Unpacking libnss-systemd:amd64 (241-7~deb10u10) ... >Errors were encountered while processing: > /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb >E: Sub-process /usr/bin/dpkg returned an error code (1) > > >J'ai trouvé 2 messages d'erreurs avant le crash définitif: > >[...] >Selecting previously unselected package linux-image-4.19.0-25-amd64. >Preparing to unpack >.../261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb ... >Unpacking linux-image-4.19.0-25-amd64 (4.19.289-2) ... >dpkg: error processing archive >/tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb >(--unpack): > cannot copy extracted data for >'./lib/modules/4.19.0-25-amd64/kernel/fs/jbd2/jbd2.ko' to >'/lib/modules/4.19.0-25-amd64/kernel/fs/jbd2/jbd2.ko.dpkg-new': failed to >write (No space left on device) >dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) >Preparing to unpack .../262-linux-image-amd64_4.19+105+deb10u20_amd64.deb >... >Unpacking linux-image-amd64 (4.19+105+deb10u20) over (4.9+80+deb9u17) ... >Preparing to unpack .../263-lnav_0.8.4-5_amd64.deb ... >[...] > >et > >[...] >Unpacking nautilus-extension-gnome-terminal (3.30.2-2) ... >Preparing to unpack .../276-network-manager-openvpn_1.8.10-1_amd64.deb ... >Unpacking network-manager-openvpn (1.8.10-1) over (1.2.8-2) ... >dpkg: warning: unable to delete old directory '/etc/NetworkManager/VPN': >Directory not empty >Preparing to unpack >.../277-network-manager-openvpn-gnome_1.8.10-1_amd64.deb ... >Unpacking network-manager-openvpn-gnome (1.8.10-1) over (1.2.8-2) ... >Preparing to unpack .../278-openvpn_2.4.7-1+deb10u1_amd64.deb ... >[...] > >J'ai sauvegardé tous les log après le crash et tout ce qui s'affichait en >console. >J'ai aussi à dispo le script enregistré lors de l'upgrade. > >Je n'ai rien fait de plus depuis le crash si ce n'est d'allumer la machine >pour faire la sauvegarde des log. > >Je dois avouer ne pas savoir du tout ce qu'il faut faire pour réparer, je >suis dans une impasse. >Toute aide sera la bienvenue ;-) > > >Très cordialement >Hugues -- Envoyé de /e/ Mail.
Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour a tous Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. Il y a quelques temps vos conseils et explications mon permis de de mettre a jours mon Stretch afin de le préparer à l'upgrade vers Bullseye (cf "Mise à jours et Update Stretch - Problème de dépôt" sur la liste => https://lists.debian.org/debian-user-french/2023/08/msg00289.html) En résumé, j'ai oublié de faire l'upgrade de mon stretch en temps et en heure. Quand j'ai voulu le faire, les dépôts de mon sources.list n'étaient plus valide. Votre aide m'a permis d'avoir les bons dépôts et de mettre a jours mon Stretch à sa dernière version avant de lancer l'upgrade. Jusque là aucun probleme. Une fois a jour, j'ai lancé la procédure d'upgrade de Stretch à Bullseye en suivant pas à pas la procedure decrite par debian.org: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html Tout s'est bien passé jusqu'au apt full-upgrade (paragraphe 4.4.6). J'ai fait les contrôles demandés, fait les sauvegardes. J'ai utilisé a plusieurs reprises les procédures d'upgrade de debian.org sans jamais rencontrer de probleme, c'est la 1ere fois que j'ai un crash lors de celle-ci et je ne sais pas trop que faire car je ne maitrise pas du tout le sujet. J'ai bien entendu tenté de faire quelques recherches mais cela ne m'a conduit a rien de concluant, soit ça n'a rien à voir, soit je ne comprends pas ce que je lis... Le probleme est survenu à environ 45% de l'installation. Voila le dernier message en console: [...] Selecting previously unselected package libnss-systemd:amd64. Preparing to unpack .../345-libnss-systemd_241-7~deb10u10_amd64.deb ... Unpacking libnss-systemd:amd64 (241-7~deb10u10) ... Errors were encountered while processing: /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) J'ai trouvé 2 messages d'erreurs avant le crash définitif: [...] Selecting previously unselected package linux-image-4.19.0-25-amd64. Preparing to unpack .../261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb ... Unpacking linux-image-4.19.0-25-amd64 (4.19.289-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb (--unpack): cannot copy extracted data for './lib/modules/4.19.0-25-amd64/kernel/fs/jbd2/jbd2.ko' to '/lib/modules/4.19.0-25-amd64/kernel/fs/jbd2/jbd2.ko.dpkg-new': failed to write (No space left on device) dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Preparing to unpack .../262-linux-image-amd64_4.19+105+deb10u20_amd64.deb ... Unpacking linux-image-amd64 (4.19+105+deb10u20) over (4.9+80+deb9u17) ... Preparing to unpack .../263-lnav_0.8.4-5_amd64.deb ... [...] et [...] Unpacking nautilus-extension-gnome-terminal (3.30.2-2) ... Preparing to unpack .../276-network-manager-openvpn_1.8.10-1_amd64.deb ... Unpacking network-manager-openvpn (1.8.10-1) over (1.2.8-2) ... dpkg: warning: unable to delete old directory '/etc/NetworkManager/VPN': Directory not empty Preparing to unpack .../277-network-manager-openvpn-gnome_1.8.10-1_amd64.deb ... Unpacking network-manager-openvpn-gnome (1.8.10-1) over (1.2.8-2) ... Preparing to unpack .../278-openvpn_2.4.7-1+deb10u1_amd64.deb ... [...] J'ai sauvegardé tous les log après le crash et tout ce qui s'affichait en console. J'ai aussi à dispo le script enregistré lors de l'upgrade. Je n'ai rien fait de plus depuis le crash si ce n'est d'allumer la machine pour faire la sauvegarde des log. Je dois avouer ne pas savoir du tout ce qu'il faut faire pour réparer, je suis dans une impasse. Toute aide sera la bienvenue ;-) Très cordialement Hugues
Re: Fast Random Data Generation (Was: Re: Unidentified subject!)
On 2/11/24 02:26, Linux-Fan wrote: I wrote a program to automatically generate random bytes in multiple threads: https://masysma.net/32/big4.xhtml Before knowing about `fio` this way my way to benchmark SSDs :) Example: | $ big4 -b /dev/null 100 GiB | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma. | For further info send an e-mail to ma_sys...@web.de. || 0.00% +0 MiB 0 MiB/s 0/102400 MiB | 3.48% +3562 MiB 3255 MiB/s 3562/102400 MiB | 11.06% +7764 MiB 5407 MiB/s 11329/102400 MiB | 19.31% +8436 MiB 6387 MiB/s 19768/102400 MiB | 27.71% +8605 MiB 6928 MiB/s 28378/102400 MiB | 35.16% +7616 MiB 7062 MiB/s 35999/102400 MiB | 42.58% +7595 MiB 7150 MiB/s 43598/102400 MiB | 50.12% +7720 MiB 7230 MiB/s 51321/102400 MiB | 58.57% +8648 MiB 7405 MiB/s 59975/102400 MiB | 66.96% +8588 MiB 7535 MiB/s 68569/102400 MiB | 75.11% +8343 MiB 7615 MiB/s 76916/102400 MiB | 83.38% +8463 MiB 7691 MiB/s 85383/102400 MiB | 91.74% +8551 MiB 7762 MiB/s 93937/102400 MiB | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB || Wrote 102400 MiB in 13 s @ 7812.023 MiB/s What algorithm did you implement? Secure Random can be obtained from OpenSSL: | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done | | real 0m49.288s | user 0m44.710s | sys 0m4.579s Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not designed to generate large amounts of random data as the size is limited by integer range... Thank you for posting the openssl(1) incantation. Benchmarking my daily driver laptop without Intel Secure Key: 2024-02-11 21:54:04 dpchrist@laalaa ~ $ lscpu | grep 'Model name' Model name: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz 2024-02-11 21:54:09 dpchrist@laalaa ~ $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done real1m40.149s user1m25.174s sys 0m14.952s So, ~1.072E+9 bytes per second. Benchmarking a workstation with Intel Secure Key: 2024-02-11 21:54:40 dpchrist@taz ~ $ lscpu | grep 'Model name' Model name: Intel(R) Xeon(R) E-2174G CPU @ 3.80GHz 2024-02-11 21:54:46 dpchrist@taz ~ $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done real1m14.696s user1m0.338s sys 0m14.353s So, ~1.437E+09 bytes per second. David
Re: Debian 12.5 upgrade error
On 12/02/2024 05:45, piorunz wrote: Anyone affected should make sure to upgrade nvidia-kernel-dkms package once new version become available. Sorry, the package in question is nvidia-graphics-drivers, that's the one being fixed. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: Debian 12.5 upgrade error
On 11/02/2024 12:48, Teemu Likonen wrote: * 2024-02-11 14:13:51+0200, Alexis Grigoriou wrote: I have encountered an error upgrading to 12.5 from 12.4 regarding the nvidia-driver and linux-image 6.1.0.18. The error is: Very likely this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063656 Not your fault. This bug number may be a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062932, which has already been fixed and will be pushed to stable soon if not already. Anyone affected should make sure to upgrade nvidia-kernel-dkms package once new version become available. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: Debian 12.5 upgrade error
On 11/02/2024 12:13, Alexis Grigoriou wrote: I have encountered an error upgrading to 12.5 from 12.4 regarding the nvidia-driver and linux-image 6.1.0.18. The error is: env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=6.1.0-18- amd64(bad exit status: 2) I get that error twice. After the upgrade I get a non-bootable 6.1.0-18 image. Doing some fiddling, I got a bootable 6.1.0-18 image but no GUI. I removed linux-image and linux-headers 6.1.0.-18 an I now have 6.1.0.-17 working. Has anyone else encounter this issue? I think this is related to this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062932 It's already being fixed: "We believe that the bug you reported is fixed in the latest version of nvidia-graphics-drivers, which is due to be installed in the Debian FTP archive." -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)
On Sun 11 Feb 2024 at 20:41:51 (+), Darac Marjal wrote: > On 11/02/2024 11:21, Rainer Dorsch wrote: > > - How do I set a timeout/limit for anacron, that it cannot block forever > > during a reboot? > > It may be germane to point out that anacron.service already explicitly > sets "TimeoutStopSec=Infinity". So, in the opinion of the developers, > the service shouldn't be prematurely killed. Of course you, as the > system administrator, always have the right to countermand that sort > of decision, but it would be curious to find out why the developers > thought they needed to override the systemd default in the first > place? Bug #915379 explains all: long-running cron jobs, like backups, can get killed, and there was also an issue with exim. There's mention there of an anacron replacement called cronie, but I don't know what the status of this is, besides being in trixie. Cheers, David.
Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)
On 12/02/2024 03:41, Darac Marjal wrote: On 11/02/2024 11:21, Rainer Dorsch wrote: - How can I found out which process anacron is still running? I think that, once the shutdown has started this is basically impossible. Likely some cron job requires a fix. Try systemctl status anacron *before* shutdown and inspect processes that are started by anacron. Other variants are systemd-cgls ps xuwf
Re: Erreur suite à un apt upgrade noyau 6.6.18
https://www.youtube.com/watch?v=XAx46zIMPCY - Mail original - De: "ajh-valmer" À: debian-user-french@lists.debian.org Envoyé: Lundi 12 Février 2024 00:32:46 Objet: Re: Erreur suite à un apt upgrade noyau 6.6.18 On Sunday 11 February 2024 23:35:11 Bernard Schoenacker wrote: > Hallo Wache, C'est qui Wache ? > Voici encore une bonne nouvelle pour une personne qui n'a pas cherché > plus loin que le bout de son nez... > #script-xrandr.sh > xrandr --newmode "1280x1024_60.00" 108.88 1280 1360 1496 1712 1024 1025 > 1028 1060 -HSync Vsync > xrandr --addmode VGA 1280x1024_60.00 > xrandr --output VGA-0 --mode 1280x1024_60.00 > #EOF > Attention, il serait sage de vérifier les modelines de la dalle TFT > https://www.mythtv.org/wiki/Modeline_Database Encore un qui n'a pas lu mon mail sans chercher plus loin que le bout de ses yeux : > xrandr --addmode VGA 1280x1024_60.00 > xrandr --output VGA-0 --mode 1280x1024_60.00 : Réponse : xrandr: Failed to get size of gamma for output default xrandr: cannot find output "VGA"
Re: hexchat being discontinued?
Hellow^^^ On Sat, 2024-02-10 at 19:54 -0500, Default User wrote: > :( > (...) > Any recommendations for a GOOD alternative? How about Emacs? Sincerely, Byunghee -- ^고맙습니다 _布德天下_ 감사합니다_^))// signature.asc Description: This is a digitally signed message part
Problemas con el controlador no libre de NVidia en la 12.5
Aviso a navegantes, la última versión 12.5 parece que causa problemas al compilar el controlador no libre de NVidia para Linux 6.1.0-18. Existe un hilo en el foro[1], pero me pareció curioso que no se mencionara nada en las listas. [1]: https://forums.debian.net/viewtopic.php?t=158200
Re: Re: Como hacer una partición no destructiva?
Muchísimas gracias. Me han sido de mucha utilidad tus respuestas. y a todos gracias por su interés. _ _ _
Re: Debian 12.5 upgrade error
On Sun, 2024-02-11 at 19:14 +0200, Alexis Grigoriou wrote: > On Sun, 2024-02-11 at 21:37 +0900, Byunghee HWANG (황병희) wrote: > > Hellow Alexis, > > > > > > What command did you type exactly? > > > > In normal cases, i do like this: > > > > > > sudo su - > > apt update > > apt upgrade > > > > > I logged on as root on tty1 > /etc/init.d/lightdm stop > apt update > apt upgrade > > I always do minor and major version updates on a tty with no GUI > running. Oh... you are better than me, then you would be good to follow <87le7rw4j1@iki.fi>'s opinion... IMHO. Sincerely, Byunghee -- ^고맙습니다 _布德天下_ 감사합니다_^))// signature.asc Description: This is a digitally signed message part
Re: Erreur suite à un apt upgrade noyau 6.6.18
On Sunday 11 February 2024 23:35:11 Bernard Schoenacker wrote: > Hallo Wache, C'est qui Wache ? > Voici encore une bonne nouvelle pour une personne qui n'a pas cherché > plus loin que le bout de son nez... > #script-xrandr.sh > xrandr --newmode "1280x1024_60.00" 108.88 1280 1360 1496 1712 1024 1025 > 1028 1060 -HSync Vsync > xrandr --addmode VGA 1280x1024_60.00 > xrandr --output VGA-0 --mode 1280x1024_60.00 > #EOF > Attention, il serait sage de vérifier les modelines de la dalle TFT > https://www.mythtv.org/wiki/Modeline_Database Encore un qui n'a pas lu mon mail sans chercher plus loin que le bout de ses yeux : > xrandr --addmode VGA 1280x1024_60.00 > xrandr --output VGA-0 --mode 1280x1024_60.00 : Réponse : xrandr: Failed to get size of gamma for output default xrandr: cannot find output "VGA"
Re: shred bug? [was: Unidentified subject!]
On 2/11/24 06:54, Greg Wooledge wrote: On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: [...] What Thomas was trying to do is to get a cheap, fast random number generator. Shred seems to have such. Well... I certainly wouldn't call it a bug. Maybe a feature request. Still there's the discrepancy between doc and behaviour. There isn't. The documentation says: SYNOPSIS shred [OPTION]... FILE... I interpret the above line to be a prototype for invoking the shred(1) program: * "shred" is the program name * "[OPTION]..." is one or more option specifiers that may be omitted. Each should be described below. * "FILE..." is one or more argument specifies that should be file system paths (strings). DESCRIPTION Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data. If FILE is -, shred standard output. I interpret the above line at face value -- if the caller provides a dash as the argument, shred(1) will operate on standard output. In every sentence, the word FILE appears. There's nothing in there which says "you can operate on a non-file". Dash is not a file, yet the above sentence says shred(1) can operate on it. Once you grasp what the command is *intended* to do (rewind and overwrite a file repeatedly), it makes absolutely perfect sense that it should only operate on rewindable file system objects. An expert may infer what you have stated, but I prefer manual pages that are explicit. The GNU project must have found a need for the FILE='-' feature, otherwise it would not exist. The manual page should describe that need (e.g. why) and how to properly use shred(1) to solve the need. If you want it to write a stream of data instead of performing its normal operation (rewinding and rewriting), that's a new feature. Humans are (in)famous for doing unexpected things. If you'd prefer the documentation to say explicitly "only regular files and block devices are allowed", that would be an upstream documentation *clarification* request. Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The obvious solution is to write one document that is complete and correct, and use it everywhere -- e.g. DRY. David
Re: Erreur suite à un apt upgrade noyau 6.6.18
Hallo Wache, Voici encore une bonne nouvelle pour une personne qui n'a pas cherché plus loin que le bout de son nez... #script-xrandr.sh xrandr --newmode "1280x1024_60.00" 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -HSync Vsync xrandr --addmode VGA 1280x1024_60.00 xrandr --output VGA-0 --mode 1280x1024_60.00 #EOF #- Attention, il serait sage de vérifier les modelines de la dalle TFT https://www.mythtv.org/wiki/Modeline_Database Merci @+ Bernard - Mail original - De: "ajh-valmer" À: debian-user-french@lists.debian.org Envoyé: Dimanche 11 Février 2024 18:21:10 Objet: Re: Erreur suite à un apt upgrade noyau 6.6.18 https://doc.ubuntu-fr.org/xrandr J'ai donc tenté ceci : # xrandr --addmode VGA 1280x1024_60.00 xrandr: Failed to get size of gamma for output default xrandr: cannot find output "VGA" Pour les autres commandes, réponses toujours en erreur.
Re: Unidentified subject!
On 2/11/24 03:13, Thomas Schmitt wrote: Hi, David Christensen wrote: Concurrency: threads throughput 8 205+198+180+195+205+184+184+189=1,540 MB/s There remains the question how to join these streams without losing speed in order to produce a single checksum. (Or one would have to divide the target into 8 areas which get checked separately.) I had similar thoughts. A FIFO should be able to join the streams. But, dividing the device by the number of virtual cores and putting a thread on each makes more sense. Either done right should fill the drive I/O capacity. Does this 8 thread generator cause any problems with the usability of the rest of the system ? Sluggish program behavior or so ? CPU Graph shows all eight virtual cores at 100%, so everything else on the system would be sluggish (unless you use nice(1)). Here is a processor with Intel Secure Key and otherwise unloaded: 2024-02-11 11:48:21 dpchrist@taz ~ $ lscpu | grep 'Model name' Model name: Intel(R) Xeon(R) E-2174G CPU @ 3.80GHz 2024-02-11 11:59:55 dpchrist@taz ~ $ cat /etc/debian_version ; uname -a 11.8 Linux taz 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux 2024-02-11 12:02:52 dpchrist@taz ~ $ dd if=/dev/urandom of=/dev/null bs=1M count=10K 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.0469 s, 536 MB/s threads throughput 1 536 MB/s 2 512+512 = 1,024 MB/s 3 502+503+503 = 1,508 MB/s 4 492+491+492+492 = 1,967 MB/s 5 492+384+491+385+491 = 2,243 MB/s 6 379+491+492+379+379+379 = 2,499 MB/s 7 352+491+356+388+352+357+388 = 2,684 MB/s 8 355+354+344+348+344+354+353+349 = 2,801 MB/s I have to correct my previous measurement on the 4 GHz Xeon, which was made with a debuggable version of the program that produced the stream. The production binary which is compiled with -O2 can write 2500 MB/s into a pipe with a pacifier program which counts the data: $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | $(scdbackup -where bin)/raedchen -step 100m -no_output -print_count 100.0g bytes real0m39.884s user0m30.629s sys 0m41.013s (One would have to install scdbackup to reproduce this and to see raedchen count the bytes while spinning the classic SunOS boot wheel: |/-\|/-\|/-\ http://scdbackup.webframe.org/main_eng.html http://scdbackup.webframe.org/examples.html Oh nostalgy ... ) Totally useless but yielding nearly 4000 MB/s: $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni >/dev/null real0m27.064s user0m23.433s sys 0m3.646s The main bottleneck in my proposal would be the checksummer: $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | md5sum 5a6ba41c2c18423fa33355005445c183 - real2m8.160s user2m25.599s sys 0m22.663s That's quite exactly 800 MiB/s ~= 6.7 Gbps. Still good enough for vanilla USB-3 with a fast SSD, i'd say. Yes -- more than enough throughput. Before I knew of fdupes(1) and jdupes(1), I wrote a Perl script to find duplicate files. It uses the Digest module, and supports any algorithm supported by that module. Here are some runs against a local ext4 on LUKS (with AES-NI) on Intel SSD 520 Series 60 GB and check summing whole files: 2024-02-11 13:32:47 dpchrist@taz ~ $ time finddups --filter w --digest MD4 .thunderbird/ >/dev/null real0m0.878s user0m0.741s sys 0m0.137s 2024-02-11 13:33:14 dpchrist@taz ~ $ time finddups --filter w --digest MD5 .thunderbird/ >/dev/null real0m1.110s user0m0.977s sys 0m0.132s 2024-02-11 13:33:19 dpchrist@taz ~ $ time finddups --filter w --digest SHA-1 .thunderbird/ >/dev/null real0m1.306s user0m1.151s sys 0m0.156s 2024-02-11 13:36:40 dpchrist@taz ~ $ time finddups --filter w --digest SHA-256 .thunderbird/ >/dev/null real0m2.545s user0m2.424s sys 0m0.121s 2024-02-11 13:36:51 dpchrist@taz ~ $ time finddups --filter w --digest SHA-384 .thunderbird/ >/dev/null real0m1.808s user0m1.652s sys 0m0.157s 2024-02-11 13:37:00 dpchrist@taz ~ $ time finddups --filter w --digest SHA-512 .thunderbird/ >/dev/null real0m1.814s user0m1.673s sys 0m0.141s It is curious that SHA-384 and SHA-512 are faster than SHA-256. I can confirm similar results on: 2024-02-11 13:39:58 dpchrist@laalaa ~ $ lscpu | grep 'Model name' Model name: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz David
Re: hexchat being discontinued?
* On 2024 10 Feb 22:31 -0600, Dan Ritter wrote:
> Default User wrote:
> > Well, it seems that hexchat is being discontinued.
> > IMHO, it is/was the only IRC client that was actually usable.
> >
> > Any recommendations for a GOOD alternative?
>
> I like weechat. Some people like quassel.
>
> Hexchat is packaged in bookworm, so there's no reason for you to
> panic until it's removed.
Some packages can be kept around for a long time after they've been
removed from 'main'. The dependency chain and any conflicts with newer
libraries will dictate success or failure. I've often "held" a package
('=' in the aptitude UI) to keep from losing it and eventually it and
what it depends on are placed in the "Obsolete and Locally Created
Packages" section of the aptitude UI.
When Groff 1.23 hits in Trixie, I know that an included utility called
"groffer" will be removed. To keep it I will copy it over from the
cloned groff repository I have locally. Sometimes a man's gotta do what
a man's gotta do...
- 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: Unidentified subject!
On 2/11/24 00:07, Thomas Schmitt wrote: In the other thread about the /dev/sdm test: Gene Heskett wrote: Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32 [...] $ sudo f3probe --destructive --time-ops /dev/sdm Bad news: The device `/dev/sdm' is a counterfeit of type limbo Device geometry: *Usable* size: 59.15 GB (124050944 blocks) Announced size: 1.91 TB (409600 blocks) David Christensen wrote: Which other thread? Please provide a URL to archived post. https://lists.debian.org/msgid-search/e7a0c1a1-f973-4007-a86d-8d91d8d91...@shentel.net https://lists.debian.org/msgid-search/b566504b-5677-4d84-b5b3-b0de63230...@shentel.net Thank you. :-) David
Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)
On 11/02/2024 11:21, Rainer Dorsch wrote: Hello, I saw during a reboot [ *** ] Job anacron.service/stop running (15min 49s / no limit) eventually I did a hard reset, since I was not sure if the system simply hang. I have two quick questions: - How can I found out which process anacron is still running? I think that, once the shutdown has started this is basically impossible. User sessions have likely been killed off so your only option would be to log in as root, but you'll probably also find that getty has been killed off too, so I don't know how you'd be able to enter any commands at this point. However, one thing that you could look at is to inspect the journal from that boot. You can run "journalctl --list-boots" to get a list of boot ids, then run "journalctl -b -u anacron". Anacron will print lines like the following: Feb 10 13:32:50 host.example.com systemd[1]: Started anacron.service - Run anacron jobs. Feb 10 13:32:50 host.example.com anacron[1822]: Anacron 2.3 started on 2024-02-10 Feb 10 13:32:50 host.example.com anacron[1822]: Will run job `cron.daily' in 5 min. Feb 10 13:32:50 host.example.com anacron[1822]: Jobs will be executed sequentially Feb 10 13:37:50 host.example.com anacron[1822]: Job `cron.daily' started Feb 10 13:37:50 host.example.com anacron[38129]: Updated timestamp for job `cron.daily' to 2024-02-10 Feb 10 13:37:51 host.example.com anacron[1822]: Job `cron.daily' terminated (mailing output) Feb 10 13:37:51 host.example.com anacron[1822]: Normal exit (1 job run) Feb 10 13:37:51 host.example.com systemd[1]: anacron.service: Deactivated successfully. So, from that, you can see which set of cron scripts were running. If you have multiple scripts, then yes, it's harder to tell which script was the long running one (perhaps it's something like locate updating it's database?) - How do I set a timeout/limit for anacron, that it cannot block forever during a reboot? It may be germane to point out that anacron.service already explicitly sets "TimeoutStopSec=Infinity". So, in the opinion of the developers, the service shouldn't be prematurely killed. Of course you, as the system administrator, always have the right to countermand that sort of decision, but it would be curious to find out why the developers thought they needed to override the systemd default in the first place? Thanks Rainer OpenPGP_signature.asc Description: OpenPGP digital signature
Re: hexchat being discontinued?
On Sun, Feb 11, 2024 at 07:42:24PM +, Richmond wrote: > You could try Pidgin. It's in the Debian repo. It has various protocols > of which irc is just one. It's a bit confusing because you have to go to > the 'buddy' menu to join an irc channel. Yes: Pidgin UI is dreadful. Lots that is non intuitive. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: -new HP AMD ryzen with realtec audio. The HP is mo1-F3xxx It has winblows 11 on it and I want it gone. It does have a 256GB SSD. Is there any thing i need to know before i try to install Bookworm.
On 10/02/2024 21:48, Maureen Thomas wrote: So can I please get some help. I have a portable CD/DVD and I made a USB with a ISO on it. The computer does not have a cd/dvd burner but I have a portable one. Can some one tell me if there are any special things I need to do to put Debian 12 on this machine. I really hate windows and need to get it gone. Your help is always appreciated by this old lady. Thank you in advance> If you'd prefer to read some documentation before getting started, the Debian Installation Guide ( https://www.debian.org/releases/stable/amd64/ ) is a VERY good place to start. Chapter 3 ( https://www.debian.org/releases/stable/amd64/ch03.en.html ) in particular, covers things like: * What the installation process consists of * Minimum Hardware Requirements * Some potential pitfalls to be aware of But the whole document is quite well written, actually. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: hexchat being discontinued?
Default User writes: > :( > > Well, it seems that hexchat is being discontinued. > IMHO, it is/was the only IRC client that was actually usable. > > Any recommendations for a GOOD alternative? > > You could try Pidgin. It's in the Debian repo. It has various protocols of which irc is just one. It's a bit confusing because you have to go to the 'buddy' menu to join an irc channel.
Re: hexchat being discontinued?
Hello, On Sun, Feb 11, 2024 at 11:58:10AM -0500, Default User wrote: > I can't really say what it is I like about hexchat and dislike about > other IRC clients, except to say that it just seems to work the way my > brain does. Which other ones have you used that you do not like, then? Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
On Friday 09 February 2024 04:41:37 pm hw wrote: > On Fri, 2024-02-09 at 11:34 -0500, Roy J. Tellason, Sr. wrote: > > On Friday 09 February 2024 06:07:16 am hw wrote: > > > What other manufacturers could we buy UPSs from? > > > > I have a Tripp-Lite sitting next to me here that replaced an APC and > > has 2-1/2 times the capabiliity. Been in service several weeks and > > so far I'm pretty happy with it... > > They seem to be extremely rare here. Where's "here"? I ordered mine from Home Depot, online. The wait until it arrived didn't seem excessive. > Are they any good, and how's the battery availability? It seems okay, and I haven't checked on the battery availability, no need at this point and if I did it'd probably change by the time I needed them anyhow. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: Erreur suite à un apt upgrade noyau 6.6.18
https://doc.ubuntu-fr.org/xrandr J'ai donc tenté ceci : # xrandr --addmode VGA 1280x1024_60.00 xrandr: Failed to get size of gamma for output default xrandr: cannot find output "VGA" Pour les autres commandes, réponses toujours en erreur.
Re: Debian 12.5 upgrade error
On Sun, 2024-02-11 at 21:37 +0900, Byunghee HWANG (황병희) wrote: > Hellow Alexis, > > > What command did you type exactly? > > In normal cases, i do like this: > > > sudo su - > apt update > apt upgrade > > I logged on as root on tty1 /etc/init.d/lightdm stop apt update apt upgrade I always do minor and major version updates on a tty with no GUI running.
Re: hexchat being discontinued?
On Sun, 2024-02-11 at 10:15 +, Michael Kjörling wrote: > On 10 Feb 2024 19:54 -0500, from hunguponcont...@gmail.com (Default > User): > > Any recommendations for a GOOD alternative [IRC client]? > > If you describe what you like about hexchat and dislike about other > alternatives, that would make it easier to suggest something you > might > find "good". > Hey guys, thanks for the replies. I can't really say what it is I like about hexchat and dislike about other IRC clients, except to say that it just seems to work the way my brain does. I don't actually use IRC very much any more, but I would like to know that it's there when I want/need it. Anyway, for now I think I will just continue to use hexchat for now. It works . . . for now.
Re: Home UPS recommendations
On Fri 09 Feb 2024 at 22:28:28 (-0500), Felix Miata wrote: > When you live on a power grid, extended outages are much less common than > when on > or near waterfront or political boundaries. Most of Florida's population has > no > out-of-state neighbors to share utilities with, making its grid more fragile. > Being the lightning capital of the world doesn't help either. Of the US, sure. But I don't think FL can compete with Maracaibo. Cheers, David.
Re: Erreur nvidia suite upgrade noyau 6.6.18
On Sunday 11 February 2024 11:16:51 Jean Bernon wrote: > Une dernière piste. Si tu es sous Wayland, as-tu essayé l'utilitaire > wlr-randr, que je ne connais pas vraiment, mais qui répond > peut-être à ton problème. Merci de vos réponses. wlr-randr : Je ne suis pas sous Wayland mais il parait qu'il a des bugs...
Re: How can we change the keyboard layout?
On Wed 07 Feb 2024 at 06:58:39 (+0100), hw wrote: > On Tue, 2024-02-06 at 21:43 -0600, David Wright wrote: > > On Tue 06 Feb 2024 at 11:28:11 (+0100), hw wrote: > > > [...] > > > I'm talking about wayland all the time; you brought Xorg up instead. > > > > If that concerned you unduly, you could have put that in the Subject > > line. > > It doesn't concern me. > > > It's also obvious that "change the keyboard layout" is ambiguous, > > and you didn't intend to mean switching between two layouts. > > It's not at all obvious, and it's not really ambiguous. Changing the > keyboard layout has always been about changing the keybaord layout and > never about switching between different keyboards or between different > layouts. That only came up much later when such a feature was added > to some so-called desktop environments, and it's a very short sighted > feature since it omits a way of changing they keyboard layouts, which > is a far more important feature. It seems quite important when you're used to typing in more than one language, and want your layout to match what you're used to. > > > [...] > > My 2014 keyboard appears to identify itself correctly as a K520. My > > old IBM M says it's an "AT Translated Set 2 keyboard", which seems > > reasonable for a keyboard dating from 1988. > > I can see USB keyboards identifying themselves, but keyboards with > PS/2 or DIN connectors? How does your keyboard from 1988 connect? PS/2. IIRC it came with a genuine IBM PS/2 computer. > > In 26 years, the number of keys has increased considerably, from 102 > > to 107, plus six audiovisual buttons. Two of the extra keys are > > shifting ones (win and fn). > > 10% more keys isn't considerably more. Can you show me a keyboard > with 122 keys that has all keys usable and unique rather than sending > key combinations instead? That would be difficult: I've never had a 122 key keyboard, or even seen one. You have one. In terms of xev output, are there duplicate keys? Which ones, and how does xev identify them? The keyboards I have access to all send usable keycodes, even where the engravings are the same, eg, Return/36 and KP_Enter/104 are both engraved with "Enter", KP_Subtract/82 and minus/20 are both engraved with "-". The only key on this K520 that doesn't send a keycode on its own is the gold FN key, which behaves more like a laptop's Fn key, sending "control functions" like Sleep; plus a battery charge indicator. > > > We're still trying to figure out keyboards manually. Instead of > > > improvements, we now have come so far that we even can't do that at > > > all now. > > > > I'm guessing that criticism is specific to wayland. > > No, it's about keyboards and computers. Well excuse me. You did say earlier that you were talking about wayland all the time. Now, without indication, you're talking about all keyboards and computers. How are we meant to keep up? As for figuring out keyboards, I would say that Xorg does a pretty flexible job. There are plenty of preselected options available in /usr/share/X11/xkb/rules/base.lst, and I guess you can override all you like with /etc/X11/xkb/ to get whatever you like. Not that I've needed to do so, as the options provided work here AFAICT. > Can you show me a keyboard > that you can plug in and have working with the correct keyboard layout > so that every key does what it is supposed to do without any > configuration required? No, not without /any/ configuration. I'm guessing that you mean an EDID-like PROM that completely describes the layout of every key. I don't know that keyboard manufacturers have ever looked at something like that, at least for detached keyboards. But even then, it's likely that some configuration would be necessary as people exercise their own preferences over at least such things as CapsLock's behaviour and placement. If such advances led to an inability to tweak the layout, I'd see that as a backward step. > I haven't seen one yet. You still need to pick a keyboard in a Debian > or Fedora installer because it can't figure out for what language the > keyboard is, how many keys it has and whatever else may be necessary. > When you log into a GUI like gnome, you still need to pick the > keyboard layout in case you connected a different keyboard after the > installation. > > I can connect a German keyboard instead of the currently connected US > one and neither the console nor gnome would adjust to that. That one > keyboard identifies itself as 'foo' and the other one as 'bar' doesn't > make a difference. > > I could connect both at the same time. What do you think what happens > when I press the same key on either, like the = key for example? I > haven't tried it yet but I'm sure that pressing = on the German > keyboard will give some other character instead of =. How can that > be? > > Do you see in the gnome settings multiple keyboards displayed when you > connect multiple keyboards at the same time so you can at least pick
Re: 6.1.0-18 i NVIDIA
Bon dia, no m'han arribat alguns missatges de la llista, entre ells el meu propi ... He compilat correctament amb 6.1.0-17 i em sembla que el 6.1.0-16 (no confirmo perquè el vaig esborrar) Finalment i espero que temporalment em quedo a 6.11.0-17 i NVIDIA esperant poder actualitzsr d'alguna manera. Salutacions Jordi Sent from MailDroid -Original Message- From: Vicen Rodriguez To: debian-user-catalan@lists.debian.org Sent: dg., 11 de febr. 2024 17:06 Subject: Re: 6.1.0-18 i NVIDIA Bon dia: Jo he tingut el mateix problema. 6.1.0-13-amd64, 6.1.0-16-amd64 i 6.1.0-17-amd64 no tenen aquest problema. L'intent d'actualització a 6.1.0-18-amd64 genera l'error. Cercant una mica, les recomanacions que he trobat per intentar esquivar el problema han estat quedar-se a 6.1.0-17-amd64 o deixar de fer servir el nvidia-driver i passar-se a nouveau. De moment, segueixo a 6.1.0-17-amd64. Salut, Vicen El dom, 11-02-2024 a las 10:07 +0100, Narcis Garcia escribió: > Bon dia; > > Debian 11 (old/Stable) per a Linux utilitza el nucli 5.10 > Debian 12 (Stable) per a Linux utilitza el nucli 6.1 > Debian 12 (Backports) per a Linux disposa del nucli 6.5 > > Entenc que et refereixes en tot moment a Linux 6.1.0-18 > Amb quins nuclis ho has provat sense problema? > > > El 11/2/24 a les 10:01, Jordi ha escrit: > > Bon dia, ahir vaig actualitzar el debian i ara a l'intentar > > compilar > > els controladors de NVIDIA em surt el següent error : GPL- > > incompatible > > module nvidia.ko uses GPL-only symbol rcu_read_unlock. Això passa > > amb > > el nucli 6.0.1-18. Cap controlador NVIDIA es pot compilar amb > > aquest > > nucli i tots els controladors es compilen en altres nuclis. > > > > Hi ha alguna referència a aquest tema en alguna llista però no he > > trobat com solventar-ho. Algú sap com fer-ho, no sé, pot ser > > afegint > > algun paràmetre a /etc/default/grub ?? > > > > Salutacions > > > > Jordi > > > > >
Re: 6.1.0-18 i NVIDIA
Bon dia: Jo he tingut el mateix problema. 6.1.0-13-amd64, 6.1.0-16-amd64 i 6.1.0-17-amd64 no tenen aquest problema. L'intent d'actualització a 6.1.0-18-amd64 genera l'error. Cercant una mica, les recomanacions que he trobat per intentar esquivar el problema han estat quedar-se a 6.1.0-17-amd64 o deixar de fer servir el nvidia-driver i passar-se a nouveau. De moment, segueixo a 6.1.0-17-amd64. Salut, Vicen El dom, 11-02-2024 a las 10:07 +0100, Narcis Garcia escribió: > Bon dia; > > Debian 11 (old/Stable) per a Linux utilitza el nucli 5.10 > Debian 12 (Stable) per a Linux utilitza el nucli 6.1 > Debian 12 (Backports) per a Linux disposa del nucli 6.5 > > Entenc que et refereixes en tot moment a Linux 6.1.0-18 > Amb quins nuclis ho has provat sense problema? > > > El 11/2/24 a les 10:01, Jordi ha escrit: > > Bon dia, ahir vaig actualitzar el debian i ara a l'intentar > > compilar > > els controladors de NVIDIA em surt el següent error : GPL- > > incompatible > > module nvidia.ko uses GPL-only symbol rcu_read_unlock. Això passa > > amb > > el nucli 6.0.1-18. Cap controlador NVIDIA es pot compilar amb > > aquest > > nucli i tots els controladors es compilen en altres nuclis. > > > > Hi ha alguna referència a aquest tema en alguna llista però no he > > trobat com solventar-ho. Algú sap com fer-ho, no sé, pot ser > > afegint > > algun paràmetre a /etc/default/grub ?? > > > > Salutacions > > > > Jordi > > > > >
Re: Mixing HDD and SSD in lvm
Hi, On Sun, Feb 11, 2024 at 11:00:07AM +0100, Kamil Jońca wrote: > ID# ATTRIBUTE_NAME FLAGSVALUE WORST THRESH FAIL RAW_VALUE > 246 Total_LBAs_Written -O--CK 100 100 000-14380174325 > [...] > --8<---cut here---end--->8--- > > Do I unterstand correctly, that to have TB written I should take > "Total_LBAs_Written" > and divide it by 1024*1024*2 ? In theory yes. The raw value of attribute 246 is supposed to be the number of LBAs written where an LBA is the logical sector size, in your case 512 bytes. However, I have a number of devices where 246 is not in units of 512 bytes. Aside from the usual 512b I have seen units of - 512,000 bytes - 1GiB (!) - 1MiB - 32MiB So your process is correct but you will want to check what units your drives actually increment in. If possible, write a known quantity to one of them and see how much it goes up by. The documentation for your drives may also let you know this, or let you know another SMART attribute you can use for this purpose. > 2nd question. > I have read about "trim/discard" operations in SSD context and I am not > sure how to setup these here. These days just don't do anything. There is a systemd timer called fstrim.timer on default Debian that activates periodically and does offline discard on every mounted filesystem, and this is probably the best way. You can instead put "discard" in the mount options of most filesystems and then they will do online discard as they go, but there is not usually any need to do this. Also LVM has a discard option. It is on by default and all this does is trigger a discard when you remove an LV. Again that is best left on by default. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: shred bug? [was: Unidentified subject!]
On Sun 11 Feb 2024 at 09:54:24 (-0500), Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: > > On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > > > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > > > > [...] > > > > > > What Thomas was trying to do is to get a cheap, fast random number > > > > generator. Shred seems to have such. > > > > > > Well... I certainly wouldn't call it a bug. Maybe a feature request. > > > > Still there's the discrepancy between doc and behaviour. > > There isn't. The documentation says: > > SYNOPSIS >shred [OPTION]... FILE... > > DESCRIPTION >Overwrite the specified FILE(s) repeatedly, in order to make it harder >for even very expensive hardware probing to recover the data. > >If FILE is -, shred standard output. > > In every sentence, the word FILE appears. There's nothing in there > which says "you can operate on a non-file". > > Once you grasp what the command is *intended* to do (rewind and overwrite > a file repeatedly), it makes absolutely perfect sense that it should > only operate on rewindable file system objects. > > If you want it to write a stream of data instead of performing its normal > operation (rewinding and rewriting), that's a new feature. > > If you'd prefer the documentation to say explicitly "only regular files > and block devices are allowed", that would be an upstream documentation > *clarification* request. Perhaps info puts it better? A FILE of ‘-’ denotes standard output. The intended use of this is to shred a removed temporary file. For example: i=$(mktemp) exec 3<>"$i" rm -- "$i" echo "Hello, world" >&3 shred - >&3 exec 3>- However, the command ‘shred - >file’ does not shred the contents of FILE, since the shell truncates FILE before invoking ‘shred’. Use the command ‘shred file’ or (if using a Bourne-compatible shell) the command ‘shred - 1<>file’ instead. Cheers, David.
Re: hexchat being discontinued?
I enjoyed using Konversation from the KDE Project. I think it's pretty good! irssi is quite nice too if you don't mind using the terminal. I thought the quickstart guide was excellent https://irssi.org/New-users/. On 2/10/24 7:54 PM, Default User wrote: :( Well, it seems that hexchat is being discontinued. IMHO, it is/was the only IRC client that was actually usable. Any recommendations for a GOOD alternative? -- Jag Talon (he/him) https://jagtalon.net/ https://weirder.earth/@jag https://aangat.lahat.computer/
Re: shred bug? [was: Unidentified subject!]
Hi, to...@tuxteam.de wrote: > Still there's the discrepancy between doc and behaviour. Depends at which documentation you look. Obviously stemming from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#36 i read in https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html "A file of ‘-’ denotes standard output. The intended use of this is to shred a removed temporary file. For example: [shell wizzardry]" It works as long as stdout is connected to a data file, or block device, or directory, or symbolic link, or to a character device that is not a terminal. (Maybe it refuses later on some of these types, but not at the location with the message "invalid file type". I wonder if i can connect stdout to a symbolic link instead of its target.) The bug would thus have to be filed against the man page https://sources.debian.org/src/coreutils/9.4-3/man/shred.1/ which says only "If FILE is \-, shred standard output." The info empire of coreutils says what above web manual says. https://sources.debian.org/src/coreutils/9.4-3/doc/coreutils.texi/#L10705 Have a nice day :) Thomas
Re: Unidentified subject!
On Sun, Feb 11, 2024 at 9:52 AM Thomas Schmitt wrote: > > David Christensen wrote: > > Concurrency: > > threads throughput > > 8 205+198+180+195+205+184+184+189=1,540 MB/s > > There remains the question how to join these streams without losing speed > in order to produce a single checksum. (Or one would have to divide the > target into 8 areas which get checked separately.) Hash Tree or Merkle Tree. They are used in blockchains. > Does this 8 thread generator cause any problems with the usability of > the rest of the system ? Sluggish program behavior or so ? > > The main reason to have my own low-quality implementation of a random > stream was that /dev/urandom was too slow for 12x speed (= 1.8 MB/s) CD-RW > media and that higher random quality still put too much load on a > single-core 600 MHz Pentium system. That was nearly 25 years ago. Jeff
latest old-stable amd64 kernel not available signed
# aptitude search linux-image | egrep -v 'dbg|cloud|rt|e-5.1' i A linux-image-6.0.0-0.deb11.2-amd64 - Linux 6.0 for 64-bit PCs (signed) i linux-image-6.1.0-0.deb11.11-amd64 - Linux 6.1 for 64-bit PCs (signed) i linux-image-6.1.0-0.deb11.13-amd64 - Linux 6.1 for 64-bit PCs (signed) p linux-image-6.1.0-0.deb11.13-amd64-unsigned - Linux 6.1 for 64-bit PCs p linux-image-6.1.0-0.deb11.17-amd64-unsigned - Linux 6.1 for 64-bit PCs i A linux-image-6.1.0-0.deb11.7-amd64 - Linux 6.1 for 64-bit PCs (signed) p linux-image-amd64 - Linux for 64-bit PCs (meta-package) p linux-image-amd64-signed-template - Template for signed linux-image packages for amd64 v linux-image-generic - # linux-image-6.1.0-0.deb11.17-amd64-unsigned has a timestamp 5 days ago. Can anyone explain why linux-image-6.1.0-0.deb11.17-amd64 apparently does not exist? How about: why does installing linux-image-amd64 propose to install a 5.10 kernel instead of 6.1 even though backports is included in sources.list? I'm using sources as shown on https://gist.github.com/gustavorv86/d60a25ad5f70b0dfc382670d3dc6da8d except omitting the deb-src lines. -- 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: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: [...] >If FILE is -, shred standard output. > > In every sentence, the word FILE appears. There's nothing in there > which says "you can operate on a non-file". Point taken, yes. Cheers -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: > On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > > [...] > > > > What Thomas was trying to do is to get a cheap, fast random number > > > generator. Shred seems to have such. > > > > Well... I certainly wouldn't call it a bug. Maybe a feature request. > > Still there's the discrepancy between doc and behaviour. There isn't. The documentation says: SYNOPSIS shred [OPTION]... FILE... DESCRIPTION Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data. If FILE is -, shred standard output. In every sentence, the word FILE appears. There's nothing in there which says "you can operate on a non-file". Once you grasp what the command is *intended* to do (rewind and overwrite a file repeatedly), it makes absolutely perfect sense that it should only operate on rewindable file system objects. If you want it to write a stream of data instead of performing its normal operation (rewinding and rewriting), that's a new feature. If you'd prefer the documentation to say explicitly "only regular files and block devices are allowed", that would be an upstream documentation *clarification* request.
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: [...] > > What Thomas was trying to do is to get a cheap, fast random number > > generator. Shred seems to have such. > > Well... I certainly wouldn't call it a bug. Maybe a feature request. Still there's the discrepancy between doc and behaviour. Cheers -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > On Sat, Feb 10, 2024 at 07:10:54PM -0500, Greg Wooledge wrote: > > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > > > 2024-02-10 16:03:50 dpchrist@laalaa ~ > > > $ shred -s 1K - | wc -c > > > shred: -: invalid file type > > > 0 > > > > > > > > > It looks like a shred(1) needs a bug report. > > > > I'm confused what you expected this command to do. You wanted to > > "destroy" (by overwriting with random data) a pipe to wc? What > > would that even look like? > > What Thomas was trying to do is to get a cheap, fast random number > generator. Shred seems to have such. Well... I certainly wouldn't call it a bug. Maybe a feature request.
Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)
On 11 Feb 2024 12:21 +0100, from m...@bokomoko.de (Rainer Dorsch): > - How do I set a timeout/limit for anacron, that it cannot block forever > during a reboot? I believe you want something like: # systemctl edit anacron.service and [Service] TimeoutStopSec=300 (or whichever value you feel comfortable with) This will create a drop-in file to customize the anacron.service unit file with the contents you provide. You can also directly edit the unit file, but that will cause conflicts when the package is upgraded. See systemd.service(5) for details; search for TimeoutSec=, TimeoutStartSec= and TimeoutStopSec=. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: shred bug?
Hi, debian-u...@howorth.org.uk wrote: > Maybe it is unstated but mandatory to use -n 1 as well? > And optionally -s N? Naw. It just doesn't want to work pipes. Initially i tried with these options: shred -n 1 -s 1K -v - | sha256sum as preparation for a proposal to Gene Heskett, like: shred -n 1 -s 204768K -v - | tee /dev/sdm1 | sha256sum > I expect reading the code would tell. My code analysis is in https://lists.debian.org/msgid-search/1162291656137153...@scdbackup.webframe.org to...@tuxteam.de found bug 155175 from 2002, which explains why. See https://lists.debian.org/msgid-search/zcdxzya0ayrmp...@tuxteam.de Have a nice day :) Thomas
Re: Erreur nvidia suite upgrade noyau 6.6.18
On 2/11/24 11:43, Michel Verdier wrote: Le 10 février 2024 ajh-valmer a écrit : Je ne peux donc pas augmenter la résolution avec ce pilote "Nouveau". On dirait que c'est le pilote "Vesa" qui a pris la main, pas "Nouveau"... As-tu regardé dans les log ? Le pilote utilisé est indiqué clairement Il me semble que le fichier à regarder serait très probablement /var/log/Xorg.0.log (après un démarrage infructueux du serveur d'affichage X11 ie Xorg) Le serveur Xorg peut aussi être démarré par la commande /usr/bin/startx Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir: https://github.com/RefPerSys/RefPerSys
Re: hexchat being discontinued?
On 2/11/24, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > On 10 Feb 2024 19:54 -0500, from hunguponcont...@gmail.com (Default User): >> Any recommendations for a GOOD alternative [IRC client]? > > If you describe what you like about hexchat and dislike about other > alternatives, that would make it easier to suggest something you might > find "good". That information might also inspire the Developers of the remaining chat clients, too. Which then reminds that there's also "reportbug" with its wishlist bug reports "--severity" option. Wishlist could be used to let programs know there are features that could be added to what's already awesome about their current offerings. Pointing Developers at existing open source code would help. Seeing this as a sign to start poking around at Debian programming oneself would be fabulous. I'm actually about to point "generative AI" at deprecated code myself because *some* folks are having luck with that newfangled option making their lives easier. Cindy :) -- Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: shred bug? [was: Unidentified subject!]
David Christensen wrote: > On 2/10/24 16:10, Greg Wooledge wrote: > > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > >> 2024-02-10 16:03:50 dpchrist@laalaa ~ > >> $ shred -s 1K - | wc -c > >> shred: -: invalid file type > >> 0 > >> > >> > >> It looks like a shred(1) needs a bug report. > > > > I'm confused what you expected this command to do. You wanted to > > "destroy" (by overwriting with random data) a pipe to wc? What > > would that even look like? > > > > The basic premise of shred is that it determines the size of the > > file, then writes data over it, rewinds it, and repeats this a few > > times. A pipe to a process has no size, and can't be rewound. > > > > Declaring a pipe to be an "invalid file type" for shredding sounds > > pretty reasonable to me. > > > The documentation is confusing: > > On 2/10/24 16:05, David Christensen wrote: > > 2024-02-10 16:03:42 dpchrist@laalaa ~ > > $ man shred | grep 'If FILE is -' > > If FILE is -, shred standard output. Maybe it is unstated but mandatory to use -n 1 as well? And optionally -s N? I expect reading the code would tell. First time I've read the man page properly. Interesting point about COW filesystems such as btrfs :)
Re: Debian 12.5 upgrade error
* 2024-02-11 14:13:51+0200, Alexis Grigoriou wrote: > I have encountered an error upgrading to 12.5 from 12.4 regarding the > nvidia-driver and linux-image 6.1.0.18. The error is: Very likely this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063656 Not your fault. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature
Re: Debian 12.5 upgrade error
Hellow Alexis, On Sun, 2024-02-11 at 14:13 +0200, Alexis Grigoriou wrote: > I have encountered an error upgrading to 12.5 from 12.4 regarding > the > nvidia-driver and linux-image 6.1.0.18. The error is: > > env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=6.1.0-18- > amd64(bad exit status: 2) > > I get that error twice. > After the upgrade I get a non-bootable 6.1.0-18 image. > Doing some fiddling, I got a bootable 6.1.0-18 image but no GUI. > > I removed linux-image and linux-headers 6.1.0.-18 an I now have > 6.1.0.-17 working. > > Has anyone else encounter this issue? What command did you type exactly? In normal cases, i do like this: sudo su - apt update apt upgrade Sincerely, Byunghee -- ^고맙습니다 _布德天下_ 감사합니다_^))// signature.asc Description: This is a digitally signed message part
Debian 12.5 upgrade error
I have encountered an error upgrading to 12.5 from 12.4 regarding the nvidia-driver and linux-image 6.1.0.18. The error is: env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=6.1.0-18- amd64(bad exit status: 2) I get that error twice. After the upgrade I get a non-bootable 6.1.0-18 image. Doing some fiddling, I got a bootable 6.1.0-18 image but no GUI. I removed linux-image and linux-headers 6.1.0.-18 an I now have 6.1.0.-17 working. Has anyone else encounter this issue?
Re: Fast Random Data Generation (Was: Re: Unidentified subject!)
On 2/11/24 05:26, Linux-Fan wrote: David Christensen writes: On 2/11/24 00:11, Thomas Schmitt wrote: [...] Increase block size: 2024-02-11 01:18:51 dpchrist@laalaa ~ $ dd if=/dev/urandom of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.62874 s, 296 MB/s Here (Intel Xeon W-2295) | $ dd if=/dev/urandom of=/dev/null bs=1M count=1K | 1024+0 records in | 1024+0 records out | 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.15018 s, 499 MB/s Raspberry pi 5: dd if=/dev/urandom of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.0122 s, 356 MB/s Now lets do it right and use random.. dd if=/dev/random of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.9859 s, 360 MB/s Secure Random can be obtained from OpenSSL: | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done | | real 0m49.288s | user 0m44.710s | sys 0m4.579s time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done real1m30.884s user1m24.528s sys 0m6.116s
Re: Debian bookworm 12.4 installation wifi card not being detected
On Sat, Feb 10, 2024 at 02:41:42PM -0600, Exeonz wrote: > Results on ubuntu are > > /03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4360 > 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03) > Subsystem: Apple Inc. BCM4360 802.11ac Wireless Network Adapter > [106b:0117] > Kernel driver in use: wl > Kernel modules: bcma, wl/ > > > During debian install it's same result but without /kernel driver and kernel > modules/ > I use an iOS device and I don't think tethering feature is supported there. I just posted this to debian-boot in response to the earlier query there: Try the image for a DVD at https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-12.5.0-amd64-DVD-1.iso That may give you more packages in order to be able to build the needed kernel modules, at least. Andy (amaca...@debian.org)
Re: Debian bookwork 12.4 installation wifi card not being detected
On Sun, Feb 11, 2024 at 12:08:08AM -0600, Exeonz wrote: > I just tried using Trixie and it's the same issues. Seems that the installer > isn't even recognizing wifi card at all so no matter what drives I give it > refuses to use them. *No Ethernet card was found on the system.* I think my > only option is using wifi usb adapter that works, I already tried using usb > wifi adapter that I had at hand but didn't work because it too uses > proprietary driver. If you can find someone to help who has a wired network or you can run an Ethernet cable to your wifi router - a USB to Ethernet adapter and a cable should work. Once you have that in place, you should be able to get the appropriate dkms package, build the module for the Debian kernel and it should all be fine. If tethering to an Apple phone can work, that can also work but will possibly be more difficult to set up. You will need the prerequisites to build kernel modules - so probably at least the Debian build-essential package and kernel headers. Andy
Re: Fast Random Data Generation
Hi, Linux-Fan wrote: > I wrote a program to automatically generate random bytes in multiple > threads: > https://masysma.net/32/big4.xhtml > ... > || Wrote 102400 MiB in 13 s @ 7812.023 MiB/s That's impressive. > Secure Random can be obtained from OpenSSL: > > | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 > * 1024)); done > | > | real 0m49.288s > | user 0m44.710s > | sys 0m4.579s > Effectively 2078 MiB/s (quite OK for single-threaded operation). Probably the best choice for sceptics who critizise a reproducible random stream or mistrust random people's aptness to produce random. (If the number of desired loops gets larger, then one could do arithmetik in a "while" loop instead of "for" and "seq".) Have a nice day :) Thomas
[ *** ] Job anacron.service/stop running (15min 49s / no limit)
Hello, I saw during a reboot [ *** ] Job anacron.service/stop running (15min 49s / no limit) eventually I did a hard reset, since I was not sure if the system simply hang. I have two quick questions: - How can I found out which process anacron is still running? - How do I set a timeout/limit for anacron, that it cannot block forever during a reboot? Thanks Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Unidentified subject!
Hi, David Christensen wrote: > Concurrency: > threads throughput > 8 205+198+180+195+205+184+184+189=1,540 MB/s There remains the question how to join these streams without losing speed in order to produce a single checksum. (Or one would have to divide the target into 8 areas which get checked separately.) Does this 8 thread generator cause any problems with the usability of the rest of the system ? Sluggish program behavior or so ? The main reason to have my own low-quality implementation of a random stream was that /dev/urandom was too slow for 12x speed (= 1.8 MB/s) CD-RW media and that higher random quality still put too much load on a single-core 600 MHz Pentium system. That was nearly 25 years ago. I wrote: > > Last time i tested /dev/urandom it was much slower on comparable machines > > and also became slower as the amount grew. > Did you figure out why the Linux random number subsystem slowed, and at what > amount? No. I cannot even remember when and why i had reason to compare it with my own stream generator. Maybe 5 or 10 years ago. The throughput was more than 100 times better. I have to correct my previous measurement on the 4 GHz Xeon, which was made with a debuggable version of the program that produced the stream. The production binary which is compiled with -O2 can write 2500 MB/s into a pipe with a pacifier program which counts the data: $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | $(scdbackup -where bin)/raedchen -step 100m -no_output -print_count 100.0g bytes real0m39.884s user0m30.629s sys 0m41.013s (One would have to install scdbackup to reproduce this and to see raedchen count the bytes while spinning the classic SunOS boot wheel: |/-\|/-\|/-\ http://scdbackup.webframe.org/main_eng.html http://scdbackup.webframe.org/examples.html Oh nostalgy ... ) Totally useless but yielding nearly 4000 MB/s: $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni >/dev/null real0m27.064s user0m23.433s sys 0m3.646s The main bottleneck in my proposal would be the checksummer: $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | md5sum 5a6ba41c2c18423fa33355005445c183 - real2m8.160s user2m25.599s sys 0m22.663s That's quite exactly 800 MiB/s ~= 6.7 Gbps. Still good enough for vanilla USB-3 with a fast SSD, i'd say. > TIMTOWTDI. :-) Looks like another example of a weak random stream. :)) Have a nice day :) Thomas
Re: Erreur nvidia suite upgrade noyau 6.6.18
Le 10 février 2024 ajh-valmer a écrit : > Je ne peux donc pas augmenter la résolution avec ce pilote "Nouveau". > On dirait que c'est le pilote "Vesa" qui a pris la main, pas "Nouveau"... As-tu regardé dans les log ? Le pilote utilisé est indiqué clairement
Fast Random Data Generation (Was: Re: Unidentified subject!)
David Christensen writes: On 2/11/24 00:11, Thomas Schmitt wrote: [...] Increase block size: 2024-02-11 01:18:51 dpchrist@laalaa ~ $ dd if=/dev/urandom of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.62874 s, 296 MB/s Here (Intel Xeon W-2295) | $ dd if=/dev/urandom of=/dev/null bs=1M count=1K | 1024+0 records in | 1024+0 records out | 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.15018 s, 499 MB/s Concurrency: threads throughput 1 296 MB/s 2 285+286=571 MB/s 3 271+264+266=801 MB/s 4 249+250+241+262=1,002 MB/s 5 225+214+210+224+225=1,098 MB/s 6 223+199+199+204+213+205=1,243 MB/s 7 191+209+210+204+213+201+197=1,425 MB/s 8 205+198+180+195+205+184+184+189=1,540 MB/s I wrote a program to automatically generate random bytes in multiple threads: https://masysma.net/32/big4.xhtml Before knowing about `fio` this way my way to benchmark SSDs :) Example: | $ big4 -b /dev/null 100 GiB | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma. | For further info send an e-mail to ma_sys...@web.de. | | 0.00% +0 MiB 0 MiB/s 0/102400 MiB | 3.48% +3562 MiB 3255 MiB/s 3562/102400 MiB | 11.06% +7764 MiB 5407 MiB/s 11329/102400 MiB | 19.31% +8436 MiB 6387 MiB/s 19768/102400 MiB | 27.71% +8605 MiB 6928 MiB/s 28378/102400 MiB | 35.16% +7616 MiB 7062 MiB/s 35999/102400 MiB | 42.58% +7595 MiB 7150 MiB/s 43598/102400 MiB | 50.12% +7720 MiB 7230 MiB/s 51321/102400 MiB | 58.57% +8648 MiB 7405 MiB/s 59975/102400 MiB | 66.96% +8588 MiB 7535 MiB/s 68569/102400 MiB | 75.11% +8343 MiB 7615 MiB/s 76916/102400 MiB | 83.38% +8463 MiB 7691 MiB/s 85383/102400 MiB | 91.74% +8551 MiB 7762 MiB/s 93937/102400 MiB | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB | | Wrote 102400 MiB in 13 s @ 7812.023 MiB/s [...] Secure Random can be obtained from OpenSSL: | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done | | real 0m49.288s | user 0m44.710s | sys 0m4.579s Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not designed to generate large amounts of random data as the size is limited by integer range... HTH Linux-Fan öö pgpoAijtbLtka.pgp Description: PGP signature
Re: Mixing HDD and SSD in lvm
Kamil Jońca writes: > Debian box with LVM > LVM uses 2 PV - raid devices each uses 2 HDD (rotating) > discs (with sata interfaces). > > Now I am considering replacing one PV with md device constisting of SSD > discs, so LVM will be have one "HDD" based pv and one SSD based PV. > Should I worry about anything (speed differences or sth)? > KJ Finally I did it. Installed 2 ssd's, made raid1 on them, and use this md as PV in lvm. Then with pvmove I moved 2 most loaded LV's to this md (and rest to the other PV, then remove old empty PV). So far so good, everything seems to working fine (and in fact machine looks to be more responsive especially with reads, but this might be autosuggestion). But I have 2 questions. 1. --8<---cut here---start->8--- sudo smartctl -x /dev/sdc [...] === START OF INFORMATION SECTION === Model Family: Crucial/Micron Client SSDs Device Model: CT4000MX500SSD1 Serial Number:2333E86CB9A0 LU WWN Device Id: 5 00a075 1e86cb9a0 Firmware Version: M3CR046 User Capacity:4 000 787 030 016 bytes [4,00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate:Solid State Device Form Factor: 2.5 inches TRIM Command: Available Device is:In smartctl database 7.3/5528 ATA Version is: ACS-3 T13/2161-D revision 5 SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is:Sun Feb 11 10:48:39 2024 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled AAM feature is: Unavailable APM level is: 254 (maximum performance) Rd look-ahead is: Enabled Write cache is: Enabled DSN feature is: Unavailable ATA Security is: Disabled, frozen [SEC2] Wt Cache Reorder: Unknown [...] ID# ATTRIBUTE_NAME FLAGSVALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 100 100 000-0 5 Reallocate_NAND_Blk_Cnt -O--CK 100 100 010-0 9 Power_On_Hours -O--CK 100 100 000-88 12 Power_Cycle_Count -O--CK 100 100 000-10 171 Program_Fail_Count -O--CK 100 100 000-0 172 Erase_Fail_Count-O--CK 100 100 000-0 173 Ave_Block-Erase_Count -O--CK 100 100 000-4 174 Unexpect_Power_Loss_Ct -O--CK 100 100 000-0 180 Unused_Reserve_NAND_Blk PO--CK 000 000 000-231 183 SATA_Interfac_Downshift -O--CK 100 100 000-0 184 Error_Correction_Count -O--CK 100 100 000-0 187 Reported_Uncorrect -O--CK 100 100 000-0 194 Temperature_Celsius -O---K 074 059 000-26 (Min/Max 19/41) 196 Reallocated_Event_Count -O--CK 100 100 000-0 197 Current_Pending_ECC_Cnt -O--CK 100 100 000-0 198 Offline_Uncorrectable CK 100 100 000-0 199 UDMA_CRC_Error_Count-O--CK 100 100 000-0 202 Percent_Lifetime_Remain CK 100 100 001-0 206 Write_Error_Rate-OSR-- 100 100 000-0 210 Success_RAIN_Recov_Cnt -O--CK 100 100 000-0 246 Total_LBAs_Written -O--CK 100 100 000-14380174325 247 Host_Program_Page_Count -O--CK 100 100 000-124507650 248 FTL_Program_Page_Count -O--CK 100 100 000-72553858 [...] --8<---cut here---end--->8--- Do I unterstand correctly, that to have TB written I should take "Total_LBAs_Written" and divide it by 1024*1024*2 ? (2 - because I should multiply by 512 as sector size, and then divide by 1024 one more) so in my case it would be --8<---cut here---start->8--- echo $(( 14380174325 / (1024*1024*2 ) )) 6857 --8<---cut here---end--->8--- this suggest almost 7TB (this is not unbelievable when I think about inital operations, later it should be less per day) Am I correct? (and any suggestions about these SMART values?) 2nd question. I have read about "trim/discard" operations in SSD context and I am not sure how to setup these here. KJ
Re: Erreur nvidia suite upgrade noyau 6.6.18
Une dernière piste. Si tu es sous Wayland, as-tu essayé l'utilitaire wlr-randr, que je ne connais pas vraiment, mais qui répond peut-être à ton problème. - Mail original - > De: "ajh-valmer" > À: debian-user-french@lists.debian.org > Envoyé: Samedi 10 Février 2024 19:52:54 > Objet: Re: Erreur nvidia suite upgrade noyau 6.6.18 > On Saturday 10 February 2024 19:41:01 Jean Bernon wrote: > > As-tu regardé du côté de xrandr ? > > https://doc.ubuntu-fr.org/xrandr#ajouter_une_resolution > Oui, merci du rappel, j'ai fait tout ça, et j'obtiens cette réponse : > Screen 0: minimum 320 x 200, ..., maximum 1024 x 768 > Je ne peux donc pas augmenter la résolution avec ce pilote "Nouveau". > On dirait que c'est le pilote "Vesa" qui a pris la main, pas > "Nouveau"... > > > Oui, j'ai fait exactement comme expliqué sur le lien sus-indiqué. > > > Ça semble marcher sauf que je me retrouve avec une résolution > > > d'écran > > > trop faible de 1024x768, alors qu'avant avec le pilote nvidia, > > > j'avais 1280x1024. > > > J'ai vainement cherché, j'ai toujours cette faible résolution > > > d'écran. > > > Voilà donc mon problème. > > > Les modules "nouveau" et "vesa" sont chargés.
Re: hexchat being discontinued?
On 10 Feb 2024 19:54 -0500, from hunguponcont...@gmail.com (Default User): > Any recommendations for a GOOD alternative [IRC client]? If you describe what you like about hexchat and dislike about other alternatives, that would make it easier to suggest something you might find "good". -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Unidentified subject!
On 2/11/24 00:11, Thomas Schmitt wrote: Hi, David Christensen wrote: $ time dd if=/dev/urandom bs=8K count=128K | wc -c [...] 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.30652 s, 249 MB/s This looks good enough for practical use on spinning rust and slow SSD. Yes. Maybe the "wc" pipe slows it down ? ... not much on 4 GHz Xeon with Debian 11: $ time dd if=/dev/urandom bs=8K count=128K | wc -c ... 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.13074 s, 260 MB/s $ time dd if=/dev/urandom bs=8K count=128K of=/dev/null ... 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.95569 s, 271 MB/s My CPU has a Max Turbo Frequency of 3.3 GHz. I would expect a 4 GHz processor to be ~21% faster, but apparently not. Baseline with pipeline, wc(1), and bs=8K due to unknown Bash pipeline bottleneck (?): 2024-02-11 01:18:33 dpchrist@laalaa ~ $ dd if=/dev/urandom bs=8K count=128K | wc -c 1073741824 131072+0 records in 131072+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.27283 s, 251 MB/s Eliminate pipeline and wc(1): 2024-02-11 01:18:44 dpchrist@laalaa ~ $ dd if=/dev/urandom of=/dev/null bs=8K count=128K 131072+0 records in 131072+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.75946 s, 286 MB/s Increase block size: 2024-02-11 01:18:51 dpchrist@laalaa ~ $ dd if=/dev/urandom of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.62874 s, 296 MB/s Concurrency: threads throughput 1 296 MB/s 2 285+286=571 MB/s 3 271+264+266=801 MB/s 4 249+250+241+262=1,002 MB/s 5 225+214+210+224+225=1,098 MB/s 6 223+199+199+204+213+205=1,243 MB/s 7 191+209+210+204+213+201+197=1,425 MB/s 8 205+198+180+195+205+184+184+189=1,540 MB/s Last time i tested /dev/urandom it was much slower on comparable machines and also became slower as the amount grew. Did you figure out why the Linux random number subsystem slowed, and at what amount? Therefore i still have my amateur RNG which works with a little bit of MD5 and a lot of EXOR. It produces about 1100 MiB/s on the 4 GHz machine. No cryptographical strength, but chaotic enough to avoid any systematic pattern which could be recognized by a cheater and represented with some high compression factor. The original purpose was to avoid any systematic interference with the encoding of data blocks on optical media. I am sure there are faster RNGs around with better random quality. I assume the Linux kernel in Debian 11 is new enough to support RDRAND (?): https://en.wikipedia.org/wiki/RdRand But, my processor is too old to have Secure Key. $ time perl -MMath::Random::ISAAC::XS -e '$i=Math::Random::ISAAC::XS->new(12345678); print pack 'L',$i->irand while 1' | dd bs=8K count=128K | wc -c 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6523 s, 13.0 MB/s Now that's merely sufficient for shredding the content of a BD-RE medium or a slow USB stick. Okay. I suggest using /dev/urandom and tee(1) to write the same CSPRN stream to all of the devices and using cmp(1) to validate. I'd propose to use a checksummer like md5sum or sha256sum instead of cmp: $random_generator | tee $target | $checksummer dd if=$target bs=... count=... | $checksummer This way one can use unreproducible random streams and does not have to store the whole stream on a reliable device for comparison. TIMTOWTDI. :-) David
Re: 6.1.0-18 i NVIDIA
Bon dia; Debian 11 (old/Stable) per a Linux utilitza el nucli 5.10 Debian 12 (Stable) per a Linux utilitza el nucli 6.1 Debian 12 (Backports) per a Linux disposa del nucli 6.5 Entenc que et refereixes en tot moment a Linux 6.1.0-18 Amb quins nuclis ho has provat sense problema? El 11/2/24 a les 10:01, Jordi ha escrit: Bon dia, ahir vaig actualitzar el debian i ara a l'intentar compilar els controladors de NVIDIA em surt el següent error : GPL-incompatible module nvidia.ko uses GPL-only symbol rcu_read_unlock. Això passa amb el nucli 6.0.1-18. Cap controlador NVIDIA es pot compilar amb aquest nucli i tots els controladors es compilen en altres nuclis. Hi ha alguna referència a aquest tema en alguna llista però no he trobat com solventar-ho. Algú sap com fer-ho, no sé, pot ser afegint algun paràmetre a /etc/default/grub ?? Salutacions Jordi -- Narcis Garcia __ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should remove and omit any @, dot and mailto combinations against automated addresses collectors.
6.1.0-18 i NVIDIA
Bon dia, ahir vaig actualitzar el debian i ara a l'intentar compilar els controladors de NVIDIA em surt el següent error : GPL-incompatible module nvidia.ko uses GPL-only symbol rcu_read_unlock. Això passa amb el nucli 6.0.1-18. Cap controlador NVIDIA es pot compilar amb aquest nucli i tots els controladors es compilen en altres nuclis. Hi ha alguna referència a aquest tema en alguna llista però no he trobat com solventar-ho. Algú sap com fer-ho, no sé, pot ser afegint algun paràmetre a /etc/default/grub ?? Salutacions Jordi
Re: Problema puerto usb-c
El 2024-02-10 a las 19:40 +0100, JA CM escribió: > Buenos días > Tengo una StremCam de Logitec con conector USB-C que hasta hace poco me > funcionaba correctamente pero que ha dejado de hacerlo de una manera > extraña. Que algo deje de funcionar sin más es extraño :-? Lo único que puede haber cambiado es la versión del kernel, pero en Debian estable los cambios del kernel son muy leves entre versiones, sólo actualizan parches de seguridad que no suelen añadir o quitar funcionalidades. Si aún mantienes alguna versión anterior, prueba a iniciar el sistema con otro kernel más antiguo (normalmente el sistema mantiene 2 o 3 núcleos cuando sale alguna actualización). > El SO es un Debian 12 y el Kernel es 6.1.0-17-amd. Tiene arranque dual con > Windows 10 (con fast boot desactivado y en Windows la cámara va bien). La > placa base es una ASUS PRIME X299-A y sólo tiene un puerto USB-C ¿Has probado a conectar la cámara a otro puerto USB (con adaptador)? ¿Has probado a conectar otro dispositivo al puerto USB-C? > Cuando arranco el sistema me detecta sin problemas el dispositivo: > * la salida lsusb y v4lw-ctl --list-devices es: > [image: lsusb.png][image: v412-list.png] > A pesar de esto, en los logs del núcleo (kern.log) me aparece varias veces > el mensaje siguiente: > usb 6-1 *current rate 16000 is different from the runtime rate 48000*. > Si ejecuto el programa de cámaras Cheese en los logs del nucleo me aparecen > multitud de veces los dos mensajes siguientes > 2024-02-10T14:25:19.003426+01:00 debian kernel: [ 2749.691059] *xhci_hcd > :03:00.0: ERROR* Transfer event TRB DMA ptr not part of current TD > ep_index 2 comp_code 13 > 2024-02-10T14:25:19.003427+01:00 debian kernel: [ 2749.691061] xhci_hcd > :03:00.0: Looking for event-dma fffc5a20 trb-start > fffc5130 trb-end fffc5130 seg-start fffc5000> seg-end > fffc5ff0 (...) > Si es guvcview quien arranca la cámara el kernel lanza lo siguiente > 2024-02-10T14:25:41.313584+01:00 debian kernel: [ 2772.000990] *uvcvideo > 6-1:1.1: Failed to query *(130) UVC probe control : -110 (exp. 26). > 2024-02-10T14:25:46.433585+01:00 debian kernel: [ 2777.117761] *uvcvideo > 6-1:1.1: Failed to set UVC probe control : -110 (exp. 26)*. > 2024-02-10T14:25:53.980089+01:00 debian kernel: [ 2784.667935] *DMAR: DRHD*: > handling fault status reg 2 > 2024-02-10T14:25:53.980100+01:00 debian kernel: [ 2784.667944] DMAR: [DMA > Write NO_PASID] Request device [03:00.0] fault addr 0xffe2a000 [fault reason > 0x05] PTE Write access is not set > 2024-02-10T14:25:53.980596+01:00 debian kernel: [ 2784.668452] *xhci_hcd > :03:00.0: WARN* Event TRB for slot 1 ep 0 with no TDs queued? > 2024-02-10T14:25:53.981078+01:00 debian kernel: [ 2784.668949] DMAR: *DRHD: > handling fault status reg 102* > 2024-02-10T14:25:53.981082+01:00 debian kernel: [ 2784.668953] *DMAR: [DMA > Read NO_PASID] *Request device [03:00.0] fault addr 0xffe2d000 [fault reason > 0x06] PTE Read access is not set > El caso es que después de esto, ya deja de aparecer la cámara al ejecutar > lsusb y v4lw-ctl con lo que dev/video0 tampoco existe y no hay cámara. > Además, en los log de núcleo tengo mensajes de intentos de reset del puerto > y de error como los siguientes sin llegar en ningún momento a reconocer la > cámara: (...) > Estoy buscando información por los temas marcados en negrita pero aún no he > llegado a nada concluyente. He descargado y recargado el módulo con > modprobe -rv usbhid ; sudo modprobe -v usbhid > pero tampoco he conseguido nada. Comentar también que recientemente y para > poder instalar el paquete "info" de ayuda de GNU tuve que corregir un error > y es que el archivo /etc/enviroment contenía: JAVA_HOME= > "/usr/lib/jvm/java-17-openjdk-amd64/" y para permitir la instalación tenía > que ser JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64/ > Ahora voy a anular el usbcore.autosuspend pero sin esperanzas, por eso les > escribo, si bien continúo buscando. > > Muchas gracias por adelantado y un saludo. Dejo también en pastebin los > siguientes archivos: > > * https://pastebin.com/1T2grDLQ con errores del kernel > * https://pastebin.com/98VY0B44 con dpkg.log > * https://pastebin.com/sdrJmK06 con history.log de apt Gracias por los paste, muy útiles y completos, así da gusto :-) Por los mensajes que recibes del kernel, he localizado algunos problemas similiares, mira a ver si te algo de lo que comentan te sirve: USB-Controller crashes after increasing webcam resolution https://bbs.archlinux.org/viewtopic.php?id=262432 Logitech BRIO webcam fails with "xhci_hcd :02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873439 Saludos, -- Camaleón
Re: Debian bookworm 12.4 installation wifi card not being detected
Am 10.02.2024 um 14:41:42 Uhr schrieb Exeonz: > /03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries > BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03) > Subsystem: Apple Inc. BCM4360 802.11ac Wireless Network Adapter > [106b:0117] > Kernel driver in use: wl > Kernel modules: bcma, wl/ > During debian install it's same result but without /kernel driver and > kernel modules/ Install the package broadcom-sta-dkms > I use an iOS device and I don't think tethering feature is supported > there. https://support.apple.com/en-ca/guide/iphone/iph45447ca6/ios It seems to be supported. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
Re: [ Era (Sin título)] Compartir archivos con Samba
El 2024-02-11 a las 01:48 +0200, Julián Daich escribió: > El 10/2/24 a las 11:03, Camaleón escribió: > > > > > El tipo (rol) de servidor samba será «standalone server» si no has > > cambiado nada más, que entiendo es lo correcto. > > > > No cambié nada, pero vale la pena verificar si vale de algo¿ en dónde me > fijo? La configuración del servidor Samba la tienes en «/etc/samba/smb.conf», pero si no lo has editado, el rol predeterminado es «standalone», que es el más sencillo. > > Las rutas con acentos no me terminan de convencer (Vídeos, Música), > > crea mejor una de prueba sin caracteres extendidos, p. ej., en Ubuntu, > > «/home/julian/prueba» o el directorio de «Documentos« si ya lo tienes > > creado en «/home/julian/Documentos», y la añades en la configuración de > > Samba (recuerda reiniciar el servidor samba cuando hags cambios). > > > > Hice la prueba. Se comporta igual con directorios sin tilde. > > > > En el cliente hago smb://nombre_del_equipo > > > > Hum... a ver, prueba mejor a conectar desde el cliente con: > > > > smb://julian@ip.servidor.samba.ubuntu/ > > > > Para que te liste los recursos/carpetas disponibles. > > El mismo efecto usando el nombre del equipo o la IP. Por lo menos reconoce > si son válidos. Probé darle rutas erróneas. Probé también con otro cliente > con XFCE4 en Sid y fueron los mismos mensajes. > > usuario@ no cambia mucho el comportamiento. Solo un campo menos en el menú > de diálogo. Por curiosidad ¿has probado a conectar desde algún cliente con Windows? > Probé también la ruta completa a la carpeta smb://equipo/carpeta. A veces da > error de parámetros incorrectos y otras veces dice que la carpeta no existe. > > Creo que el problema está en el servidor. Un Debian 12. Revisa los registros de samba en el servidor, quizá te den alguna pista del origen del problema. Los tienes en «/var/log/samba/*». Si tienes instalado en el cliente «smbclient» prueba a conectarte al recurso desde línea de órdenes «smbclient -U julian //ip.servidor.samba/mi_carpeta_compartida», para depurar errores la consola mejor que la aplicación gráfica (gestor de archivos). > > > Veo que esto de compartir archivos sigue siendo igual > > > de complicado como 20 años atrás. > > > > Igual no... ¡peor! :-) > > > > Ahora tienes que lidiar con la versión de NTLM entre cliente y servidor > > cuando trabajas con equipos y sistemas operativos antiguos (Windows XP, > > etc...). Un horror. > > > > Usé NFS entre servidores de red, pero también me dio problemas cuando lo > quise usar en casa. > > > Por exigencias de la red, tengo Samba en un servidor con Debian 12 y me > > contecto desde mi equipo habitual (Debian 11) sin problemas > > ¿ podrías pasar tu configuración? Claro, lo pongo en un paste que es un poco extenso (expira en 3 días): https://paste.debian.net/1306925 > > , pero con > > dos linux en juego, prefiero conectarlos mediante SFTP, va como la seda > > (eso sí, necesitas que SSH esté configurado y ejecutándose en el > > servidor pero entiendo que lo estará). > > > > sftp://julian@ip.servidor.ubuntu > > > > Si KDE-Connect tendría la opción de explorar archivos entre computadoras > todo sería más fácil- A mi solo me funciona de computadora a teléfono. No sé qué gestor de archivos usa KDE ahora (¿Dolphin, Konqueror?) pero normalmente sólo tienes que instalar algún paquete para que pueda usar protocolos de red (smb://, sftp://, obex://...). Desconozco si KDE-Connect dispone de esa funcionalidad :-? Saludos, -- Camaleón
Re: Unidentified subject!
Hi, David Christensen wrote: > $ time dd if=/dev/urandom bs=8K count=128K | wc -c > [...] > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.30652 s, 249 MB/s This looks good enough for practical use on spinning rust and slow SSD. Maybe the "wc" pipe slows it down ? ... not much on 4 GHz Xeon with Debian 11: $ time dd if=/dev/urandom bs=8K count=128K | wc -c ... 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.13074 s, 260 MB/s $ time dd if=/dev/urandom bs=8K count=128K of=/dev/null ... 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.95569 s, 271 MB/s Last time i tested /dev/urandom it was much slower on comparable machines and also became slower as the amount grew. Therefore i still have my amateur RNG which works with a little bit of MD5 and a lot of EXOR. It produces about 1100 MiB/s on the 4 GHz machine. No cryptographical strength, but chaotic enough to avoid any systematic pattern which could be recognized by a cheater and represented with some high compression factor. The original purpose was to avoid any systematic interference with the encoding of data blocks on optical media. I am sure there are faster RNGs around with better random quality. > $ time perl -MMath::Random::ISAAC::XS -e > '$i=Math::Random::ISAAC::XS->new(12345678); print pack 'L',$i->irand while 1' > | dd bs=8K count=128K | wc -c > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6523 s, 13.0 MB/s Now that's merely sufficient for shredding the content of a BD-RE medium or a slow USB stick. > I suggest using /dev/urandom and tee(1) to write the same CSPRN > stream to all of the devices and using cmp(1) to validate. I'd propose to use a checksummer like md5sum or sha256sum instead of cmp: $random_generator | tee $target | $checksummer dd if=$target bs=... count=... | $checksummer This way one can use unreproducible random streams and does not have to store the whole stream on a reliable device for comparison. Have a nice day :) Thomas
Re: Unidentified subject!
Hi, i wrote: > > In the other thread about the /dev/sdm test: Gene Heskett wrote: > > > Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32 > > > [...] > > > $ sudo f3probe --destructive --time-ops /dev/sdm > > > Bad news: The device `/dev/sdm' is a counterfeit of type limbo > > > Device geometry: > > > *Usable* size: 59.15 GB (124050944 blocks) > > > Announced size: 1.91 TB (409600 blocks) David Christensen wrote: > Which other thread? Please provide a URL to archived post. https://lists.debian.org/msgid-search/e7a0c1a1-f973-4007-a86d-8d91d8d91...@shentel.net https://lists.debian.org/msgid-search/b566504b-5677-4d84-b5b3-b0de63230...@shentel.net > So, the 2 TB USB SSD's are really scam 64 GB devices? The manufacturer would probably state that it's no intentional scam but just poor product quality. (Exploiting Hanlon's Razor.) It might be intentional that the write speed gets slower and slower as the end of the usable area is approached. This avoids the need for confessing the failure to the operating system. But it might also be an honest attempt of the disk's firmware to find some blocks which can take and give back the arriving data. Have a nice day :) Thomas
Re: Erreur nvidia suite upgrade noyau 6.6.18
On 2/11/24 08:54, Basile Starynkevitch wrote (citant un autre message peut-être de ajh-valmer) Devrais-je être obligé d'acheter une nouvelle carte vidéo plus récente ? Nvidia a mauvaise réputation dans le monde Linux (sur PC portable ou fixe). On peut googler "fuck nvidia". Si vous achetez une nouvelle carte, considérez plutôt une carte AMD/ATI car AMD a payé des développeurs de pilotes libres pour Linux, et je crois que Nvidia (l'entreprise) est réticent à aider même le projet Nouveau (qui travaille par rétro-ingénierie). Et définissez d'abord votre besoin. En particulier avez vous besoin de faire du calcul hybride (OpenCL/OpenACC) sur la carte graphique, ou bien juste d'afficher correctement du texte et regarder des vidéos à une résolution pas trop élevée. Il faut aussi savoir si vous avez un ou plusieurs écrans. Personnellement, avec deux écrans, je mets plusieurs jours à les configurer correctement. Sur un ordinateur fixe avec deux cartes graphiques AMD. root@rimski:/# lspci|grep VGA 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) 42:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts PRO [Radeon HD 6850] J'utilise nvidia uniquement sur un ordinateur portable (sous Ubuntu). J'ajouterais que dans mon expérience linuxienne il est préférable, si on a le choix, d'acheter un contrôleur graphique pas trop récent dans sa conception. Mon heuristique est de choisir un modèle de carte qui est vendu depuis plusieurs mois, et de poser explicitement la question au vendeur de son support sous Linux Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir:https://github.com/RefPerSys/RefPerSys
