Linux LVM w trybie rescue

artykuł pochodzi z mojej poprzedniej strony i został utworzony 23 stycznia 2011 zaraz po usuwaniu awarii domowego serwera. przyczyną awarii był sam admin, czyli ja :D

Kilkanaście minut temu artykuł znaleziony w necie uratował mnie od ponownej instalacji systemu…
Popełniłem gafę – zmniejszyłem rozmiar woluminu lvm dla / przed zmniejszeniem filesystemu ext3….
i niestety system przestał działać – reboot też nie pomógł!
Odpaliłem płytkę z Centosem 5.5 w trybie rescue i postąpiłem wg poniższej instrukcji, wystarczyło przywrócić wolumin lvm dla / do pierwotnej wielkości i zapuścić na filesystemie / e2fsck i zrebootować system… ;)

Późne godziny pracy mogą być przyczyną błędu ludzkiego. Na szczęście obeszło się bez reinstalacji. :D

Poniżej wskazówki, które mogą się przydać w krytycznej sytuacji.

artykuł ze strony:

http://dailypackage.fedorabook.com/index.php?/archives/159-System-Recovery-Week-Using-LVM-In-Rescue-Mode.html

System Recovery Week: Using LVM In Rescue Mode

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

Logical Volume Management (LVM) is a powerful storage system layer which abstracts the logical view of storage from the actual physical layout. It is automatically configured in the default Fedora storage configuration. LVM enables you to grow and shrink volumes, add storage from new devices to existing volumes, and migrate volumes between storage devices, all without taking the system offline. In fact, the system-config-lvm package provides a convenient way to perform all of these operations using a graphical interface.

However, you can’t (yet) shrink a filesystem while it is mounted. This isn’t a limitation of LVM itself, but of most filesystems, including ext3. To shrink a partition that is always mounted when the system is running — such as the root filesystem — it’s necessary to boot from another medium, which is where rescue mode comes in (see yesterday’s article). It may also be necessary to use rescue mode to recover from some particularly nasty corruption or misconfiguration issues.

To do LVM and filesystem-resizing work within the Fedora rescue mode, boot the rescue mode from disc as usual, but select Skip when the system offers to mount your hard-disk partitions. Unfortunately, this will mean that your volume groups will not be detected or activated, so you will need to do that manually.

The commands normally used for logical volume management such as vgdisplay, pvcreate, and lvreduce are actually symbolic links to a single executable named lvm. These symbolic links are not available in rescue mode, so you must explicitly use the lvm command followed by the operation you wish to perform: if you wish to do a vgscan, for example, enter the command lvm vgscan.

Therefore, to discover and activate all volume groups, you must execute these commands:

sh-3.2# lvm vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
sh-3.2# lvm vgchange -ay
2 logical volume(s) in volume group "VolGroup00" now active

You can display information about the logical volumes using lvm lvs (or lvm lvdisplay for a more verbose display):

sh-3.2# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
LogVol00 VolGroup00 -wi-a- 28.66G
LogVol01 VolGroup00 -wi-a- 992.00M

Note that the LV and VG names are not very descriptive — which is why it’s a good idea to override the default names during system installation. In this case, we know the approximate size of the LV containing the root filesystem, so we can determine that it is LogVol00 in VolGroup00.

Armed with this information, you can now check (fsck) the filesystem, shrink the filesystem within that logical volume, and then shrink the LV. Because of the potential for rounding errors, it’s best to shrink the filesystem to a size slightly smaller than the new LV size, resize the LV, and then grow the filesystem to fully fill the LV:

sh-3.2# e2fsck -f /dev/VolGroup00/LogVol00
e2fsck 1.40.2 (12-Jul-2007)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking refernce counts
Pass 5: Checking group summary information
/dev/VolGroup00/LogVol00: 122967/7514560 files (0.9% non-contiguous), 1113272/7512064 blocks
 
sh-3.2# resize2fs /dev/VolGroup00/LogVol00 19G
resize2fs 1.40.2 (12-Jul-2007)
Resizing the filesystem on /dev/VolGroup00/LogVol00 to 4980736 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 4980736 blocks long.
 
sh-3.2# lvm lvresize VolGroup00/LogVol00 --size 20G
WARNING: Reducing active logical volume to 20.00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]: y
Reducing logical volume LogVol00 to 20.00 GB
Logical volume LogVol00 successfully resized
 
sh-3.2# resize2fs /dev/VolGroup00/LogVol00
resize2fs 1.40.2 (12-Jul-2007)
Resizing the filesystem on /dev/VolGroup00/LogVol00 to 5242880 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 5242880 blocks long.

Note that the operations following the first resize2fs do not need to be performed in rescue mode — you can reboot the system at that point and continue after the system has booted normally. Earlier versions of the Fedora rescue mode may not set up the symbolic link /dev/VolumeGroup/LogicalVolume, so you may need to refer to /dev/mapper/VolumeGroup-LogicalVolume (e.g., use /dev/mapper/VolGroup00-LogVol00 in place of /dev/VolGroup00/LogVol00).

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

sysadmin/software engineer