Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 27/03/2023, à 18:03

geole

Installation atypique d'un serveur 22.04 en EFI.

Bonjour.
Il y a quelques mois, j'avais voulu découvrir le logiciel  d'installation  de serveurs en version EFI.
J'avais fait une petite documentation
La version 22.04.2 étant maintenant disponible, j'ai retenté. Mais toujours le même problème.

Alors, j'ai pensé à faire un peu autrement à base de RAIDS10.  ( Pour la performance).   
Voici ma réalisation faite sur un seul disque.   Mais le principe serait le même pour les utilisateurs disposant de quatre disques.
1) Booter avec le support d'installation de la version 22.04.2 standard
2) Mettre l'iso dans un répertoire ventoy
3) Booter et  prendre le choix "autre chose".
3) Avec gparted, initialiser le/les disque(s)
     Une table de partition GPT
     Une partition  en FAT32 de boot EFI . Environ 100  Mo.
     Une partition de boot standard  en EXT4.    Environ 1,5 Go
     Une partition contenant le logiciel   environ 20 Go.
     Une partition EXT4 contenant le reste de l'espace libre du disque.
4) Installer le logiciel MDADM  bêtement absent.
5) Fabriquer les deux RAIDS.
       Cette étape est très longue. Elle est certainement optimisable.
6) Installer  ubuntu en lui précisant:
      D'utiliser la partition de boot standard sur le point de montage /boot
      D'utiliser la partition efi prévue sur le point de montage /boot/efi
      D'utiliser le petit RAID sur le point de montage /
      D'utiliser le gros RAID sur le point de montage /media/Data ( j'ai oublié!).
7)  Traitement après installation.
  Si vous avez  pris l'option d'installer avec la commande ubiquity -b, l'installation  devrait se finir sans problème mais sans possibilité de booter.
  Si vous avez cliqué sur l'icône d'installation automatique, l'installation va se planter au moment de la création des fichiers de boot.
Pas de panique:  Faire un chroot ou son équivalent en mode graphique
    Installer d'abord MDADM puis le grub et  générer et quitter.
8)  Dans la nouvelle instance qui met en route, il ne reste qu'à installer l'application tasksel puis les services  souhaités.
Remarque, La documentation d'installation de ces services n'est pas tout à fait exacte pour la version 22.04.  J'y ai  mis un ou deux ajouts, mais il y en aurait plus à faire,  en particulier pour KVM.
9) Il reste toute la partie réseau, peut-être la plus importante. Elle se sera pas traitée.


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#2 Le 27/03/2023, à 18:04

geole

Re : Installation atypique d'un serveur 22.04 en EFI.

Les scripts d'installation.

sudo mdadm --create /dev/md10 --level=10  --raid-devices=4 /dev/sdc[3-6] 
sudo mdadm --create /dev/md20 --level=10  --raid-devices=4 /dev/sdc[7-9] /dev/sdc10
sudo mkfs.ext4 /dev/md10
sudo mkfs.ext4 /dev/md20

mke2fs 1.46.5 (30-Dec-2021)
En train de créer un système de fichiers avec 10477056 4k blocs et 2621440 i-noeuds.
UUID de système de fichiers=b9c1881f-a0b5-4fe3-b5ea-eb3d4567cfec
Superblocs de secours stockés sur les blocs : 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624

Allocation des tables de groupe : complété                            
Écriture des tables d'i-noeuds : complété                            
Création du journal (65536 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

mke2fs 1.46.5 (30-Dec-2021)
En train de créer un système de fichiers avec 50512896 4k blocs et 12632064 i-noeuds.
UUID de système de fichiers=ba461a6f-4066-449c-8043-55926fef8671
Superblocs de secours stockés sur les blocs : 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872

Allocation des tables de groupe : complété                            
Écriture des tables d'i-noeuds : complété                            
Création du journal (262144 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété 
sudo mdadm --detail /dev/md10
/dev/md10:
           Version : 1.2
     Creation Time : Fri Mar 24 19:58:52 2023
        Raid Level : raid10
        Array Size : 41908224 (39.97 GiB 42.91 GB)
     Used Dev Size : 20954112 (19.98 GiB 21.46 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Fri Mar 24 20:04:20 2023
             State : clean, resyncing 
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

            Layout : near=2
        Chunk Size : 512K

Consistency Policy : resync

     Resync Status : 13% complete

              Name : p:10  (local to host p)
              UUID : d9442342:aaf72e05:5793a60e:5ed333e4
            Events : 8

    Number   Major   Minor   RaidDevice State
       0       8       35        0      active sync set-A   /dev/sdc3
       1       8       36        1      active sync set-B   /dev/sdc4
       2       8       37        2      active sync set-A   /dev/sdc5
       3       8       38        3      active sync set-B   /dev/sdc6

====> Trente minutes pour synchroniser MD10  puis  3 heures pour MD20.
et de mémoire

apt install mdadm
grub-install
update-initramfs -u - -all
update-grub

Car j'en ai un peu bavé pour cette structure de boot.
1)  Initialement: Un seul fichier de boot en efi  qui pointait bien sur le raids. Mais au boot, le grub se plantait. Mon analyse était que le RAIDS n'était pas monté.
2) Maintenant:  Avec deux partitions de boot, tout  fonctionne.
3) La suite: Installer la totalité du logiciel de boot dans la partition EFI. D'où la présence d'une grosse partition de boot EFI, actuellement vide.
    Il semble impossible d'utiliser la même partition pour y installer les données du répertoire /boot et du répertoire /boot/efi.
     L'installateur actuel refusant de mettre /boot dans une partition FAT32 et le bios refusant de booter dans une partition EXT4.
     La solution est donc à faire après l'installation  et peut-être en mode chroot.

Dernière modification par geole (Le 28/03/2023, à 17:59)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#3 Le 27/03/2023, à 18:04

geole

Re : Installation atypique d'un serveur 22.04 en EFI.

Le fonctionnement.

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.2 LTS
Release:	22.04
Codename:	jammy
 systemd-analyze time
Startup finished in 5.439s (firmware) + 24.006s (loader) + 10.109s (kernel) + 33.476s (userspace) = 1min 13.031s 
graphical.target reached after 2min 33.995s in userspace
systemd-analyze blame | head -20
1min 34.330s mysql.service
1min 30.220s nmbd.service
     57.131s postfix@-.service
     41.921s postgresql@14-main.service
     34.219s snapd.service
     31.198s udisks2.service
     27.364s networkd-dispatcher.service
     18.765s gpu-manager.service
     16.586s ModemManager.service
     15.727s apache2.service
     14.140s cups.service
     12.022s NetworkManager-wait-online.service
     11.733s dev-md10.device
     11.396s user@1000.service
     11.035s gdm.service
      9.057s named.service
      8.580s fwupd-refresh.service
      8.350s systemd-journal-flush.service
      7.068s dev-loop7.device
      6.480s dev-loop8.device
df -htext4
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/md10           40G     13G   25G  35% /
/dev/sdb7          2,0G    147M  1,7G   9% /boot
/dev/md20          187G     28K  178G   1% /media/Data
sudo mdadm --examine /dev/md10
sudo mdadm --detail /dev/md10
mdadm: No md superblock detected on /dev/md10.
/dev/md10:
           Version : 1.2
     Creation Time : Fri Mar 24 19:58:52 2023
        Raid Level : raid10
        Array Size : 41908224 (39.97 GiB 42.91 GB)
     Used Dev Size : 20954112 (19.98 GiB 21.46 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Mon Mar 27 19:18:42 2023
             State : active 
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

            Layout : near=2
        Chunk Size : 512K

Consistency Policy : resync

              Name : p:10
              UUID : d9442342:aaf72e05:5793a60e:5ed333e4
            Events : 26

    Number   Major   Minor   RaidDevice State
       0       8       19        0      active sync set-A   /dev/sdb3
       1       8       20        1      active sync set-B   /dev/sdb4
       2       8       21        2      active sync set-A   /dev/sdb5
       3       8       22        3      active sync set-B   /dev/sdb6
lsblk -fe7 /dev/sdb
NAME     FSTYPE         FSVER LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb                                                                                         
├─sdb1                                                                                      
├─sdb2   vfat           FAT32 USBEFIA   E736-D8EE                             112,1M     9% /boot/efi
├─sdb3   linux_raid_mem 1.2   p:10      d9442342-aaf7-2e05-5793-a60e5ed333e4                
│ └─md10 ext4           1.0             b9c1881f-a0b5-4fe3-b5ea-eb3d4567cfec   24,1G    33% /
├─sdb4   linux_raid_mem 1.2   p:10      d9442342-aaf7-2e05-5793-a60e5ed333e4                
│ └─md10 ext4           1.0             b9c1881f-a0b5-4fe3-b5ea-eb3d4567cfec   24,1G    33% /
├─sdb5   linux_raid_mem 1.2   p:10      d9442342-aaf7-2e05-5793-a60e5ed333e4                
│ └─md10 ext4           1.0             b9c1881f-a0b5-4fe3-b5ea-eb3d4567cfec   24,1G    33% /
├─sdb6   linux_raid_mem 1.2   p:10      d9442342-aaf7-2e05-5793-a60e5ed333e4                
│ └─md10 ext4           1.0             b9c1881f-a0b5-4fe3-b5ea-eb3d4567cfec   24,1G    33% /
├─sdb7   ext4           1.0   GRUBUSBB  4da8d84e-5a4e-48d2-aefa-f532bb59bd95    1,6G     8% /boot
├─sdb8   vfat           FAT32 GRUBFAT32 0CE7-7793                                 2G     0% /media/a/GRUBFAT32
├─sdb9   linux_raid_mem 1.2   a:20      437c98b2-754f-cc2a-aead-e4ff8fb8ddec                
│ └─md20 ext4           1.0             bdc1b81a-1bbf-4b2a-9b20-add5808e6f5d  177,1G     0% /media/Data
├─sdb10  linux_raid_mem 1.2   a:20      437c98b2-754f-cc2a-aead-e4ff8fb8ddec                
│ └─md20 ext4           1.0             bdc1b81a-1bbf-4b2a-9b20-add5808e6f5d  177,1G     0% /media/Data
├─sdb11  linux_raid_mem 1.2   a:20      437c98b2-754f-cc2a-aead-e4ff8fb8ddec                
│ └─md20 ext4           1.0             bdc1b81a-1bbf-4b2a-9b20-add5808e6f5d  177,1G     0% /media/Data
└─sdb12  linux_raid_mem 1.2   a:20      437c98b2-754f-cc2a-aead-e4ff8fb8ddec                
  └─md20 ext4           1.0             bdc1b81a-1bbf-4b2a-9b20-add5808e6f5d  177,1G     0% /media/Data
sudo mdadm --examine /dev/sdb[3-6] |  grep -E "sdb|Update Time|Events"

/dev/sdb3:
    Update Time : Mon Mar 27 19:33:18 2023
         Events : 25
/dev/sdb4:
    Update Time : Mon Mar 27 19:33:18 2023
         Events : 25
/dev/sdb5:
    Update Time : Mon Mar 27 19:33:18 2023
         Events : 25
/dev/sdb6:
    Update Time : Mon Mar 27 19:33:18 2023
         Events : 25
tasksel --list-tasks
i desktop	Debian desktop environment
i gnome-desktop	GNOME
u xfce-desktop	Xfce
u gnome-flashback-desktop	GNOME Flashback
u kde-desktop	KDE Plasma
u cinnamon-desktop	Cinnamon
u mate-desktop	MATE
u lxde-desktop	LXDE
u lxqt-desktop	LXQt
i web-server	web server
i ssh-server	SSH server
i laptop	laptop

Le regroupement des deux partitions de boot en une seule partition FAT32.
Voila le principe.
1) Démonter la partition EFI et la remonter ailleurs.

umount  -v /boot/efi
mkdir /EFI
mount -v /dev/xxxx /EFI

2) Transférer les données de boot standard dans la partition de boot EFI. Pendant cette opération les liens symboliques vont être perdus...  Mais ils semblent ne servir nulle part.

cp -rv /boot/* /EFI
umount -v /boot
umount -v /EFI

3) Modifier le fichier /etc/fstab: Supprimer le montage de la partition de boot standard et  modifier le UUID de la partition EFI si ce n'est plus la même partition.
4) Monter la partition de boot.

mount -av

5) Réinstaller le logiciel de boot   éventuellement sans mettre à jour la NVRAM  en précisant que le point de montage est au premier niveau et plus au second.

sudo grub-install /dev/xxx --no-nvram --efi-directory=/boot  --target=x86_64-efi 

Dernière modification par geole (Le 28/03/2023, à 17:58)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#4 Le 16/05/2023, à 14:47

Coeur Noir

Re : Installation atypique d'un serveur 22.04 en EFI.

C'est quoi l'intérêt de monter un système en RAID ?

Au boulot - dans un contexte particulier - ce que je constate sur les machines serveurs fournies par divers prestataires, c'est :
⋅ des disques en RAID pour les données, les stockages,
⋅ des supports distincts pour les systèmes, pas en RAID.

Si un disque système flanche, suffit de remplacer CE disque par un qui contient déjà le même système, pas de longue reconstruction du RAID derrière.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#5 Le 16/05/2023, à 15:02

geole

Re : Installation atypique d'un serveur 22.04 en EFI.

Un particulier peut disposer de deux disques (voir plus) et avoir le droit à une installation automatique facile en RAID y compris pour son logiciel.


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#6 Le 16/05/2023, à 15:23

Coeur Noir

Re : Installation atypique d'un serveur 22.04 en EFI.

Pas d'accord : le système tu le sors de l'équation RAID, c'est beaucoup plus prudent, le jour où tu as des pépins ou des maintenances à faire dans ta grappe RAID tu seras content que le système n'en fasse pas partie.
C'est plutôt heureux que l'installateur ne le propose pas.
Car, au pire, c'est terriblement simple de remplacer un disque « indépendant » qui contient un système, par un autre disque contenant un système ( ou le même, préalablement copié, sauvegardé, pré-configuré. )

Le but d'un RAID c'est la disponibilité continue et à long terme des données, en prévention des morts de disques.

Ce qui peut servir, imaginons qu'on a trois disques dans la machine :
⋅ sur chacun d'eux une grande partition ( de taille identique ) qui feront partie d'une même grappe RAID ;
⋅ sur chacun d'eux une petite partition, qui ne font pas partie d'un RAID ;
⋅ chaque petite partition contient un système, prêt à l'emploi et déjà configuré.

→ de cette façon, le jour où tu as un disque en panne MAIS pas de disque de remplacement sous le coude pour réparer ton RAID,
tu as quand même ton OS disponible sur chaque disque restant, sans besoin de reconstruction de RAID pour la partie OS.

Dernière modification par Coeur Noir (Le 16/05/2023, à 16:09)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#7 Le 16/05/2023, à 17:25

jplemoine

Re : Installation atypique d'un serveur 22.04 en EFI.

Au boulot, on utilise du RAID6 : le système et les données sont dessus mais il y a 8 disques (dont  2 de secours) pour en faire un visible par le système.
Si j'ai bien compris, La baie neutralise le disque  en panne  et le remplace par un des disques de secours puis recalcule son contenu grâce au système RAID.
Mais pour un particulier (ou une PME) qui utiliserait un RAID, je suis d'accord avec "Coeur Noir" : le système sur une disque classique (avec sauvegarde) et les données sur un RAID.


Membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre)
- En pro, après 20 ans de développement, administrateur Linux / Unix depuis Avril 2019.
- En privé, sous Ubuntu-Xubuntu depuis 2009.

Hors ligne

#8 Le 16/05/2023, à 17:46

geole

Re : Installation atypique d'un serveur 22.04 en EFI.

Mais lorsqu'on achète au appareil    qui a une possibilité RAIDS, c'est tout simplement stupide de ne pas mettre le logiciel dans du RAID.
Si le seul disque qui  contient  le logiciel  tombe en panne, les données restent inaccessibles tant que ce n'est pas réparé.
D'autre part, je sais que d'autres personnes du forum pensent que le logiciel doit être  installé dans du RAID10 afin qu"il soit un peu moins lent au fonctionnement.

Si vous avez lu/survoler la discussion qui m'a pensé à faire cet aide mémoire, ce n'est pas triste. Ubuntu RAID EXT4 n'en sort pas grandi.
Mais je ne pratique pas (encore) BTRFS ou ZFS.

Dernière modification par geole (Le 16/05/2023, à 17:48)


Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit,  utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir  https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248

Hors ligne

#9 Le 16/05/2023, à 17:54

bruno

Re : Installation atypique d'un serveur 22.04 en EFI.

J'irai plus loin : un particulier n'a pas besoin de RAID (coucou les marchands de NAS avec x disques wink )
La fausse idée que cela sécurise les données, ou pire que c'est une sauvegarde a la vie dure…

Le RAID est destiné à la tolérance aux pannes des disques et à la haute disponibilité, pas à autre chose. Et pour cela il faut avoir le système et les données sur une grappe RAID. L'objectif est que lorsqu'un disque tombe en panne le système puisse continuer à fonctionner pendant plusieurs heures, voire plusieurs jours le temps que l'on trouve un  créneau  où la réparation n'impactera pas la production.

Hors ligne

#10 Le 16/05/2023, à 22:00

Coeur Noir

Re : Installation atypique d'un serveur 22.04 en EFI.

Geole, ça n'est pas parce qu'une chose est possible que cette chose est souhaitable, partout, pour tout le monde.

Un particulier + du RAID = catastrophe assurée, tôt ou tard, puisque pas d'outils conviviaux pour gérer les incidents.
Quand on voit déjà la difficulté à faire comprendre les notions de base ( montage, partitions, système de fichiers, droits… ) je suis sceptique quant à proposer RAID « par défaut » dès l'installation.
Or gérer RAID implique de l'aise à ces sujets préalables, et d'autres, et de l'aise au terminal.

Le RAID est destiné à la tolérance aux pannes des disques et à la haute disponibilité, pas à autre chose
Oui ↑ c'est terriblement mieux dit que ↓
Le but d'un RAID c'est la disponibilité continue et à long terme des données, en prévention des morts de disques.

Si le seul disque qui  contient  le logiciel  tombe en panne…
Bah relis ce que je propose :
⋅ chaque petite partition contient un système, prêt à l'emploi et déjà configuré.
(…)
tu as quand même ton OS disponible sur chaque disque restant, sans besoin de reconstruction de RAID pour la partie OS.

C'est affaire de contexte : à moi ça paraît plus simple de dédier 1 ou 2 petits disques au système seul, si la panne a lieu par là, j'enlève le 1 en panne et je mets le 2 sain à la place… 5 minutes top chrono, pas de commandes à passer.
Et à partir du moment où vous avez un système serveur qui vous va bien → image iso ! À garder sous le coude, au cas où.

Allez au pire, une grappe RAID dédiée aux petites partitions système - mais pas tout ( syst. + data ) dans le même RAID parce que ça prendrait beaucoup plus de temps en reconstruction, le cas échéant.
Et pendant une reconstruction, ne comptez pas vous servir du système « normalement », il est forcément ralenti…

Enfin surtout, la sagesse c'est d'agir avec une méthode qu'on maîtrise : le jour où un disque tombe en panne, ça sera forcément à un moment où on était déjà en train de se prendre la tête à propos d'un autre pépin, c'est toujours comme ça, la loi de l'emmerdement maximal.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne