Reprise du message précédent :
J'ai un autre keymap mais c'est bien un keymap FR.
 
De ton côté pour le mdp chiffré il est bien en azerty?

Oui c'est en azerty, j'ai jamais eu ce problème.
Au départ j'avais KEYMAP=fr dans /etc/vconsole.conf, et puis ensuite j'ai mis fr-latin9 histoire d'avoir quelques caractères non ascii dans les tty, mais c'est pas nécessaire pour être en azerty évidemment.

J'ai même refais un update au cas ou mais ça ne change rien...
 
Je pige pas trop le soucis du coup...

Un update de quoi, du système ou du initramfs ?
Parce que c'est ce que j'allais te dire en fait : même si c'est peu probable, peut-être que le initramfs a été généré avant que son fichier de config et/ou vconsole.conf aient été correctement renseignés.
Donc peut-être faire un

histoire d'être sûr que t'es à jour à ce niveau (à condition que là aussi ce soit bien comme sous arch, c'est-à-dire que tu aies bien un fichier linux.preset dans /etc/mkinitcpio.d/, qui correspond à l'appel avec l'option -p linux ci-dessus, sinon ça marchera pas)

C'est justement ce que j'ai fais.
C'est linux54 sous manjaro mais c'est exactement ce que j'ai fais.
Aucun changement.

Attends, on a peut-être pas la même config en fait : est-ce que tu as une partition /boot séparée et non chiffrée, ou est-ce que /boot est intégré à la racine et chiffré avec le reste ?
Parce que si tu es dans le second cas, vois ce topic : https://forum.manjaro.org/t/does-lu [...] ards/87582
Dans ce cas-là, c'est évidemment au niveau de grub qu'il faut agir pour avoir le clavier fr.

Il me semble que ça a tout chiffré, le /boot aussi.
En gros je n'ai fais que cocher la case chiffrer depuis l'installeur.

EDIT: ce topic je suis déjà tombé dessus, et justement ils ne disent rien.
A la fin ça termine en moude USB keyboard donc...

Il faudrait que je vois s'il n'y a pas d'autre moyen pour chiffrer et obtenir ce que j'avais sur les autres distrib.
Mais donc encore une fois on est à des années lumières du "clef en main".

Oui, je n'ai jamais installé manjaro, donc j'ai découvert par ce topic que le chiffrement par défaut incluait /boot (ce qui est peu commun il me semble, voire exceptionnel en tant que comportement par défaut).
Mais j'imagine que tu dois pouvoir passer en partitionnement manuel et choisir le mode plus classique, avec /boot sur une partition séparée et non chiffrée.
 
Concernant les solutions proposées dans le topic que j'ai cité, il me semblait que ce post en proposait une : https://forum.manjaro.org/t/does-lu [...] ds/87582/6
Mais évidemment je n'ai pas testé ni même spécialement détaillé la réponse, vu que je n'ai pas cette config…

J'avais le même "problème" avec mon ancienne config Manjaro, je n'ai jamais réussi a la configurer normalement pour de déblocage de LUKS.
Et finalement j'ai fini par retenir le mot de passe en avec le clavier Qwerty, j'ai du coup j'ai lâcher l'affaire.
Je sent que ce message va beaucoup aider  

Il faut que je regarde comment faire en "manuel", mais comme j'ai vu l'option j'ai fais exactement comme j'avais fais sous debian/ubuntu, coché l'option quoi.
Je vais voir en manuel comment faire en lisant un peu des infos.

Pour l'instant c'est que je fais, mais ce n'est pas top.
Par ce que du coup par facilité le mdp général c'est le même que le root (étant le seul utilisateur voilà quoi ), et bon saisir un coup en qwerty un coup en azerty c'est pas l'idéal.
Même si maintenant je sais taper mon mdp en qwerty aussi.

EDIT: dans les autres "défauts" de manjaro, de base il n'y a pas d'écran de chargement.
Que ça soit sur ma vm ou mon pc portable, la phase de boot c'est un écran "noir". Je vais voir comment mettre plymouth ou autre, mais du coup ça enlève encore une fois sur le côté clef en main.

Dans le genre "c'est l'utilisateur qui doit s'adapter à la machine et pas l'inverse", c'est pas mal    

Bon, j'ai tenté à la main avec un partitionnement manuel.

Je créais donc une partition /boot de 1go en ext4 que je mets en amorçable.
Je créais ensuite une partition /ext4 chiffré.
Je rajoute un swap chiffré

Je lance l'installation ==> ça "plante" juste après le partitionnement.
Par "plante" l'installeur disparait donc je pense qu'il y a une erreur mais là je ne pige pas...

Clairement le côté stable pour l'instant je ne le croise vraiment pas.

EDIT; c'est le swap chiffré le pb.
J'ai refais le partitionnement sans le swap, juste avec /boot et / et cette fois ça installe...

EDIT2; une fois l'installation faite comme ça, il me demande 2 fois le mot de passe...
Donc clairement pas pratique, ok c'est enfin en en azerty, mais saisir 2 fois le mot de passe ce n'est pas pratique.
Et le temps de boot est clairement long.

Donc je veux bien être patient et creuser, mais jusque là je suis très loin du côté "stable" frendly qu'il m'a été venté.

EDIT3: il faut que je teste ça pour l'histoire du mdp:
https://forum.manjaro.org/t/asked-t [...] word/31267

A voir si le temps s'améliore. Il restera à mettre un truc un peu plus cosmétique si possible pour l'écran du mdp et le chargement.

Perso je conseille ce schéma de partitionnement :

- une partition "/" qui contient le système (et le répertoire /boot),
car une partition /boot séparée n'a pas beaucoup de sens de nos jours, les gens installent en général qu'un seul OS sur leur PC,
et si on veut tester plusieurs distributions linux : il est beaucoup plus simple de créer des machines virtuelles (virtualbox, qemu)

- une partition swap qui fait la taille de la mémoire vive (ou légèrement plus)
---> en sachant qu'elle sera très peu utilisée vu les PC avec 8 ou 16 Go de ram,
sauf si énorme fuite mémoire d'un logiciel bogué (ça m'est arrivé avec le bureau plasma, dû à un bug de Qt5) qui entraînera l'utilisation du disque dur
comme mémoire vive d'appoint
---> une alternative à la partition swap est de faire comme windows : créer un ou plusieurs fichiers swap de plusieurs Go via systemd plutôt qu'une partition swap

- une partition "/home"

et pas de chiffrement des partitions, que du classique avec du ext4, comme ça pas de souci,
si on veut malgré tout chiffrer (PC portable utilisé en entreprise, des risques de vol) alors bien suivre le wiki d'archlinux (ou de manjaro) sur le chiffrement,

et ne chiffrer que la partition /home ou une partition supplémentaire dédiée à des données sensibles, inutile de chiffrer la partition système ou une partition "/home" qui contiendrait que des vidéos de vacances ou des vidéos de série télé, le pirate s'intéressera surtout
aux fichiers produits par l'utilisateur (bureautique, mails, carnet d'adresse, rapports confidentiels de son entreprise, base de données comptable, code source d'un logiciel sensible, schémas d'un produit innovant), pas les fichiers bibliothèques *.so du système.

On peut s'entrainer à installer linux et les différents scénarios de partitionnement et de chiffrement en utilisant une machine virtuelle, une fois la technique bien en main on peut alors installer tout ça sur une machine physique,
c'est comme ça que j'avais fait pour tester archlinux, avant de l'installer sur un PC physique.

Par curiosité j'ai testé une install dans une vm, avant que tu édites ton message burn2.
J'ai juste mis une petite partition en clair pour /boot, et une chiffrée pour la racine, et j'obtiens le résultat que tu décris dans tes edits.
Avec deux fois le mot de passe donc, en azerty les deux, ce qui m'a un peu surpris : je m'attendais à ce que le premier (venant de grub) soit en qwerty, comme dans le cas d'un chiffrement complet.
 
J'ai trouvé ça bien rapide comme install en tout cas, significativement plus rapide qu'ubuntu il me semble.
J'ai trouvé aussi que l'installeur était pas si mal, même si ces installeurs user-friendly ça manque toujours d'infos, particulièrement quand on veut faire du chiffrement, mais c'est pareil chez ubuntu, et ailleurs j'imagine.
Pour les deux mots de passe ça doit pas être grand chose à faire, une petite manip au niveau de grub simplement, et de même pour l'écran de chargement.
Au final en première impression je serais pas trop sévère personnellement.
 
Je pense que pour avoir le swap chiffré, il aurait fallu mettre ça dans un lvm contenant le swap et la racine, et lui-même dans un conteneur luks.
C'est ce qu'on fait normalement, on ne met pas une partition primaire pour le swap.
Je testerai peut-être ça demain, ainsi que le chiffrement intégral pour voir.

Pour le temps d'installation je ne sais pas trop.
Pour le temps de boot ça me semble bien plus long qu'une ubuntu chiffrée par contre.
Mais la méthode de chiffrement est peut-être plus lourde.
(le cpu n'ayant pas les instructions AES ça peut expliquer la différence si les choix sont plus lourd).

Pour le paramétrage je vais voir ce que tu dis.

Je  suis sévère à cause du contexte, je remonte "juste" ce que je constate.
Je trouve dommage par rapport à ce qu'on annonce de manjaro d'en être encore là
Oui ça marche, oui si on reste sur le truc basique sans chiffrement ça va, mais c'est le cas depuis bien longtemps sur les distribs linux ça!
J'utilise les options fournies de l'installeur graphique et c'est là qu'on voit très rapidement les limites.
Personnellement je ne peux pas trouver acceptable le problème du mdp qwerty quand on coche " tout chiffrer" (option dispo dans l'installeur, ce n'est pas un truc caché ni rien). Ok la différence c'est dans le fait de chiffrer le boot ou pas comparé aux autres distributions, mais dans ce cas il manque un choix. Si ce n'est pas possible d'avoir de l'azerty alors il faut le mentionner et proposer un choix différent.

Ce qui me choque c'est que même une debian pourtant à la renommée pas user frendly, réfractaire aux débutants est au final plus clef en main. Il faut que je reteste avec chiffrement pour vérifier à 100% que ça fonctionne sans rien faire pour voir mais ça reste franchement surprenant.

Par exemple pourquoi ne pas mettre d'écran de chargement? Toutes les distributions avec bureau graphique le font. Pourquoi ce choix?

Si je suis "critique" c'est justement parce que lorsqu'on vend un truc pour débutant, et surtout que certains ici ne mettent pas les formes pour parler de la stabilité/limites de la distribution donc je m'attends à un truc parfait.
Pour rappel ce que dit manjaro

Or pour l'instant clairement on est à des années lumières de ce qu'apporte Ubuntu par exemple, et même potentiellement de Debian de base ce qui est pour moi un comble.
Si j'arrive au bout de la conf ça ne va pas me bloquer pour l'utiliser si j'en suis satisfait, mais vu comment c'est vendu et la manière de parler sèche de certains ici, je remonte de la même manière les infos.

D'ailleurs petite question, sous debian gnome, lors des mises à jour, l'installation se faisait au final au reboot. c'est la première fois que je vois ça, et c'est au contraire un point fort, car pas possible d'éteindre le pc en cours de mise à jour. (comme c'est le cas partout avec les gestionnaire de maj qui tourne sur la session utilisateur).
Je pensais que c'était gnome qui apportait ça, mais sous manjaro ce n'est pas le cas.

Du coup ça provient d'ou cette bonne idée?

 
Tu vas sur le forum d'ubuntu : tu verras que beaucoup d'utilisateurs galèrent quand même dès le moindre imprévu, ce n'est pas une distribution qui garantit le "zéro soucis",
 
ça marche dans un premier temps quand il s'agit d'installer la distribution grâce à l'assistant d'installation, mais tôt ou tard l'absence de connaissances linux, du shell, le manque de discipline dans la lecture du wiki chez le débutant finit par être un handicap, un frein, avec au final des mécontents, des râleurs.
 
Le vrai noob/débutant il sera plutôt heureux chez du apple, google, avec un OS fermé, livré en bundle avec le matériel conçu pour l'OS, sans possibilité d'upgrade (ou alors c'est très encadré par apple, pour garantir le "zéro souci" ).
 
Que ce soit avec manjaro ou ubuntu il faudra à un moment mettre les mains dans le camboui et chercher à comprendre comment marche les rouages de l'OS, pour être un peu plus autonome dans la résolution des problèmes (personnalisation du bureau, ajout d'un dépôt, créer son propre paquet, configurer xorg, sa carte graphique, faire en sorte que l'imprimante soit bien reconnue, le chiffrement des partitions etc...), sinon avoir un pote administrateur linux si on est vraiment bloqué.

Non mais je suis d'accord, mais je pars d'un postula simple et d'un installation simple.
Sur ubuntu 18.04, que j'ai installé très souvent,
je fais suivant suivant suivant et voilà.
Strictement aucun paramétrage spécifique à faire.
Les seules choses restantes étant donc d'installer compiz ou pas, et d'installer quelques logiciels si nécessaire. Bref de l'applicatif et thème de bureau.

Depuis la précédente LTS, ça fait longtemps que je n'ai plus eu à intervenir sur AUCUN des pcs ou je l'ai installé. Je fais les majs de temps en temps et ça roule. j'ai ça sur divers pc de génération différentes sans aucune modification spécifique à faire.

Si besoin de réinstaller car changement de ssd ou autre, c'est fait en moins de 4h reprise des données et conf logicielle inclue.
Là pour l'instant je suis très loin de ça, pour "juste" faire l'installation.

Tout ce que tu mentionnes reste du spécifique, un problème matériel, un installation de logiciel non prévu, c'est pareil pour toutes les distributions et c'est logique.
Moi je ne parle que de la base à savoir une installation avec ce qu'on me permet de faire.
Une installation clef en main, et une mise à jour (tant qu'on upgrade pas) 100% stable à faire les yeux fermées.
Pour l'instant sous debian/ubuntu LTS j'ai ça depuis plusieurs années.

Encore une fois ça ne sera pas bloquant pour moi, si ça me convient, il n'y a pas de raison que je ne continue pas avec manjaro.
Mais quand je vois ça, clairement je me pose la question sur le long terme avec le rolling release puisque déjà à un instant T je constate quelques bugs et paramétrage nécessaire.
Or rien ne me garantie que ce qui pour moi est l'usage basique (mais qui visiblement sort déjà du courant...) ne posera pas problème lors des upgrades vu que j'en suis déjà à réfléchir pour une installation à un instant T ou tout est freezé en croisant déjà quelques bugs.

Et c'est exactement ce que j'avais émis comme doute sur un autre topic, mais on m'a rassuré, manjaro c'est ultra stable, et aucun risque avec le rolling release.  (je réponds sur le meme ton que certains avait pris à l'époque ces personnes se reconnaîtront...)
Or là j'ai donc déjà réussi à faire planter l'installeur graphique en faisant une conf de partition à la main, ou à me retrouver avec un mdp qwerty en cochant "juste" une case dans l'installeur de base. Donc clairement la stabilité légendaire du rolling release pour l'instant je le sens pas trop et forcément j'ai des doutes sur le long terme.

Sur ce j'arrête le côté critique sèche, j'ai assez développé, je vais plutôt avancer sur l'installation/paramétrage et voir comment ça se comporte sur le long terme en pratique.
Pour l'instant il faut juste que j'arrive à faire le paramétrage qui me va bien, me note tout bien et une fois ça fait je pourrais suivre sur ce pc comment ça évolue sur plusieurs mois et si je croise ou pas des soucis suite aux upgrades.

La question est légitime, mais d’un autre côté, faut se rappeler qu’à part en France et en Belgique (pour l’AZERTY), et en Allemagne et en Suisse (pour le QWERTZ), tous les autres pays utilisent des claviers QWERTY, et les variantes locales ne changent pas le fait que la disposition des 26 lettres de base reste le QWERTY (je ne compte pas les quelques excentriques qui préfèrent les dispositions plus ergonomiques comme le BÉPO, le Dvorak, le COLEMAK, etc.). Donc, pourquoi s’embêter pour quatre pays réfractaires quand les ≈ 190 autres utilisent la même base commune ?

Pour ne pas ralentir le démarrage avec un truc aussi inutile que purement cosmétique ? Après, il y a des gens qui préfèrent ne pas avoir d’écran Plymouth (tiens, si tu veux le rajouter, tu as son nom). OK, chez les linuxiens, personne ne veut la même chose que tout le monde ; c’est pour ça que Linux ne remplacera jamais Windows sur les PC des Toulemonde (sauf si l’idée vient de MS) : par manque de volonté et de vision commune, chacun voulant rester dans son coin et sans avoir davantage d’ambition.

C’est Fedora qui a inauguré ça. Mais là encore, tu auras bien plus de critiques négatives envers ce système de mise à jour « à la Windows » (car elles ne sont donc appliquées et n’entrent en vigueur qu’après un redémarrage du système, rendant ce dernier inutilisable durant tout ce temps) que de louanges. Au contraire, le fait de pouvoir continuer à se servir du PC pendant qu’il se met à jour (hormis pour celles touchant au noyau) et avoir celles-ci appliquées immédiatement est justement acclamé depuis toujours comme un vrai avantage par rapport à Windows. Tu es donc une exception, sur ce point.

Je sais, mais ça ne reste pas une excuse valable, si tu proposes le choix dans toutes les configurations, que ça soit au boot du livecd, lors de l'installation tu t'attends à ce que ça marche, surtout quand tu vises le débutant.
Et j'avais cru comprendre que c'était une distribution développée en Australie/france et allemagne.
Donc il semble légitime de ne pas s'attendre à ce genre de défaut.

Mais bref, en soit ce n'est pas grave, juste qu'on sort de l'option clef en main quand une option peut avoir ce genre d'impact.
il aurait mieux fallut mettre un warning lorsque l'option est cochée et/ou laisser le choix de basculer avec un /boot non chiffré quand on est en clavier azerty.

AU final entre ça et le fait de devoir aller dans les options pour rajouter les traductions après installation, on se dit vraiment qu'en fait ce n'est pas fait pour toutes les langues au contraire de ce qu'ils essaient de mettre en avant.

Merci pour le nom mais je connaissais plymouth oui.
Heu tu parles de ralentir le démarrage? ALors ok je veux bien que sur un truc léger comme xfce ou autre, on puisse sortir ça, mais je suis désolé sur un truc lourd à charger comme gnome ou kde c'est du foutage de gueule là hein.
Le temps de chargement de plymouth je doute que ça soit réellement marquant... Surtout comparé au poids de ces bureaux à charger.

Encore une fois e nc'est pas grave, mais je doute qu'un utilisateur lambda trouve ça accueillant un mdp à saisir sur un terminal le tout en anglais total.
C'est justement comme ça qu'on maintient le préjugé de linux c'est que du terminal et pas user frendly.

Encore une fois on s'en fou, je rajouterais mon truc pas de soucis, juste que clairement je trouve que ça va à l'encontre de ce que vise manjaro. ET que encore une fois ça doit bien être la seule distrib "vendue" pour les débutants à faire ce choix là.
Même debian ne fait pas ce choix là.

ça a des avantages et des inconvénients. Dans mon cas perso, je préfère la mise à jour sur le bureau comme tu le dis, c'est juste que dans le cas d'un utilisateur lambda c'est au contraire mieux que la maj se fasse au reboot quand les mises à jour sont automatiques.
En effet si la maj se fait en arrière plan sur le bureau, il manque (du moins c'est ce que j'ai pu tester volontairement sous ubuntu) le fait de ne pas pouvoir éteindre son pc pendant la maj.

Donc en gros avec une maj auto en arrière plan si tu éteins ton pc tu flingues ton os... (c'est tout à fait possible sous ubuntu par exemple, je ne sais pas si des mécanismes pour éviter ça existent ailleurs)

Je ne dis pas que ça soit mon choix, je croyais juste que c'était un choix provenant de l'environnement "gnome" et du coup je m'étonnais ne le trouver que sous debian gnome. (de mémoire debian cinnamon ne fonctionne pas comme ça, donc je pensais vraiment que c'était dû à gnome)
Sous ubuntu LTs je ne l'ai pas ça ne me pose pas de soucis.
Je pense clairement que si c'était réalisable ça serait le genre d'option utile, comme ça chacun choisirait entre les deux.

Après en soit s'il est possible de bloquer l’arrêt de la machine en cours de mise à jour, alors ce n'est pas forcément nécessaire.

Bref en soit, ça n'en fait pas une mauvaise distribution pour autant, mais que du coup on s'éloigne clairement du userfrendly et individu lambda et que je trouve ça dommage vu l'effort fait pour rendre tout ça présentable/abordable.

Encore une fois rien d'insurmontable, mais personne ne mentionne ces points.

Sur les quelques boot que j'ai fait hier, certains étaient rapides (au moins autant qu'ubuntu au mieux de sa forme), certains assez lents effectivement.
Je n'ai pas mesuré, mais je dirais qu'entre les deux ça allait facile d'un facteur 3-4.
Je suppose que c'est à cause de l'ordre dans lequel systemd active les services, qui peut changer d'un démarrage à l'autre.
Une fois j'ai eu le défilement des activations (ok / ko), et pas mal de choses galéraient à se lancer effectivement.
 

J'en doute très fortement, à mon avis c'est exactement la même chose, mis à part la petite différence d'inclure /boot ou non, ce qui n'a rien à voir avec la méthode de chiffrement des données.
 

Ça, clairement, ça va pas. Surtout que le problème est connu depuis un moment au vu du topic cité dans un précédent post.
 

Peut-être pour se distinguer par un choix cosmétique à la con, comme le font la plupart des distribs orienté noob, au lieu d'être standard : c'est pas nouveau…

Pour moi avec les deux mdp c'était bien plus long.
genre après le mdp grub, j'ai genre presque 10s avant qu'il ne me demande le mdp pour le /
Et entre ces deux phases, je n'ai aucune ligne qui défile rien. sur le moment je me suis posé la question même d'un plantage.
Je pense vraiment qu'il y a une cause sur la manière de chiffrer (nombre de passe de Hash etc).

J'essaierais de prendre une vidéo pour que tu puisses voir, mais c'est clairement très long à vérifier le mdp au niveau du grub. (celui que je vais désactiver du coup)

Perso c'est plus sur le côté recompilation et disponibilité de paquets via AUR que c'est facile. Le côté doc bien fournie sur archlinux a son avantage ainsi que le volet rolling release.
Après les chiffrements, il y en a pas beaucoup AMHA qui utilisent ça comme tu le fais : jusqu'à chiffrer le swap ...
Debian / Ubuntu la critique que j'ai à faire : vieux paquets (je sais tu m'as déjà répondu dessus mais la modularité des versions est plus flex sur les bases arch) + long et pénible à recompiler si la version du paquet dispo dans les dépôts ne comprend pas la petite option que tu veux.

Oui tu as raison, le temps de boot dont je parlais dans mon précédent post commençait au second déchiffrement.
Personnellement, pour ce temps entre les deux déchiffrements, je penche pour un bug, puisque de toutes façons il n'a pas lieu d'être.
C'est pourquoi je ne le mentionnais même pas : pour moi c'est un bug à corriger.
 
Sinon je viens d'essayer une install en partitionnement manuel avec un swap et une racine dans un lvm, et je n'ai jamais réussi à la configurer, chiffrement ou pas    
Impossible de lui faire prendre en compte un groupe de volumes    
Du coup j'ai abandonné et j'ai lancé une install chiffrée par défaut pour voir (avec swap).
 

C'est le choix par défaut pour une install chiffrée sous ubuntu, et beaucoup se ramènent sur le forum ubuntu fr avec cette config.

C’est ce que je disais au début. La question de la fin était orientée du point de vue des devs. Mais oui : le lambda débutant, face à ça, va trouver ça naze.
 
Pour ce que j’en sais, le big boss de Manjaro (Philm) est allemand, oui.
 

Oui, on parle de quelques secondes au pire (et sur un SSD, tu dois même pas avoir le temps de le voir). Je veux dire que ce truc aura forcément un impact sur le temps de démarrage, aussi peu perceptible soit-il.

ça d'accord, mais à ce compte là le bureau c'est aussi du temps perdu, le thème aussi etc.

C'est un tout nécessaire pour la cohésion d'ensemble je trouve.
Mais bon pas grave.

Tu pourrais tester Fédora moi je la préfère à Manjaro.

Bon ben apparemment pour ça aussi il faut finasser, et en gros il faut passer en install cli : https://forum.manjaro.org/t/how-to- [...] ions/44173
C'est pour le coup que pour le côté user-friendly, on repassera !    
En gros, niveau chiffrement en tout cas, ça m'a l'air un peu bancal quand même…

Pour le clavier fr au niveau de grub ça a pas l'air si simple en fait, voire même pas du tout.
J'ai réussi à l'avoir en automatique à partir de la console grub (déjà en bricolant), mais pas au moment de rentrer le mot de passe de déchiffrement, qui est un cran plus tôt encore.
Les pistes pour avancer étaient bien pour partie contenues dans le post manjaro déjà cité (https://forum.manjaro.org/t/does-lu [...] ds/87582/5), mais elles sont surtout résumées dans cette discussion arch : https://wiki.archlinux.org/index.ph [...] ard_layout
Un type a essayé d'aller plus loin sur le forum arch en, sans succès, mais il cite d'autres liens et c'est pas inintéressant : https://bbs.archlinux.org/viewtopic.php?id=240739

Heu oui mais là clairement non pour deux raisons:
1) fédora c'est en général un bac à sable, on ne le prend clairement pas pour une stabilité reconnue.
Or je le rappelle c'est mon critère principal.  
2) la durée de vie d'une version c'est 6Mois, et mettre à jour tous les 6 mois c'est non. (ça veut dire gérer les régressions etc)
Ce n'est pas pour rien que je ne restais que sur des LTS. Je n'ai plus ce temps là.
 

C'est ce que je te disais, sur le topic au final ça finissait en "ça marche pas".
Pour l'instant je n'ai pas tenté d'aller plus loin.
 
Si le /boot n'est pas chiffré ce n'est pas forcément ultra grave. Après s'il y a une solution pourquoi pas, mais j'ai peur que ça ne pète un jour ou l'autre ou que je ne doive bidouiller en continu à chaque update de certains éléments en retombant en qwerty voir pire sans possibilité de saisir mon mdp.  
 
Je vais refaire des tests d'install en vm pour me faire une procédure et voir ce que j'arrive à faire.

Bah si tu mets un /boot séparé en clair, il suffit de virer la ligne qu'ils ont rajouté pour rien dans /etc/default/grub à la fin, pour que ça te vire la première demande de mot de passe :

Attention : j'ai vu qu'il y avait deux lignes comme ça : la première est celle présente par défaut vers le début du fichier, et elle est commentée.
La seconde est celle rajoutée par l'installeur manjaro, à la fin du fichier et non commentée : c'est celle -là qu'il faut virer.
 
Ensuite éventuellement adapter un peu la ligne

pour que ça t'affiche quelque chose quand ça boote (attention à laisser les infos relatives à la partition chiffrée, nécessaires sous arch/manjaro pour le déchiffrement après grub, lorsqu'on est encore dans le initramfs).

Oui mais reste le soucis du swap pas chiffré.
Bon en soit ce n'est pas un soucis car je n'aurais pas de donnée risquée dedans, et même il sera très peu voir pas utilisé mais bon...

Dans le swap il n'y a que des données binaires (contenu d'un bloc mémoire, les bits que manipulent un programme) non compréhensibles par un humain, donc normalement pas besoin de chiffrer le swap,

sauf si le hacker est un génie et sait exactement comment interpréter ces blocs mémoires, mais normalement ça va être du chinois pour le pirate lambda, lui ce qu'il cherche ce sont des fichiers classiques qui ont une valeur marchande, qu'il pourra revendre à un concurrent de l'entreprise qui a été piraté (texte, image, vidéos, fichier de clients, adresses emails pour faire du spam), c'est ce type de fichier qu'il faut chiffrer.

Pour le chiffrement du swap, il reste peut-être la possibilité de rajouter une partition après coup, une fois l'install faite, et de configurer son déchiffrement par fichier dans /etc/crypttab, comme on peut faire pour une partition de données.
Je n'ai jamais testé ceci dit, c'est à faire, car une partition de swap n'est pas une partition de données…

Sinon avec l'équivalent de l'install "net" en faisant tout en cli tout ça marche ou pas?
il faudrait que je teste voir ce que ça donne.

Oui il y a cette possibilité aussi effectivement, d'après les quelques topics manjaro que j'ai vus l'install a l'air plus souple en cli niveau chiffrement.
Et puis sinon, si on n'utilise pas l'hibernation, il y a la possibilité de ne pas mettre de partition de swap et d'utiliser systemd-swap : https://wiki.archlinux.org/index.php/Swap#systemd-swap
Par ailleurs, pour le chiffrement d'une partition swap après coup, ça a bien l'air possible, avec diverses options : https://wiki.archlinux.org/index.ph [...] encryption

Pour revenir sur le côté user friendly de manjaro, c'est surtout user-friendly par rapport à une arch-linux. La distribution n'a pas du tout l'ambition d'être aussi facile à utiliser qu'un Ubuntu (ne serait-ce que par le côté rolling-release).
 
Par contre, comparé à un Arch elle viens clé en main, et ça ça la rends vraiment plus pratique !

@burn2 : pour le clavier azerty en early boot, je pense avoir trouvé un tuto correct incluant les cas efi et bios (j'avais plus ou moins trouvé pour efi sur le wiki arch, mais pas pour bios jusque-là) : https://cryptsetup-team.pages.debia [...] -boot.html
C'est à la section 5. Je ne l'ai pas encore testé, mais je pense que je le ferai, je te mets le lien au cas où tu voudrais essayer.
En tout cas c'est ça : pour avoir l'azerty en early boot, il faut se faire une image customisée de grub et l'installer à la main, pas moyen d'y couper.

Merci pour l'info.
Je pense clairement qu'il vaut mieux partir sur un chiffrement "juste" du / et pas du boot.
 
Parce que la compilation de grub, je sens bien le truc qui va péter un moment ou l'autre après un upgrade et ou plus rien ne sera bootable... Genre de chose que je ne peux pas me permettre. Donc je pars plus sur un /boot non chiffré.

Bon pour l'instant c'est un fail.
J'ai testé en vm et ça ne marche pas.
Voilà ce que j'ai fais:
1) install plymouth
2) modif de grub dans /etc/default/grub pour enlever la ligne
GRUB_ENABLE_CRYPTODISK=y
3) Rajout de "splash" dans la ligne "default"
4) sudo mkinitcpio -p linux54
5) sudo grub-update

Au final je n'ai plus le premier mdp à taper, mais pas de plymouth.
ET le temps de boot me semble quand même anormalement long entre le grub et le mdp pour déverrouiller "/" .
En gros on a toujours ce temps ou le CPU est au taquet pendant quelques secondes AVANT le mdp.
Et là c'est une vm sur un ryzen 2600 donc ça va quand même quoi..

EDIT: ici je lis qu'au final ce n'est plus plymouth mais bootplash qu'il faut?
https://forum.manjaro.org/t/help-to [...] th/66819/5

J'avais pas vu la notice en haut de la doc...
https://wiki.manjaro.org/index.php?title=Plymouth

ça devrait être plus viisible je trouve... bon allez on part sur bootsplash et on recommence.
Mais pour le coup pas de doc sur le wiki de manjaro à priori.

EDIT2: les dépôts ne semblent plus répondre?

Bon, j'ai du mal à saisir là.
J'apprends au final que bootplash est déprecated maintenant.
j'avais commencé à faire ça
https://blog.seboss666.info/2019/05 [...] r-manjaro/
J'ai bien l'écran de chargement, mais impossible de saisir le mdp donc ça reste bloqué durant le chargement.
Et dans les commentaires on apprend qu'au final c'est fini bootsplash?

Bon c'est quoi alors au final qu'il faut utiliser??? C'est vraiment pas à jour les docs.

EDIT: je repars sur plymouth au final, je pars de la doc de base d'arch, c'est plus sûr...

EDIT2: c'est bon j'ai réussi!
Donc il faut:
Installer plymouth + le thème qu'on veut
Ensuite on modifie /etc/mkinitcpio.conf pour remplacer "encrypt" par:
plymouth plymouth-encrypt
sudo mkinitcpio -p linux54

On configure le thème qu'on veut de plymouth.

Sur le grub on fait bien ce que j'avais fait:
2) modif de grub dans /etc/default/grub pour enlever la ligne
GRUB_ENABLE_CRYPTODISK=y
3) Rajout de "splash" dans la ligne "default"
sudo grub-update

Et c'est bon, j'ai bien un écran de chargement et un mdp à saisir en mode graphique.