Dotaz: lvm přiřadilo stejné dm dvoum logical volumes?

[chinook]

Zdravím, na jednom server jsem vytvořil logical volume o velikosti 550G.

Když jsem na ně začal něco kopírovat přes dd, vypsalo to hlášku po zkopírování 20G, že došlo místo. Bohužel to odpovída lv-rootu. Jak je to možné, že to dostalo stejné dm?

root@kvm2:~# ll /dev/vg1/vg1-lv-testovaci-server
lrwxrwxrwx 1 root root 7 Sep 28  2020 /dev/vg1/vg1-lv-testovaci-server -> ../dm-4
root@kvm2:~# ll /dev/mapper/vg1-vg1--lv--root
lrwxrwxrwx 1 root root 7 Sep 19 10:45 /dev/mapper/vg1-vg1--lv--root -> ../dm-4

Vše na serveru zatím běží, ale nevím co s tím. Restart se obávám nepřežije a příkaz nejde spustit skoro žádný. Ale jede rsync, tak jsem se tam nakopíroval df a mount.

df ukazuje na rootu velikost disku 61Z.

Jak to opravit, nejlépe za chodu? Běží mně tam nějaké virtuální servery. Mám zálohu souborového systému, tedy /

---

---

Odpovědi

[chinook]

Tak nevím co se stalo :(

ls -la /dev/disk/by-id/dm-name-vg1-vg1--lv--root
lrwxrwxrwx 1 root root 10 Sep 19 10:45 /dev/disk/by-id/dm-name-vg1-vg1--lv--root -> ../../dm-4
root@kvm2:~# ls -la /dev/disk/by-id/dm-name-vg1-vg1--lv--testovaci--server
lrwxrwxrwx 1 root root 10 Sep 19 09:48 /dev/disk/by-id/dm-name-vg1-vg1--lv--testovaci--server -> ../../dm-3
root@kvm2:~#

[chinook]

Příloha:

• spatnej-den.mp4 (617961 bytů)

Ty jo, tak tomu říkám špatnej den.

Nakopíroval bych / ze zálohy do tmpfs nebo někam (pokud nemáš "někam", sežeň si busybox-static ve kterém je mount), chrootnul se do něho a tím máš funkční systém. Pak bych vyrobil nové LV, na něm FS a nakopíroval / do něj. Pak je potřeba upravit fstab, konfiguraci grubu a přegenerovat initramfs, aby to nabootovalo z nově pojmenovaného LV -- nebo můžeš staré LV zkusit přejmenovat a nové LV vyrobit se stejným názvem, ale to nevím jestli půjde, když je zatím aktivní.

[chinook]

Postup mě posunul, ale nedaří sem ně to opravit. Novou lv se mně nedaří vytvořit.

lvcreate -L20G -n vg1-lv-root2 vg1
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  /dev/vg1/vg1-lv-root2: not found: device not cleared
  Aborting. Failed to wipe start of new LV.

Ale použil jsem nějakou která tam již byla a nakopíroval tam / ze zálohy, ale nedaří se mně upgradovat grub

mount /dev/vg1/vg1-lv-vm-backups /mnt
$ mount --bind /dev /mnt/dev
$ mount --bind /dev/pts /mnt/dev/pts
$ mount --bind /proc /mnt/proc
$ mount --bind /sys /mnt/sys
$ chroot /mnt
$grub-install --boot-directory=/mnt/boot /dev/sda
Installing for i386-pc platform.
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.

Zkusil jsem v lvm.conf vypnout use_lvmetad = 0 ale nepomohlo to. Co s tím?

[k3dAR]

rve to ze mas GPT bez oddilu s priznakem bios_grub, kterej pri pouziti GPT je pouzivan na instalaci grubu-pc (bios/legacy)...
urcite si mel pretim pouzit grub-pc? nemel si spis grub-efi?

btw: kdyz udelas chroot do /mnt, tak grub-install nemusis volat s parametrem --boot-directory a uz vubec ne s =/mnt/boot kdyz v tom chrootu to mas v /boot
btw2: kdyz uz zacinas v postupu znakem $ pred commandem, tak ti tam chybi bud sudo, nebo pro poustene jako root # misto $

[chinook]

Těžko říct co tam bylo.

V záloze i na disku /dev/sda1 mám boot a tam je:

root@kvm2:/# ll /boot/
total 54087
drwxr-xr-x  4 root root     1024 Mar 11  2022 .
drwxr-xr-x 20 root root     4096 Sep 21 16:16 ..
-rw-r--r--  1 root root   186696 Jan 20  2020 config-4.9.0-12-amd64
-rw-r--r--  1 root root   186766 Mar  7  2022 config-4.9.0-18-amd64
drwxr-xr-x  5 root root     1024 Mar 11  2022 grub
-rw-r--r--  1 root root 19897001 Dec 28  2021 initrd.img-4.9.0-12-amd64
-rw-r--r--  1 root root 19915040 Mar 11  2022 initrd.img-4.9.0-18-amd64
drwx------  2 root root    12288 Oct  5  2017 lost+found
-rw-r--r--  1 root root  3206712 Jan 20  2020 System.map-4.9.0-12-amd64
-rw-r--r--  1 root root  3217463 Mar  7  2022 System.map-4.9.0-18-amd64
-rw-r--r--  1 root root  4261664 Jan 20  2020 vmlinuz-4.9.0-12-amd64
-rw-r--r--  1 root root  4265760 Mar  7  2022 vmlinuz-4.9.0-18-amd64
root@kvm2:/# fdisk -l /dev/sda
Disk /dev/sda: 3.3 TiB, 3598914158592 bytes, 7029129216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 71CF70F8-838A-4A61-B206-8B9420A85A88

Device      Start        End    Sectors  Size Type
/dev/sda1    2048     391167     389120  190M Linux filesystem
/dev/sda2  391168 7029127167 7028736000  3.3T Linux LVM

Ale také je možné, že se tam dříve používalo grup-pc a ted efi. A ta partition /dev/sda1 tam zůstala. V fstabu není namapovaná. Je možné, že ji někdo namapoval ručně a dostala se mně tedy do záloh. Jak poznám co tam bylo?

Klidně vytvořím efi. Jen nevím jak to udělat. Hlavně at to pak nabootuje.

[chinook]

Prosím Tě, jak poznat jestli tam bylo EFI, případně jak to mám opravit? Je mně jedno jak to bude bootovat a klidně tam může být něco jiného než bylo. Hlavně ať to nabootuje až to restartnu.

[Jendа]

Prosím Tě, jak poznat jestli tam bylo EFI

Tak, že existuje EFI partition a je na ní GRUB. (to samozřejmě neříká že nemůže být současně _i_ legacy ale to by se člověk musel trochu snažit)

[chinook]

Pokud to musí být na zvláštní partition, tak tam EFI nebylo. A server vždy bez problémů bootoval. grub-install má problém, že tam je GPT bez oddilu s priznakem bios_grub. Jak to tedy opravit? A proč to řve? Jediné co se tam poškodilo byla ta root partition na LVM. Se diskem sda se nic nedělalo.

fdisk -l /dev/sda
Disk /dev/sda: 3.3 TiB, 3598914158592 bytes, 7029129216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 71CF70F8-838A-4A61-B206-8B9420A85A88

Device      Start        End    Sectors  Size Type
/dev/sda1    2048     391167     389120  190M Linux filesystem
/dev/sda2  391168 7029127167 7028736000  3.3T Linux LVM


mount | grep sda
/dev/sda1 on /boot type ext2 (rw,relatime)
root@kvm2:/# ll /boot/
total 54087
drwxr-xr-x  4 root root     1024 Mar 11  2022 .
drwxr-xr-x 20 root root     4096 Sep 26 12:35 ..
-rw-r--r--  1 root root   186696 Jan 20  2020 config-4.9.0-12-amd64
-rw-r--r--  1 root root   186766 Mar  7  2022 config-4.9.0-18-amd64
drwxr-xr-x  5 root root     1024 Mar 11  2022 grub
-rw-r--r--  1 root root 19897001 Dec 28  2021 initrd.img-4.9.0-12-amd64
-rw-r--r--  1 root root 19915040 Mar 11  2022 initrd.img-4.9.0-18-amd64
drwx------  2 root root    12288 Oct  5  2017 lost+found
-rw-r--r--  1 root root  3206712 Jan 20  2020 System.map-4.9.0-12-amd64
-rw-r--r--  1 root root  3217463 Mar  7  2022 System.map-4.9.0-18-amd64
-rw-r--r--  1 root root  4261664 Jan 20  2020 vmlinuz-4.9.0-12-amd64
-rw-r--r--  1 root root  4265760 Mar  7  2022 vmlinuz-4.9.0-18-amd64

[Jendа]

A server vždy bez problémů bootoval.

Nj, tak buď zázrak, nebo to předtím někdo nějak doprasil…

Každopádně /boot bylo zvlášť a nepoškodilo se, tak bys vlastně na GRUB nemusel vůbec sahat, ne?

Zkus jestli to nabootuje v qemu a uvidíš (pozor pokud to bude chtít připojit nějaké FS automaticky pro zápis, tak aby se nepřipojily ze dvou míst současně). qemu-system-x86_64 -enable-kvm -m 1G -hda /dev/sda

[chinook]

QEMU výbornej nápad zkusím. Teoreticky by tedy stačilo vytvořit to LVM, změnit v fstab a mělo by to naběhnout?

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# 

/dev/mapper/vg1-vg1--lv--root /               ext4    errors=remount-ro 0       1
 /boot was on /dev/sda1 during installation
UUID=cab5217c-fd49-4745-9e44-96e3186b0b9f /boot           ext2    defaults        0       2
/dev/mapper/vg1-vg1--lv--home /home           ext4    defaults        0       2
/dev/mapper/vg1-vg1--lv--log /var/log        ext4    defaults        0       2
/dev/mapper/vg2-vg2--lv--swap none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0


qemu-system-x86_64 -enable-kvm -m 1G -hda /dev/sda
WARNING: Image format was not specified for '/dev/sda' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
Could not initialize SDL(No available video device) - exiting

[Jendа]

Bohužel mi přišlo, že jádru nestačí dát root= parametr na commandline, ale je to nahardcodované někde v initramdisku, takže ještě přegenerovat ten, aby tam byla nová cesta.

[k3dAR]

- pro EFI bys mel mit separatni oddil FAT/FAT32 s priznakem boot a esp, ten nemas
- grub mas vychozi ted grub-pc, protoze pru grub-install to vola "Installing for i386-pc platform" coz je to -pc aka legacy/bios
- disk mas type: gpt
- EFI bezne pouziva "gpt", Legacy/BIOS bezne pouzva "msdos"
- to zda HW bootuje v EFI ci Legacy/BIOS je vec jeho nastaveni v BIOSu, muzes tam mit moznost Oboje, JedEFI, JenLegacy

takze to na me pusobi (tim ze nemas ani EFI ani bios)grub oddil), ze si mel:
- bootovani pres legacy
- disk type: msdos

a neco/nekdo ti predelal msdos na gpt takze asi nejjednodusi bude to prevest na msdos:

sudo gdisk /dev/sda
r
g

a pak nainstalovat grub tak jak si zkouset kdyz to rvalo ze nema grub_bios, kterej pri MBR uz nepotrebuje, mozna pred grubem jeste ocuchat znovu oddily:

sudo partprobe /dev/sda

[Jendа]

a neco/nekdo ti predelal msdos na gpt takze asi nejjednodusi bude to prevest na msdos:

Ten disk má 3TiB, takže to nepůjde, ne?

[trekker.dk]

Hlavně je to na 99.9% zbytečné, ještě jsem nepotkal počítač, co by nebyl schopen udělat legacy boot z GPT disku.

[chinook]

Nakonec to bylo celkem easy.

Nakopiroval jsem zálohu na nové lvm, upravil fstab, ale zapomněl jsem přegenerovat initramfs. Server nenaběhl.

Nabootoval jsem live distro z USB. Kupodivu všechna LVM vypadala v pořádku i symlinky. Zkusil jsem namountovat lv-root. To samozřjmě nešlo, protože bylo přepsáno. Zformátoval jsem je. Nahrál vše ze zálohy. A server bez problémů naběhl.

Zajimavé je, že pak i inkriminované LV, které původně ukazovalo na LV-root, je již v pořádku a můžu na ně zapisovat jak chci. Na čem ty symlinky záleží, že po bootu vypadají jinak?

Všem děkuji za rady.

[Jendа]

Zkusil jsem namountovat lv-root. To samozřjmě nešlo, protože bylo přepsáno. Zformátoval jsem je. Nahrál vše ze zálohy. A server bez problémů naběhl.

Aha, no tohle by samozřejmě bylo to co bych udělal, myslel jsem, že je to nepřípustné (~hodina downtime, nebo že vůbec nemáš tu možnost nabootovat z USB a dostat se na konzoli - že je to nějaký vzdálený server a management tohle neumí, například).

[chinook]

V normálním provozu by to nešlo. Tím, že byl druhý den svátek, jsem to risknul. Hlavně, jsem měl strach, že výpadek, bude delší, nakonec to bylo asi za 20min. zprovozněno, což nebylo tak zlý.

Samozřejmě by bylo lepší, kdyby se to jen restartovalo a server naběhl.

[k3dAR]

Ten disk má 3TiB, takže to nepůjde, ne?

to sem prehlidl, vychazel sem z toho ze jde o GPT a neni ani EFI ani bios_grub oddil,
takze asi jde o HW co umi prasacky Legacy z GPT bez potrebneho bios_grub oddilu...

[Jendа]

/dev/vg1/vg1-lv-root2: not found: device not cleared

A ten /dev jsi nabindoval i tady?

[chinook]

Co tím myslíš?

Udělal jsem:

mount --bind /dev /mnt/dev
atd.
pak
chroot /mnt

A pak jsem chtěl vytvořit to lvm. Ale píše to tu chybu.

lvcreate -L20G -n vg1-lv-root vg1

/dev/vg1/vg1-lv-root2: not found: device not cleared

[trekker.dk]

Ohledně co s tím, už vám odpovídají jiní, já jenom dodám k tomu "proč" - protože zařízení v /dev/, které odpovídá příslušné LV, je jedině /dev/dm-X. Všechno ostatní jsou symlinky, které dynamicky vytváří a maže udev a ten to občas po***e. Už jsem na to párkrát narazil taky, ale naštěstí to vždycky podchytila nějaká kontrola předtím, než se tam to dd pustilo automaticky.

[chinook]

Nikdy se mně to nestalo. Jak tedy ideálně překontrolovat, že se lv vytvořilo v pořádku? Mám na serverech klidně 30lv na jednom vg. Nevíc /dev/mapper/lv mně ukazuje něco jineho než /dev/vg/lv. Každý odkazuje na jiný symlink.

[trekker.dk]

Jo, tak na to můžu říct jenom "dobrá otázka". Vzhledem k tomu, že mě to nikdy nepokousalo takovým způsobem jako vás, tak jsem nad tím nepřemejšlel. Takhle z fleku mě napadá akorát kontrolovat si, že všechny symlinky v /dev/mapper ukazují na unikátní cíl. Nebo si ověřit major a minor čísla toho zařízení v porovnání s výstupem lvs -v

V /dev/mapper by mělo být /dev/mapper/vg-lv a pokud to ukazuje někam jinam než /dev/vg/lv, tak bych řekl, že jedno z toho ukazuje blbě.