Re: Modifier le nom d'une partition /dev/sda.

[Basile Starynkevitch]

On 20/04/2023 20:17, Dethegeek wrote:
Les volumes sont assignés une fois pour toutes pendant un cycle de 
boot / arrêt de l'OS. Arrêter le lecteur qui occupe /dev/sda 'e 
changera rien.


Par contre tu peux essayer de rebooter après avoir éteint ce lecteur. 
Il y a de bones chances que ça resolve le souci (mais ce n'est pas 
perenne).


Vu que plusieurs personnes t'incitent à utiliser les UUID pour 
désigner tes volumes dans /etc/fstab, ce serait bien que tu précise si 
ton problème s'étend jusqu'à avoir des problèmes de montage de volumes 
après un boot, ou si ton problème est "juste" que tu aimes avoir ton 
disque de boot nommé /dev/sda.


Cela dit, la recommandation d'utiliser des UUID dans fstab est la 
bonne pratique.



Et en voici un exemple réel (deux lignes de mon /etc/fstab), sur mon PC 
domestique.



#/dev/sdc4: Linux rev 1.0 ext4 filesystem data, 
UUID=dbf5c0b8-7781-4225-82a4-e6d886b634d2, volume name "big" (extents) (large 
files) (huge files)
UUID=dbf5c0b8-7781-4225-82a4-e6d886b634d2 /bigext4   defaults   
 56



Le commentaire est extrait de la sortie de la commande blkid /dev/sdc4 
qui donne chez moi



/dev/sdc4: LABEL="big" UUID="dbf5c0b8-7781-4225-82a4-e6d886b634d2" BLOCK_SIZE="4096" TYPE="ext4" 
PARTLABEL="big" PARTUUID="e660a882-dbe1-41fa-9b12-a58defca2cd5"


Et donc cette commande (avec l'aide defdisk -l) permettrait de résoudre 
le problème initial.



Librement.


PS. Je cherche des partenaires intéressés par http://refpersys.org/



--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

FTP Repository all man pages?

[jeremy ardley]

Is there any FTP repository that holds all the current Jessie man page 
files in one location?


I have tried various scripts and wget to extract man pages from 
https://manpages.debian.org/jessie/ but my scripting ability lacks somewhat.


Jeremy

Re: /etc/fstab question (problem)?

[tomas]

On Thu, Apr 20, 2023 at 11:29:26PM -0500, David Wright wrote:
> On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote:
> > On 20/04/2023 19:05, songbird wrote:
> > > Default User wrote:
> > > > And when partitions were named /dev/hda5, not
> > > > 6a105a72-f5d5-441b-b926-1e405151ee84.
> 
> With modern hardware, you'd probably not want to go back to those
> device names, because the way the buses work, the internal drives
> can be assigned different names according to what's plugged into
> the computer.

FWIW, I do live with that (laptop here, one spinning rust inside).

The built-in disk is sda, when I stuff a usb stick in, it'll become
sdb unless... I stuff the usb stick too early in the boot process :)

I know this and can cope with it pretty well. But that's what labels
or (ugh) UUIDs were designed to solve.

There's a sweet spot between how much the user should "know" and
how much the system solves implicitly. Where this exactly is depends
on many factors, and it isn't the same for everyone.

Sometimes I doubt we are doing us a favour by making systems "smarter"
and users dumber: we create more and more dependencies.

But hey, that's me.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /etc/fstab question (problem)?

[David Wright]

On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote:
> On 20/04/2023 19:05, songbird wrote:
> > Default User wrote:
> > > And when partitions were named /dev/hda5, not
> > > 6a105a72-f5d5-441b-b926-1e405151ee84.

With modern hardware, you'd probably not want to go back to those
device names, because the way the buses work, the internal drives
can be assigned different names according to what's plugged into
the computer.

> >i use labels on all of my partitions and give them a
> > legible name.  those are what i use in my fstab and also
> > in any grub or refind configs.
> > 
> >i hate UUIDS.  i do understand what they're for and know
> > about them, but i do not need them for the simple stuff i'm
> > doing.
> 
> Since Default User is playing with restoring partitions from backup
> and cloning disks lies somewhere nearby, it may happen that 2 disks
> with identical partition labels may be installed simultaneously.
> 
> Partition UUIDs are affected as well,

Precisely, and users with a small collection of disks are far more
likely to anticipate and rectify a LABEL collision than a UUID one.
Humans prefer working with names and small numbers rather than
128-bit numbers. It takes little effort to devise a satisfactory
naming scheme.

> but e.g. sgdisk has a dedicated
> option:
> https://www.rodsbooks.com/gdisk/sgdisk.html
> > -G, --randomize-guids
> > Randomize the disk's GUID and all partitions' unique GUIDs (but not
> > their partition type code GUIDs). This function may be used after
> > cloning a disk in order to render all GUIDs once again unique

Very useful for the sysadmin who has a way of keeping track of the
filesystem and partition UUIDS on each disk; the point being that
UUIDs scale well, particularly when handled by software.

Repurposing a well-known meme¹: UUIDs are for people who treat their
disks like cattle, LABELs are for those who treat them like pets.

Were I using UUIDs for unlocking and mounting disks at the command
line, or in files like fstab, the giveaway is that I would have to
depend on the machine to tell me what the UUIDs were, either by
completion, or by copy/paste. Seriously, no one ever types a UUID
into a computer, do they?

> P.S. Some people hate consistent network device naming that was
> introduced to solve the same problem with eth0-like names as the one
> caused widespread of UUID in fstab instead of /dev/hdaX.

That's not the same problem at all. Network device names aren't, and
don't need to be, unique across even just two machines. What they need
to be is stable and persistent on each individual machine. Typically,
the people who dislike them seem to be those who have no necessity for
them, often because their machines contain but a single device. It
seems simple to configure any device names you like, so I don't really
understand why they complain.

¹ originally applied to servers, I believe.

Cheers,
David.

Re: "Bug" in Debian Installer?

[David Wright]

On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:

> Opt-out variant for ESP sounds reasonable for me. However I am unsure
> if it is possible to complete installation with no ESP at all.

If you mean: to install Grub but not write to the ESP, I think you can
do this by saying Yes to:

┌─┤ [!] Install the GRUB boot loader ├──┐
│   │
│ The following other operating systems have been detected on this  │
│ computer: Debian GNU/Linux 11 (bullseye)  │
│   │
│ If all of your operating systems are listed above, then it should be  │
│ safe to install the boot loader to your primary drive (UEFI   │
│ partition/boot record). When your computer boots, you will be able to │
│ choose to load one of these operating systems or the newly installed  │
│ Debian system.│
│   │
│ Install the GRUB boot loader to your primary drive?   │

and Go Back to:

┌──┤ [!] Install the GRUB boot loader ├───┐
│ │
│ You need to make the newly installed system bootable, by installing │
│ the GRUB boot loader on a bootable device. The usual way to do this │
│ is to install GRUB to your primary drive (UEFI partition/boot   │
│ record). You may instead install GRUB to a different drive (or  │
│ partition), or to removable media.  │
│ │
│   Device for boot loader installation:  │

If there was already a working Grub on the disk, then it should be
straightforward to boot by editing one of its menu entries.
With anything less than that, it helps to be familiar with the Grub
rescue prompt.

> What may be considered as issues from my point of view:
> 1. From the disks overview screen it is not immediately obvious that
> installer is going to write to ESP partitions.

If, by disks overview, you mean the screen quoted just above, then no,
it is less obvious than ISTR in the past (up to buster), where MBR was
explicitly mentioned on BIOS machines.

Bullseye had a misfeature where it would, even on a BIOS machine,
solicit installing to the fallback location. I don't know whether
it was the presence of a GPT disk that caused this offer (I have no
MBR disks to try out instead), or whether it was a belt and braces
(suspenders) approach for mitigating buggy UEFI implementations.

If you forget which mode you booted with, then sure-fire confirmation
is given by   # ls /sys/firmware/efi   in VC2/VC3, which is present
only for UEFI. (Doesn't count as obvious, though.)

> 2. On a laptop having ESP partitions on 2 disks, both ones are marked
> for usage as ESP. I am unsure if it causes installation error later or
> grub is installed on both ones (taking into account single /boot/efi
> mount point).

I would assume not, as people complain about this as a single point of
failure in UEFI booting. I haven't tried repeating "Install the GRUB
boot loader" from the Main Menu, but I don't see why it shouldn't
work. But I don't think that that would get you two entries in NVRAM
without playing some tricks.

Cheers,
David.

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 4/15/23 15:51, David Christensen wrote:
>  "Debian GNU/Linux UEFI Installer menu" -> "Install"

On 18/04/2023 15:51, David Christensen wrote:

On 4/17/23 21:47, David Wright wrote:

As in "Permission to break an egg, sir"? Did not pressing Enter in
reply to "Install" imply something?


d-i modifying a disk without explicit notification and permission is 
unacceptable.


d-i modifying NVRAM without explicit notification and permission is 
unacceptable.


These modifications happen at the last installation steps, so they 
hardly could be considered as unintended at least in the case of default 
(not expert) install.


I have tried bookworm RC1 netinst. "Detect disks" + manual partitioning 
detects existing ESP and selects it for ESP. I think, it is reasonable 
default action. I aborted installation, so I can say nothing concerning 
install grub stage.


Perhaps, preparing disk for another machine, you did not expect that you 
have to create another EFI System Partition, to choose it to use as ESP 
and to explicitly tell installer that existing ESP should not be used.


Opt-out variant for ESP sounds reasonable for me. However I am unsure if 
it is possible to complete installation with no ESP at all.


What may be considered as issues from my point of view:
1. From the disks overview screen it is not immediately obvious that 
installer is going to write to ESP partitions.
2. On a laptop having ESP partitions on 2 disks, both ones are marked 
for usage as ESP. I am unsure if it causes installation error later or 
grub is installed on both ones (taking into account single /boot/efi 
mount point).



Do you contribute to d-i?


No, I do not. You may check if your case has been discussed on the 
installer mailing list or in the bug tracker.


I am not sure that the topic starter faced the same issue as you are 
trying to rise since quite few details have been provided so far.

Re: gitification (was Re: /etc/fstab question (problem)?

[David Christensen]

On 4/20/23 14:51, songbird wrote:

David Christensen wrote:
...

Please describe your use-case(s), what the requirements are and why, and
how Git is failing.


   i require maintaining an accurate record of the
file and it's attributes - i consider that a part of
the reason the file exists to begin with (otherwise
why have a different file at all?).

   if you change a file, do a git commit then go back
later and do a git restore of a different version it
will not restore the file attributes of that version.
so while i expect to see the right date and time
stamp on a file that has been restored it isn't what
happens.

   and no, i don't considering catering to make being
broken or needing to use a time stamp to keep track
of changed file a requirement, if i personally need
to rebuild a project and i'm using git i would make
sure to have things properly cleaned up so that it
would work without me having to not properly record
the file attributes (or to restore them if i need to
use a different version).

   in my recent case of git screwing me over i had a
series of files in several directories all with proper
dates and time stamps and i forgot about git being a
git and did a git restore and every subdirectory was
corrupted and i had to go back and restore them
again (and then i removed that project from using git
so i'd not do it again).


   songbird



So, you need preservation of mtime (?).


Another reader pointed to Git work-arounds, so I will not repeat that.


Another idea would be to use ZFS:

1.  Create a ZFS file system for one project.

2.  Check-out or create the project working directory within the ZFS 
file system.


3.  Whenever you check-in, also create a ZFS snapshot.

4.  ZFS snapshots can be accessed via the Unix file system at 
/.zfs/snapshot.  Both the data and metadata are read-only, 
and match the state of the file system when the snapshot was taken.


5.  You can roll back a file system to the most recent snapshot with the 
'zfs rollback' command.  ZFS can also roll back to an older snapshot, if 
you are willing to destroy all intermediate snapshots.  'rsync -a' could 
achieve the same result without destroying snapshots.


6.  Another possibility would be to make a clone based upon a snapshot.


David

Re: gitification (was Re: /etc/fstab question (problem)?

[Jeremy Ardley]

On 21/4/23 05:41, songbird wrote:

Stefan Monnier wrote:


   songbird


I have not used these, but there seem to be some work-arounds for 
storing metadata in/with git


lfs has the ability to script xattr handling

https://git-lfs.github.com/

These applications work directly with metadata and can be scripted into 
the git process:


Metastore: https://github.com/przemoc/metastore

Git-meta: https://github.com/chasinglogic/git-meta

None of these will handle NTFS Alternate Data Streams, so archive 
operations between windows and linux are guaranteed to lose data and 
metadata.


--
Jeremy
(Lists)

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

Stefan Monnier wrote:
...
> BTW, the `bup` tool does add some of the needed functionality
> (e.g. storing metadata), but it's not developed with an eye towards
> merging some of that extra functionality into Git, and it doesn't aim to
> be a "generic file storage tool" either :-(

  i tried bup for a while but ended up just going back to
using tar as my backups and depending upon other factors
i may use git or not during some development but ultimately
i end up ditching git.


  songbird

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

David Christensen wrote:
...
> Please describe your use-case(s), what the requirements are and why, and 
> how Git is failing.

  i require maintaining an accurate record of the 
file and it's attributes - i consider that a part of
the reason the file exists to begin with (otherwise
why have a different file at all?).

  if you change a file, do a git commit then go back
later and do a git restore of a different version it
will not restore the file attributes of that version.
so while i expect to see the right date and time 
stamp on a file that has been restored it isn't what 
happens.

  and no, i don't considering catering to make being
broken or needing to use a time stamp to keep track
of changed file a requirement, if i personally need
to rebuild a project and i'm using git i would make
sure to have things properly cleaned up so that it
would work without me having to not properly record
the file attributes (or to restore them if i need to
use a different version).

  in my recent case of git screwing me over i had a
series of files in several directories all with proper
dates and time stamps and i forgot about git being a
git and did a git restore and every subdirectory was
corrupted and i had to go back and restore them 
again (and then i removed that project from using git
so i'd not do it again).


  songbird

Re: Modifier le nom d'une partition /dev/sda.

[ajh-valmer]

On Thursday 20 April 2023 22:42:48 Th.A.C wrote:
> Et je confirme que c'est une très mauvaise idée :

Voici les 2 fautifs (liens symboliques) :
usb-iDRAC_LCDRIVE_20120430-0:0 -> ../../sda
usb-iDRAC_Virtual_Floppy_20120430-0:1 -> ../../sdb
wwn-0x600508e04422b6a2821d890b -> ../../sdc

qui prennent sda et sdb sur 2 ports USB.

Ce n'est pas "une très mauvaise idée" que de vouloir rétablir
le disque dur en /dev/sda car les 6 autres partitions sont 
estampillées sda.
Sur mes autres ordinateurs, c'est pareil, le disque dur est sda,
et sdb si deuxième disque dur.

Bonne nuit à tous.

Re: Modifier le nom d'une partition /dev/sda.

[Th.A.C]

Le 20/04/2023 à 21:43, ajh.val...@free.fr a écrit :

On Thursday 20 April 2023 20:26:21 you wrote:

Je ne maîtrise pas trop ce qu'est Idrac. Il me semble que c'est une
technologie de Dell permettant d'administrer à distance une machine. C'est
un peu l'équivalent de l'IPMI, non ?
Du coup, est ce que tu peux rebooter ta machine sans utiliser idrac-kvm
(via SSH par exemple) ?


Oui, c'est bien ça, équivalent d'un IPMI, on peut tout faire à distance.
La partition 7 a été installée avec la console kvm activée,


ca n'influence pas le nommage physique des disques


depuis une image iso.




Si je désactive totalement la console kvm, reboote le serveur,
on a toujours /dev/sdc.


et que dit lsblk dans ce cas?

dans ta première liste, il y a ce que je pense être un SAN:
wwn-0x600508e04422b6a2821d890b
qui est peut etre vu comme sda ou sdb (voir les 2) parce que détecté avant.


Il faudrait pouvoir modifier l'étiquette /dev/sdc par /dev/sda
depuis le système, mais comment ?
Ça doit se faire dans /dev/disk/ en modifiant les liens symboliques,
ln -s ..
Bonne fin de soirée.



ces liens sont générés "à la volée" au démarrage du système, tu ne 
pourras donc pas les modifier durablement...


Et je confirme que c'est une très mauvaise idée.

Re: gitification (was Re: /etc/fstab question (problem)?

[David Christensen]

On 4/20/23 05:10, songbird wrote:

David Wright wrote:
...

I see nothing unreasonable. The only oddity to me is that the listings
you give (which are from the backups, I assume) have today's date,
which means that the backup method is not preserving the file metadata.
(If you've not used partition 5 for a while, the dates should be old.)
It doesn't affect what you're doing now, as all the originals are
heading into oblivion, but I'd be reading the backup spec sometime
to see if I could improve that.


   aside rant,

   thank gitification for that IMO.

   one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.

   i got bit by this a few weeks ago yet again.  i hate using
git because of it destroying my file meta data.


   songbird



Please describe your use-case(s), what the requirements are and why, and 
how Git is failing.



David

Re: Modifier le nom d'une partition /dev/sda.

[Basile Starynkevitch]

On 20/04/2023 18:28, ajh-valmer wrote:

On Thursday 20 April 2023 17:35:19 Sébastien NOBILI wrote:

Le 2023-04-20 17:25, ajh-valmer a écrit :

Malgré longues recherches, dont tune2fs, rien ne fonctionne.
Merci d'une aide, bonne journée.

Tu devrais tout passer en UUID, ce sera plus fiable :
UUID=x  /  ext4defaults,errors=remount-ro 0   1

C'est bien ce que j'ai dans mon "/etc/fstab", tout en UUID.



Il faut utiliser blkid pour vérifier que c'est le bon UUID dans /etc/fstab


Librement.


NB. Si vous êtes intéressé par http://refpersys.org/ faites moi signe!

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

Re: je repete : NE PAS Modifier le nom d'une partition /dev/sda.

[hamster]

Le 20/04/2023 à 21:43, ajh.val...@free.fr a écrit :

Il faudrait pouvoir modifier l'étiquette /dev/sdc par /dev/sda
depuis le système, mais comment ?
Ça doit se faire dans /dev/disk/ en modifiant les liens symboliques,
ln -s ..


C'est une tres mauvaise idée. Sous linux, la bonne manière de faire, 
c'est de faire son deuil de son gout pour le nom /dev/sda, laisser le 
noyau faire comme il l'entend et apprendre a vivre avec.

Re: gitification (was Re: /etc/fstab question (problem)?

[Stefan Monnier]

>> It could be a sister project of Git.
>   there are other attempts which are done for it and 
> process flows for me but i'd really prefer just a
> simple flag or environment variable i could set which
> would do it instead so then i'd be able to get rid of
> the gyrations.

AFAIK the Git maintainers aren't very interested in pushing Git in that
direction (i.e. a generic file storage tool), which is why I think it
needs to be a sister project (at least at first).

BTW, the `bup` tool does add some of the needed functionality
(e.g. storing metadata), but it's not developed with an eye towards
merging some of that extra functionality into Git, and it doesn't aim to
be a "generic file storage tool" either :-(


Stefan

Re: Modifier le nom d'une partition /dev/sda.

[ajh . valmer]

On Thursday 20 April 2023 20:26:21 you wrote:
> Je ne maîtrise pas trop ce qu'est Idrac. Il me semble que c'est une
> technologie de Dell permettant d'administrer à distance une machine. C'est
> un peu l'équivalent de l'IPMI, non ?
> Du coup, est ce que tu peux rebooter ta machine sans utiliser idrac-kvm
> (via SSH par exemple) ?

Oui, c'est bien ça, équivalent d'un IPMI, on peut tout faire à distance.
La partition 7 a été installée avec la console kvm activée,
depuis une image iso.

Si je désactive totalement la console kvm, reboote le serveur, 
on a toujours /dev/sdc.
Il faudrait pouvoir modifier l'étiquette /dev/sdc par /dev/sda
depuis le système, mais comment ?
Ça doit se faire dans /dev/disk/ en modifiant les liens symboliques,
ln -s ..
Bonne fin de soirée.

Re: Modifier le nom d'une partition /dev/sda.

[Dethegeek]

Ce sont des domaines où je n'ai pas assez de connaissance. Est ce que
quelque chose dans grub, sa configuration par exmple, pourrait fixer le nom
du lecteur qui contient le système de fichiers racine ?

Est ce que ton kvm était actif pendant une étape particulière
d'installation ou upgrade de ton système, nottamment pendant la (re)
configuration de grub ?

Le jeu. 20 avr. 2023 à 20:33, ajh-valmer  a écrit :

> On Thursday 20 April 2023 20:20:50 you wrote:
> > Ta commande lsblk montre que sda et sdb semblent pris par des lecteurs
> > ayant des supports amovibles. Par exemple un lecteur de cartes mémoire,
> > comme on en rencontrait il y a une petite 20aine d'années, gérant des sd,
> > compact flash, MMC, etc.
> > Cela renforce la pertinence de ta remarque et ma proposition précédente.
> > > Les volumes sont assignés une fois pour toutes pendant un cycle de
> boot /
> > > arrêt de l'OS. Arrêter le lecteur qui occupe /dev/sda 'e changera rien.
> > > Par contre tu peux essayer de rebooter après avoir éteint ce lecteur.
> Il y
> > > a de bones chances que ça resolve le souci (mais ce n'est pas perenne).
> > > Vu que plusieurs personnes t'incitent à utiliser les UUID pour désigner
> > > tes volumes dans /etc/fstab, ce serait bien que tu précise si ton
> problème
> > > s'étend jusqu'à avoir des problèmes de montage de volumes après un
> boot,
> > > si ton problème est "juste" que tu aimes avoir ton disque de boot nommé
> > > /dev/sda.
> > > Cela dit, la recommandation d'utiliser des UUID dans fstab est la bonne
> > > pratique.
> Merci :
> C'est que je préfère avoir mon disque nommé /dev/sda.
> Depuis longtemps, mon fstab est en UUID.
> Si j'éteins la console kvm, pareil, reboot, le DD reste /dev/sdc.
> - Gparted m'indique partitions /dev/sda,
> - fdisk -l m'indique partitions /dev/sdc.
> - update-grub2 créé : hd2,msdos7 (comme si sda et sdb était déjà pris).
>
> Bonne soirée.
>
>

Re: Re: Vsync causes stuttering in various games regardless of uncapped performance

[flavonol]

> For variable refresh rate without (much) tearing you turn vsync off in
> game settings. That's how you get the highest frame rates as your
> benchmarks show.

It's true that the highest framerates are achieved by disabling vertical sync. 
However, my understanding was that if my system can deliver sufficiently high 
minimum framerates, vertical sync can be used with consistent frametimes 
(minimal or no stuttering). I used vertical sync this way with games on Windows 
years ago, and I believe this is common. That's why the stuttering with Vsync 
on in the above Mountain Peak & Geothermal Valley examples was unexpected to me.

I tried disabling Freesync on the monitor after seeing Reddit threads with 
Windows users complaining of stuttering with 10-bit color depth & Freesync 
while using other Radeon GPUs.

Re: Modifier le nom d'une partition /dev/sda.

[ajh-valmer]

On Thursday 20 April 2023 20:20:50 you wrote:
> Ta commande lsblk montre que sda et sdb semblent pris par des lecteurs
> ayant des supports amovibles. Par exemple un lecteur de cartes mémoire,
> comme on en rencontrait il y a une petite 20aine d'années, gérant des sd,
> compact flash, MMC, etc.
> Cela renforce la pertinence de ta remarque et ma proposition précédente.
> > Les volumes sont assignés une fois pour toutes pendant un cycle de boot /
> > arrêt de l'OS. Arrêter le lecteur qui occupe /dev/sda 'e changera rien.
> > Par contre tu peux essayer de rebooter après avoir éteint ce lecteur. Il y
> > a de bones chances que ça resolve le souci (mais ce n'est pas perenne).
> > Vu que plusieurs personnes t'incitent à utiliser les UUID pour désigner
> > tes volumes dans /etc/fstab, ce serait bien que tu précise si ton problème
> > s'étend jusqu'à avoir des problèmes de montage de volumes après un boot, 
> > si ton problème est "juste" que tu aimes avoir ton disque de boot nommé
> > /dev/sda.
> > Cela dit, la recommandation d'utiliser des UUID dans fstab est la bonne
> > pratique.
Merci :
C'est que je préfère avoir mon disque nommé /dev/sda.
Depuis longtemps, mon fstab est en UUID.
Si j'éteins la console kvm, pareil, reboot, le DD reste /dev/sdc.
- Gparted m'indique partitions /dev/sda,
- fdisk -l m'indique partitions /dev/sdc.
- update-grub2 créé : hd2,msdos7 (comme si sda et sdb était déjà pris).

Bonne soirée.

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

Stefan Monnier wrote:
...
> FWIW, I think it makes perfect sense for Git to ignore such metadata
> in the context of the intended use of Git (i.e. tracking source code).

  it didn't make sense to me then and still doesn't 
but whatever...  :)


> But I wish there was a concerted effort to develop/maintain "Git as
> a general purpose data storage tool" where various things can be tweaked
> depending on the use-case, such as storing metadata, trying to handle
> terabyte sized repositories, hash-splitting large files/directories, ...
>
> It could be a sister project of Git.

  there are other attempts which are done for it and 
process flows for me but i'd really prefer just a
simple flag or environment variable i could set which
would do it instead so then i'd be able to get rid of
the gyrations.

  but it really sux to get a directory structure set
up how i'd like it and the forget that git has this
effect and then come back some time later and see the
mess it's made.


  songbird

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

Max Nikulin wrote:
> On 20/04/2023 19:10, songbird wrote:
>>one of the worst design decisions i've come across in
>> the modern era was the lack of git respecting file metadata.
>
> In the case of git you can get commit time from git log.

  i do not want commit time, i want the file attributes to
not be f'd with.  i know what all you've written below but
it does not apply to what i want or how i use those tools
and i consider git broken that it caters to broken tools
and intentionally then has to screw up information which i
consider both useful and critical to how i do things.

...
> Version control systems update modification time on operations like "git 
> checkout" or "git pull" to allow build systems, relying on timestamp 
> comparison (make), to recompile changed files even if source tree is 
> switched to an older version.

  to me that's broken and wrong.  if i need to remake a 
project then i clean it out and remake it i don't rely
upon anything else to do it and that is also what compiler
caching is for if the project is large enough where it
makes that much of a difference.  i don't force another
tool to destroy information.


> Some build systems make decisions based on file hashes, not their 
> modification times. It may require a daemon watching file changes to 
> avoid recalculation of all hashes on each build. So such approach is a 
> kind of trade-off.

  not a choice i agree with and so i have to work around
it for my purposes.


  songbird

Re: Modifier le nom d'une partition /dev/sda.

[Dethegeek]

Je ne maîtrise pas trop ce qu'est Idrac. Il me semble que c'est une
technologie de Dell permettant d'administrer à distance une machine. C'est
un peu l'équivalent de l'IPMI, non ?

Du coup, est ce que tu peux rebooter ta machine sans utiliser idrac-kvm
(via SSH par exemple) ?

Le jeu. 20 avr. 2023 à 20:20, Dethegeek  a écrit :

> Ta commande lsblk montre que sda et sdb semblent pris par des lecteurs
> ayant des supports amovibles. Par exemple un lecteur de cartes mémoire,
> comme on en rencontrait il y a une petite 20aine d'années, gérant des sd,
> compact flash, MMC, etc.
>
> Cela renforce la pertinence de ta remarque et ma proposition précédente.
>
> Le jeu. 20 avr. 2023 à 20:17, Dethegeek  a écrit :
>
>> Les volumes sont assignés une fois pour toutes pendant un cycle de boot /
>> arrêt de l'OS. Arrêter le lecteur qui occupe /dev/sda 'e changera rien.
>>
>> Par contre tu peux essayer de rebooter après avoir éteint ce lecteur. Il
>> y a de bones chances que ça resolve le souci (mais ce n'est pas perenne).
>>
>> Vu que plusieurs personnes t'incitent à utiliser les UUID pour désigner
>> tes volumes dans /etc/fstab, ce serait bien que tu précise si ton problème
>> s'étend jusqu'à avoir des problèmes de montage de volumes après un boot, ou
>> si ton problème est "juste" que tu aimes avoir ton disque de boot nommé
>> /dev/sda.
>>
>> Cela dit, la recommandation d'utiliser des UUID dans fstab est la bonne
>> pratique.
>>
>> Le jeu. 20 avr. 2023 à 19:54, ajh-valmer  a écrit :
>>
>>> On Thursday 20 April 2023 18:32:37 Dethegeek wrote:
>>> > Peux tu montrer la liste complète dans /dev/disks/by-id/ ? :
>>> =
>>> ata-TEAC_DVD-ROM_DV-28SW_10101313150629
>>> usb-iDRAC_Virtual_CD_20120430-0:0
>>> scsi-3600508e04422b6a2821d890b
>>> usb-iDRAC_Virtual_Floppy_20120430-0:1
>>> scsi-3600508e04422b6a2821d890b-part1
>>> wwn-0x600508e04422b6a2821d890b
>>> scsi-3600508e04422b6a2821d890b-part2
>>> wwn-0x600508e04422b6a2821d890b-part1
>>> scsi-3600508e04422b6a2821d890b-part3
>>> wwn-0x600508e04422b6a2821d890b-part2
>>> scsi-3600508e04422b6a2821d890b-part4
>>> wwn-0x600508e04422b6a2821d890b-part3
>>> scsi-3600508e04422b6a2821d890b-part5
>>> wwn-0x600508e04422b6a2821d890b-part4
>>> scsi-3600508e04422b6a2821d890b-part6
>>> wwn-0x600508e04422b6a2821d890b-part5
>>> scsi-3600508e04422b6a2821d890b-part7
>>> wwn-0x600508e04422b6a2821d890b-part6
>>> usb-iDRAC_LCDRIVE_20120430-0:0
>>> wwn-0x600508e04422b6a2821d890b-part7
>>> =
>>>
>>> > Que dit la commande lsblk (pour voir les volumes disponibles
>>> > et leur point de montage) ? :
>>> =
>>> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
>>> loop07:00  63,3M  1 loop /snap/core20/1822
>>> loop17:10  63,3M  1 loop /snap/core20/1852
>>> loop27:20  49,8M  1 loop /snap/snapd/18357
>>> loop37:30 111,9M  1 loop /snap/lxd/24322
>>> loop47:40  53,2M  1 loop /snap/snapd/18933
>>> sda  8:01 0B  0 disk
>>> sdb  8:16   1 0B  0 disk
>>> sdc  8:32   0   1,8T  0 disk
>>> ââsdc1   8:33   0 259,3G  0 part
>>> ââsdc2   8:34   0 165,1G  0 part
>>> ââsdc3   8:35   0 3G  0 part [SWAP]
>>> ââsdc4   8:36   0 1K  0 part
>>> =
>>>
>>> > Est ce que tu aurais pas un support de stockage qui aurait pris
>>> > /dev/sda à la place to actuel sdc ? :
>>> Si, par la console Idrac-kvm.
>>> Si je l'éteins, pareil, les partitions et le disque dur restent en
>>> /dev/sdc
>>>
>>> Merci.
>>>
>>>

Re: Modifier le nom d'une partition /dev/sda.

[Dethegeek]

Ta commande lsblk montre que sda et sdb semblent pris par des lecteurs
ayant des supports amovibles. Par exemple un lecteur de cartes mémoire,
comme on en rencontrait il y a une petite 20aine d'années, gérant des sd,
compact flash, MMC, etc.

Cela renforce la pertinence de ta remarque et ma proposition précédente.

Le jeu. 20 avr. 2023 à 20:17, Dethegeek  a écrit :

> Les volumes sont assignés une fois pour toutes pendant un cycle de boot /
> arrêt de l'OS. Arrêter le lecteur qui occupe /dev/sda 'e changera rien.
>
> Par contre tu peux essayer de rebooter après avoir éteint ce lecteur. Il y
> a de bones chances que ça resolve le souci (mais ce n'est pas perenne).
>
> Vu que plusieurs personnes t'incitent à utiliser les UUID pour désigner
> tes volumes dans /etc/fstab, ce serait bien que tu précise si ton problème
> s'étend jusqu'à avoir des problèmes de montage de volumes après un boot, ou
> si ton problème est "juste" que tu aimes avoir ton disque de boot nommé
> /dev/sda.
>
> Cela dit, la recommandation d'utiliser des UUID dans fstab est la bonne
> pratique.
>
> Le jeu. 20 avr. 2023 à 19:54, ajh-valmer  a écrit :
>
>> On Thursday 20 April 2023 18:32:37 Dethegeek wrote:
>> > Peux tu montrer la liste complète dans /dev/disks/by-id/ ? :
>> =
>> ata-TEAC_DVD-ROM_DV-28SW_10101313150629
>> usb-iDRAC_Virtual_CD_20120430-0:0
>> scsi-3600508e04422b6a2821d890b
>> usb-iDRAC_Virtual_Floppy_20120430-0:1
>> scsi-3600508e04422b6a2821d890b-part1
>> wwn-0x600508e04422b6a2821d890b
>> scsi-3600508e04422b6a2821d890b-part2
>> wwn-0x600508e04422b6a2821d890b-part1
>> scsi-3600508e04422b6a2821d890b-part3
>> wwn-0x600508e04422b6a2821d890b-part2
>> scsi-3600508e04422b6a2821d890b-part4
>> wwn-0x600508e04422b6a2821d890b-part3
>> scsi-3600508e04422b6a2821d890b-part5
>> wwn-0x600508e04422b6a2821d890b-part4
>> scsi-3600508e04422b6a2821d890b-part6
>> wwn-0x600508e04422b6a2821d890b-part5
>> scsi-3600508e04422b6a2821d890b-part7
>> wwn-0x600508e04422b6a2821d890b-part6
>> usb-iDRAC_LCDRIVE_20120430-0:0
>> wwn-0x600508e04422b6a2821d890b-part7
>> =
>>
>> > Que dit la commande lsblk (pour voir les volumes disponibles
>> > et leur point de montage) ? :
>> =
>> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
>> loop07:00  63,3M  1 loop /snap/core20/1822
>> loop17:10  63,3M  1 loop /snap/core20/1852
>> loop27:20  49,8M  1 loop /snap/snapd/18357
>> loop37:30 111,9M  1 loop /snap/lxd/24322
>> loop47:40  53,2M  1 loop /snap/snapd/18933
>> sda  8:01 0B  0 disk
>> sdb  8:16   1 0B  0 disk
>> sdc  8:32   0   1,8T  0 disk
>> ââsdc1   8:33   0 259,3G  0 part
>> ââsdc2   8:34   0 165,1G  0 part
>> ââsdc3   8:35   0 3G  0 part [SWAP]
>> ââsdc4   8:36   0 1K  0 part
>> =
>>
>> > Est ce que tu aurais pas un support de stockage qui aurait pris
>> > /dev/sda à la place to actuel sdc ? :
>> Si, par la console Idrac-kvm.
>> Si je l'éteins, pareil, les partitions et le disque dur restent en
>> /dev/sdc
>>
>> Merci.
>>
>>

Re: Modifier le nom d'une partition /dev/sda.

[Dethegeek]

Les volumes sont assignés une fois pour toutes pendant un cycle de boot /
arrêt de l'OS. Arrêter le lecteur qui occupe /dev/sda 'e changera rien.

Par contre tu peux essayer de rebooter après avoir éteint ce lecteur. Il y
a de bones chances que ça resolve le souci (mais ce n'est pas perenne).

Vu que plusieurs personnes t'incitent à utiliser les UUID pour désigner tes
volumes dans /etc/fstab, ce serait bien que tu précise si ton problème
s'étend jusqu'à avoir des problèmes de montage de volumes après un boot, ou
si ton problème est "juste" que tu aimes avoir ton disque de boot nommé
/dev/sda.

Cela dit, la recommandation d'utiliser des UUID dans fstab est la bonne
pratique.

Le jeu. 20 avr. 2023 à 19:54, ajh-valmer  a écrit :

> On Thursday 20 April 2023 18:32:37 Dethegeek wrote:
> > Peux tu montrer la liste complète dans /dev/disks/by-id/ ? :
> =
> ata-TEAC_DVD-ROM_DV-28SW_10101313150629
> usb-iDRAC_Virtual_CD_20120430-0:0
> scsi-3600508e04422b6a2821d890b
> usb-iDRAC_Virtual_Floppy_20120430-0:1
> scsi-3600508e04422b6a2821d890b-part1
> wwn-0x600508e04422b6a2821d890b
> scsi-3600508e04422b6a2821d890b-part2
> wwn-0x600508e04422b6a2821d890b-part1
> scsi-3600508e04422b6a2821d890b-part3
> wwn-0x600508e04422b6a2821d890b-part2
> scsi-3600508e04422b6a2821d890b-part4
> wwn-0x600508e04422b6a2821d890b-part3
> scsi-3600508e04422b6a2821d890b-part5
> wwn-0x600508e04422b6a2821d890b-part4
> scsi-3600508e04422b6a2821d890b-part6
> wwn-0x600508e04422b6a2821d890b-part5
> scsi-3600508e04422b6a2821d890b-part7
> wwn-0x600508e04422b6a2821d890b-part6
> usb-iDRAC_LCDRIVE_20120430-0:0
> wwn-0x600508e04422b6a2821d890b-part7
> =
>
> > Que dit la commande lsblk (pour voir les volumes disponibles
> > et leur point de montage) ? :
> =
> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
> loop07:00  63,3M  1 loop /snap/core20/1822
> loop17:10  63,3M  1 loop /snap/core20/1852
> loop27:20  49,8M  1 loop /snap/snapd/18357
> loop37:30 111,9M  1 loop /snap/lxd/24322
> loop47:40  53,2M  1 loop /snap/snapd/18933
> sda  8:01 0B  0 disk
> sdb  8:16   1 0B  0 disk
> sdc  8:32   0   1,8T  0 disk
> ââsdc1   8:33   0 259,3G  0 part
> ââsdc2   8:34   0 165,1G  0 part
> ââsdc3   8:35   0 3G  0 part [SWAP]
> ââsdc4   8:36   0 1K  0 part
> =
>
> > Est ce que tu aurais pas un support de stockage qui aurait pris
> > /dev/sda à la place to actuel sdc ? :
> Si, par la console Idrac-kvm.
> Si je l'éteins, pareil, les partitions et le disque dur restent en /dev/sdc
>
> Merci.
>
>

Re: Modifier le nom d'une partition /dev/sda.

[ajh-valmer]

On Thursday 20 April 2023 18:32:37 Dethegeek wrote:
> Peux tu montrer la liste complète dans /dev/disks/by-id/ ? :
=
ata-TEAC_DVD-ROM_DV-28SW_10101313150629   
usb-iDRAC_Virtual_CD_20120430-0:0
scsi-3600508e04422b6a2821d890b
usb-iDRAC_Virtual_Floppy_20120430-0:1
scsi-3600508e04422b6a2821d890b-part1  
wwn-0x600508e04422b6a2821d890b
scsi-3600508e04422b6a2821d890b-part2  
wwn-0x600508e04422b6a2821d890b-part1
scsi-3600508e04422b6a2821d890b-part3  
wwn-0x600508e04422b6a2821d890b-part2
scsi-3600508e04422b6a2821d890b-part4  
wwn-0x600508e04422b6a2821d890b-part3
scsi-3600508e04422b6a2821d890b-part5  
wwn-0x600508e04422b6a2821d890b-part4
scsi-3600508e04422b6a2821d890b-part6  
wwn-0x600508e04422b6a2821d890b-part5
scsi-3600508e04422b6a2821d890b-part7  
wwn-0x600508e04422b6a2821d890b-part6
usb-iDRAC_LCDRIVE_20120430-0:0
wwn-0x600508e04422b6a2821d890b-part7
=

> Que dit la commande lsblk (pour voir les volumes disponibles 
> et leur point de montage) ? :
=
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop07:00  63,3M  1 loop /snap/core20/1822
loop17:10  63,3M  1 loop /snap/core20/1852
loop27:20  49,8M  1 loop /snap/snapd/18357
loop37:30 111,9M  1 loop /snap/lxd/24322
loop47:40  53,2M  1 loop /snap/snapd/18933
sda  8:01 0B  0 disk
sdb  8:16   1 0B  0 disk
sdc  8:32   0   1,8T  0 disk
ââsdc1   8:33   0 259,3G  0 part
ââsdc2   8:34   0 165,1G  0 part
ââsdc3   8:35   0 3G  0 part [SWAP]
ââsdc4   8:36   0 1K  0 part 
=

> Est ce que tu aurais pas un support de stockage qui aurait pris 
> /dev/sda à la place to actuel sdc ? :
Si, par la console Idrac-kvm.
Si je l'éteins, pareil, les partitions et le disque dur restent en /dev/sdc

Merci.

Re: NE PAS Modifier le nom d'une partition /dev/sda.

[hamster]

Le 20/04/2023 à 17:35, Sébastien NOBILI a écrit :

Bonjour,

Le 2023-04-20 17:25, ajh-valmer a écrit :

Malgré longues recherches, dont tune2fs, rien ne fonctionne.
Merci d'une aide, bonne journée.


Tu devrais tout passer en UUID, ce sera plus fiable :

     UUID=x  /  ext4    defaults,errors=remount-ro 0   1


Je confirme : le noyau appelle les partitions comme ca lui chante et on 
a aucune prise dessus. Les appellations du genre /dev/sda7 sont des 
outils de travail pratiques mais non pérennes. Il est donc toujours 
nécessaire de vérifier comment une partition s'appelle avant de les 
utiliser. Par exemple avec lsblk.


C'est une mauvaise idée que de vouloir modifier la facon dont le noyau 
nomme les partitions. Pour désigner une partition de facon pérenne, 
utiliser l'UUID, c'est fait pour ca. Par exemple :

/dev/disk/by-uuid/11265a[…]a2724d

Re: Modifier le nom d'une partition /dev/sda.

[Dethegeek]

Bonjour

Peux tu montrer la liste complète dans /dev/disks/by-id/ ?

Que dit la commande lsblk (pour voir les volumes disponibles et leur point
de montage) ?

Est ce que tu aurais pas un support de stockage qui aurait pris /dev/sda à
la place to actuel sdc ?

Le jeu. 20 avr. 2023 à 18:28, ajh-valmer  a écrit :

> On Thursday 20 April 2023 17:35:19 Sébastien NOBILI wrote:
> > Le 2023-04-20 17:25, ajh-valmer a écrit :
> > > Malgré longues recherches, dont tune2fs, rien ne fonctionne.
> > > Merci d'une aide, bonne journée.
>
> > Tu devrais tout passer en UUID, ce sera plus fiable :
> > UUID=x  /  ext4defaults,errors=remount-ro 0   1
>
> C'est bien ce que j'ai dans mon "/etc/fstab", tout en UUID.
>
>

Re: Modifier le nom d'une partition /dev/sda.

[ajh-valmer]

On Thursday 20 April 2023 17:35:19 Sébastien NOBILI wrote:
> Le 2023-04-20 17:25, ajh-valmer a écrit :
> > Malgré longues recherches, dont tune2fs, rien ne fonctionne.
> > Merci d'une aide, bonne journée.

> Tu devrais tout passer en UUID, ce sera plus fiable :
> UUID=x  /  ext4defaults,errors=remount-ro 0   1

C'est bien ce que j'ai dans mon "/etc/fstab", tout en UUID.

Re: Duda sobre la salida de lsusb

[Camaleón]

El 2023-04-20 a las 17:23 +0200, Luis Muñoz Fuente escribió:
> 
> El 19/4/23 a las 20:57, Camaleón escribió:
> > Hum... Es el acrónimo de «ifnum» (InterfaceNumber), pero hasta ahí puedo
> > contar O:-)
> > 
> > https://docs.kernel.org/driver-api/usb/usb.html
> Ahí dice que If 0 y If 1 son distintas interfaces de una configuración de un
> dispositivo USB. No sé que significará en el caso del teclado, pero algo me
> ha aclarado. Gracias Camaleón.

USB Descriptors
https://www.beyondlogic.org/usbnutshell/usb5.shtml

USB Report Protocol
https://wiki.osdev.org/USB_Human_Interface_Devices#USB_Report_Protocol


The interface descriptor could be seen as a header or grouping of the 
endpoints into a functional group performing a single feature of the 
device. For example you could have a multi-function fax/scanner/printer 
device. Interface descriptor one could describe the endpoints of the 
fax function, Interface descriptor two the scanner function and 
Interface descriptor three the printer function. Unlike the 
configuration descriptor, there is no limitation as to having only one 
interface enabled at a time. A device could have 1 or many interface 
descriptors enabled at once.

Interface descriptors have a bInterfaceNumber field specifying the 
Interface number and a bAlternateSetting which allows an interface to 
change settings on the fly. For example we could have a device with two 
interfaces, interface one and interface two. Interface one has 
bInterfaceNumber set to zero indicating it is the first interface 
descriptor and a bAlternativeSetting of zero.

Interface two would have a bInterfaceNumber set to one indicating it is 
the second interface and a bAlternativeSetting of zero (default). We 
could then throw in another descriptor, also with a bInterfaceNumber 
set to one indicating it is the second interface, but this time setting 
the bAlternativeSetting to one, indicating this interface descriptor 
can be an alternative setting to that of the other interface descriptor 
two. 
***

Conforme a la explicación anterior, y trasladado a un teclado 
multimedia, se me ocurre que pueda ser útil para agrupar funciones de 
combinaciones de las teclas:

1. Sonido → subir/bajar volumen, silenciar...
2. Pantalla → brillo, conmutar con monitor externo...
3. Control multimedia → iniciar, pausar, avanzar...

Saludos,

-- 
Camaleón 

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 18/04/2023 11:47, David Wright wrote:

On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:


I have never seen a document that completely and accurately explains,
in computer engineering and science terms, the design and
implementation of the boot processes for Debian (or FreeBSD, or
Windows, or macOS) for all the possible combinations of BIOS, UEFI,
MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
Boot Partition", etc..  If anyone knows of such, please provide a
citation.

You might start with:

   https://www.rodsbooks.com/gdisk/whatsgpt.html


The site by Roderick W. Smith contains a lot of invaluable information 
from "first hands" of a developer of a boot loader and of GPT fdisk. 
Sometimes however I had difficulties however to find details related to 
particular question.


Concerning UEFI I have the following links in my notes:

https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/
Adam Williamson. UEFI boot: how does that actually work, then? 
2014-01-25 21:07


https://en.opensuse.org/openSUSE:UEFI
About UEFI

https://www.rodsbooks.com/linux-uefi/
Roderick W. Smith. Linux on UEFI:
A Quick Installation Guide

I do not think a document that "completely and accurately explains..." 
exists at all.

Re: How do I report a problem about Debian 12 not reading USB pen drives?

[Joe]

On Thu, 20 Apr 2023 09:51:27 -0400
John LeRoy  wrote:

> Hello,
> The Subject is my question.
> Debian 12 on my computer can't read USB pen drives. The drives are
> read correctly on a similar computer running Debian 11.
> I have registered on the Debian Forum, but can't find an entry about 
> this problem.
> I would like to report this as a bug, or at least get help diagnosing 
> the problem.
>
You will need more data to make a useful bug report or get help from us
here. On the offending machine, open a terminal window, type:

sudo tail -f /var/log/syslog

and return. If you don't have/use sudo, then su to root, syslog needs
root permission to read.

Now plug in a USB stick. You should see many lines of text added. At
the moment, try the same procedure with the good computer, see if the
logs look approximately the same. You're looking for an 'sdX' appearing
as the stick is mounted, X depending on what other drives you have. If
this isn't happening, you won't see anything on the stick, as you
describe.

In that case, copy and paste the log lines from the problem machine and
post here. From a terminal window, copy by using ctrl-shift-C instead
of the usual GUI ctrl-C. Oh yes, you stop the tail command by using
ctrl-C first.

-- 
Joe

Re: Modifier le nom d'une partition /dev/sda.

[Sébastien NOBILI]

Bonjour,

Le 2023-04-20 17:25, ajh-valmer a écrit :

Malgré longues recherches, dont tune2fs, rien ne fonctionne.
Merci d'une aide, bonne journée.


Tu devrais tout passer en UUID, ce sera plus fiable :

UUID=x  /  ext4defaults,errors=remount-ro 0   1

Sébastien

Modifier le nom d'une partition /dev/sda.

[ajh-valmer]

Bonjour,

Depuis que j'ai installé sur mon serveur une Debian,
dans une partition existante /dev/sda7,
toutes les partitions sont devenues /dev/sdc1 à /dev/sdc7.
/dev/disk/ :  renvoit tout vers /devsdc :
pci-:01:00.0-scsi-0:1:0:0-part1 -> ../../sdc1
Le serveur n'a qu'un seul disque dur qui s'est toujours appelé /dev/sda.

Malgré longues recherches, dont tune2fs, rien ne fonctionne.
Merci d'une aide, bonne journée.

Antoine

Re: gitification (was Re: /etc/fstab question (problem)?

[Max Nikulin]

On 20/04/2023 19:10, songbird wrote:

   one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.


In the case of git you can get commit time from git log.

Version control systems update modification time on operations like "git 
checkout" or "git pull" to allow build systems, relying on timestamp 
comparison (make), to recompile changed files even if source tree is 
switched to an older version.


Some build systems make decisions based on file hashes, not their 
modification times. It may require a daemon watching file changes to 
avoid recalculation of all hashes on each build. So such approach is a 
kind of trade-off.

Re: Duda sobre la salida de lsusb

[Luis Muñoz Fuente]

El 19/4/23 a las 20:57, Camaleón escribió:

Hum... Es el acrónimo de «ifnum» (InterfaceNumber), pero hasta ahí puedo
contar O:-)

https://docs.kernel.org/driver-api/usb/usb.html
Ahí dice que If 0 y If 1 son distintas interfaces de una configuración 
de un dispositivo USB. No sé que significará en el caso del teclado, 
pero algo me ha aclarado. Gracias Camaleón.

Re: tmp on tmpfs

[Vincent Lefevre]

On 2023-04-20 16:19:41 +0200, to...@tuxteam.de wrote:
> On Thu, Apr 20, 2023 at 04:13:48PM +0200, Vincent Lefevre wrote:
> 
> [...]
> 
> > "marginally faster" is incorrect, but this probably depends on
> > how fast the disk is. For the MPFR svn-to-git conversion with
> > reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because
> > it was awfully slow on /tmp (but the SSD disk was rather slow:
> > the new one I got several months later was about 50 times as
> > fast, IIRC).
> 
> Hm. Interesting. I'd expected the buffer cache to paper over the
> difference (provided you have enough RAM for that, but since we
> are comparing that to putting things in tmpfs, by definition, you
> have :)

I think that the issue is that even though there is a buffer cache,
data are written to disk, even when this is not needed for really
temporary data. These write operations make the system slow when it
tries to read other data from the disk.

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

Re: /etc/fstab question (problem)?

[Max Nikulin]

On 20/04/2023 19:05, songbird wrote:

Default User wrote:

And when partitions were named /dev/hda5, not
6a105a72-f5d5-441b-b926-1e405151ee84.


   i use labels on all of my partitions and give them a
legible name.  those are what i use in my fstab and also
in any grub or refind configs.

   i hate UUIDS.  i do understand what they're for and know
about them, but i do not need them for the simple stuff i'm
doing.


Since Default User is playing with restoring partitions from backup and 
cloning disks lies somewhere nearby, it may happen that 2 disks with 
identical partition labels may be installed simultaneously.


Partition UUIDs are affected as well, but e.g. sgdisk has a dedicated 
option:

https://www.rodsbooks.com/gdisk/sgdisk.html

-G, --randomize-guids
Randomize the disk's GUID and all partitions' unique GUIDs (but not
their partition type code GUIDs). This function may be used after
cloning a disk in order to render all GUIDs once again unique


P.S. Some people hate consistent network device naming that was 
introduced to solve the same problem with eth0-like names as the one 
caused widespread of UUID in fstab instead of /dev/hdaX.

Re: tmp on tmpfs

[tomas]

On Thu, Apr 20, 2023 at 10:29:04AM -0400, Jeffrey Walton wrote:
> On Thu, Apr 20, 2023 at 10:14 AM Vincent Lefevre  wrote:
> >
> > On 2023-04-19 08:34:50 +0200, to...@tuxteam.de wrote:
> > > There is one downside to /tmp on tmpfs: it eats RAM. You gotta
> > > have some of it (currently I've 9G free on / and 16G RAM).
> >
> > True, and when I used tmpfs in the past (in 2012), I got many failures
> > due to lack of space (because of limited RAM).
> 
> That makes me want to cringe. It brings back memories of Solaris
> constantly running out of RAM when trying to run the SunCC compiler.
> (Solaris does not over commit memory. You need boatloads of RAM).
> 
> Who would want to torture themselves like that?

These were other times. My current lowly laptop's RAM is quite possibly
bigger than your whole hard disk back then.

And -- with one exception (firefox, I'm looking at you!) -- software's
hunger hasn't been able to keep up with that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: tmp on tmpfs

[Jeffrey Walton]

On Thu, Apr 20, 2023 at 10:14 AM Vincent Lefevre  wrote:
>
> On 2023-04-19 08:34:50 +0200, to...@tuxteam.de wrote:
> > There is one downside to /tmp on tmpfs: it eats RAM. You gotta
> > have some of it (currently I've 9G free on / and 16G RAM).
>
> True, and when I used tmpfs in the past (in 2012), I got many failures
> due to lack of space (because of limited RAM).

That makes me want to cringe. It brings back memories of Solaris
constantly running out of RAM when trying to run the SunCC compiler.
(Solaris does not over commit memory. You need boatloads of RAM).

Who would want to torture themselves like that?

Jeff

Re: /etc/fstab question (problem)?

[Default User]

On Thu, 2023-04-20 at 10:09 +0200, DdB wrote:
> You got your plan mapped out. and i agree, except for one little
> detail:
> see below. -
> 
> Am 19.04.2023 um 22:06 schrieb Default User:
> > > I think, it is the case when reboot is safer. Open file
> > > descriptors
> > > remain on the original partition. However I do not expect that
> > > single
> > > user mode or booting from live image is required. Just restore
> > > original
> > > /etc/fstab and reboot.
> > > 
> > > Perhaps update-initramfs is necessary after restoring of
> > > /etc/fstab
> > > in
> > > any chosen approach.
> > > 
> > > 
> > 
> > 
> > Well, now I am totally confused.
> > 
> > I had hoped for, and really expected, an easy, obvious, intuitive
> > solution.  But I guess that may be a distant memory of the good old
> > days, before [insert string of four-letter words here] like dbus,
> > systemd, and Gnome 3. And when partitions were named /dev/hda5, not
> > 6a105a72-f5d5-441b-b926-1e405151ee84.
> > 
> > Sigh.
> > 
> > Anyway, here is where I am at:
> > 
> > I have two Clonezilla backups.
> > 1) a full disk backup.
> > 2) a "partitions" backup.
> > So, if things really go bad, I can theoretically revert to the
> > setup as
> > of 2023-04-18, when this thread was started.
> > 
> > I also have a backup of the current /tmp directory (from under the
> > /
> > directory).
> > And I have a backup of the old tmp partition.
> > 
> > Both of these tmp backups were made using a Debian Stable 11.6
> > Live/install usb thumb drive, as root user.
> > 
> > All of these backups are on an external usb hdd.
> > 
> > Here is what was in the (root) tmp directory:
> > 
> > _root_partition/tmp
> > total 32K
> > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./
> > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../
> > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/
> > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/
> > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/
> > 88473610 drwx-- 2 [user] [user] 4.0K Apr 19 14:18 tracker-
> > extract-
> > files.116/
> > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/
> > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/
> > 
> > And here is what was in the old tmp partition:
> > 
> > total 48K
> > 88473611 drwxr-xr-t 10 root    root    4.0K Apr 19 14:20 ./
> > 88473603 drwxr-xr-x  3 [user] [user] 4.0K Apr 19 14:20 ../
> > 88473618 drwxr-xr-t  2 root    root    4.0K Apr 19 14:20 .font-
> > unix/
> > 88473615 drwxr-xr-t  2 root    root    4.0K Apr 19 14:20 .ICE-unix/
> > 88473620 drwx--  2 root    root    4.0K Apr 19 14:20
> > lost+found/
> > 88473619 drwxr-xr-t  2 root    root    4.0K Apr 19 14:20 .Test-
> > unix/
> > 88473624 drwx--  2 root    root    4.0K Apr 19 14:20 tracker-
> > extract-files.1000/
> > 88473623 drwx--  2 root    root    4.0K Apr 19 14:20 tracker-
> > extract-files.116/
> > 88473621 -r--r--r--  1 root    root  11 Apr 19 14:20 .X1024-
> > lock
> > 88473622 -r--r--r--  1 root    root  11 Apr 19 14:20 .X1025-
> > lock
> > 88473612 drwxr-xr-t  2 root    root    4.0K Apr 19 14:20 .X11-unix/
> > 88473617 drwxr-xr-t  2 root    root    4.0K Apr 19 14:20 .XIM-unix/
> > 
> > As far as I can tell, there is nothing crucial in either tmp
> > backup.
> > 
> > BTW, I know nothing about bind or mount --bind. I looked them up
> > briefly, and decided that they are too difficult and maybe
> > dangerous to
> > try to learn and use under the current circumstances.
> > 
> > So here is what I am thinking of doing:
> > 
> > While running from within the Debian Stable 11.6 Live/install usb
> > thumb
> > drive, as root user:
> > 
> > 1) On the computer's internal ssd, delete the /tmp directory and
> > its
> > contents.
> Do NOT delete the directory itself, only its content, as it will be
> used
> as the mountpoint for your /tmp drive.
> 
> > 
> > 2) On the computer's internal ssd, delete the contents of the old
> > tmp
> > partition, but not the partition itself.
> > 
> > 3) On the computer's internal ssd, replace /etc/fstab with
> > /etc/fstab.original, renaming it /etc/fstab. I have already made a
> > copy
> > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19.
> > 
> > The UUIDs of all partitions on computer's internal ssd seem to be
> > the
> > same as in /etc/fstab.original.
> > 
> > (Note: in /etc/fstab.original, it states "Please run 'systemctl
> > daemon-
> > reload' after making changes here." Since I am doing all this from
> > a
> > live usb, I do not think that applies, so I would skip that.)
> > 
> > Then I would shut down, remove the usb thumb drive, and boot into
> > the
> > Debian system on the computer's internal ssd.
> > 
> > I hope that from then on, the system would mount the old tmp
> > partition
> > on the computer's internal ssd as /tmp, re-populating it
> > automatically,
> > and use it as such from then on.
> > 
> > Does that seem reasonable?
> > 
> > Or am I missing 

Re: tmp on tmpfs

[tomas]

On Thu, Apr 20, 2023 at 04:13:48PM +0200, Vincent Lefevre wrote:

[...]

> "marginally faster" is incorrect, but this probably depends on
> how fast the disk is. For the MPFR svn-to-git conversion with
> reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because
> it was awfully slow on /tmp (but the SSD disk was rather slow:
> the new one I got several months later was about 50 times as
> fast, IIRC).

Hm. Interesting. I'd expected the buffer cache to paper over the
difference (provided you have enough RAM for that, but since we
are comparing that to putting things in tmpfs, by definition, you
have :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: tmp on tmpfs

[Vincent Lefevre]

On 2023-04-19 08:34:50 +0200, to...@tuxteam.de wrote:
> There is one downside to /tmp on tmpfs: it eats RAM. You gotta
> have some of it (currently I've 9G free on / and 16G RAM).

True, and when I used tmpfs in the past (in 2012), I got many failures
due to lack of space (because of limited RAM).

> That's the only one I can read between the lines in the above
> linked post. Do you see any other?
> 
> The upsides aren't that spectacular either. If you've enough
> RAM, file system caching is so good that tmpfs will only be
> marginally faster: The write path to the disk will be a bit
> clearer. There will be a bit less CPU usage if your /tmp would
> be otherwise on a LUKS partition (mine would).

"marginally faster" is incorrect, but this probably depends on
how fast the disk is. For the MPFR svn-to-git conversion with
reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because
it was awfully slow on /tmp (but the SSD disk was rather slow:
the new one I got several months later was about 50 times as
fast, IIRC).

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

How do I report a problem about Debian 12 not reading USB pen drives?

[John LeRoy]

Hello,
The Subject is my question.
Debian 12 on my computer can't read USB pen drives. The drives are read 
correctly on a similar computer running Debian 11.
I have registered on the Debian Forum, but can't find an entry about 
this problem.
I would like to report this as a bug, or at least get help diagnosing 
the problem.

Thank you.
John LeRoy

Re: Vsync causes stuttering in various games regardless of uncapped performance

[Anssi Saari]

flavonol  writes:

> Hello Debian community,
>
> Whenever I enable vertical sync in any one of various video games (including, 
> but not limited to, Rise of the Tomb Raider, Team Fortress 2,
> Minecraft Java Edition & Hollow Knight), framerates frequently drop to 
> between around 30 to 50 frames per second*. This occurs even if minimum
> framerates prior to enabling vertical sync exceeded the refresh rate of my 
> display. Disabling Freesync in my monitor's built-in settings menu does
> not resolve this issue.

For variable refresh rate without (much) tearing you turn vsync off in
game settings. That's how you get the highest frame rates as your
benchmarks show.

Re: gitification (was Re: /etc/fstab question (problem)?

[Stefan Monnier]

>   one of the worst design decisions i've come across in 
> the modern era was the lack of Git respecting file metadata.
>
>   i got bit by this a few weeks ago yet again.  i hate using
> Git because of it destroying my file meta data.

FWIW, I think it makes perfect sense for Git to ignore such metadata
in the context of the intended use of Git (i.e. tracking source code).

But I wish there was a concerted effort to develop/maintain "Git as
a general purpose data storage tool" where various things can be tweaked
depending on the use-case, such as storing metadata, trying to handle
terabyte sized repositories, hash-splitting large files/directories, ...

It could be a sister project of Git.


Stefan

Re: gitification (was Re: /etc/fstab question (problem)?

[Jeremy Ardley]

On 20/4/23 20:10, songbird wrote:


   aside rant,

   thank gitification for that IMO.

   one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.

   i got bit by this a few weeks ago yet again.  i hate using
git because of it destroying my file meta data.


Not ideal, but you can store your files in a container that maintains 
metadata and then store that in git.


Ideally you would want a container application that restores files with 
every metadata attribute as at insertion into the container, but for 
some purposes that may not be essential for all metadata elements.


--
Jeremy
(Lists)

gnome-calls per a GSM

[Narcis Garcia]

Bona tarda de nou;

Voldria saber si algú ha utilitzat alguna aplicació disponible a Debian 
per a fer i/o rebre trucades de mòbil.
Una vegada que aconsegueixo connexió a Internet amb ModemManager i 
NetworkManager, i el MMCLI m'indica que tot està bé amb l'operador, 
intento utilitzar el gnome-calls per a trucar a un número, però no acaba 
produint res.


El sm.puri (cridat per gnome-calls) diu:
SelectMode failed with code 0: 
GDBus.Error:org.freedesktop.DBus.Error.Failed: Operation failed


El servei de ModemManager diu:
  [modem11/call9] user request to start call
  [modem11/call9] call state changed: unknown -> dialing 
(outgoing-started)

  [modem11/call9] call is started
  [modem11] unexpected outgoing call to number 'n/a' reported in 
call list: state active

  [modem11/call9] call state changed: dialing -> ringing-out (unknown)
  [modem11] unexpected outgoing call to number 'n/a' reported in 
call list: state active



Gràcies.
--


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: /etc/fstab question (problem)?

[songbird]

Default User wrote:
...
> Well, now I am totally confused. 
>
> I had hoped for, and really expected, an easy, obvious, intuitive
> solution.  But I guess that may be a distant memory of the good old
> days, before [insert string of four-letter words here] like dbus,
> systemd, and Gnome 3. And when partitions were named /dev/hda5, not
> 6a105a72-f5d5-441b-b926-1e405151ee84.
>
> Sigh.
...

  i use labels on all of my partitions and give them a
legible name.  those are what i use in my fstab and also
in any grub or refind configs.

  i hate UUIDS.  i do understand what they're for and know
about them, but i do not need them for the simple stuff i'm
doing.


  songbird

Re: /etc/fstab question (problem)?

[songbird]

davidson wrote:
...
> Consider the -a option to cp for backup/backdown operations, to
> preserve all attributes (including timestamps), recursively copy
> directories, and more. Read the manual for details.

  that's what i use by default for all copies.  saves me
a lot of wondering where something might have come from
and also acts as a warning to me when i see something that
should not have changed.

  since i frequenlty run into issues with git doing things
i do not like to my file metadata it's something i've become
a bit more wary about.  ugh!, blah! and drats!


  songbird

gitification (was Re: /etc/fstab question (problem)?

[songbird]

David Wright wrote:
...
> I see nothing unreasonable. The only oddity to me is that the listings
> you give (which are from the backups, I assume) have today's date,
> which means that the backup method is not preserving the file metadata.
> (If you've not used partition 5 for a while, the dates should be old.)
> It doesn't affect what you're doing now, as all the originals are
> heading into oblivion, but I'd be reading the backup spec sometime
> to see if I could improve that.

  aside rant,

  thank gitification for that IMO.

  one of the worst design decisions i've come across in 
the modern era was the lack of git respecting file metadata.

  i got bit by this a few weeks ago yet again.  i hate using
git because of it destroying my file meta data.


  songbird

Re: tmp on tmpfs

[songbird]

 wrote:
...
> Definitely,but we nerds gotta nerd :)

  haha!  :)


  songbird  (nerd lives matta!

Re: Second monitor doesn't quite work

[Vincent Lefevre]

On 2023-04-20 11:56:17 +0100, Eric S Fraga wrote:
> On Wednesday, 19 Apr 2023 at 23:34, Stefan Monnier wrote:
> >> Any idea why the second monitor is sort of there but not quite?  Below is
> >> a copy of the xorg.conf generated by the Nvidia setup utility.
> >
> > I have no experience with multi-monitor setups on nVidia, but the last
> > time I used a non-empty `xorg.conf` was many years ago, so I suggest
> > you try to just remove the config file generated by `nvidia-settings`.
> 
> I second this.  I have three monitors on my system, with two graphics
> cards, and have no xorg.conf file.  One of the graphics cards is an
> nvidia (cannot remember which model, however). xrandr finds all monitors
> successfully.

In my case, an empty xorg.conf doesn't work with my 3-monitor setup.
The issue is that the Nvidia driver (contrary to nouveau?) doesn't
work with 3 monitors, so one of them cannot be used, but when the
X server is restarted (e.g. when I log out), the Nvidia driver is
confused about which monitor to use.

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

Re: Second monitor doesn't quite work

[Vincent Lefevre]

On 2023-04-19 19:43:01 -0700, Charlie Gibbs wrote:
> Section "Screen"
> Identifier "Screen0"
> Device "Device0"
> Monitor"Monitor0"
> DefaultDepth24
> Option "Stereo" "0"
> Option "metamodes" "HDMI-0: nvidia-auto-select +0+0"
> Option "SLI" "Off"
> Option "MultiGPU" "Off"
> Option "BaseMosaic" "off"
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection
> 
> Section "Screen"
> Identifier "Screen1"
> Device "Device1"
> Monitor"Monitor1"
> DefaultDepth24
> Option "Stereo" "0"
> Option "nvidiaXineramaInfoOrder" "DFP-0"
> Option "metamodes" "DVI-D-0: nvidia-auto-select +0+0
> {AllowGSYNC=Off}"
> Option "SLI" "Off"
> Option "MultiGPU" "Off"
> Option "BaseMosaic" "off"
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection

Not sure whether this is correct. I have only one Screen section
for 2 monitors (that's before I change the configuration with
xrandr when logging in, because I actually have 3 monitors):

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
Option "Stereo" "0"
Option "metamodes" "DP-3: nvidia-auto-select +0+0, DP-4: 
nvidia-auto-select +0+0"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth   24
EndSubSection
EndSection

In your case, the metamodes option should probably be

  Option "metamodes" "HDMI-0: nvidia-auto-select +0+0, DVI-D-0: 
nvidia-auto-select +0+0"

I don't know what "{AllowGSYNC=Off}" is about.

Also check the xrandr output: both monitors should be "connected"
with a screen geometry shown.

For instance, in my case:

Screen 0: minimum 8 x 8, current 7680 x 2160, maximum 16384 x 16384
VGA-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 connected (normal left inverted right x axis y axis)
   3200x1800 59.98 +  40.00  
DP-4 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 
700mm x 390mm
   3840x2160 60.00*+  30.0029.97  
   2560x1440 59.95  
   1920x1080 60.0059.94  
   1680x1050 59.95  
   1600x900  60.00  
   1440x900  59.89  
   1280x1024 75.0260.02  
   1280x800  59.81  
   1280x720  60.00  
   1152x864  75.00  
   1024x768  75.0370.0760.00  
   800x600   75.0072.1960.3256.25  
   640x480   75.0072.8159.94  
DP-5 connected 3840x2160+3840+0 (normal left inverted right x axis y axis) 
597mm x 336mm
   3840x2160 60.00*+  29.98  
   2560x1440 59.95  
   1920x2160 59.99  
   1920x1080 60.0059.9450.00  
   1680x1050 59.95  
   1440x900  59.89  
   1280x1024 75.0260.02  
   1280x960  60.00  
   1280x720  60.0059.9450.00  
   1024x768  75.0370.0760.00  
   800x600   75.0072.1960.3256.25  
   720x576   50.00  
   720x480   59.94  
   640x480   75.0072.8159.9459.93  
DP-6 disconnected (normal left inverted right x axis y axis)

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

Re: OffTopic: iniciar programas gráficos en otra computadora, solo con X

[Gonzalo Rivero]

El 12/4/23 a las 15:21, JavierDebian escribió:



El 12/4/23 a las 15:17, Gonzalo Rivero escribió:


El 12/4/23 a las 14:55, JavierDebian escribió:



El 12/4/23 a las 14:46, Gonzalo Rivero escribió:

Hola a todos,

esto es mas una duda que se me ocurrió mientras pensaba en la 
inmortalidad del cangrejo, y que no se ni como buscarla en google 
para resolverla por mi mismo.


Yo se que si estoy en la computadora A, y quiero arrancar algún 
programa gráfico en la computadora B, entonces puedo entrar por ssh 
y ejecutarlo, algo así:


yo@pcA:~ $ ssh -X pcB
yo@pcB:~ $ programaGráfico

Veo y manejo el programa desde pcA. Hay mas de una forma de hacerlo 
(ssh -Y, xhost +,...) incluso puedo cargar un escritorio completo, 
o algún tipo de xdm y transformar pcA en una especie de terminal boba.


Lo que no se si será posible y en caso que lo sea me gustaría saber 
como (y si queda tiempo le buscaré una aplicación útil al invento) 
hacer que programaGráfico se vea en la pantalla de pcB. Se que se 
puede usar vnc, rdp, teamviewer o equivalentes... pero yo decía 
hacerlo solo aprovechando lo que exista en x.org y ssh o telnet 
incluso






export DISPLAY=:0 ( o el display que fuera)


https://www.shellhacks.com/start-gui-application-remote-computer-ssh/


ESTO es exactamente lo que me preguntaba si sería posible, no imaginé 
que sería tan simple, gracias! :D


Si me quedará tiempo para encontrar alguna aplicación práctica jejeje



La única vez que lo vi hacer en algo realmente útil, fue en una charla 
de un expositor.

El tipo hablaba con una laptop en el escritorio.
Los esbirros buscábamos afanosamente en internet o archivos, cuando 
surgían preguntas de datos específicos, y se lo mostrábamos en su 
pantalla.


ya le encontré dos utilidades a arrancar remotamente programas que se 
vean en la pantalla remota y no la mía:


* molestar a los nuevos con xmessage o similares en la oficina

* el anterior ya no es muy útil para mi porque pasé a trabajar desde 
casa todo el tiempo. Pero ayer en la computadora que me enviaron, con 
kubuntu, se clavó parte del kde: los programas que tenía abiertos 
seguían andando, pero no el panel, ni el administrador de ventantas. Me 
pasó varias veces pero esta vez no tenía abierta ninguna consola, 
entonces entré por ssh y ejecuté: killall plasmashell; killall kwin_x11; 
kstart5 plasmashell; kwin_x11

bug subscription issue

[Vincent Lefevre]

I've subscribed to a bug at 09:09:57 UTC and received a
"Please confirm subscription" message from bendel.debian.org
two minutes later. Fine.

I've subscribed to 3 more bugs at 10:01:05 UTC, but I haven't received
any "Please confirm subscription" message. I cannot see any connection
from bendel.debian.org concerning these bug subscriptions in the mail
logs of my server (there are other connections, the last one at 11:21,
but concerning the debian-user list). Does anyone know what happens
with bug subscription?

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

Sat/Sun @Geldrop (Eindhoven, NL): T-DOSE Open Source Event

[J.A. Bezemer]

Hi all,

This Saturday and Sunday, Debian has a booth at the T-DOSE "Technical 
Dutch Open Source Event" in Geldrop, The Netherlands.


Join us to discuss all things Debian, meet people from other projects, and 
listen to interesting talks on many subjects. Entrance is free!


More info: https://t-dose.org

Thanks,
Anne Bezemer

Re: Apt sources.list

[Greg Wooledge]

On Thu, Apr 20, 2023 at 12:18:35PM +0200, Vincent Lefevre wrote:
> Anyway, in the time of freeze like now (probably with more
> users trying testing), isn't it important that testing gets
> security updates?

It's not really about what's "important", but what's feasible given the
available resources (time spent by the security team).

If the security team has the time to offer a handful of testing
updates -- which, apparently, they did at least once in the last few
months -- then that's great.  Everyone loves security updates.

However, their primary goal must, and will, remain supporting the stable
release(s).  Sometimes they struggle even doing that.

Re: Second monitor doesn't quite work

[Eric S Fraga]

On Wednesday, 19 Apr 2023 at 23:34, Stefan Monnier wrote:
>> Any idea why the second monitor is sort of there but not quite?  Below is
>> a copy of the xorg.conf generated by the Nvidia setup utility.
>
> I have no experience with multi-monitor setups on nVidia, but the last
> time I used a non-empty `xorg.conf` was many years ago, so I suggest
> you try to just remove the config file generated by `nvidia-settings`.

I second this.  I have three monitors on my system, with two graphics
cards, and have no xorg.conf file.  One of the graphics cards is an
nvidia (cannot remember which model, however). xrandr finds all monitors
successfully.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-04-18) on Debian 11.6

Re: Apt sources.list

[Vincent Lefevre]

On 2023-04-18 13:52:13 -0400, Jeffrey Walton wrote:
> On Tue, Apr 18, 2023 at 1:46 PM Frank  wrote:
> > Interesting. Like Tixy, I was under the impression testing didn't
> > receive security support. I remember checking that several times over
> > the years. Curious.

Anyway, in the time of freeze like now (probably with more
users trying testing), isn't it important that testing gets
security updates?

> I did not think so, either. But have a look at
> https://www.debian.org/security/faq#testing and

This one does not concern testing-security, but security updates
that "migrate" from unstable to testing, like any other update for
unstable (so this is just "testing", not "testing-security"):

  Security for testing benefits from the security efforts of the
  entire project for unstable. However, there is a minimum two-day
  migration delay, and sometimes security fixes can be held up by
  ^
  transitions. The Security Team helps to move along those transitions
  holding back important security uploads, but this is not always
  possible and delays may occur. Especially in the months after a new
  stable release, when many new versions are uploaded to unstable,
  security fixes for testing may lag behind. If you want to have a
  secure (and stable) server you are strongly encouraged to stay with
  stable.

There is a better solution concerning the "in the months after
a new stable release" case, even for users using unstable: have
"stable-security" in apt sources (e.g. /etc/apt/sources.list).
Since stable is new, most packages are based on the same version
as stable. That way, users can benefit from security updates for
stable.

> https://wiki.debian.org/DebianTesting .

This is strange that

  If you are tracking testing or the next-stable code name, you
  should always have a corresponding deb http://security.debian.org
  <"testing" or codename>-security main entry in your apt sources.
  See this FAQ-Item.

links to the above FAQ item, as testing-security is not related to
what the above FAQ-Item says. This may confuse users.

This wiki page also links to the more detailed

  
https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing

which first mentions the unstable-to-testing migration like the FAQ,
but also says:

  Additionally, the http://secure-testing-master.debian.net can issue
  Debian Testing Security Advisories (DTSAs) for packages in the
  testing branch if there is an immediate need to fix a security issue
  in that branch and cannot wait for the normal procedure (or the
  normal procedure is being blocked by some other packages).

  Users willing to take advantage of this support should add the
  following lines to their /etc/apt/sources.list (instead of the
  lines described in Section 4.2, “Execute a security update”):

  deb http://security.debian.org testing/updates main contrib non-free
  # This line makes it possible to donwload source packages too
  deb-src  http://security.debian.org testing/updates main contrib non-free

which is out-of-date: use testing-security instead of the old
testing/updates (this changed in July 2019). This is the following
bug (from July 2019):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931520

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

Cura et erreur de chargement de plugins fournis avec le logiciel

[BERTRAND Joël]

Bonjour à tous,

Je suis en train d'essayer de me faire la main avec un e imprimante 3D
supportée par Cura (motif : imprimer des feeders pour ma machine de
pick'n place).

J'utilise la version packagée (4.13.0-1).

Lorsque je la démarre, j'ai des erreurs de plugins :
- TrimeshReader ;
- AMFReader.

Visiblement, il s'agit d'un problème avec une extension python
(trimesh). J'ai donc installé pour l'utilisateur en question ce qui
allait bien :

⚠️  Note: f2py was already on your PATH at /usr/bin/f2py
⚠️  Note: f2py3 was already on your PATH at /usr/bin/f2py3
⚠️  Note: f2py3.11 was already on your PATH at /usr/bin/f2py3.11
  installed package trimesh 3.21.5, installed using Python 3.11.2
  These apps are now globally available
- f2py
- f2py3
- f2py3.11
⚠️  Note: '/home/bertrand/.local/bin' is not on your PATH environment
variable. These apps will not be globally accessible until your PATH is
updated. Run `pipx ensurepath` to automatically add it, or manually
modify
your PATH in your shell's config file (i.e. ~/.bashrc).
done! ✨  ✨
hilbert:[~] >

Python 3.11 est la version par défaut. Or lorsque je lance :

hilbert:[~] > PATH=/home/bertrand/.local/bin:$PATH cura

j'obtiens toujours les mêmes erreurs. Comment corriger le problème ?
J'ai bien vu un rapport de bug, mais sans solution.

Bien cordialement,

JKB

AW: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Schwibinger Michael]

"I haven't a clue what you are going on about here. Shift-L in mutt was used at
this end."

Hello

I am confused.

Its said
You can use any driver from EPSON
to use a printer.

Bit it is not working.

I did open GEDIT
ordered "PRINT"
but no reaction.

Regards
Sophie


Thank You.





Von: Brian 
Gesendet: Freitag, 14. April 2023 22:52
An: debian-user@lists.debian.org 
Betreff: Re: EPSON ET M 1120 new printer: If You can read this, you are using 
the wrong driver

On Fri 14 Apr 2023 at 18:22:09 -0400, The Wanderer wrote:

> On 2023-04-14 at 18:10, Brian wrote:
>
> > On Fri 14 Apr 2023 at 14:40:33 +, Schwibinger Michael wrote:
> >
> >> Good afternoon.
> >> The new printer is not  working.
> >> EPSON is saying
> >> You cant use EPSON with Linux.
> >>
> >> Is this true?
> >
> > You could consider:
> >
> >   * Stating the Debain OS being used.
> >   * Giving the printer make and model.
>
> The make *was* stated: Epson.
>
> The model may also have been stated, albeig only in the Subject line: ET
> M1120. From a bit of Googling, the "ET" appears to stand for "EcoTank".

The EPSON ET M 1120 doesn't exist. Do we have to guess its correct name as well
as any other relevant information?

> >   * Specifying the connection method. USB. Network.
> >   * Giving the exact error message and where it came from.
>
> Also:
>
> * Starting a new thread to discuss the matter, rather than replying to
> an existing message deep in an existing thread, deleting the body, and
> changing the Subject line before sending.
>
> (This question, and its replies, are appearing as responses to a mail
> from Michael Stone in the 'update-initramfs' thread.)

I haven't a clue what you are going on about here. Shift-L in mutt was used at
this end.

--
Brian.

Re: /etc/fstab question (problem)?

[DdB]

You got your plan mapped out. and i agree, except for one little detail:
see below. -

Am 19.04.2023 um 22:06 schrieb Default User:
>> I think, it is the case when reboot is safer. Open file descriptors
>> remain on the original partition. However I do not expect that single
>> user mode or booting from live image is required. Just restore
>> original
>> /etc/fstab and reboot.
>>
>> Perhaps update-initramfs is necessary after restoring of /etc/fstab
>> in
>> any chosen approach.
>>
>>
>
>
> Well, now I am totally confused.
>
> I had hoped for, and really expected, an easy, obvious, intuitive
> solution.  But I guess that may be a distant memory of the good old
> days, before [insert string of four-letter words here] like dbus,
> systemd, and Gnome 3. And when partitions were named /dev/hda5, not
> 6a105a72-f5d5-441b-b926-1e405151ee84.
>
> Sigh.
>
> Anyway, here is where I am at:
>
> I have two Clonezilla backups.
> 1) a full disk backup.
> 2) a "partitions" backup.
> So, if things really go bad, I can theoretically revert to the setup as
> of 2023-04-18, when this thread was started.
>
> I also have a backup of the current /tmp directory (from under the /
> directory).
> And I have a backup of the old tmp partition.
>
> Both of these tmp backups were made using a Debian Stable 11.6
> Live/install usb thumb drive, as root user.
>
> All of these backups are on an external usb hdd.
>
> Here is what was in the (root) tmp directory:
>
> _root_partition/tmp
> total 32K
> 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./
> 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../
> 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/
> 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/
> 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/
> 88473610 drwx-- 2 [user] [user] 4.0K Apr 19 14:18 tracker-extract-
> files.116/
> 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/
> 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/
>
> And here is what was in the old tmp partition:
>
> total 48K
> 88473611 drwxr-xr-t 10 rootroot4.0K Apr 19 14:20 ./
> 88473603 drwxr-xr-x  3 [user] [user] 4.0K Apr 19 14:20 ../
> 88473618 drwxr-xr-t  2 rootroot4.0K Apr 19 14:20 .font-unix/
> 88473615 drwxr-xr-t  2 rootroot4.0K Apr 19 14:20 .ICE-unix/
> 88473620 drwx--  2 rootroot4.0K Apr 19 14:20 lost+found/
> 88473619 drwxr-xr-t  2 rootroot4.0K Apr 19 14:20 .Test-unix/
> 88473624 drwx--  2 rootroot4.0K Apr 19 14:20 tracker-
> extract-files.1000/
> 88473623 drwx--  2 rootroot4.0K Apr 19 14:20 tracker-
> extract-files.116/
> 88473621 -r--r--r--  1 rootroot  11 Apr 19 14:20 .X1024-lock
> 88473622 -r--r--r--  1 rootroot  11 Apr 19 14:20 .X1025-lock
> 88473612 drwxr-xr-t  2 rootroot4.0K Apr 19 14:20 .X11-unix/
> 88473617 drwxr-xr-t  2 rootroot4.0K Apr 19 14:20 .XIM-unix/
>
> As far as I can tell, there is nothing crucial in either tmp backup.
>
> BTW, I know nothing about bind or mount --bind. I looked them up
> briefly, and decided that they are too difficult and maybe dangerous to
> try to learn and use under the current circumstances.
>
> So here is what I am thinking of doing:
>
> While running from within the Debian Stable 11.6 Live/install usb thumb
> drive, as root user:
>
> 1) On the computer's internal ssd, delete the /tmp directory and its
> contents.
Do NOT delete the directory itself, only its content, as it will be used
as the mountpoint for your /tmp drive.

>
> 2) On the computer's internal ssd, delete the contents of the old tmp
> partition, but not the partition itself.
>
> 3) On the computer's internal ssd, replace /etc/fstab with
> /etc/fstab.original, renaming it /etc/fstab. I have already made a copy
> of the current /etc/fstab as /etc/fstab.as-of-2023-04-19.
>
> The UUIDs of all partitions on computer's internal ssd seem to be the
> same as in /etc/fstab.original.
>
> (Note: in /etc/fstab.original, it states "Please run 'systemctl daemon-
> reload' after making changes here." Since I am doing all this from a
> live usb, I do not think that applies, so I would skip that.)
>
> Then I would shut down, remove the usb thumb drive, and boot into the
> Debian system on the computer's internal ssd.
>
> I hope that from then on, the system would mount the old tmp partition
> on the computer's internal ssd as /tmp, re-populating it automatically,
> and use it as such from then on.
>
> Does that seem reasonable?
>
> Or am I missing something, obvious or not.

Please report your success, will you?

Re: SOS

[Sébastien NOBILI]

Bonjour,

Le 2023-04-19 18:41, Philippe HUGUET a écrit :
J'ai un sérieux problème depuis quelques mois, en fait depuis quelques 
mises à jours, il m'est devenu impossible de réaliser de l'imagerie, 
que ce soit avec SweetHome3D , LibreCAD, et FREECAD, dès que le dessin 
devient un peu lourd et complexe. Mémoire 4Go saturée, espace d'échange 
également, processeurs entre 98 et 100% en permanence. Bref, ça rame 
dur ! Alors qu'avant c'était impeccable


Dans les moments où ça rame, ça serait intéressant de voir l'état 
d'occupation du CPU et de la mémoire

(avec htop par exemple) :

- Quels sont les 5 (ou 10) processus qui utilisent le plus de CPU ?
- Quels sont les 5 (ou 10) processus qui utilisent le plus de mémoire ?

(sinon atop est bien aussi car il enregistre régulièrement l'état du 
système et permet de lire ces

informations a posteriori)

C'est seulement après cette analyse qu'on pourra en déduire des pistes 
d'amélioration.


Sébastien