Pages : 1
#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
En 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
En 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
En 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ébuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insé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
En 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ébuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insé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.
Ce compte ne servira plus : vous pouvez le supprimer si le coeur vous en dit...
Laissé par l'auteur pour historique.
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
En 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 )
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.
#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ébuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
Pages : 1