Ah, ce n’est pas mon cas, je suis encore au bon vieux msdos, je ne suis pas encore convaincu par gpt car beaucoup de cartes-mère ne le gèrent pas encore et, utilisateur actif de LVM, je n’en vois pas l’intérêt.
Il n’y a pas la même chose pour le swap seulement ?
idem pour moi; mais pour combien de temps encore les cartes mère donnerons le choix entre uefi et csm/legacy? un jour ou l’autre ne seront obligés de passer par uefi et donc gpt. Si je dis une connerie Pascal nous le dira.
UEFI, c’est pas le truc qui amène le système daubé du cul de Secure Boot. Je n’ai pas confiance en ce truc, un jour, Secure Boot signera la fin du libre, voire la fin de l’informatique. Je ne comprend même pas à quoi ça sert, donc pas de ça chez moi.
Et puis, le legacy est peut-être limité (je ne vois pas en quoi, par ailleurs), mais c’est simple et compréhensible.
Et sinon, pour revenir au sujet, une idée pour l’activation automatique du swap ?
La carte mère n’a pas plus besoin de gérer le format GPT qu’elle n’a besoin de gérer le format ext4. Tu confonds peut-être avec l’UEFI. Quant à l’intérêt de GPT indépendamment de LVM, il se manifeste au moins dans deux cas :
-
avec un disque de plus de 2 Tio, ce qui devient de plus en plus courant,
-
quand on a besoin de créer plus de 4 partitions, ce qui peut arriver même avec LVM.
Par contre systemd-gpt-auto-generator ne marche pas avec les swaps qui sont dans des volumes logiques LVM, même si le disque contenant le PV est au format GPT. Encore un avantage de LVM pour moi, gniark gniark.
Pour ton besoin, tu pourrais peut-être t’inspirer du contenu de systemd-gpt-auto-generator pour créer ton propre générateur. Ne l’ayant jamais regardé, je ne sais pas si c’est compliqué.
Sinon, un script de base qui recherche et active les swaps présents.
swapon $(blkid -t TYPE="swap" -o device)
non, UEFI n’a rien à voir avec secure boot qui est un truc spécifique à M$, il faut désactiver secureboot pour installer autre chose que windows; la question est d’avoir le choix entre UEFI et csm/legacy/bios, auront nous toujours le choix; mais d’un autre côté l’installeur debian gère bien uefi ,enfin je le crois d’après les infos dont nous pouvons disposer; et si un jour il faudra en passer par uefi je ferai comme tout le monde; mais tant que c’est possible je garde le vieux bios .
c’est dans fstab que je choisis la partition swap commune à mes trois debian; stable, testing et sid
Si, quand même. C’est bien l’UEFI qui a introduit le secure boot en tant qu’option.
Pas du tout. C’est spécifique à l’UEFI, et Microsoft s’en sert, ainsi que d’autres distributions Linux que Debian (qui y travaille).
Ça, c’est déjà réglé : la réponse est non. Il y a déjà des machines dotées d’un firmware UEFI qui n’a pas de mode de compatibilité BIOS/legacy/CSM.
La vraie question concerne la possibilité de désactiver le secure boot et d’importer ses propres clés dans le firmware afin de ne pas dépendre de celle de Microsoft, comme font actuellement les distributions compatibles avec le secure boot.
Les spécifications de Microsoft imposées aux fabricants pour bénéficier du label de compatibilité Windows 8 imposaient que le secure boot soit désactivable sur architecture PC x86, mais non désactivable sur architecture ARM. Je n’ai pas regardé ce qu’il en est avec Windows 10, mais je ne suis pas optimiste.
L’autre problème de l’UEFI est que pour le moment la plupart de ses implémentations sont mal finies et farcies de bugs plus ou moins gênants.
C’est-à-dire, à quoi ça ressemble ?
exemple :
UUID=819ed4f4-718f-4b82-b4d0-28ee4fbc8fcd swap swap defaults,noatime 0 0
j’ai une partition swap commune à stable, testing et sid
tes propos sont inquiétants; *nux seront ils toujours installables dans le futur si l’option “disable secure boot” n’est plus proposée et si les fabricants de cartes mères refusent de prendre en compte les os *nux?
Oui, à condition que les chargeurs d’amorçage ou noyaux des distributions Linux soient signées par une organisation dont la clé est reconnue par les firmwares UEFI (en clair : Microsoft). Mais l’utilisateur ne sera pas libre de modifier les éléments signés.
mais il ny a pas que M$, debian peut aussi fournir une clé, ou mageia ou open suse; les fabricants devront tout de même tenir compte des systèmes autre que M$; quand on pense seulement aux nombres de machines qui tournent sous Redhat et RedHat acceptera il de passer sous les fourches caudines de M$? La seule solution c’est l’option de désactiver le secure boot.
Qu’est-ce qui les y obligera ?
rien, mais en face il y a tout de même les grosses boîtes qui financent et utilisent le kernel linux et il seraient étonnant qu’elles n’est pas leur mot à dire dans cette histoire, et peut être il y aura une signature commune pour *nux, un genre de pool.
Ah, non, ça ne fonctionnera pas, je ne connais pas l’UUID des partitions de swap, et je ne connais pas leur périphérique non plus.
Je vais plutôt les repérer avec un blkid -t TYPE="swap" -o device et les monter à la main, comme proposé par @PascalHambourg.
avram@sda1-sparky: 17:44:05: ~$ sudo blkid
/dev/sda1: UUID=“9941acf0-5d5d-443e-b757-fc47cbb829a4” TYPE=“ext4” PARTUUID=“425b6edf-01”
/dev/sda5: UUID=“7143bc1a-14c4-4d23-ba45-46aac2e0ed4a” TYPE=“ext4” PARTUUID=“425b6edf-05”
/dev/sda6: UUID=“819ed4f4-718f-4b82-b4d0-28ee4fbc8fcd” TYPE=“swap” PARTUUID=“425b6edf-06”
/dev/sdb1: UUID=“85f8f7fd-89e0-4ea5-80bd-cffd745ab99a” TYPE=“ext4” PARTUUID=“9482716d-01”
/dev/sdb2: UUID=“d485c131-0a20-4948-8f71-f58685f1a271” TYPE=“ext4” PARTUUID=“9482716d-02”
/dev/sdb5: UUID=“31b0128b-b1fd-47f2-8590-b08825142bd7” TYPE=“ext4” PARTUUID="9482716d-05"
avram@sda1-sparky: 17:44:26: ~$
Merci, je connais blkid et je sais m’en servir. Ce que je voulais, c’est que, sur un système dont je ne connais rien, je lance un script, ou je change de la configuration, et les swap s’activent, où qu’il soient, la solution de @PascalHambourg me convient, sauf s’il y a mieux.
Voilà, pour info, la façon dont j’ai intégré ça dans mon projet en Python3 :
from subprocess import call, getoutput
listswaps_cmd = (
'/sbin/blkid',
'-t',
'TYPE=swap',
'-o',
'device',
)
swapon = '/sbin/swapon'
def list_swaps ():
'''
Récupère la liste de toutes les partition et volumes logiques étant déclarés comme du swap
Retourne ça sous la forme d'un tuple
'''
r = []
for i in getoutput (listswaps_cmd).split ('\n'):
if i != '':
r.append (i)
return (r)
for i in list_swaps ():
call ([swapon, i])
Voilà, bonne journée et merci les gars.
Quel est ton problème avec systemd exactement? Normalement tu n’as rien à faire, à partir du moment où une partition est de type swap, systemd se charge de la monter et s’en servir en tant que telle au démarrage.
Que je sache, comme je l’ai écrit plus haut, systemd ne fait cela qu’avec les partitions de swap du disque système si celui-ci est au format GPT.