<p dir="ltr">Bonjour Olivier,</p>
<p dir="ltr">Mes meilleurs vœux à toi également ;)</p>
<p dir="ltr">Le 4 janv. 2014 17:38, "Olivier Saraja" <<a href="mailto:olivier.saraja@gmail.com">olivier.saraja@gmail.com</a>> a écrit :<br>
><br>
> Bonjour,<br>
><br>
> J'ai résolu il y a deux jours mes soucis d'installation de Mint 16! Youpi!<br>
><br>
> Quelques remarques, des fois que ce soit utile pour d'autres:<br>
><br>
> * Mon ordinateur n'a pas du tout aimé que je désactive le SecureBoot: il a tenté de démarrer en "mode BIOS" un peu plus classique, mais il n'a pas su comment gérer les paramètres d'overclocking, a bloqué avant l'amorçage et m'a invité à entrer dans le Setup du BIOS pour résoudre ce point. Ne sachant quoi faire, je suis revenu au SecureBoot<br>

></p>
<p dir="ltr">Le SecureBoot est une option de l'UEFI, mais le désactiver ne passe pas forcément en boot BIOS.<br>
Par contre, il est possible que les paramètres d'overclocking ne soient pas partagés entre les deux mode de boot, ou que le BIOS ne le gère pas du tout.</p>
<p dir="ltr">> * Avec ce BIOS UEFI, on peut choisir son disque de démarrage sans plus de formalité, sans se soucier de leur montage en interne. Ainsi, c'est sur sdb que je démarre (mon SSD) et non sur sda (le HDD).<br>

></p>
<p dir="ltr">Ça devrait être le plus rapide. Et pas de délai dû a la mise en rotation des plateaux ;)</p>
<p dir="ltr">> * Lors de l'installation, j'ai (comme à chaque fois) utilisé la méthode d'installation personnalisée: j'ai détruit mon ancienne racine de 100 Go, et en ai créé deux autres à la place:<br>

> -250 Mo déclaré en partition de démarrage UEFI (sans préciser de répertoire d'amorçage: le logiciel de partitionnement ne le permettait pas)<br>
> -Le complément "système" déclaré en ext4, reformaté et monté en tant que /<br>
></p>
<p dir="ltr">C'est effectivement le plus simple. Au moins tu es en full EFI (boot PC et amorçage de l'OS).</p>
<p dir="ltr">La partition peut-être vu comme de type VFAT ou FAT32, mais mieux vaut ne pas passer dosfsck dessus (j'ai flingué la mienne comme ça).<br>
Elle doit être monté dans /boot/efi ; à vérifier dans /etc/fstab ou via un 'cat /proc/mounts'</p>
<p dir="ltr">> À l'époque de Linux Mint 14, les disques SSD étaient encore "frais" sur le marché, et je me rappelle avoir pas mal modifié mon /etc/fstab à la main pour minimiser les cycles d'écriture inutiles. Est-ce utile de modifier le fstab de nos jours, ou des mécanismes idoines ont-ils été injectés au niveau du noyau? Voici ce que j'avais noté pour ma configuration, à l'époque de nos discussions sur cette même liste:<br>

><br>
> SSD<br>
><br>
> formatage en ext4<br>
><br>
> / (15 Go)<br>
><br>
> dans le /etc/fstab: noatime (pour éviter d'écrire sur le disque la date du dernier accès en lecture lorsqu'il n'y a pas d'écriture), discard (pour le trim)<br>
><br>
> /home (105 Go)<br>
><br>
><br>
><br>
> HD<br>
><br>
> formatage en ext4<br>
><br>
> /swap 16 Go<br>
><br>
> /var/log (via Bind)<br>
><br>
> /data (multimedia, sauvegardes, archives)<br>
><br>
><br>
> tmpfs<br>
><br>
> tmpfs /tmp tmpfs defaults<br>
><br>
><br>
> Merci pour vos ultimes conseils :-)<br>
></p>
<p dir="ltr">Tout ça me semble bien.</p>
<p dir="ltr">Il y a des débats au sujet de la gestion du trim et de l'option 'discard'.<br>
Le noyau a beaucoup progressé en 3.0 et 3.1 ce qui rend difficile les comparatifs.<br>
L'une des alternative et de ne pas activer le discard dans fstab mais de programmer un cron journalier ou hebdo qui lance le trim sur le disque ou la partition (de mémoire).<br>
Si tu as des traitements qui créent et suppriment bcp de fichiers (ex : fichiers temporaires), le trim par job cron est préférable pour éviter que le noyau lance des trim à la chaîne et sature le SSD. Mais par contre risque d'avoir des pb si pas lancé assez souvent (quels pb ? ça je ne me rappelle plus :-/ ).<br>

Avec bcp de RAM ça me semble la meilleure solution, sinon il suffit d'un tmpfs en RAM pour éviter les écritures.</p>
<p dir="ltr">J'ai aussi passé le délai de commit à 600 sec (au lieu de 60 sec), pour réduire les écritures : mais je suis sur un onduleur. Et je fais des 'sync' quand je veux être sûr (ex : maj noyau avant reboot).</p>

<p dir="ltr">> Au moins la machine est fonctionnelle, et Linux Mint en édition MATE toujours aussi agréable à utiliser :-)<br>
><br>
J'ai parlé de ton cas sur la ML Ubuntu avec le mainteneur de MultiSystem sur l'impossibilité de booter sans UEFI.<br>
Cela pose des pb avec les clés USB live MultiSystem lors des install party notamment, et on se pose des questions sur le choix du bon support d'installation.<br>
Pourrais-tu faire un test ? Il te faudrait créer une clé bootable avec MultiSystem et une ISO (de préférence Ubuntu mais Mint fera l'affaire), et voir si le PC en UEFI amorce l'ISO.</p>
<p dir="ltr">MultiSystem : <a href="http://liveusb.info/dotclear/index.php?pages/install">http://liveusb.info/dotclear/index.php?pages/install</a></p>
<p dir="ltr">Merci d'avance !!</p>
<p dir="ltr">A+<br>
Régis</p>