Habituellement l'installation du /boot se fait hors lvm=2E Mais depuis gru=
b2, =C3=A7a semble g=C3=A9rer le lvm=2E Debian utilise par d=C3=A9faut le g=
rub2=2E
L'id=C3=A9e du GRUB2 hors de lvm est il toujours d'actualit=C3=A9 ? Ou est=
il possible de l'utiliser sur du lvm ?
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fine=
s)=2E Quel peut =C3=AAtre le risque ?
Salut,<br><br>Habituellement l'installation du /boot se fait hors lvm=2E Ma=
is depuis grub2, =C3=A7a semble g=C3=A9rer le lvm=2E Debian utilise par d=
=C3=A9faut le grub2=2E<br>L'id=C3=A9e du GRUB2 hors de lvm est il toujours =
d'actualit=C3=A9 ? Ou est il possible de l'utiliser sur du lvm ?<br><br>J'u=
tilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines)=
=2E Quel peut =C3=AAtre le risque ?<br><br>Cdlt,<br>-- <br>Pat2
------UFE4DA2V3NUEJGCEHY7BKSN22B3JV3--
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Le 21/10/2019 à 18:46, Patg a écrit :
Habituellement l'installation du /boot se fait hors lvm. Mais depuis grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.
En effet.
L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il possible de l'utiliser sur du lvm ?
C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais il est aussi soumis à ses inconvénients et notamment une complexité supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible. Avec /boot hors LVM, GRUB pourra au moins charger le noyau et l'initramfs, procurant un système minimal permettant au moins de faire un diagnostic voire de réparer.
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). Quel peut être le risque ?
Qu'appelles-tu "partitions fines" ?
Le 21/10/2019 à 18:46, Patg a écrit :
Habituellement l'installation du /boot se fait hors lvm. Mais depuis grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.
En effet.
L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il possible de l'utiliser sur du lvm ?
C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais
il est aussi soumis à ses inconvénients et notamment une complexité
supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux
volumes logiques, tout démarrage est impossible. Avec /boot hors LVM,
GRUB pourra au moins charger le noyau et l'initramfs, procurant un
système minimal permettant au moins de faire un diagnostic voire de réparer.
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). Quel peut être le risque ?
Habituellement l'installation du /boot se fait hors lvm. Mais depuis grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.
En effet.
L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il possible de l'utiliser sur du lvm ?
C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais il est aussi soumis à ses inconvénients et notamment une complexité supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible. Avec /boot hors LVM, GRUB pourra au moins charger le noyau et l'initramfs, procurant un système minimal permettant au moins de faire un diagnostic voire de réparer.
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). Quel peut être le risque ?
Qu'appelles-tu "partitions fines" ?
Patg
------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Je pensais que le grub2 répondait aux problématiques d'avant. U n lvm en raid ne répond pas à ce problème de GRUB, donc. .. Il faut rester sur l'option sans lvm... Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le /boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça : https://wiki.archlinux.fr/LVM Le 21 octobre 2019 21:12:13 GMT+02:00, Pascal Hambourg .eu.org> a écrit :
Le 21/10/2019 à 18:46, Patg a écrit :
Habituellement l'installation du /boot se fait hors lvm. Mais depuis
grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2. En effet.
L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il
possible de l'utiliser sur du lvm ? C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais il est aussi soumis à ses inconvénients et notamment une comple xité supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible. Avec /boot hors L VM, GRUB pourra au moins charger le noyau et l'initramfs, procurant un système minimal permettant au moins de faire un diagnostic voire de réparer.
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions
fines). Quel peut être le risque ? Qu'appelles-tu "partitions fines" ?
-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté. ------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body>Je pensais que le grub2 répondait aux probl ématiques d'avant. Un lvm en raid ne répond pas à ce probl ème de GRUB, donc... Il faut rester sur l'option sans lvm.. .<br><br>Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le /boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça :<br><br><a href="https://wiki.a rchlinux.fr/LVM">https://wiki.archlinux.fr/LVM</a><br><br><div class ="gmail_quote">Le 21 octobre 2019 21:12:13 GMT+02:00, Pascal Hambourg < ;> a écrit :<blockquote class="gmail_ quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204 , 204, 204); padding-left: 1ex;"> <pre class="k9mail">Le 21/10/2019 à 18:46, Patg a écrit : <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br>Habituellement l'i nstallation du /boot se fait hors lvm. Mais depuis grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.<br></blockq uote><br>En effet.<br><br><blockquote class="gmail_quote" style="marg in: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex; ">L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou es t il possible de l'utiliser sur du lvm ?<br><br>C'est possible . /boot peut ainsi bénéficier des avantages de LVM. Mais <br> il est aussi soumis à ses inconvénients et notamment une complexi té <br>supplémentaire. En cas de problème qui empêche rait GRUB d'accéder aux <br>volumes logiques, tout démarrage est impossible. Avec /boot hors LVM, <br>GRUB pourra au moins charger le noya u et l'initramfs, procurant un <br>système minimal permettant au moins de faire un diagnostic voire de réparer.<br><br><blockquote class ="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px sol id #729fcf; padding-left: 1ex;">J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). Quel peut être le risque ?<br></b lockquote><br>Qu'appelles-tu "partitions fines" ?<br><br></pre></blockquote ></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mai l. Veuillez excuser ma brièveté.</body></html> ------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8--
Je pensais que le grub2 répondait aux problématiques d'avant. U n lvm en raid ne répond pas à ce problème de GRUB, donc. .. Il faut rester sur l'option sans lvm...
Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le /boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça :
https://wiki.archlinux.fr/LVM
Le 21 octobre 2019 21:12:13 GMT+02:00, Pascal Hambourg <pascal@plouf.fr .eu.org> a écrit :
Le 21/10/2019 à 18:46, Patg a écrit :
Habituellement l'installation du /boot se fait hors lvm. Mais depuis
grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.
En effet.
L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il
possible de l'utiliser sur du lvm ?
C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais
il est aussi soumis à ses inconvénients et notamment une comple xité
supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux
volumes logiques, tout démarrage est impossible. Avec /boot hors L VM,
GRUB pourra au moins charger le noyau et l'initramfs, procurant un
système minimal permettant au moins de faire un diagnostic voire de
réparer.
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions
fines). Quel peut être le risque ?
Qu'appelles-tu "partitions fines" ?
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté.
------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Je pensais que le grub2 répondait aux probl ématiques d'avant. Un lvm en raid ne répond pas à ce probl ème de GRUB, donc... Il faut rester sur l'option sans lvm.. .<br><br>Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le /boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça :<br><br><a href="https://wiki.a rchlinux.fr/LVM">https://wiki.archlinux.fr/LVM</a><br><br><div class ="gmail_quote">Le 21 octobre 2019 21:12:13 GMT+02:00, Pascal Hambourg < ;pascal@plouf.fr.eu.org> a écrit :<blockquote class="gmail_ quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204 , 204, 204); padding-left: 1ex;">
<pre class="k9mail">Le 21/10/2019 à 18:46, Patg a écrit : <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br>Habituellement l'i nstallation du /boot se fait hors lvm. Mais depuis grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.<br></blockq uote><br>En effet.<br><br><blockquote class="gmail_quote" style="marg in: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex; ">L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou es t il possible de l'utiliser sur du lvm ?<br></blockquote><br>C'est possible . /boot peut ainsi bénéficier des avantages de LVM. Mais <br> il est aussi soumis à ses inconvénients et notamment une complexi té <br>supplémentaire. En cas de problème qui empêche rait GRUB d'accéder aux <br>volumes logiques, tout démarrage est impossible. Avec /boot hors LVM, <br>GRUB pourra au moins charger le noya u et l'initramfs, procurant un <br>système minimal permettant au moins de faire un diagnostic voire de réparer.<br><br><blockquote class ="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px sol id #729fcf; padding-left: 1ex;">J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). Quel peut être le risque ?<br></b lockquote><br>Qu'appelles-tu "partitions fines" ?<br><br></pre></blockquote ></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mai l. Veuillez excuser ma brièveté.</body></html>
------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8--
------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Je pensais que le grub2 répondait aux problématiques d'avant. U n lvm en raid ne répond pas à ce problème de GRUB, donc. .. Il faut rester sur l'option sans lvm... Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le /boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça : https://wiki.archlinux.fr/LVM Le 21 octobre 2019 21:12:13 GMT+02:00, Pascal Hambourg .eu.org> a écrit :
Le 21/10/2019 à 18:46, Patg a écrit :
Habituellement l'installation du /boot se fait hors lvm. Mais depuis
grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2. En effet.
L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou est il
possible de l'utiliser sur du lvm ? C'est possible. /boot peut ainsi bénéficier des avantages de LVM. Mais il est aussi soumis à ses inconvénients et notamment une comple xité supplémentaire. En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible. Avec /boot hors L VM, GRUB pourra au moins charger le noyau et l'initramfs, procurant un système minimal permettant au moins de faire un diagnostic voire de réparer.
J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions
fines). Quel peut être le risque ? Qu'appelles-tu "partitions fines" ?
-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté. ------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body>Je pensais que le grub2 répondait aux probl ématiques d'avant. Un lvm en raid ne répond pas à ce probl ème de GRUB, donc... Il faut rester sur l'option sans lvm.. .<br><br>Pour la partition fine, j'ai vu ça dans le lien ci dessous indiquant que le /boot sur partition fine n'est pas recommandé. Mais j'ai pas creusé plus que ça :<br><br><a href="https://wiki.a rchlinux.fr/LVM">https://wiki.archlinux.fr/LVM</a><br><br><div class ="gmail_quote">Le 21 octobre 2019 21:12:13 GMT+02:00, Pascal Hambourg < ;> a écrit :<blockquote class="gmail_ quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204 , 204, 204); padding-left: 1ex;"> <pre class="k9mail">Le 21/10/2019 à 18:46, Patg a écrit : <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br>Habituellement l'i nstallation du /boot se fait hors lvm. Mais depuis grub2, ça semble gérer le lvm. Debian utilise par défaut le grub2.<br></blockq uote><br>En effet.<br><br><blockquote class="gmail_quote" style="marg in: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex; ">L'idée du GRUB2 hors de lvm est il toujours d'actualité ? Ou es t il possible de l'utiliser sur du lvm ?<br><br>C'est possible . /boot peut ainsi bénéficier des avantages de LVM. Mais <br> il est aussi soumis à ses inconvénients et notamment une complexi té <br>supplémentaire. En cas de problème qui empêche rait GRUB d'accéder aux <br>volumes logiques, tout démarrage est impossible. Avec /boot hors LVM, <br>GRUB pourra au moins charger le noya u et l'initramfs, procurant un <br>système minimal permettant au moins de faire un diagnostic voire de réparer.<br><br><blockquote class ="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px sol id #729fcf; padding-left: 1ex;">J'utilise un serveur en raid5 avec le /boot en lvm (pas de partitions fines). Quel peut être le risque ?<br></b lockquote><br>Qu'appelles-tu "partitions fines" ?<br><br></pre></blockquote ></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mai l. Veuillez excuser ma brièveté.</body></html> ------7K2AQ2MVKTZL57Y33E43Z4LRCCERS8--
Pascal Hambourg
Le 25/10/2019 à 09:21, Patg a écrit :
Les problématiques, il s'agit de celles qui existaient déjà avec GRUB 1 au sujet de lvm, et que je pensais à tord résolu dans la version 2, que tu énonces "ses inconvénients et notamment une complexité supplémentaire.
Je ne comprends pas trop ce que tu veux dire. GRUB 1 ne supportait pas du tout LVM. GRUB 2 comble cette carence (au moins pour les volumes logiques simples) mais il est évident qu'il ne change rien à la complexité intrinsèque de LVM (qui est le prix de sa souplesse et de ses fonctionnalités).
En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible" Je pense notamment suite à un plantage du serveur ou autre... Et qui empêcherait GRUB d'avoir la main sur le boot en lvm.
Il ne faut pas exagérer la gravité de cet inconvénient. Il reste possible de démarrer un système de dépannage depuis un support amovible.
Je n'ai pas non plus besoin de thin provisioning. Dont je n'ai pas bien compris l'intérêt d'ailleurs, mais c'est pas la question.
L'intérêt du thin provisioning est de pouvoir créer des volumes d'une taille définie sans allouer immédiatement tout l'espace disque correspondant. Cela permet notamment d'éviter de devoir redimensionner ces volumes et leur contenu (systèmes de fichiers) pour répartir l'espace disque a posteriori.
Le 25/10/2019 à 09:21, Patg a écrit :
Les problématiques, il s'agit de celles qui existaient déjà avec GRUB 1 au sujet de lvm, et que je pensais à tord résolu dans la version 2, que tu énonces "ses inconvénients et notamment une complexité supplémentaire.
Je ne comprends pas trop ce que tu veux dire. GRUB 1 ne supportait pas
du tout LVM. GRUB 2 comble cette carence (au moins pour les volumes
logiques simples) mais il est évident qu'il ne change rien à la
complexité intrinsèque de LVM (qui est le prix de sa souplesse et de ses
fonctionnalités).
En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible"
Je pense notamment suite à un plantage du serveur ou autre... Et qui empêcherait GRUB d'avoir la main sur le boot en lvm.
Il ne faut pas exagérer la gravité de cet inconvénient. Il reste
possible de démarrer un système de dépannage depuis un support amovible.
Je n'ai pas non plus besoin de thin provisioning. Dont je n'ai pas bien compris l'intérêt d'ailleurs, mais c'est pas la question.
L'intérêt du thin provisioning est de pouvoir créer des volumes d'une
taille définie sans allouer immédiatement tout l'espace disque
correspondant. Cela permet notamment d'éviter de devoir redimensionner
ces volumes et leur contenu (systèmes de fichiers) pour répartir
l'espace disque a posteriori.
Les problématiques, il s'agit de celles qui existaient déjà avec GRUB 1 au sujet de lvm, et que je pensais à tord résolu dans la version 2, que tu énonces "ses inconvénients et notamment une complexité supplémentaire.
Je ne comprends pas trop ce que tu veux dire. GRUB 1 ne supportait pas du tout LVM. GRUB 2 comble cette carence (au moins pour les volumes logiques simples) mais il est évident qu'il ne change rien à la complexité intrinsèque de LVM (qui est le prix de sa souplesse et de ses fonctionnalités).
En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible" Je pense notamment suite à un plantage du serveur ou autre... Et qui empêcherait GRUB d'avoir la main sur le boot en lvm.
Il ne faut pas exagérer la gravité de cet inconvénient. Il reste possible de démarrer un système de dépannage depuis un support amovible.
Je n'ai pas non plus besoin de thin provisioning. Dont je n'ai pas bien compris l'intérêt d'ailleurs, mais c'est pas la question.
L'intérêt du thin provisioning est de pouvoir créer des volumes d'une taille définie sans allouer immédiatement tout l'espace disque correspondant. Cela permet notamment d'éviter de devoir redimensionner ces volumes et leur contenu (systèmes de fichiers) pour répartir l'espace disque a posteriori.
