niente boot dopo aumento dimensioni root con lvm

Se avete problemi con l'installazione e la configurazione di Slackware64 postate qui. Non usate questo forum per argomenti che trattano la Slackware32 o generali... per quelli usate rispettivamente il forum Slackware e Gnu/Linux in genere.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware64 usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
emmexx
Linux 0.x
Linux 0.x
Messaggi: 67
Iscritto il: lun gen 05, 2009 14:37
Slackware: current
Kernel: 4.19.75
Desktop: kde

niente boot dopo aumento dimensioni root con lvm

Messaggioda emmexx » mar set 24, 2019 22:10

Slackware 14.2 su notebook xiaomi mi air 12.5

Ho avuto la bella idea di aumentare la dimensione dei volumi logici che uso con lvm. I 2 volumi sono uno per la root e l' altro per la directory /home
Dopo aver riavviato si sono verificati 2 problemi in fasi successive.

fase 1
Il sistema non si avvia piu'. Nei messaggi a video si blocca tutto nel momento in cui viene fatto il mount della root. Non riesco ad essere piu' preciso a causa del problema della fase 2

fase 2
Per provare a riaccedere al sistema ho riavviato da cd usando systemrescuecd. Per fare questo ho dovuto modificare le opzioni del bios. Dopo alcuni tentativi ci sono riuscito ma quando ho provato a ripristinare le precedenti opzioni del bios per riprovare ad avviare slackware, non ci sono riuscito, non parte piu' il bootloader di slackware ma uno di windows che non so nemmeno da dove salta fuori visto che ho piallato windows 30 secondi dopo avere ricevuto il notebook.
I file del nb sembrano a posto, nel senso che con un mount riesco ad accedere al filesystem ed a leggere i file.

Domande

1. Non credo di aver fatto errori estendendo i volumi logici. Avrei dovuto fare anche qualche altra operazione prima di riavviare?
2. Una volta si poteva avviare slackware da floppy. Non si puo' fare qualcosa di simile con una chiavetta usb da usare solo per avviare slackware installato sul notebook (sempre che sia possibile)?
3. Come faccio per sistemare bios/efi in modo che al boot venga eseguita la partizione con efi? Ho iisto che esiste efibootmgr ma non ho capito se lo devo usare dal terminale di systemrescuecd o se devo fare un chroot ed eseguirlo da lì.

Ogni suggerimento è benvenuto

grazie
maxx

p.s. sono riuscito a sistemare il problema della mancanza della voce di avvio nel bios usando efibootmgr da systemrescuecd.
Ora quindi il boot avviene correttamente sino a quando appaiono a video le seguenti righe:

Codice: Seleziona tutto

...
insmod /lib/modules/4.4.14/kernel/fs/ext4/ext4.ko
  1 logical volume(s) in volume group "myvg" now active
mount: mounting /dev/myvg/root on /mnt failed: No such file or directory
ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
       You can try to fix it. Type 'exit' when things are done.

/bin/sh: can' t access tty: job control turned off


A questo punto ho provato il comando vgscan che mi ha risposto con:

Codice: Seleziona tutto

Couldn' t find device with uuid abc...
Couldn' t find device with uuid xyz...
Found volume group "myvg" using metadata type lvm2


Ho il sospetto che l'aggiunta di spazio da 2 partizioni diverse da quella su cui si trovava myvg abbia fatto casino.
La configurazione di prima era la seguente:
disco fisico con partizione /dev/sda2
gruppo myvg in cui ho creato 2 volumi: root e home

Il disco aggiuntivo /dev/sdb ha 2 partizioni che ho aggiunti ai 2 volumi esistenti
/dev/sdb1 lo ho aggiunto a /dev/myvg/root
/dev/sdb2 lo ho aggiunto a /dev/myvg/home

Probabilmente in fase di boot /dev/sdb non è ancora visibile o montato e questo blocca tutto.

C'è modo di rimediare o di tornare indietro?

emmexx
Linux 0.x
Linux 0.x
Messaggi: 67
Iscritto il: lun gen 05, 2009 14:37
Slackware: current
Kernel: 4.19.75
Desktop: kde

Re: niente boot dopo aumento dimensioni root con lvm

Messaggioda emmexx » ven set 27, 2019 10:58

Aggiornamento (a futura memoria).

Purtroppo non sono riuscito a ripristinare la situazione alla configurazione precedente l'aggiunta delle nuove partizioni.

Ho provato a ridimensionare il volume logico in cui si trovava la root ma, immagino per mia ignoranza, in qualche passaggio devo aver sballato le dimensioni. Dopo aver fatto resizefs e lvreduce la dimensione presente nel superblock e quella fisica risultavano differenti. Ho seguito alcune indicazioni trovate in rete dando il comando mkfs -S ma mi sono ritrovato con il volume accessibile ma vuoto.

Per fortuna non ho fatto operazioni sul volume logico con la mia directory home, ne ho fatto un backup ed ho piallato e reinstallato tutto.

Sono piuttosto deluso da lvm, sicuramente a causa di mia ignoranza, ma avevo impiegato parecchio tempo a configurare il sistema proprio per poter utilizzare lvm nel caso avessi voluto aggiungere dischi o cambiare le dimensioni delle partizioni. Ma al primo utilizzo di questa funzione si e' incriccato tutto. Quindi suggerisco di fare bene attenzione a chi decide di usarlo.

ciao
maxx

hashbang
Packager
Packager
Messaggi: 1975
Iscritto il: ven giu 04, 2010 10:27
Nome Cognome: Luca De Pandis
Distribuzione: macOS Catalina
Località: Lecce / Bergamo / Milano
Contatta:

Re: niente boot dopo aumento dimensioni root con lvm

Messaggioda hashbang » mar ott 08, 2019 19:05

emmexx ha scritto:A questo punto ho provato il comando vgscan che mi ha risposto con:

Codice: Seleziona tutto

Couldn' t find device with uuid abc...
Couldn' t find device with uuid xyz...
Found volume group "myvg" using metadata type lvm2


Ho il sospetto che l'aggiunta di spazio da 2 partizioni diverse da quella su cui si trovava myvg abbia fatto casino.
La configurazione di prima era la seguente:
disco fisico con partizione /dev/sda2
gruppo myvg in cui ho creato 2 volumi: root e home

Il disco aggiuntivo /dev/sdb ha 2 partizioni che ho aggiunti ai 2 volumi esistenti
/dev/sdb1 lo ho aggiunto a /dev/myvg/root
/dev/sdb2 lo ho aggiunto a /dev/myvg/home
Non capisco il senso di partizionare il secondo disco per darlo allo stesso VG. Non potevi dare diretto il disco al VG e poi dare la quantità di spazio necessaria al singolo LV? Così si usa LVM, non facendo come hai fatto tu.

Tip: quando si usa LVM usare sempre dischi interi. Mai dare porzioni di disco. LVM è fatto per scalare su array di dischi eliminando il concetto stesso di partizionamento, che viene definito ad un livello superiore (gli LV).


Probabilmente in fase di boot /dev/sdb non è ancora visibile o montato e questo blocca tutto.
Cos'è /dev/sdb? Immagino sia un disco SATA collegato, e non un disco USB, giusto?

C'è modo di rimediare o di tornare indietro?
Se hai fatto resize del file system, io sconsiglio vivamente di ridurre i due LV. Lo shrink lato file system, per quanto possa essere supportato, non è mai una operazione sicura, perché per quanto un file system possa scrivere in maniera contigua, non si è mai sicuri che qualche cluster non venga perso durante il ridimensionamento.
Lo storage non si riduce, o si allarga o lo si tiene uguale.

emmexx
Linux 0.x
Linux 0.x
Messaggi: 67
Iscritto il: lun gen 05, 2009 14:37
Slackware: current
Kernel: 4.19.75
Desktop: kde

Re: niente boot dopo aumento dimensioni root con lvm

Messaggioda emmexx » mar ott 08, 2019 19:42

hashbang ha scritto:Non capisco il senso di partizionare il secondo disco per darlo allo stesso VG. Non potevi dare diretto il disco al VG e poi dare la quantità di spazio necessaria al singolo LV? Così si usa LVM, non facendo come hai fatto tu.

Come ho scritto, sono partito da un sistema che aveva un disco che con lvm avevo diviso in 2 unità logiche.
Ora non ricordo perché ho deciso di partizionare il secondo disco, probabilmente lo ho letto su qualche guida ma potrei anche essermi sbagliato. Non credo comunque che questo avrebbe cambiato il blocco al boot del sistema.

Tip: quando si usa LVM usare sempre dischi interi. Mai dare porzioni di disco. LVM è fatto per scalare su array di dischi eliminando il concetto stesso di partizionamento, che viene definito ad un livello superiore (gli LV).

Credo che per un po' farò a meno di LVM, almeno sul mio pc principale. Per altre situazioni valuterò.

Cos'è /dev/sdb? Immagino sia un disco SATA collegato, e non un disco USB, giusto?

Un disco nvme interno.

Se hai fatto resize del file system, io sconsiglio vivamente di ridurre i due LV. Lo shrink lato file system, per quanto possa essere supportato, non è mai una operazione sicura, perché per quanto un file system possa scrivere in maniera contigua, non si è mai sicuri che qualche cluster non venga perso durante il ridimensionamento.
Lo storage non si riduce, o si allarga o lo si tiene uguale.

Quello che scrivi mi sembra ragionevole ma leggendo la documentazione di lvm e svariate guide, la riduzione dei volumi sembra semplice quanto l'allargamento.
Sicuramento avrò sbagliato io qualche passaggio (anche se, visto che c'era in gioco la perdita di dati e una reinstallazione del sistema, ho letto e riletto documentazione e varie guide) ma, almeno in teoria, le nuove unità logiche le ho solo aggiunte, non ci ho fatto altro, non ho aggiunto o spostato file, togliendo quel che avevo aggiunto sarei dovuto tornare alla situazione di partenza. Invece mi sono ritrovato con unità logica e partizione con vari giga di dimensione di differenza.

Diciamo che questa è l'ennesima riprova che è meglio fare dei test su unità di test prima che su unità di produzione. Questo è il mio pc personale con cui lavoro ma il discorso vale lo stesso. :-(

grazie
maxx

hashbang
Packager
Packager
Messaggi: 1975
Iscritto il: ven giu 04, 2010 10:27
Nome Cognome: Luca De Pandis
Distribuzione: macOS Catalina
Località: Lecce / Bergamo / Milano
Contatta:

Re: niente boot dopo aumento dimensioni root con lvm

Messaggioda hashbang » mar ott 08, 2019 20:09

emmexx ha scritto:Ora non ricordo perché ho deciso di partizionare il secondo disco, probabilmente lo ho letto su qualche guida ma potrei anche essermi sbagliato. Non credo comunque che questo avrebbe cambiato il blocco al boot del sistema.
Probabilmente no, visto che il ramdisk non ha trovato entrambi gli UUID dei dischi. Ma rimane comunque una configurazione errata.

Un disco nvme interno.
OK, naturalmente non si può andare più in là con l'analisi, visto che hai "rollbackato" la configurazione. L'ideale in quei casi è comunque "farsi un giro" all'interno del ramdisk per capire in che stato è il disco, ovvero: se è visibile lato block e se è possibile forzare uno scan dei PV. Si deve procedere per gradi, partendo dalla situazione "fisica" e spostandosi via via verso l'astrazione, altrimenti non ne vieni a capo.

Quello che scrivi mi sembra ragionevole ma leggendo la documentazione di lvm e svariate guide, la riduzione dei volumi sembra semplice quanto l'allargamento.
Sicuro che è facile. Mai detto il contrario.
La sintassi del comando non è diversa da un grow. Il punto è che non si fa. Anche i file system possono venire shrinkati, ma per best practice non si dovrebbe mai fare, perché la corruzione dei dati è dietro l'angolo, quando si tratta di dati allocati in posizioni specifiche di un disco.

emmexx
Linux 0.x
Linux 0.x
Messaggi: 67
Iscritto il: lun gen 05, 2009 14:37
Slackware: current
Kernel: 4.19.75
Desktop: kde

Re: niente boot dopo aumento dimensioni root con lvm

Messaggioda emmexx » mar ott 08, 2019 21:05

hashbang ha scritto:OK, naturalmente non si può andare più in là con l'analisi, visto che hai "rollbackato" la configurazione. L'ideale in quei casi è comunque "farsi un giro" all'interno del ramdisk per capire in che stato è il disco, ovvero: se è visibile lato block e se è possibile forzare uno scan dei PV. Si deve procedere per gradi, partendo dalla situazione "fisica" e spostandosi via via verso l'astrazione, altrimenti non ne vieni a capo.

Non ho più l'età per queste cose... ;-)
Se lo facessi per mestiere avrebbe sicuramente senso, studiare cose poco note per un singolo PC quando mi serviva solamente tornare operativo, non avrebbe avuto molto senso.
Se avessi perso l'accesso alla partizione con i miei dati ci avrei anche provato. Ma quando ho iniziato il rollback un barlume di ragione mi ha impedito di fare l'operazione su entrambi i volumi logici.

La sintassi del comando non è diversa da un grow. Il punto è che non si fa. Anche i file system possono venire shrinkati, ma per best practice non si dovrebbe mai fare, perché la corruzione dei dati è dietro l'angolo, quando si tratta di dati allocati in posizioni specifiche di un disco.

Giuro che lo shrink non lo faccio più! :-)

Grazie per le utili indicazioni tecniche.

maxx