Il volume LVM è inattivo dopo il riavvio di CentOS


9

Ho reinstallato un server Linux da CentOS 6 a 7. Il server ha 3 unità: un'unità SSD di sistema (ospita tutto tranne /home) e due unità HDD da 4 TB che ospitano /home. Tutto usa LVM. Le due unità da 4 TB sono speculari (usando l'opzione raid all'interno di LVM stesso) e sono completamente riempite con la partizione / home.

Il problema è che sebbene i dischi da 4 TB vengano riconosciuti correttamente e LVM rilevi il volume senza problemi, non lo attiva automaticamente. Tutto il resto viene attivato automaticamente. Posso attivarlo manualmente e funziona.

Ho un'immagine della vecchia unità di sistema in / home. Ciò contiene anche volumi LVM. Se lo monto con kpartx, e LVM li raccoglie e li attiva. Ma non vedo alcuna differenza tra quei volumi e quelli inattivi.

Anche il filesystem di root è LVM, e questo si attiva bene.

Vedo una cosa singolare però: l'esecuzione lvchange -aaymi dice che devo specificare quali unità voglio attivare. Non lo fa neanche automaticamente. Se lo specifico lvchange -ay lv_home, funziona.

Non riesco a trovare nulla che possa essere responsabile di questo comportamento.

Aggiunto: ho notato che il vecchio sistema (che utilizzava init) aveva vgchange -aay --sysinitnei suoi script di avvio. Il nuovo usa systemd e non vedo la vgchangechiamata nei suoi script. Ma non so nemmeno dove metterlo.

Aggiunto 2: iniziare a capire systemd. Ho scoperto dove si trovano gli script e ho iniziato a capire come vengono chiamati. Ho anche scoperto che potevo vedere gli script eseguiti con systemctl -al. Questo mi mostra che dopo l'avvio lvmetadchiama pvscanper ogni dispositivo di blocco udev noto. Tuttavia a quel punto c'è solo un dispositivo a blocchi udev registrato, e questo è uno dei volumi lvm riconosciuti. Ci sono anche i dischi rigidi, ma con percorsi diversi e nomi molto più lunghi. Il dispositivo a blocchi riconosciuto è qualcosa di simile 8:3, mentre i dischi rigidi sono simili /device/something/. Non sono più sul server, quindi non posso scriverlo con precisione (risolverò più tardi).

Penso che abbia qualcosa a che fare con udev e rilevamento / mappatura dei dispositivi. Continuerò la sera e studierò udev allora.

Se tutto il resto fallisce, ho trovato lo script che chiama pvscane ho verificato che posso modificarlo per scansionare tutti i dispositivi in ​​ogni momento. Ciò risolve il problema, ma sembra un trucco piuttosto brutto, quindi proverò a capire la vera causa principale.

Aggiunto 3 : OK, non so ancora perché questo accada, ma almeno ho fatto una soluzione abbastanza accettabile. Ho creato un altro servizio systemd che chiama pvscanuna volta, subito dopo l'avvio lvmetad. L'altra chiamata per il dispositivo specifico è ancora lì, e penso che in realtà udevlo chiami (è l'unico posto in cui ho trovato riferimento ad esso). Perché non lo chiama per gli altri dischi rigidi - non ne ho idea.


I servizi di sistema LVM sono in esecuzione? Questo mi è successo.
Naftuli Kay,

@NaftuliTzviKay - Sì, i servizi stanno iniziando bene (almeno lo lvmetadè - non ne ho notato altri).
Vilx-

C'era un altro servizio il cui nome mi sfugge al momento.
Naftuli Kay,

@NaftuliTzviKay - Hmm ... c'era anche un qualche tipo di servizio di "monitoraggio". Anche questo inizia bene, anche se ricordo di aver letto cosa fa e di essere giunto alla conclusione che non mi riguarda. Al momento non ho accesso alla casella, quindi ricontrollerò più tardi.
Vilx-

Risposte:


7

L'ho fatto! L'ho fatto! L'ho riparato correttamente (penso).

Ecco la storia:

Dopo qualche tempo il server si è rivelato difettoso e ha dovuto essere demolito. Ho tenuto i dischi e ho ottenuto tutto il resto nuovo. Quindi ho reinstallato nuovamente CentOS sull'unità SSD e quindi ho collegato gli HDD. LVM ha funzionato bene, i dischi sono stati riconosciuti, la configurazione mantenuta. Ma lo stesso problema si è ripresentato: dopo un riavvio, il volume era inattivo.

Comunque questa volta ho notato qualcos'altro: il bootloader passa i seguenti parametri al kernel:

crashkernel = auto rd.lvm.lv = centos / root rd.lvm.lv = centos / swap rhgb quiet

Hmm, aspetta un attimo, quelli sembrano FAMILIARI !

Query google veloce, ed eccoci qui :

rd.lvm.lv =

attiva solo i volumi logici con il nome indicato. rd.lvm.lv può essere specificato più volte sulla riga di comando del kernel.

Bene ora. Questo lo spiega!

Quindi, la risoluzione è stata (raccolta da molte altre query di Google):

  1. Modifica /etc/defaults/grubper includere il volume aggiuntivo nei parametri:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
  2. Riconfigura grub con grub2-mkconfig -o /boot/grub2/grub.cfg
  3. Riconfigurare initramfs con mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64. Nota: i tuoi valori possono variare. Utilizzare uname -rper ottenere quella versione del kernel. O continua a leggere mkinitrd. (Francamente, non so perché questo passaggio sia necessario, ma a quanto pare lo è - ho provato senza di esso e non ha funzionato)
  4. E infine, reinstalla grub: grub2-install /dev/sda
  5. Riavvia, naturalmente.

TA-DA! Il volume è attivo al riavvio. Aggiungilo fstabe divertiti! :)


2

Aggiornamento secondario (per RHEL 7 su computer EFI (non BIOS) ):

Ho successo con questi passaggi:

  1. Modifica /etc/defaults/grubper includere il volume aggiuntivo nei parametri: rd.lvm.lv=rhel/home(oltre a rhel/roote rhel/swap)
  2. Riconfigura grub con

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    

    ( nota: un altro percorso!)

  3. Riconfigurare initramfs con

    mkinitrd -f -v /boot/initramfs-$(uname -r).img $(uname -r)
    
  4. Skip reinstalla grub: grub2-install /dev/sda(perché ho una directory vuota /usr/lib/grub/)
  5. Riavvia, naturalmente.

Hmm, sembra che tu stia usando EFI. Nel mio caso era una scatola del BIOS, quindi è probabilmente il motivo della differenza.
Vilx-

Sì, è una lama x240. Ho aggiunto una nota su EFI.
gennaio

@ Vilx- Esiste una soluzione alternativa proposta da un fornitore per questo errore. Ma è davvero brutto. Essi propongono di aggiungere _netdevbandiera per fstab, consentire chkconfig netfs one anche spegnere use_lvmetad = 0il lvmetadin /etc/lvm/lvm.confproprio nella speranza dispositivi si ri-polling e ripresa ...
Jno

Siamo spiacenti, non riesco a vederlo, dal momento che non sono un cliente RedHat. Ma non vedo perché le nostre soluzioni non siano corrette ed è necessaria una soluzione alternativa. Voglio dire, questo non è un bug - tutto funziona come dovrebbe.
Vilx-

Penso che sia un bug: root e swap sono elencati esplicitamente nel cmdline del kernel mentre home non lo è. Quindi, abbiamo due volumi LVM montati e uno penzolante nello stato "inattivo". Ho citato la loro proposta qui esattamente per evitare la necessità di specifiche credenziali di accesso :)
jno

1

Ho avuto anche questo problema. Nel mio caso era una combinazione di iscsi, multipath e lvm e l'ordinamento della creazione della sessione ecc. Ho risolto il problema aggiungendo una chiamata /sbin/vgchange -a ya /etc/rc.local.


0

Quindi ho provato rd.lvm.lv = impostazione in / etc / default / grub e non ha funzionato

Avevo bisogno che entrambi i volumi logici nel gruppo di volumi ssd_vg fossero attivi all'avvio. Oltre al volume logico home_lv su kubuntu-vg per essere attivo

Ciò che ha funzionato è stato modificare /etc/lvm/lvm.conf Nella sezione dell'elenco dei volumi inserirla in volume_list = ["ssd_vg", "kubuntu-vg / home_lv"]

risultato dopo il riavvio

$ sudo lvscan inattivo Originale '/ dev / kubuntu-vg / root' [50.00 GiB] eredita

inactive          '/dev/kubuntu-vg/swap_1' [7.88 GiB] inherit

ACTIVE            '/dev/kubuntu-vg/home_lv' [1000.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap11' [50.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap12' [50.00 GiB] inherit

ACTIVE            '/dev/ssd_vg/root' [224.02 GiB] inherit

ACTIVE            '/dev/ssd_vg/swap_1' [7.88 GiB] inherit

0

Da parte mia, ho commentato questa riga in /etc/lvm/lvm.conf

auto_activation_volume_list = [ "vg00", "vg01" ]

Perché se è attivo, all'avvio sono attivi solo i volumi vg00 e vg01.

La documentazione di lvm.conf:

If auto_activation_volume_list is defined, each LV that is to be
activated with the autoactivation option (--activate ay/-a ay) is
first checked against the list. There are two scenarios in which
the autoactivation option is used:

  - automatic activation of volumes based on incoming PVs. If all the
    PVs making up a VG are present in the system, the autoactivation
    is triggered. This requires lvmetad (global/use_lvmetad=1) and udev
    to be running. In this case, "pvscan --cache -aay" is called
    automatically without any user intervention while processing
    udev events. Please, make sure you define auto_activation_volume_list
    properly so only the volumes you want and expect are autoactivated.

  - direct activation on command line with the autoactivation option.
    In this case, the user calls "vgchange --activate ay/-a ay" or
    "lvchange --activate ay/-a ay" directly.

By default, the auto_activation_volume_list is not defined and all
volumes will be activated either automatically or by using --activate ay/-a ay.

N.B. The "activation/volume_list" is still honoured in all cases so even
if the VG/LV passes the auto_activation_volume_list, it still needs to
pass the volume_list for it to be activated in the end.

If auto_activation_volume_list is defined but empty, no volumes will be
activated automatically and --activate ay/-a ay will do nothing.

auto_activation_volume_list = []

If auto_activation_volume_list is defined and it's not empty, only matching
volumes will be activated either automatically or by using --activate ay/-a ay.

  "vgname" and "vgname/lvname" are matched exactly.
  "@tag" matches any tag set in the LV or VG.
  "@*" matches if any tag defined on the host is also set in the LV or VG


Only activate vg00 and vg01 automatically.
auto_activation_volume_list = [ "vg00", "vg01" ]
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.