Ubuntu: LVM config wordt niet goed opgeslagen

[Boudewijn]

Hoihoi

Ik heb een virtueel systeem dat zijn LVM config regelmatig kwijtraakt, best irritant... en ik kom er niet 1-2-3 meer uit.

Situatie:

Ubuntu 14.04, schone install op virtuele disk.
10x pv op 200gb disks, ook virtueel.

Het rootfs staat (by default...) in lvm, en de 10 (of 12, aantal boeit niet zo) pv's vormen samen 1 vg, en 1 lv.

Bij booten ko ik in busybox uit met de melding:

/dev/mapper/downloadbak--vg-root does not exist. dropping to a shell.

(Downloadbak is de hostname van die box, wat zou hij nou toch doen )

Vanaf daar kan ik natuurlijk mijn volumes ook niet mounten wegens gare lvm ondersteuning. Als ik de disks verwijder uit de vm (behalve de OS disk) werkt het prima. Voeg ik in runtime de disks toe en ga ik pvscan/vgscan/lvscan doen, dan werkt het ook top.

Maw: Mijn OS-disk pakt de verkeerde lv om vanaf te booten. Interessant, maar hoe los ik dat op? Het vervelende is dat ik de disk-volgorde niet aan lijk te kunnen passen; de OS disk is later pas toegevoegd.

Wat opvalt is dat in mijn lvm.conf na een reboot geen informatie over downloadbak--vg-root staat...

Maar goed, die staat wel in de backup:

code:

root@downloadbak:/etc/lvm# cat archive/downloadbak-vg_00000-77126147.vg
contents = "Text Format Volume Group"
version = 1
description = "Created *before* executing 'vgscan'"
creation_host = "downloadbak"   # Linux downloadbak 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64
creation_time = 1412012171      # Mon Sep 29 19:36:11 2014

downloadbak-vg {
        id = "bXft7r-7yQ0-TZBk-vdie-GckW-hc6D-w0i0Mk"
        seqno = 3
        format = "lvm2" # informational
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 8192              # 4 Megabytes
        max_lv = 0
        max_pv = 0
        metadata_copies = 0

        physical_volumes {

                pv0 {
                        id = "95kgng-QYdU-EgmS-4u3r-iD8R-6waW-6BXfkW"
                        device = "/dev/vda5"    # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 24662016     # 11.7598 Gigabytes
                        pe_start = 2048
                        pe_count = 3010 # 11.7578 Gigabytes
                }
        }

        logical_volumes {

                root {
                        id = "b2L5xU-9PBj-WcgP-MeBz-DyJj-oqGK-dUtKMx"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        creation_host = "downloadbak"
                        creation_time = 1412011783      # 2014-09-29 19:29:43 +0200
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 2748     # 10.7344 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 0
                                ]
                        }
                }

            *KNIP*

(heb irrelevante meuk geknipt).


Hoe kan ik hier het beste mee verder gaan? Tot nu toe zelden LVM-troubleshooting hoeven doen....

[Hero of Time]

Als je naar een initramfs shell wordt getrapt en je kan daar al je LVM niet vinden, is er meer aan de hand. Je zegt 'brakke LVM ondersteuning'. Leuk, maar weet je ook wat je daarmee zegt? Je geeft dan net HET probleem aan. Je initram kan geen LVM vinden, hoe zou 't dan je root file system moeten mounten? Oftewel, ga eens na of je schijf nog in orde is. Boot met een Live CD, installeer LVM en check of je dan je volumes kan vinden.

[Rainmaker]

Let erop dat een initramfs by default geen "degraded" VG up brengt.

Dus als 1 van de disken nog niet gedetecteerd is tijdens de vgchange -ay in de initramfs, wordt die VG en dus LV niet geactiveerd.

Er zou dan een melding boven moeten staan (iets met "use --degraded") tijdens de boot. Zet sowieso quiet en splash eens uit in de grub config, om te kijken of er meer meldingen naar boven komen.

Ik gok dat je udev net te lang erover doet om de device nodes aan te maken. Eigenlijk een bug in de dependencies van de init scripts (dus; report).
Maar eerst maar eens kijken of dat het probleem ook echt is.

*edit; in lvm.conf staat standaard ook geen PV / VG / LV info (alleen welke devices een PV mogen zijn). Soms zit er echter wel een .cache file in (/etc/lvm/.cache). Kijk ook even wat er gebeurd als je die verwijderd en een update-initramfs -u -k all draait.

[ Voor 17% gewijzigd door Rainmaker op 30-09-2014 22:57 ]

[Boudewijn]

Hero of Time schreef op dinsdag 30 september 2014 @ 20:25:
Als je naar een initramfs shell wordt getrapt en je kan daar al je LVM niet vinden, is er meer aan de hand. Je zegt 'brakke LVM ondersteuning'. Leuk, maar weet je ook wat je daarmee zegt? Je geeft dan net HET probleem aan. Je initram kan geen LVM vinden, hoe zou 't dan je root file system moeten mounten? Oftewel, ga eens na of je schijf nog in orde is. Boot met een Live CD, installeer LVM en check of je dan je volumes kan vinden.

Werkt prima, had dat idd al even getest. Voeg ik nu die disks toe aan die VM... zelfde shit.

Kennelijk dus een timeout gerelateerd issue zoals Rainmaker ook al denkt. Hoe kan ik dat efficient fixen? Het gaat inderdaad om veel disks... (12)

[CAPSLOCK2000]

rootdelay=30 meegeven aan de kernel (of natuurlijk een andere waarde) anders "echo sleep 30 > /etc/initramfs-tools/scripts/init-premount; chmod +x ... " en dan een nieuwe initramfs bakken.