Full Circle Magazine FR

Though I have been using and studying GNU/Linux for quite some time now, LVM is a new beast in my menagerie. Perhaps other aspects of system administration seemed more interesting, or maybe I didn’t feel the need for LVM. But now that I know more about it, it is fast becoming an essential part of my toolkit. If we take a look at back issues of our favorite magazine (Full Circle Mag, what other?), we actually find that LVM is mentioned very few times. It did appear in the 2011 “Special Edition 01: the Perfect Server”, and it was also mentioned briefly in issues 31 and 67. But there have been no in-depth articles on the matter. For today, after giving a simple example to put all the pieces in place, we will look at three different scenarios, covering some real-world, hands-on applications for LVM. In the first, we will use LVM to give us some flexibility when installing a new system. This will be a system for which we do not really know from day one exactly what disk space requirements will arise for our system and user document partitions. Should we retain a Windows partition, or will we want to remove it later on and combine this space with our Ubuntu partitions? In the second scenario, we will see how the LVM snapshot capability may be a life-saver if we should want to upgrade an existing system, without risking losing it all. Finally, in the third case we will be creating a bootable USB drive with several Ubuntu (or other) distributions all at once, so we can boot a computer from any of them.

Bien que j'utilise et j'étudie GNU/Linux depuis un certain temps maintenant, LVM est une nouvelle bête dans mon zoo. Peut-être que d'autres aspects de l'administration du système semblaient plus intéressants, ou peut-être que je n'ai pas senti le besoin d'avoir LVM. Mais maintenant que j'en sais plus à ce sujet, il est en passe de devenir un élément essentiel de ma boîte à outils.

Si nous jetons un coup d’œil aux numéros précédents de notre magazine préféré (Full Circle Mag, quoi d'autre ?), nous constatons effectivement que LVM est mentionné très peu de fois. Il apparaît en fait dans l'« Edition spéciale 01 : le Serveur Parfait » en 2011, et il a également été brièvement mentionné dans les numéros 31 et 67, mais il n'y a pas eu d'articles de fond sur la question.

Pour aujourd'hui, après avoir donné un exemple simple pour mettre tous les morceaux en place, nous allons examiner trois scénarios différents, couvrant quelques applications de LVM, pratiques, du monde réel. Dans la première, nous allons utiliser LVM pour nous donner une certaine souplesse lors de l'installation d'un nouveau système. Ce sera un système pour lequel nous ne connaissons pas vraiment dès le début quels besoins exacts en espace disque surgiront pour notre système et pour les partitions de documents des utilisateurs. Devrions-nous conserver une partition Windows, ou allons-nous vouloir l'enlever plus tard et combiner cet espace avec nos partitions Ubuntu ? Dans le deuxième scénario, nous verrons comment la capacité de LVM à prendre des clichés (snapshots) peut être une bouée de sauvetage si nous devons mettre à niveau un système existant, sans risquer de tout perdre. Enfin, dans le troisième cas, nous allons créer une clé USB bootable avec plusieurs Ubuntu (ou autres distributions) ensemble, afin que nous puissions démarrer un ordinateur à partir de l'un d'eux.

What LVM is Normal disk management under GNU/Linux - and also under Ubuntu - consists of working with disk partitions on the one hand, and file-systems on the other. Disk partitions are the low-level divisions of our disks. If you start out with a disk detected by the system as /dev/sda, it may contain partitions /dev/sda1, /dev/sda2, etc. Each of these partitions can then be formatted using a file-system: extended for GNU/Linux, NTFS or VFAT for Windows, HFS for Mac-OS-X, etc. The limitation with this scheme is that each partition can support one single file-system. The main idea behind the Logical Volume Manager (LVM) is to insert a third layer between the physical partitions on one hand, and file-systems on the other. This is an abstraction layer that makes file-systems more independent from the physical disks beneath. Physical disks are grouped together into this abstraction layer on one side, and then file-systems are created on the other that are completely independent from the disks.

Ce qu'est LVM

La gestion normale de disque sous GNU/Linux, et aussi sous Ubuntu, consiste à travailler avec des partitions de disque, d'une part, et des systèmes de fichiers d'autre part. Les partitions de disque sont les divisions de bas niveau de nos disques. Si vous commencez avec un disque détecté par le système comme étant /dev/sda, il peut contenir des partitions /dev/sda1, /dev/sda2, etc. Chacune de ces partitions peut ensuite être formatée en utilisant un système de fichiers : extended pour GNU/Linux, NTFS ou VFAT pour Windows, HFS pour Mac-OS-X, etc. La limitation de cette organisation est que chaque partition ne peut supporter qu'un seul système de fichiers.

L'idée principale derrière le gestionnaire de volumes logiques (LVM = Logical Volume Manager) est d'insérer une troisième couche entre les partitions physiques d'une part, et les systèmes de fichiers d'autre part. Il s'agit d'une couche d'abstraction qui rend les systèmes de fichiers plus indépendants des disques physiques en dessous. Les disques physiques sont regroupés d'un côté de cette couche d'abstraction et ensuite les systèmes de fichiers sont créés de l'autre côté, complètement indépendants des disques.

A simple example To use LVM, in the first place one should make sure we have the appropriate programs installed. They come as standard on most modern Ubuntu versions (13.04, 13.10, …) and derivatives (e.g. Linux Mint 15). They can also be installed on earlier versions - look for package lvm2 in your favorite software manager. Once the software is installed, we need to go through three steps: 1. We convert our physical disk partitions to LVM Physical Volumes (PV). Each partition converted will no longer be able to support a file-system directly, so we must be sure they do not contain any data we wish to keep. 2. We group our Physical Volumes together into a Volume Group (VG). There is no actual need to have more than one PV in a particular VG, but if needed we may do so. PVs are then combined within the VG, and their sizes add up. The group then be used as a single pool of disk space we can split into chunks and use as we wish. 3. We create one or more Logical Volumes out of our Volume Group.

Un exemple simple

Pour utiliser LVM, en premier lieu on doit s'assurer que nous avons installé les programmes appropriés. Ils existent en standard dans la plupart des versions modernes d'Ubuntu (13.04, 13.10,…) et des dérivés (ex. : Linux Mint 15). Ils peuvent également être installés sur des versions antérieures : cherchez le paquet lvm2 dans votre gestionnaire de logiciels préféré.

Une fois le logiciel installé, il faut passer par trois étapes :

1. Nous convertissons nos partitions de disques physiques en volumes physiques LVM (PV = Physical Volume). Chaque partition convertie ne pourra plus accueillir un système de fichiers directement, ainsi nous devons nous assurer qu'ils ne contiennent pas de données que nous voulons garder.

2. Nous regroupons nos volumes physiques dans un groupe de volumes (VG = Volume Group). Il n'y a pas de besoin réel d'avoir plus d'un PV dans un VG particulier, mais si nécessaire nous pouvons le faire. Les PV sont ensuite combinés dans le VG, et leurs tailles s'additionnent. Le groupe peut ensuite être utilisé comme un seul ensemble d'espace disque, que nous pouvons diviser en morceaux et utiliser comme souhaité.

3. Nous créons un ou plusieurs volumes logiques (LV = Logical Volume) à partir de notre groupe de volumes.

To take a practice example, we could start out with a computer with two drives, /dev/sdc and /dev/sdd, both being 2 TB volumes. sdc holds a single partition occupying the whole disk and noted sdc1, while sdd is divided into sdd1 and sdd2, both with 1 TB. We want to use sdc1 and sdd2 with LVM, conserving sdd1 without making any changes to it. Step 1 would be: sudo bash (we need to be root to alter LVM volumes) pvcreate /dev/sdc1 pvcreate /dev/sdd2 Once we have the two PVs created, we can create our volume group to host them. The VG may be called just about anything (but no spaces or “weird” characters in the name), so in this case we will simply call it “group”. So we will create it first with one volume, then add the second: vgcreate group /dev/sdc1 vgextend group /dev/sdd2

Pour prendre un exemple pratique, nous pourrions commencer avec un ordinateur ayant deux disques : /dev/sdc et /dev/sdd, les deux étant des volumes de 2 To. sdc porte une partition unique occupant tout le disque et hotée () sdc1, alors que sdd est divisé en sdd1 et sdd2, chacune de 1 To. Nous voulons utiliser sdc1 et sdd2 avec LVM, et conserver sdd1 sans faire de modifications.

L'étape 1 serait :

sudo bash

(Nous devons être root pour modifier les volumes LVM.)

pvcreate /dev/sdc1

pvcreate /dev/sdd2

Une fois que nous avons les deux PV créés, nous pouvons créer notre groupe de volumes pour les accueillir. Le VG peut être appelé n'importe comment (mais pas d'espaces ou de caractères « bizarres » dans le nom), ainsi dans cet exemple nous allons l'appeler simplement « groupe ». Nous allons donc d'abord le créer avec un volume, puis ajouter le deuxième :

vgcreate group /dev/sdc1

vgextend group /dev/sdd2

We now obtain a single volume group, with total capacity 3 TB. We can now proceed to step 3, and “carve” out one or more logical volumes as necessary - and yes, the technical term used is indeed “to carve”. For example, if we wished to create a 1.5 TB volume we will be using as a backup, we could do it this way: lvcreate group -L 1500M -n backup Giving the LV a significant name with the -n option will make it easier for us to recognize and use. For example: mkfs.ext4 /dev/group/backup mount /dev/group/backup /mnt

Nous obtenons maintenant un seul groupe de volumes, avec une capacité totale de 3 To. Nous pouvons maintenant passer à l'étape 3 et « sculpter » un ou plusieurs volumes logiques selon le besoin ; et oui, le terme technique utilisé est en effet « sculpter » [Ndt : « to carve » en anglais, mais en français on utilise plutôt le verbe « créer »]. Par exemple, si nous voulions créer un volume de 1,5 To, pour l'utiliser comme sauvegarde, nous pourrions le faire de cette façon :

lvcreate group -L 1500M -n backup

Donner au LV un nom significatif avec l'option -n, nous le rendra plus facile à reconnaître et à utiliser. Par exemple :

mkfs.ext4 /dev/group/backup

mount /dev/group/backup /mnt

Note that LV divisions borders do not necessarily coincide with disk partitions; in this example our backup LV may in actual fact be completely contained within /dev/sdc1, or it could just as well be divided up into chunks physically located on both /dev/sdc1 and /dev/sdd2. We do not have to manage it. On the other hand, we do know we still have some 1.5 TB of free space we can further carve up – into one or several more LVs. So this simple example already shows us some of LVM’s potential flexibility. Though I personally prefer to use the console, not everybody feels that way. So a graphical front-end for LVM has been developed, called system-config-lvm. If you feel so inclined, by all means install it on top of lvm and give it a test. It also outputs some pretty graphics such as those above. However, it does have some issues with recent versions of Linux Mint and Cinnamon (but not with Unity).

Notez que les frontières de division des LV ne coïncident pas nécessairement avec les partitions de disque ; dans cet exemple, notre LV de sauvegarde peut en fait être entièrement contenu dans /dev/sdc1, ou il pourrait tout aussi bien être divisé en morceaux qui se trouvent physiquement sur les deux /dev/sdc1 et /dev/sdd2. Nous n'avons pas à gérer ceci. D'autre part, nous savons bien que nous avons encore quelque 1,5 To d'espace libre que nous pouvons continuer à creuser, avec un ou plusieurs autres LV. Donc ce simple exemple nous montre déjà une partie de la possible flexibilité de LVM.

Bien que personnellement, je préfère utiliser la console, tout le monde n'est pas à l'aise avec. Ainsi, une interface graphique pour LVM a été développée, appelée system-config-lvm. Si vous êtes dans ce cas, ne manquez pas de l'installer par dessus LVM et de l'essayer. Elle affiche aussi quelques jolis graphiques tels que ceux ci-dessus. Cependant, elle a quelques problèmes avec les versions récentes de Linux Mint et Cinnamon (mais pas avec Unity).

Scenario 1: juggling disks when you do not know what the final system will look like Most of us have installed Ubuntu or one of its derivatives on a disk that already contained a Windows partition. At least at the very beginning, we often wanted to retain at least part of the Windows installation, just in case we wanted to go back - for whatever reason. At the end of the day, however, this “going back” somehow rarely happens. What does happen is that we run out of space on the Linux side, and end up thinking of adding the Windows partition or partitions to Ubuntu. LVM makes this easier. Let us set out with a typical laptop hard drive, that often comes from the factory preset with three partitions: • /dev/sda1 as C:, the main Windows system disk; • /dev/sda2 as D:, where we place our files, often set up as the My Documents folder; • /dev/sda3, an invisible partition under Windows that holds a system image that can be used to reinstall Windows to its factory settings.

Scénario 1 : jongler avec les disques lorsque vous ne savez pas à quoi le système final ressemblera

La plupart d'entre nous ont installé Ubuntu ou un de ses dérivés sur un disque qui contient déjà une partition Windows. Au moins au début, nous voulions souvent conserver au moins une partie de l'installation de Windows, juste au cas où nous voudrions y retourner, pour une raison quelconque. A la fin de la journée, cependant, ce « retour en arrière » se passe plutôt rarement. Ce qui arrive c'est que nous manquons d'espace du côté Linux, et on finit par penser à ajouter la ou les partitions de Windows à Ubuntu. LVM rend cela plus facile.

Partons d'un disque dur d'ordinateur portable typique, qui est souvent fourni avec la valeur d'usine pour trois partitions : • / dev/sda1 pour C:, le disque principal système de Windows ; • / dev/sda2 pour D:, où nous plaçons nos fichiers, souvent mis en place comme le dossier Mes documents ; • / dev/sda3, une partition invisible sous Windows qui contient une image du système qui peut être utilisée pour réinstaller Windows avec ses réglages d'usine.

A simple installation choice is to replace the NTFS D: partition with our Ubuntu system. If we simply discard the existing D: and give the installer free reign we will probably end up with something a tad complicated. It loves to create two separate partitions, one for the system itself, and another as swap memory. So we could end up with something like this: • /dev/sda1 as the existing C: • /dev/sda2 as an ext4 partition • /dev/sda4, a primary partition containing • /dev/sda5, a secondary partition used as swap • /dev/sda3, the existing invisible image partition This is already a bit involved, and will become even more so when, later on, we decide to get rid of Windows once and for all, and reuse /dev/sda1 and /dev/sda3 for Ubuntu as well.

Un simple choix d'installation est de remplacer la partition NTFS D: avec notre système Ubuntu. Si nous écrasons tout simplement le D: existant et que nous donnons les pleins pouvoirs à l'installeur, nous allons probablement finir avec quelque chose d'un peu compliqué. Il aime créer deux partitions distinctes, l'une pour le système lui-même et un autre au fichier d'échange de méméoire (swap). Donc, nous pourrions arriver à quelque chose comme ceci : • / dev/sda1 pour le C: existant ; • / dev/sda2 pour une partition ext4 ; • / dev/sda4, une partition primaire contenante ; • / dev/sda5, une partition secondaire utilisée comme fichier d'échange ; • / dev/sda3, la partition image invisible existante.

C'est déjà un peu compliqué, et le sera encore plus quand, plus tard, nous déciderons de nous débarrasser de Windows une fois pour toutes et de réutiliser aussi /dev/sda1 et /dev/sda3 pour Ubuntu.

So, in comes LVM to help us simplify things. When installing Ubuntu for the first time, instead of going directly to the installer, we will fire up a terminal, become root and: sudo bash (no password is necessary with the LiveCD) pvcreate /dev/sda2 vgcreate group /dev/sda2 vgcreate group -n system -L <system size> vgcreate group -n swap -L <swap size>

Donc, arrive LVM pour nous aider à simplifier les choses. Lors de l'installation d'Ubuntu pour la première fois, au lieu d'aller directement à l'installeur, nous lancerons un terminal, deviendrons root et :

sudo bash

(Aucun mot de passe n'est nécessaire avec le LiveCD.)

pvcreate /dev/sda2

vgcreate group /dev/sda2

vgcreate group -n system -L <system size>

vgcreate group -n swap -L <swap size>

We now have: • /dev/sda1 as the existing C: • /dev/sda2 as a PV, used by VG “group” and containing • /dev/group/system, a partition we will use as the system root • /dev/group/swap, a partition used as swap • /dev/sda3, the existing invisible image partition We can now proceed to the Ubuntu installer, and when presented with the screen to choose disk management, go to “manual partitioning”. From there, we get /dev/group/system formatted as an ext4 file-system and mounted on /, while /dev/group/swap gets formatted and used as swap. The rest of the system installation process should go on as usual. A word of warning: earlier versions of Ubuntu were not LVM-aware. What is described here should work out-of-the-box for Raring (13.04) and Saucy (13.10), as well as Linux Mint 15. Earlier versions need some heavy-duty console work to mount the target partition, bind-mount accessory directories such as /tmp and /dev; go to it in a chroot jail and install the lvm2 package. This is certainly doable, but perhaps not for the faint of heart.

Nous avons maintenant : • /dev/sda1 pour le C: existant ; • /dev/sda2 pour un PV, utilisé par le VG « group » et contenant : • /dev/group/system, une partition que nous allons utiliser comme racine du système ; • /dev/group/swap, une partition utilisée comme fichier d'échange de mémoire ; • /dev/sda3, la partition existante de l'image invisible.

Nous pouvons maintenant procéder à l'installation d'Ubuntu et lorsqu'on vous présentera l'écran pour choisir la gestion de disque, allez dans « manual partitioning » (partitionnement manuel). De là, nous aurons /dev/group/system formaté comme un système de fichiers ext4 et monté sur /, tandis que /dev/group/swap sera formaté et utilisé comme fichier d'échange. Le reste du processus d'installation du système devrait se dérouler comme d'habitude.

Un mot d'avertissement : les versions antérieures d'Ubuntu ne connaissent pas LVM. Ce qui est décrit ici devrait fonctionner tel quel pour Raring (13.04) et Saucy (13.10), ainsi que Linux Mint 15. Les versions antérieures nécessitent beaucoup de travail sur la console pour monter la partition cible, relier et monter les répertoires accessoires tels que /tmp et /dev, l'inclure dans une prison chroot et installer le paquet lvm2. C'est certainement faisable, mais peut-être pas pour les couards.

Now, what happens when we wish to add the Windows partitions to our Ubuntu system? Let us say, for example, that we simply wish to reform /dev/sda1 (C:), retaining the image partition for the time being. Inside a terminal, we create a new PV from /dev/sda1, and add it to VG “ubuntu”: sudo bash pvcreate /dev/sda1 vgextend group /dev/sda1 If we now use the vgdisplay command, it can be seen that the space available on VG “ubuntu” is larger than before, comprising both /dev/sda2 and /dev/sda1. We can then make our LV “system” and root file-system larger. This cannot be done while it is mounted, so we will need to boot from the Ubuntu LiveCD once more. Supposing our /dev/sda1 partition was 40 GBytes in size, and /dev/sda2 was 60 GBytes, we could: sudo bash lvextend /dev/ubuntu/system +40G (adds the newly available 40 GB to LV “system”) resize2fs /dev/ubuntu/system 100G (makes the “system” ext4 filesystem a total of 100 GB large)

Maintenant, que se passe-t-il quand on veut ajouter les partitions Windows à notre système Ubuntu ? Disons, par exemple, que nous voulons simplement réutiliser /dev/sda1 (C:), en conservant la partition d'image pour le moment. Dans un terminal, nous créons un nouveau PV avec /dev/sda1, et l'ajoutons au VG « ubuntu » :

sudo bash

pvcreate /dev/sda1

vgextend group /dev/sda1

Si nous utilisons maintenant la commande vgdisplay, on peut voir que l'espace disponible sur le VG « ubuntu » est plus grande qu'avant, comprenant à la fois /dev/sda2 et /dev/sda1. Nous pouvons alors faire de notre LV « system » et accroître notre système de fichiers racine. Cela ne peut se faire alors qu'il est monté, donc nous aurons à nouveau besoin de démarrer à partir du LiveCD Ubuntu. Supposons que notre partition /dev/sda1 soit de 40 Go en taille, et /dev/sda2 était de 60 Go, on pourrait faire :

sudo bash

lvextend /dev/ubuntu/system +40G

(Ajoute les 40 Go nouvellement disponibles au LV « system ».)

resize2fs /dev/ubuntu/system 100G

(Agrandit le système de fichiers ext4 « system » à total de 100 Go.)

We should then be able to reboot as usual from the hard disk, and test drive our new, enlarged, system. Our system now looks like this: • /dev/sda1 and /dev/sda2 as PVs, used by VG “group” and containing • /dev/group/system, a partition we will use as the system root • /dev/group/swap, a partition used as swap • /dev/sda3, the existing invisible image partition If we do not need the image partition any more, we could also go one step further, and add it as well to VG “group”. The usual warnings apply: we are making extensive changes to the operating system, so things could eventually go very wrong. Naturally, you should do this for the first time only on a system which you are prepared to reinstall from scratch if things go bad. And, of course, make a backup of your data before starting!

Nous devrions alors être en mesure de redémarrer comme d'habitude depuis le disque dur, et de faire l'essai de notre nouveau système agrandi. Notre système ressemble maintenant à ceci : • /dev/sda1 et /dev/sda2 comme PV, utilisés par le VG « group » et contenant ; • /dev/groupe/system, une partition que nous allons utiliser comme racine du système ; • /dev/groupe/swap, une partition utilisée comme fichier d'échange ; • /dev/sda3, la partition existante de l'image invisible.

Si nous n'avons plus besoin de la partition d'image, nous pouvons aussi aller plus loin, et l'ajouter aussi au VG « group ».

Les avertissements habituels s'appliquent : nous faisons des changements importants sur le système d'exploitation, donc les choses pourraient éventuellement aller très mal. Naturellement, vous devriez le faire pour la première fois uniquement sur un système pour lequel vous êtes prêt à le réinstaller à partir de zéro si les choses vont mal. Et, bien sûr, faire une sauvegarde de vos données avant de commencer !

Scenario 2: a safety net when upgrading an existing system One of the nice things about Ubuntu and GNU/Linux systems in general is that new, upgraded versions come up very often, in our case every six months. So there is a natural tendency to upgrade systems that may or may not really need it - just to stay on top of things. But strange things do sometimes happen when upgrading, even with Linux. For example, in theory it should be possible to upgrade an existing Ubuntu-based system to a newer version by simply changing the repositories in /etc/apt/sources.list and then executing sudo bash aptitude update ; aptitude safe-upgrade -y ; shutdown -r now In actual fact, this is not a good idea for many distributions. Some old cruft always gets carried over to the new version. More importantly, new versions may need newer versions of their configuration files, that might even not be in the same directories any more. This is particularly true of Linux Mint: except for their Debian-based distributions (LMDE), upgrading in place has specifically been discouraged - see Clément Lefebvre’s “How to upgrade to a newer release” (http://community.linuxmint.com/tutorial/view/2).

Scénario 2 : un filet de sécurité lors de la mise à jour d'un système existant

Une des choses sympas sur les systèmes Ubuntu et GNU/Linux en général, c'est que de nouvelles versions améliorées arrivent très souvent, dans notre cas, tous les six mois. Donc, il y a une tendance naturelle à mettre à niveau des systèmes qui en ont ou n'en ont pas vraiment besoin : juste pour rester au top des choses. Mais des choses étranges se produisent parfois lors de la mise à jour, même avec Linux. Par exemple, en théorie, il devrait être possible de mettre à niveau un système basé sur un Ubuntu existant vers une nouvelle version en changeant simplement les dépôts dans /etc/apt/sources.list, puis en exécutant

sudo bash

aptitude update ; aptitude safe-upgrade -y ; shutdown -r now

En fait, ce n'est pas une bonne idée pour de nombreuses distributions. Certains vieux lambeaux sont toujours transportés sur la nouvelle version. Plus important, les nouvelles versions peuvent avoir besoin de nouvelles versions de leurs fichiers de configuration, qui pourrait même ne pas être du tout dans les mêmes répertoires. Cela est particulièrement vrai pour Linux Mint : sauf pour leurs distributions basées sur Debian (LMDE), la mise à niveau sur place a été spécifiquement déconseillée, voir l'article de Clément Lefebvre « Comment mettre à niveau vers une version plus récente » (http://community.linuxmint.com/tutorial/view/2).

Anyhow, if downloading, installing and re-configuring a new system is just too much hassle and you do want to go down the path of in-place upgrading, it is always nice to have a Plan B ready: a way to get your system back up and working as it was before trying to upgrade. Once more, LVM comes to the rescue with its snapshot capability. The way this works is, if we have enough free space in our VG, we create a second LV that is essentially a copy of the first, though in essence “frozen in time”. We can then do whatever we want to the first LV, and can always copy our files back from the snapshot if needed. First, we create the snapshot of LV “system”. In my own case, I tend to use very small 10 GByte system partitions, so I will create a snapshot reserving double this space - just in case it fills up for whatever reason. We will call the snapshot “system-snap”: sudo bash lvcreate -s -n system-snap -L 20G /dev/group/system

Cependant, si le téléchargement, l'installation et la reconfiguration d'un nouveau système se révèlent être trop d’embarras pour vous et que vous ne voulez pas vous aventurer sur une mise à niveau en place, il est toujours agréable d'avoir préparé un plan B : une manière d'avoir votre système sauvegardé et fonctionnant comme avant d'essayer de le mettre à niveau. Une fois de plus, LVM vient à la rescousse avec sa capacité de photo instantanée (snapshot).

La façon dont cela fonctionne est que, si nous avons assez d'espace libre dans notre VG, nous créons un deuxième LV qui est essentiellement une copie du premier, mais par essence « figé dans le temps ». Nous pouvons alors faire ce que nous voulons au premier LV, et pouvons toujours copier nos fichiers en provenance de la photo si nécessaire.

Tout d'abord, nous créons la photo du LV « système ». Dans mon propre cas, j'ai tendance à utiliser de très petites partitions système de 10 Go, donc je vais créer une photo en réservant le double d'espace, juste au cas où elle se remplirait pour une raison quelconque. Nous allons appeler la photo « system-snap »:

sudo bash

lvcreate -s -n system-snap -L 20G /dev/group/system

That’s it, all done. Now we can proceed to upgrade our system to whatever newer version is available (Ubuntu 13.10, perhaps?), or perform any other kind of black magic that could eventually bork things in a big way. Let us suppose that it has indeed done that, and that our original system (in LV “system”) is in a very bad shape. We need to reboot from the trusty Ubuntu LiveCD, and in a terminal make a copy of the snapshot we will work from: sudo bash lvrename /dev/group/system system-old lvcreate group -n system -L 10G (put in here whatever size you used for the system partition) dd if=/dev/group/system-snap of=/dev/group/system bs=1M At this point, LVs should be this way: lvscan ACTIVE Original '/dev/group/system-old' [10,00 GiB] inherit ACTIVE Snapshot '/dev/group/system-snap' [20,00 GiB] inherit ACTIVE '/dev/group/system' [10,00 GiB] inherit

Ça y est, c'est fait. Nous pouvons maintenant procéder à la mise à niveau de notre système vers une quelconque nouvelle version disponible (Ubuntu 13.10, peut-être ?), ou effectuer tout autre type de magie noire qui pourrait éventuellement brouiller les choses gravement.

Supposons que c'est ce qui s'est passé, et que notre système d'origine (sur le LV « system ») est dans un très mauvais état. Nous devons redémarrer à partir du fidèle LiveCD Ubuntu, et dans un terminal faisons une copie de la photo à partir de laquelle nous allons travailler:

sudo bash

lvrename /dev/group/system system-old

lvcreate group -n system -L 10G

(Mettez ici la taille que vous avez utilisée pour la partition système)

dd if=/dev/group/system-snap of=/dev/group/system bs=1M

À ce stade, le LV devrait être ainsi:

lvscan

ACTIVE Original '/dev/group/system-old' [10,00 GiB] inherit

ACTIVE Snapshot '/dev/group/system-snap' [20,00 GiB] inherit

ACTIVE '/dev/group/system' [10,00 GiB] inherit

The “system-old” LV is the old, wrecked system. “system-snap” is the snapshot containing a copy of the system as it was before making the fatal changes, and “system” is the current, recreated, system. We can clean up a bit by removing both the old system and the snapshot, regaining the space they occupied: lvremove /dev/group/system-snap lvremove /dev/group/system-old Depending on what happened while upgrading/breaking your system, your GRUB installation may also be off-course. It is perhaps a good idea to recreate it while you are still booted into the LiveCD. Mount your new /dev/group/system, for example on /media/ubuntu/system, and reinstall GRUB on /dev/sda with: grub-install –boot-directory /media/ubuntu/system/boot /dev/sda

Le LV « système-old » est l'ancien système échoué. « Système-snap » est la photo contenant une copie du système tel qu'il était avant de faire les changements fatals, et « system » est le système courant, recréé.

Nous pouvons nettoyer un peu en enlevant à la fois l'ancien système et la photo, et retrouver l'espace qu'ils occupaient:

lvremove /dev/group/system-snap

lvremove /dev/group/system-old

Selon ce qui s'est passé pendant la mise à niveau ou la casse de votre système, l'installation de GRUB peut également être hors-course. C'est peut-être une bonne idée de la recréer pendant que vous êtes encore démarré avec le LiveCD. Montez votre nouveau /dev/group/system, par exemple sur /media/ubuntu/system et réinstallez GRUB sur /dev/sda avec:

grub-install –boot-directory /media/ubuntu/system/boot /dev/sda

Scenario 3: making your “Swiss army knife” USB boot disk In this day and age of external USB hard drives, we have at our disposal a simple means of booting ailing computers, and fixing whatever is wrong or even cloning a system image. The standard Ubuntu LiveCD image can help us, naturally, but another way of going about it is to simply install Ubuntu on an external drive. That way, we can add our very own collection of tools and keep it set up just the way we want it. However, some tasks need simple tools such as booting a very old computer off a lightweight Xubuntu, while others may need a more complete solution, such as cloning a school lab’s worth of computers all to the same spec with Ubuntu Studio. Since modern hard drives have plenty of space, why not put several different distributions on the same external drive? However, we may encounter several practical problems. If we want to use the disk to boot older computers, we will need to use the classical Master Boot Record (MBR) partitioning system. This means we are limited to four principal partitions - slightly more if we use secondary partitions, but still very limited in number. So, even if the hard disk itself has more than enough capacity for several dozen Ubuntu installations - perhaps of varying ages and flavors - the partition map will not take them.

Scénario 3: créer votre disque de démarrage USB « couteau suisse »

En cette époque des disques durs USB externes, nous avons à notre disposition un moyen simple de démarrer des ordinateurs en difficulté, de corriger tout ce qui ne va pas ou même de cloner une image système. L'image standard du LiveCD Ubuntu peut nous aider, bien sûr, mais une autre façon de le faire est de simplement installer Ubuntu sur un disque externe. De cette façon, nous pouvons ajouter notre propre collection d'outils et garder son paramétrage tel que nous le voulons.

Cependant, certaines tâches ont besoin d'outils simples tels que le démarrage d'un très vieil ordinateur sur un système léger Xubuntu, tandis que d'autres peuvent avoir besoin d'une solution plus complète, comme le clonage de tous les ordinateurs du laboratoire d'une l'école avec la même spécification d'Ubuntu Studio. Comme les disques durs modernes ont beaucoup d'espace, pourquoi ne pas mettre plusieurs distributions différentes sur le même disque dur externe?

Mais, nous pouvons rencontrer des problèmes pratiques. Si nous voulons utiliser le disque pour démarrer les ordinateurs plus anciens, nous aurons besoin d'utiliser le système de partitionnement classique avec une zone amorce (Master Boot Record - MBR). Cela signifie que nous sommes limités à quatre partitions principales; un peu plus si nous utilisons les partitions secondaires, mais encore très limitées en nombre. Ainsi, même si le disque dur lui-même a la capacité suffisante pour plusieurs dizaines d'installations Ubuntu, peut-être d'âges et de saveurs variées, la carte de partition ne les prendra pas.

Even worse is that unless we plan very carefully beforehand how much space to assign to each installation, we may end up with some partitions running out of space, while there is plenty left over on the disk. A case in point would be if we have a backup partition on disk, as well as the system installations. At this point, it should be clear that we would be better off using LVM on the external disk. Setting it up is simplicity itself. Once we have booted from the LiveCD for the first Ubuntu system we wish to install, we use the terminal or the gparted utility to create a first ext4 partition occupying the entire external disk: /dev/sda1 or similar. Once that is done, we can proceed to the terminal, create a PV from the partition, and a VG from that. Then we can carve out a first LV from the VG, format it and install Ubuntu on it. For successive installations of other versions of *buntu, we proceed in the same way: boot from the appropriate LiveCD, use the terminal to create a new LV (use significant volume labels!), format the new LV with an ext4 file-system, an install in the traditional way. Each time, however, the GRUB installation will probably get overwritten by the installer so, whatever you do, make sure beforehand the version of Ubuntu you are installing does actually support lvm out of the box! Just run any of the commands - lvdisplay will suffice - from the terminal. A helpful tip: it is best to practice installing Ubuntu on an external disk on a computer with its internal hard drive disconnected. Doing things this way can help avoid wee mistakes, such as overwriting the main hard drive’s system inadvertently…

Et même pire, si nous ne prévoyons pas très soigneusement à l'avance combien d'espace à attribuer à chaque installation, nous pourrions nous retrouver avec des partitions manquant d'espace, alors qu'il en reste beaucoup non utilisé sur le disque. Un exemple serait lorsque nous avons une partition de sauvegarde sur disque, ainsi que les installations du système.

À ce stade, il devrait être clair que nous ferions mieux d'utiliser LVM sur le disque externe.

Sa mise en place est la simplicité même. Une fois que nous avons démarré depuis le LiveCD pour le premier système Ubuntu que nous souhaitons installer, nous utilisons le terminal ou l'utilitaire gparted pour créer une première partition ext4 occupant la totalité du disque externe: /dev/sda1 ou similaire. Une fois ceci fait, nous pouvons retourner dans le terminal, créer un PV à partir de la partition, et un VG à partir du PV. Ensuite, nous pouvons sculpter un premier LV sur le VG, le formater et installer Ubuntu dessus.

Pour les installations successives d'autres versions de *buntu, nous procédons de la même manière: démarrer sur le LiveCD approprié, utiliser le terminal pour créer un nouveau LV (utiliser des étiquettes de volume faisant sens!), formater le nouveau LV avec un système de fichiers ext4, et installer de manière traditionnelle. Chaque fois, cependant, l'installation de GRUB va probablement être écrasée par l'installeur donc, quoi que vous fassiez, assurez-vous au préalable que la version d'Ubuntu que vous installez supporte réellement LVM dès sa sortie de l'emballage! Il suffit de lancer l'une des commandes, lvdisplay suffira, dans le terminal.

Une astuce utile: il est préférable de s'entrainer à installer Ubuntu sur un disque externe pour un ordinateur ayant son disque dur interne déconnecté. Faire les choses de cette manière peut aider à éviter les erreurs minables, comme remplacer le système du disque dur principal par inadvertance.

Conclusions Though LVM may seem to be a bit of overkill for a simple Ubuntu installation, as we have seen in these three scenarios - installing GNU/Linux on a (former) Windows machine, using a snapshot to keep our backs covered when upgrading in place, and making an external USB boot diskb - it does give us a lot of flexibility. Without LVM, one partition must correspond to precisely one file-system. With LVM, we can play separately on two different levels: with partitions on the one hand, and with Logical Volumes on the other. While I hope these three scenarios may help the reader in real-life situations, this is by no means the end of LVM applications. Further possibilities include using it to encrypt a complete partition - as set out in Xavier Berger’s “Create a thief-proof PC”, in Full Circle issue 67 (http://fullcirclemagazine.org/issue-67/). If we want to set up a data repository or NAS box on our network, LVM mirroring gets us data replication (two copies of each item) without having to fiddle around with RAID volumes.

Conclusions

Bien que LVM peut sembler être un peu exagéré pour une installation simple d'Ubuntu, comme nous l'avons vu dans ces trois scénarios : installer GNU/Linux sur une machine (anciennement) Windows, utiliser une photo pour rester couvert lors d'une mise à niveau sur place, et faire un disque de démarrage USB externe; il nous donne vraiment beaucoup de souplesse. Sans LVM, une partition doit correspondre exactement à un système de fichiers. Avec LVM, nous pouvons jouer séparément sur deux niveaux différents: avec les partitions d'une part, et avec des volumes logiques d'autre part. Bien que j'espère que ces trois scénarios pourront aider le lecteur dans des situations de la vie réelle, ce n'est à aucun moment l'ensemble des possibilités de LVM. Des possibilités plus avancées incluent son utilisation pour chiffrer une partition complète, comme indiqué dans « Créer un PC à l'épreuve des voleurs » de Xavier Berger, dans le numéro Full Circle 67 (EN : http://fullcirclemagazine.org/issue-67/, FR : http://www.fullcirclemag.fr/visionneuse/visionner.php?numero=issue67fr). Si nous voulons mettre en place un partage de données ou un appareil NAS sur notre réseau, La copie mirroir de LVM nous permet la réplication de données (deux copies de chaque élément) sans avoir à bidouiller avec des volumes RAID.

In any case, I would like to encourage everybody to play around with LVM, at least to explore its various possibilities. But please stay safe: do it on a computer you do not need for work, that you are happy to format if need be, and obviously with all data on it correctly backed up. Even small units such as USB flash pen-drives are enough to try out LVM, though the system may or may not regain access to the LVs if you pop them out and back in again (it usually does). Perhaps the best way to test it out would be with virtual machines under Virtualbox. If your main computer has enough RAM (say 2 GB), enough CPU horsepower (any dual-core should suffice) and some space disk space left, this would definitely be the way to go.

En tout cas, je tiens à encourager tout le monde à jouer avec LVM, au moins d'explorer ses différentes possibilités. Mais s'il vous plait restez sans problème: faites-le sur un ordinateur, dont vous n'avez pas besoin pour le travail, que vous serrez heureux de formater si besoin, et évidemment avec toutes ses données correctement sauvegardées. Même les petites unités comme les stylo flash USB sont suffisants pour essayer LVM, bien que le système puisse ou ne puisse pas retrouver l'accès aux LV si vous les retirez et remettez à nouveau (il le fait habituellement). Peut-être la meilleure façon de le tester serait avec des machines virtuelles dans Virtualbox. Si votre ordinateur principal a assez de RAM (disons 2 Go), assez de puissance CPU (tout bicoeur devrait suffire) et qu'il reste de l'espace disque, ce serait certainement la formule à suivre.