Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

goutter le code source ?

16 réponses
Avatar
ptilou
Bonsoir,

C'est gratuit de goutter le code source ?

merci de vos lumi=C3=A8res

--=20
ptilou

10 réponses

1 2
Avatar
Marc SCHAEFER
[ Followup-To: fr.comp.os.linux.configuration ]
ptilou wrote:
Je me demander j'ai une clés USB de 2 To, çà marche comment la table de partition ?

Une clé USB est un périphérique bloc comme un autre. La table des partitions
est exactement la même que sur un autre type de disque-dur, souple ou
sans parties tournantes. Les mêmes outils de partitionnement legacy
MS-DOS FAT ou plus moderne sont utilisés.
NB: pour le BIOS (démarrage de la machine), toutefois, il n'y a pas
cette orthogonalité, des problèmes peuvent survenir.
Sous GNU/Linux, on peut bien sûr ne pas partitionner et utiliser l'ensemble
de la capacité pour le filesystem choisi, exemple:
df
/dev/sdb 15G 1.8G 13G 13% /scratch/LOGS
/dev/sde 2.7T 2.4T 195G 93% /backup
lsblk
sdb 8:16 1 15G 0 disk /scratch/LOGS
sde 8:64 0 2.7T 0 disk /backup
Si l'on partitionne, voir que l'on découpe en volumes logiques,
avec ou sans RAID, cela ressemblera plutôt à: (lsblk)
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
|-sda1 8:1 0 3.7G 0 part
| `-md0 9:0 0 3.7G 0 raid1 [SWAP]
`-sda2 8:2 0 1.8T 0 part
`-md1 9:1 0 1.8T 0 raid1
|-vg1-root 253:0 0 18.6G 0 lvm /
|-vg1-lxc--103 253:1 0 21G 0 lvm /var/lib/lxc/103
|-vg1-lxc--123 253:2 0 14G 0 lvm /var/lib/lxc/123
|-vg1-lxc--104 253:3 0 529G 0 lvm /var/lib/lxc/104
|-vg1-lxc--124 253:4 0 1G 0 lvm /var/lib/lxc/124
|-vg1-lxc--105 253:5 0 25G 0 lvm /var/lib/lxc/105
|-vg1-lxc--200 253:6 0 27G 0 lvm /var/lib/lxc/200
|-vg1-lxc--203 253:7 0 20G 0 lvm /var/lib/lxc/203
|-vg1-lxc--121 253:8 0 672.7G 0 lvm /var/lib/lxc/121
|-vg1-scratch 253:9 0 220G 0 lvm /scratch
`-vg1-lxc--204 253:10 0 40G 0 lvm /var/lib/lxc/204
sdb 8:16 0 1.8T 0 disk
|-sdb1 8:17 0 3.7G 0 part
| `-md0 9:0 0 3.7G 0 raid1 [SWAP]
`-sdb2 8:18 0 1.8T 0 part
`-md1 9:1 0 1.8T 0 raid1
|-vg1-root 253:0 0 18.6G 0 lvm /
|-vg1-lxc--103 253:1 0 21G 0 lvm /var/lib/lxc/103
|-vg1-lxc--123 253:2 0 14G 0 lvm /var/lib/lxc/123
|-vg1-lxc--104 253:3 0 529G 0 lvm /var/lib/lxc/104
|-vg1-lxc--124 253:4 0 1G 0 lvm /var/lib/lxc/124
|-vg1-lxc--105 253:5 0 25G 0 lvm /var/lib/lxc/105
|-vg1-lxc--200 253:6 0 27G 0 lvm /var/lib/lxc/200
|-vg1-lxc--203 253:7 0 20G 0 lvm /var/lib/lxc/203
|-vg1-lxc--121 253:8 0 672.7G 0 lvm /var/lib/lxc/121
|-vg1-scratch 253:9 0 220G 0 lvm /scratch
`-vg1-lxc--204 253:10 0 40G 0 lvm /var/lib/lxc/204
sdc 8:32 1 231.9G 0 disk /var/lib/lxc/121/rootfs/usenet-fr-dbs
sde 8:64 0 2.7T 0 disk /backup
Avatar
Nicolas George
Marc SCHAEFER , dans le message <peotsi$o0e$, a
écrit :
La table des partitions
est exactement la même que sur un autre type de disque-dur, souple ou

^^^^^^
sans parties tournantes.

Je n'ai pas vu souvent de tables de partitions sur des disquettes.
Avatar
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
Je n'ai pas vu souvent de tables de partitions sur des disquettes.

C'est vrai, mais je l'ai fait sur un lecteur de disquette SCSI,
comme on n'en fait plus :->
Avatar
Nicolas George
Marc SCHAEFER , dans le message <pepa6g$ks7$, a
écrit :
C'est vrai, mais je l'ai fait sur un lecteur de disquette SCSI,
comme on n'en fait plus :->

Je suis plus que dubitatif quant à cette affirmation : le
partitionnement est une propriété du support, pas du lecteur.
Avatar
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
C'est vrai, mais je l'ai fait sur un lecteur de disquette SCSI,
comme on n'en fait plus :->

Je suis plus que dubitatif quant à cette affirmation : le
partitionnement est une propriété du support, pas du lecteur.

Le partitionnement est une propriété du type de périphérique.
Je ne crois pas avoir jamais partitionné un /dev/fd0 sous Linux,
pour la bonne raison que je pense que le kernel ne lit pas la
table des partitions dans ce cas et ne génère pas les points
d'entrées à /dev/fd0pX: probablement même que la numérotation
des minors ne le prévoit pas. Il se peut même qu'il manque
certains ioctl(2) spécifiques qui retourneraient une erreur
au moment où on ferait un `w' dans fdisk, p.ex, ou même
à la lecture. A tester! (sauf que je n'ai plus aucun
lecteur de floppy je crois).
Dans le cas d'un lecteur de floppy SCSI, c'était
alors, de mémoire, géré comme un disque-dur amovible,
soit un bon vieux /dev/sdX, donc les minors étaient prévus
pour cela, et la table des partitions était lue. Les
partitions Y étaient accessibles sous /dev/sdXY comme
d'habitude.
Comme tu m'as instillé le doute, je viens de regarder
le standard SCSI, et les floppy sont bien des Direct-Access
Devices avec drapeau Removable Medium, et non pas un type
spécifique "floppy", ou du moins je n'en trouve pas. Le
kernel ne peut donc pas faire la différence et décider
de partitionner ou pas. Cela ne veut pas dire qu'un BIOS
va supporter ça, par contre.
PS: j'ai aussi partitionné des cassettes, mais là, c'est
un concept qui s'utilise avec `mt', sans device spécifique,
d'autant plus qu'ici c'est un character-device.
(on déroule la bande jusqu'à une partition particulière).
Avatar
Nicolas George
Marc SCHAEFER , dans le message <pepp8u$h55$, a
écrit :
Le partitionnement est une propriété du type de périphérique.

C'est tellement vague que ça ne veut rien dire.
Je ne crois pas avoir jamais partitionné un /dev/fd0 sous Linux,
pour la bonne raison que je pense que le kernel ne lit pas la
table des partitions dans ce cas et ne génère pas les points
d'entrées à /dev/fd0pX: probablement même que la numérotation
des minors ne le prévoit pas. Il se peut même qu'il manque
certains ioctl(2) spécifiques qui retourneraient une erreur
au moment où on ferait un `w' dans fdisk, p.ex, ou même
à la lecture. A tester! (sauf que je n'ai plus aucun
lecteur de floppy je crois).

On peut faire lire des partitions sur n'importe quel support, si on sait
s'y prendre, y compris du loopback, des partitions, etc. Le noyau ne le
fait PAR DÉFAUT que quand c'est utile.
Dans le cas d'un lecteur de floppy SCSI, c'était
alors, de mémoire, géré comme un disque-dur amovible,
soit un bon vieux /dev/sdX, donc les minors étaient prévus
pour cela, et la table des partitions était lue. Les
partitions Y étaient accessibles sous /dev/sdXY comme
d'habitude.

Oui, on peut le faire. Et si on le fait on se retrouve avec un machin
qui ne va marcher qu'avec ces lecteurs ou des manipulations explicites,
avec comme conséquence de perdre un peu du peu de place disponible sur
une disquette et aucun bénéfice.
Mais bon, tu gaspilles ton temps comme tu veux.
Avatar
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
On peut faire lire des partitions sur n'importe quel support, si on sait
s'y prendre, y compris du loopback, des partitions, etc. Le noyau ne le
fait PAR DÉFAUT que quand c'est utile.

Tiens, j'aimerais bien un exemple pour le loopback, rien que pour voir
quels minors sont utilisés.
J'en ai trouvé un:
https://stackoverflow.com/questions/1419489/how-to-mount-one-partition-from-an-image-file-that-contains-multiple-partitions
Et on voit bien les major/minors:
# kpartx -v -a logging-test.img
add map loop0p1 (251:0): 0 497664 linear /dev/loop0 2048
add map loop0p2 (251:1): 0 66605058 linear /dev/loop0 501758
add map loop0p5 (251:2): 0 66605056 251:1 2
# ls /dev/mapper/
control loop0p1 loop0p2 loop0p5
# mount /dev/mapper/loop0p1 /mnt/test
# mount | grep test
/dev/mapper/loop0p1 on /mnt/test type ext2 (rw)
J'ai appris quelque chose, car jusqu'ici, je faisais comme dans
le lien (au début), soit jouer avec l'offset.
Donc, même un floppy type PC pourrait être partitionné *et* utilisé.
Intéressant.
Avatar
Pascal Hambourg
Le 01/06/2018 à 06:27, Marc SCHAEFER a écrit :
Tiens, j'aimerais bien un exemple pour le loopback, rien que pour voir
quels minors sont utilisés.

(...)
Et on voit bien les major/minors:
# kpartx -v -a logging-test.img
add map loop0p1 (251:0): 0 497664 linear /dev/loop0 2048
add map loop0p2 (251:1): 0 66605058 linear /dev/loop0 501758
add map loop0p5 (251:2): 0 66605056 251:1 2
# ls /dev/mapper/
control loop0p1 loop0p2 loop0p5
# mount /dev/mapper/loop0p1 /mnt/test

Note : kpartx utilise un périphérique loop pour le fichier entier, mais
gère les partitions avec le device-mapper.
Une autre méthode consiste à faire gérer les partitions directement par
le pilote loop et le noyau. Deux variantes :
- utiliser l'option max_part lors du chargement du module loop. Les
minors de /dev/loop* sont alors écartés les uns des autres pour faire de
la place aux partitions /dev/loopXpY, de façon similaire aux disques
/dev/sdX. L'écartement est arrondi à la puissance de 2 supérieure ou
égale la plus proche :
brw-rw---T 1 root disk 7, 0 juin 9 12:19 /dev/loop0
brw-rw---T 1 root disk 7, 4 juin 9 12:19 /dev/loop1
brw-rw---T 1 root disk 7, 8 juin 9 12:19 /dev/loop2
...
- utiliser l'option -P de losetup pour forcer la lecture de la table de
partition du périphérique loop par le noyau. Les partitions /dev/loopXpY
auront alors le major 259 (block extended pour allocation dynamique, le
même que pour les partitions /dev/sdXY au delà de 15).
Avatar
ptilou
Bonsoir,
Le jeudi 31 mai 2018 15:38:27 UTC+2, Marc SCHAEFER a écrit :
[ Followup-To: fr.comp.os.linux.configuration ]
ptilou wrote:
Je me demander j'ai une clés USB de 2 To, çà marche comm ent la table de partition ?

Une clé USB est un périphérique bloc comme un autre. La t able des partitions
est exactement la même que sur un autre type de disque-dur, souple o u
sans parties tournantes. Les mêmes outils de partitionnement legacy
MS-DOS FAT ou plus moderne sont utilisés.
NB: pour le BIOS (démarrage de la machine), toutefois, il n'y a pas
cette orthogonalité, des problèmes peuvent survenir.
Sous GNU/Linux, on peut bien sûr ne pas partitionner et utiliser l'e nsemble
de la capacité pour le filesystem choisi, exemple:
df
/dev/sdb 15G 1.8G 13G 13% /scratch/LOGS
/dev/sde 2.7T 2.4T 195G 93% /backup
lsblk
sdb 8:16 1 15G 0 disk /scratch/LOGS
sde 8:64 0 2.7T 0 disk /backup
Si l'on partitionne, voir que l'on découpe en volumes logiques,
avec ou sans RAID, cela ressemblera plutôt à: (lsblk)
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
|-sda1 8:1 0 3.7G 0 part
| `-md0 9:0 0 3.7G 0 raid1 [SWAP]
`-sda2 8:2 0 1.8T 0 part
`-md1 9:1 0 1.8T 0 raid1
|-vg1-root 253:0 0 18.6G 0 lvm /
|-vg1-lxc--103 253:1 0 21G 0 lvm /var/lib/lxc/103
|-vg1-lxc--123 253:2 0 14G 0 lvm /var/lib/lxc/123
|-vg1-lxc--104 253:3 0 529G 0 lvm /var/lib/lxc/104
|-vg1-lxc--124 253:4 0 1G 0 lvm /var/lib/lxc/124
|-vg1-lxc--105 253:5 0 25G 0 lvm /var/lib/lxc/105
|-vg1-lxc--200 253:6 0 27G 0 lvm /var/lib/lxc/200
|-vg1-lxc--203 253:7 0 20G 0 lvm /var/lib/lxc/203
|-vg1-lxc--121 253:8 0 672.7G 0 lvm /var/lib/lxc/121
|-vg1-scratch 253:9 0 220G 0 lvm /scratch
`-vg1-lxc--204 253:10 0 40G 0 lvm /var/lib/lxc/204
sdb 8:16 0 1.8T 0 disk
|-sdb1 8:17 0 3.7G 0 part
| `-md0 9:0 0 3.7G 0 raid1 [SWAP]
`-sdb2 8:18 0 1.8T 0 part
`-md1 9:1 0 1.8T 0 raid1
|-vg1-root 253:0 0 18.6G 0 lvm /
|-vg1-lxc--103 253:1 0 21G 0 lvm /var/lib/lxc/103
|-vg1-lxc--123 253:2 0 14G 0 lvm /var/lib/lxc/123
|-vg1-lxc--104 253:3 0 529G 0 lvm /var/lib/lxc/104
|-vg1-lxc--124 253:4 0 1G 0 lvm /var/lib/lxc/124
|-vg1-lxc--105 253:5 0 25G 0 lvm /var/lib/lxc/105
|-vg1-lxc--200 253:6 0 27G 0 lvm /var/lib/lxc/200
|-vg1-lxc--203 253:7 0 20G 0 lvm /var/lib/lxc/203
|-vg1-lxc--121 253:8 0 672.7G 0 lvm /var/lib/lxc/121
|-vg1-scratch 253:9 0 220G 0 lvm /scratch
`-vg1-lxc--204 253:10 0 40G 0 lvm /var/lib/lxc/204
sdc 8:32 1 231.9G 0 disk /var/lib/lxc/121/rootfs/use net-fr-dbs
sde 8:64 0 2.7T 0 disk /backup

Y a t'il quelque chose de particulier sous linux, pour les adaptateur sdcar d to sata, faut un drive ou c'est natif avec le bios ?
merci
--
ptilou
Avatar
Marc SCHAEFER
Hello,
ptilou wrote:
[ suppression de 63 lignes inutiles ]
Y a t'il quelque chose de particulier sous linux, pour les adaptateur sdcard to sata, faut un drive ou c'est natif avec le bios ?

J'en ai effectivement utilisé un qui se présentait sous Linux comme un raw
device. Maintenant on peut toujours imaginer qu'ils fassent un modèle avec
des difficultés.
De quel modèle parles-tu ? (lien)
NB: le BIOS est souvent bien plus compliqué à convaincre que Linux. En
particulier pour démarrer sur des trucs un tout petit peu exotiques.
1 2