Skip to content

LVM Systemd Service

Da ich neulich in ein Phänomen rein gelaufen bin, das ich so seit langem nicht mehr gesehen habe..

Kunde wollte einen SLES12 mit folgender Partitionierung haben...

Zwei interne Platten /boot als eigenes md Device ohne LVM... danach ein zweites md Device mit LVM

drauf.

Anscheinend hat sowohl SLES12 als auch OpenSuSE Leap mit dieser Partitionierung Alzheimer....

Beim durchbooten vergisst der LVM das Er seine Volgroup aktivieren soll

Über die Sinnhaftigkeit der Partitionierung kann man streiten... aber was solls...

Um das Problem zu lösen...

hab icch mir folgendes Systemd  Manifest zusammen gedübelt.

Description=LVM activation
DefaultDependencies=no


Before=local-fs.target
Before=basic.target shutdown.target
Conflicts=shutdown.target

[Service]
ExecStart=/sbin/vgchange --available y
Type=oneshot
TimeoutSec=0
RemainAfterExit=yes

[Install]
WantedBy=basic.target

Danach klappts auch wieder mit der Nachbarin LVM.

systemd aka crapware oder mounten war gestern

Meine Abneigung gegen System ist ja nichts grundsätzlich neues, da ich mir gestern im Büro ein Testsystem aufgesetzt habe, mit mehreren Platten drin hat sich bei der verwendeten SuSE ein interessanter Effekt eingestellt.

 

 Mar 24 15:01:28 installserver.site systemd[1]: Timed out waiting for device dev-mapper-vg_build\x2dsrc.device.
Mar 24 15:01:28 installserver.site systemd[1]: Dependency failed for /usr/src.
Mar 24 15:01:28 installserver.site systemd[1]: Dependency failed for Local File Systems.
Mar 24 15:01:28 installserver.site systemd[1]: Dependency failed for Remote File Systems (Pre).

 

Beim  Booten der Büchse ist beim Systemstart jedesmal der Device Mappe des LVM abgestorben. Im Redhat Bugtracker gibt's dazu auch ein Ticket.  Süss ist auch das da…. Im Archlinux Forum bin ich dann auf folgenden Workaround gestolpert.. 

Aber Leute ehrlich das kann es doch nicht sein. Der Dreck landet im kommenden RHEL 7 und im kommenden SLES…  diese SMF für Arme hat kein vernünftiges Loging der Services zumindest hab ich bisher keines gefunden.  

In der SMF krieg ich wenigstens Logs für jeden einzigen Service und wieso dieser fehlschlägt, bei Systemd fehlt das bisher völlig. Sowas soll in Enterprise Umgebungen einziehen?

Dont fuckin kiddin me... 

Der kleine Plattenleger: Resizing LVM Volumes

Heute morgen hab ich ein relativ nettes Ticket erhalten, Resizen von DB2 Directories.

Abgesehen vom Runterfahren des ganzen Gammels sollte ein Volume verkleinert werden und zwei Volumes mit dem abgeknappsten Diskspace erweitert werden. Eingesetztes FS ext3

Erster Schritt unmounten der Filesysteme nach DB/2 Stop:

umount /srv/db2/data1/
umount /srv/db2/home/
umount /srv/db2/var/

Filesystemcheck des zu verkleinernden Volumes


e2fsck -f /dev/mapper/vgdata-lvsrv_db2_data1

e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vgdata-lvsrv_db2_data1: 11/4980736 files (0.0% non-contiguous), 358644/19898368 blocks

Filesystemcheck auf die zu erweiternden Volumes

 

e2fsck -f /dev/mapper/vgdata-lvsrv_db2_var
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vgdata-lvsrv_db2_var: 11/196608 files (0.0% non-contiguous), 29901/786432 blocks

Shrinken des Filesystems:

 resize2fs /dev/mapper/vgdata-lvsrv_db2_data1 60G   ------> Den neuen Wert verwenden der alte Wert war 75 GB

resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/mapper/vgdata-lvsrv_db2_data1 to 15728640 (4k) blocks.
The filesystem on /dev/mapper/vgdata-lvsrv_db2_data1 is now 15728640 blocks long.

Nachdem das Filesystem geshrinkt wurde Im folgenden Schritt Das Logical Volume verkleinern.

Lvreduce auf das Logical Volume mit dem Neuen Wert:


lvreduce -L 60G /dev/mapper/vgdata-lvsrv_db2_data1

 WARNING: Reducing active logical volume to 60.00 GiB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lvsrv_db2_data1? [y/n]: y
  Reducing logical volume lvsrv_db2_data1 to 60.00 GiB
  Logical volume lvsrv_db2_data1 successfully resized





Erweitern der Logical Volumes:

lvextend -L +2G /dev/mapper/vgdata-lvsrv_db2_home

  Extending logical volume lvsrv_db2_home to 4.00 GiB
  Logical volume lvsrv_db2_home successfully resized

lvextend -L +12G /dev/mapper/vgdata-lvsrv_db2_var
  Extending logical volume lvsrv_db2_var to 15.00 GiB
  Logical volume lvsrv_db2_var successfully resized
root@s96srs2d0:/root : 

Growfs auf die einzelnen Logical Volumes:

Nach dem Aufblasen des Logical Volumes muss das  Filesystem wieder mit Hilfe von resize2fs erweitert werden.

Wie im Beispiel zu sehen ist..... der  fsck ist zwingend!


resize2fs /dev/mapper/vgdata-lvsrv_db2_home 4G

resize2fs 1.41.9 (22-Aug-2009)
Please run 'e2fsck -f /dev/mapper/vgdata-lvsrv_db2_home' first.


 e2fsck -f  /dev/mapper/vgdata-lvsrv_db2_home
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vgdata-lvsrv_db2_home: 11/131072 files (0.0% non-contiguous), 25405/524288 blocks
resize2fs /dev/mapper/vgdata-lvsrv_db2_home 4G -------> Wichtig den absoluten Endwert verwenden
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/mapper/vgdata-lvsrv_db2_home to 1048576 (4k) blocks.
The filesystem on /dev/mapper/vgdata-lvsrv_db2_home is now 1048576 blocks long.



resize2fs /dev/mapper/vgdata-lvsrv_db2_var 15G -------> Wichtig den absoluten Endwert verwenden
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/mapper/vgdata-lvsrv_db2_var to 3932160 (4k) blocks.
The filesystem on /dev/mapper/vgdata-lvsrv_db2_var is now 3932160 blocks long.




mount /srv/db2/data1/
mount /srv/db2/home/
mount /srv/db2/var/

Action completed.  smile

Du sollst nicht Spiegel aufreissen und Volume Manager kleben..

Notiz an mich selbst!!

Wenn Du wieder Kopfschmerzen hast.... Junge...

Don't mess with LVM2 fdisk and mdadm!!!

Ein nicht bootbares System könnte die Folge draus sein!!!

sfdisk -d /dev/sda | sfdisk /dev/sdb

 mdadm --zero-superblock /dev/sdb1  mdadm -a /dev/md0 /dev/sdb1  mdadm --manage /dev/md1 --remove /dev/sdb2  mdadm --zero-superblock /dev/sdb2  mdadm -a /dev/md1 /dev/sdb2 mdadm --zero-superblock /dev/sdb4 mdadm -a /dev/md1 /dev/sdb3

Personalities : [linear] [raid0] [raid1] md2 : active raid1 sda4[0] sdb4[1]       462881680 blocks super 1.0 [2/2] [UU]       bitmap: 0/4 pages [0KB], 65536KB chunk md0 : active raid1 sdb1[1] sda1[0]       1023936 blocks [2/2] [UU] md1 : active raid1 sdb3[1] sda3[0]       20479936 blocks [2/2] [UU] unused devices: <none> vgcfgrestore cloud -f /etc/lvm/archive/cloud_00003-767776368.vg Restored volume group cloud pvscan PV /dev/md2 VG cloud lvm2 [441.43 GiB / 381.43 GiB free] Total: 1 [441.43 GiB] / in use: 1 [441.43 GiB] / in no VG: 0 [0 ] # vgs VG #PV #LV #SN Attr VSize VFree cloud 1 2 0 wz--n- 441.43g 381.43g pvs PV VG Fmt Attr PSize PFree /dev/md2 cloud lvm2 a- 441.43g 381.43g # mount /dev/md2 /mnt/