Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
==== 1 ====
**
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 aient semblé plus intéressants, ou peut-être que je n'aie pas senti le besoin d'avoir LVM. Mais maintenant que j'en sais plus à son 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é (le Full Circle, évidemment), 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 en a pas eu d'articles de fond.

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 usages, pratiques et tirés de la « vraie vie » de LVM. Dans la première, nous utiliserons 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 les besoins exacts en espace disque du système et des partitions de documents des utilisateurs. Devrions-nous conserver une partition Windows, ou allons-nous vouloir l'enlever plus tard et fusionner cet espace avec nos partitions Ubuntu ? Dans le deuxième scénario, nous verrons comment la capacité de LVM à prendre des photos instantanées (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 amorçable avec plusieurs distributions Ubuntu (ou autres) ensemble, afin que nous puissions démarrer un ordinateur à partir de n'importe lequel d'entre 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.

==== 2 ====
**
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 nous devons nous assurer d'avoir 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 à notre guise.

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
**

Voici 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 a une partition unique occupant tout le disque et noté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 créé les deux PV, 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 « group ». 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 avons actuellement un seul groupe de volumes, avec une capacité totale de 3 To. Nous pouvons maintenant passer à l'étape 3 et « tailler » un ou plusieurs volumes logiques selon nos besoins ; et oui, le terme technique utilisé est en effet « tailler » [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

Si nous donnons au LV un nom significatif avec l'option -n, nous pourrons le reconnaître et l'utiliser plus facilement. 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 cela. En revanche, nous savons bien que nous avons encore quelque 1,5 To d'espace libre que nous pouvons continuer à tailler, en créant un ou plusieurs autres LV. Ainsi, ce simple exemple nous donne déjà une idée de la flexibilité potentielle 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 en avez envie, vous pouvez très bien l'installer par dessus LVM pour 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).

==== 3 ====
**
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 ressemblera le système final 

La plupart d'entre nous ont installé Ubuntu ou un de ses dérivés sur un disque qui contenait 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 quelconque raison.  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 finissons par penser à ajouter la ou les partitions Windows à Ubuntu. LVM rend cela plus facile.

Partons d'un disque dur d'ordinateur portable typique, qui nous arrive souvent du fabricant pré-configuré en trois partitions : 
 • / dev/sda1 pour C:, le disque principal du système Windows ;
 • / dev/sda2 pour D:, où nous mettons nos fichiers, souvent paramétré en tant que 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 en donnant 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 l'autre pour le fichier d'échange de mémoire (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 contenant ;
 • / 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 /dev/sda1 et /dev/sda3 pour Ubuntu aussi.


**
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>
**

Alors, voici LVM pour nous aider à simplifier les choses. Lors de la première installation d'Ubuntu, 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, lorsque l'écran pour choisir la gestion de disque s'affichera, aller 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.

Mise en garde : 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 pour Linux Mint 15. Les versions antérieures nécessitent beaucoup de travail à 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 sans doute pas pour les timorés.

**
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)
**

Bon. 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 accroître notre LV « system » et notre système de fichiers racine. Cela ne peut pas se faire quand il est monté, nous aurons donc à nouveau besoin de démarrer à partir du LiveCD Ubuntu. En supposant que notre partition /dev/sda1 était de 40 Go et que /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 » à un 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 qui contient l'image invisible.

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

Les mises en garde habituelles s'appliquent : nous faisons des changements importants dans le système d'exploitation et les choses pourraient éventuellement aller très mal. Naturellement, vous devriez le faire pour la première fois uniquement sur un système que vous voudrez bien 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 !

==== 4 ====
**
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. Il y a donc une tendance naturelle à mettre à niveau des systèmes qui en ont - ou pas - vraiment besoin, pour rester maître de la situation. Mais des choses étranges se produisent parfois lors d'une mise à jour, même avec Linux. Par exemple, en théorie, il devrait être possible de mettre à niveau un système Ubuntu ou dérivés existant vers une version plus récente 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. Quelques vieilleries restent présentes sur la nouvelle version. Plus important, les nouvelles versions peuvent avoir besoin de versions plus récentes de leurs fichiers de configuration, qui pourraient même ne pas se trouver 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 in situ 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
**

Quoi qu'il en soit, si le téléchargement, l'installation et la reconfiguration d'un nouveau système se révèlent trop compliqué et que vous ne voulez pas faire une mise à niveau hasardeuse in situ, il est toujours agréable d'avoir un plan B qui vous permettra de ressusciter votre système dans son état avant votre essai malheureux de mise à niveaux. 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 en fait une copie du premier, mais par essence « figé dans le temps ». Nous pouvons alors faire ce que nous voulons au premier LV, et ensuite récupérer les fichiers de la « photo »  si nécessaire.

Tout d'abord, nous créons la photo du LV « système ». Dans mon cas, j'ai tendance à utiliser de très petites partitions système de 10 Go ; par conséquent, je vais créer une photo en réservant le double de l'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 s'adonner à tout autre type de magie noire qui pourrait, le cas échéant, gravement endommager le système.

Supposons que c'est ce qui s'est passé et que notre système d'origine (sur le LV « system ») est dans un état lamentable. Nous devons redémarrer à partir du fidèle LiveCD Ubuntu et, dans un terminal, faire 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 endommagé. « 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 actuel, recréé.

Nous pouvons nettoyer un peu en enlevant à la fois l'ancien système et la photo pour 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 avoir souffert. C'est peut-être une bonne idée de la recréer pendant que vous utilisez 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

==== 5 =====
**
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 »

À cette époque des disques durs USB externes, nous avons à notre disposition un moyen simple de démarrer des ordinateurs en difficulté et de corriger tout ce qui ne va pas ou même de cloner une image système. Évidemment, l'image standard du LiveCD Ubuntu peut nous aider, mais une autre façon de faire est de tout simplement installer Ubuntu sur un disque externe. De cette façon, nous pouvons ajouter notre propre collection d'outils et être certain que son paramétrage reste 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 école avec les mêmes spécifications, sous 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 ?

Toutefois, il se peut que nous rencontrions plusieurs 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 un nombre très limité. 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, le schéma des partitions 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...
**

Pire, même, si nous ne prévoyons pas très soigneusement à l'avance la quantité d'espace à attribuer à chaque installation, nous pourrons nous retrouver avec des partitions qui manquent d'espace, alors qu'il en reste beaucoup de libre 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é sur le LiveCD du 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 cela fait, nous pouvons retourner dans le terminal, créer un PV à partir de la partition et un VG à partir du PV. Ensuite, nous pouvons créer 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 parlantes !), formater le nouveau LV avec un système de fichiers ext4 et installer le système de manière traditionnelle. Chaque fois, cependant, l'installation de GRUB sera probablement écrasée par l'installeur, alors, quoi que vous fassiez, assurez-vous au préalable que la version d'Ubuntu que vous installez supporte réellement LVM sans bricolage ! Il suffit de lancer l'une des commandes, lvdisplay suffira, dans le terminal.

Une astuce utile : il est préférable de s'entraîner à installer Ubuntu sur un disque externe en utilisant un ordinateur dont le disque dur interne est déconnecté. Faire les choses de cette manière peut aider à éviter les petites erreurs, comme écraser le système du disque dur principal par inadvertance.

==== 6 ====
**
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 puisse sembler un peu trop pour une simple installation 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 in situ, et faire un disque de démarrage USB externe - il nous donne vraiment beaucoup de souplesse. Sans LVM, une partition doit correspondre exactement à un seul 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 réelles, je ne vous ai pas présenté l'ensemble des possibilités de LVM, loin de là. D'autres usages possibles sont, notamment, le chiffrage d'une partition complète, comme indiqué dans « Créer un PC à l'épreuve des voleurs » de Xavier Berger, dans le numéro 67 du Full Circle (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 miroir de LVM nous permet la réplication de données (deux copies de chaque élément), sans que nous devions tripoter 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 à vous encourager tous à jouer avec LVM ou au moins à explorer ses différentes possibilités. Mais, s'il vous plaît, pensez à votre sécurité : faites-le sur un ordinateur dont vous n'avez pas besoin pour le travail, que vous seriez heureux de formater si besoin et, évidemment, dont toutes les données sont correctement sauvegardées. Même les petites unités comme les clés USB sont suffisantes pour essayer LVM, bien que le système puisse ou ne puisse pas retrouver l'accès aux LV si vous débranchez la clé et la rebranchez à 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 bi-cœur devrait suffire) et qu'il reste de l'espace disque, ce serait certainement la méthode à suivre.