[Guida] Chroot

[xavier77]

) Salve, la schermata vuole richiamare sul come sono consequenzializzati i comandi, ovvero prima la rimozione di /dev/sda2 colla efi e poi del sistema /dev/sda1 se ext4, o /dev/sdc1 se btrfs.

2 osservazioni, leggendo ora la wiki trovo:

Se presente, smontare l'eventuale partizione EFI con il comando:

sudo umount /dev/sda1 /mnt/boot/efi/

sostituendo eventualmente /dev/sda1 con la partizione EFI effettiva presente nel proprio sistema.

La partizione efi creata dall'installer da predefinito può essere solo /dev/sda2, che è la locazione standard di Window.

L'allocarla in altre locazioni è un'impostazione manuale da parte dell'utente, se la locazione è già occupata o non c'è quella di Window da utilizzare, tipicamente è il caso dei multiboot.

Inoltre è meglio specificare che altre distro possono avere il doppio subvolume, per restare in tema colla wiki ho già trovato delle Fedora col doppio volume, seppur i proprietari di regola cadono dal pero e non sanno com'è mai è così la struttura.

Se non si fosse capito, l'intento sarebbe semplificare la guida, non aggiungere ciccia sul fuoco (nei limiti del possibile), aggiungendo soltanto le informazioni davvero indispensabili.

Se si va a scorrere nella cronologia delle modifiche, si nota benissimo che prima (grosso modo fino alla versione 10) la guida consisteva di 6 semplici passaggi divisi in due paragrafi. Oggi il solo guardarla mi fa male agli occhi, consultarla mi fa venire il mal di testa...
Quindi chissene importa del doppio subvolume di altre distro, di dove Windows posiziona EFI ecc. Intendo che noi indichiamo la regola generale, il lettore individuerà le sue partizioni e addatterà i comandi al suo sistema.

Intanto ho iniziato una pagina di prova. Forse riuscirò a terminarla senza i miei soliti tempi biblici.

EDIT: dovrebbe rispondere solo:

Codice: Seleziona tutto

sudo umount /dev/sda2 /mnt/boot/efi/
umount: /dev/sda2: not mounted.
umount: /mnt: not mounted.
sudo umount /dev/sda3 /mnt/
umount: /dev/sda3: not mounted.
umount: /mnt: not mounted.

Ovvero ad indicare che lo smontaggio è eseguito, il no mount point specified non l'ho mai visto, salvo se sbaglio la sintassi ma allora si può vedere anche ben altro.

Ad esempio nel mio caso:

Codice: Seleziona tutto

wilecoyote@CactusField:~$ sudo mount -t ext4 /dev/sda7 /mnt
[sudo] password di wilecoyote: 
wilecoyote@CactusField:~$ for i in dev proc sys run; do sudo mount --bind /$i /mnt/$i; done
wilecoyote@CactusField:~$ sudo chroot /mnt
root@CactusField:/# echo $XDG_SESSION_TYPE && echo $DESKTOP_SESSION $XDG_CURRENT_DESKTOP && lsb_release -dcr && uname -rm

Pantheon
Description:    Pubuntu 22.04.1 LTS Jammy
Release:        22.04.1
Codename:       Jammy
5.15.0-57-generic x86_64
root@CactusField:/# exit
exit
wilecoyote@CactusField:~$ cd ~
wilecoyote@CactusField:~$ for i in /dev /proc /sys /run /; do sudo umount -l /mnt$i; done
wilecoyote@CactusField:~$ sudo umount /dev/sda7 /mnt
umount: /dev/sda7: not mounted.
umount: /mnt: not mounted.
wilecoyote@CactusField:~$

Ti sei accorto che l'output è identico (indipendentemente che la root sia su sda3 o sda7)????
Della serie fatti una domanda e datti una risposta.

[wilecoyote]

) Salve, l'output c'avrebbe 1 differenza:

sudo umount /dev/sda2 /mnt/boot/efi/
umount: /dev/sda2: not mounted.
umount: /mnt/boot/efi/: no mount point specified

Se s'indica nello smontaggio della partizione efi /dev/sda1, allora dovrebbe parimenti essere indicata così anche nel montaggio.

:: Ciao

[xavier77]

...contrariamente ai pronostici ce l'ho fatta a finirla la pagina di prova!
andreas-xavier/prova4

• aggiunte informazioni nell'intro (unica parte che ho arricchito)
• riorganizzato o riscritto il resto della guida, sforbiciando dove si poteva. Spero che la parte "pratica" sia più chiara e scorrevole da leggere.

Visto che c'ero ho installato una VM Ubuntu in btrfs. Rimangono sempre i dubbi espressi negli interventi precedenti, ossia sull'ultimissima parte con l'ultimo umount. Di buono c'è che almeno sono comandi che non dovrebbero compromettere nulla.

Chiederei di dare un'occhiata anche a @iononsbalgiomai @emanuc che in passato avevano detto la loro, ma come sempre ogni osservazione è benvenuta.

@wilecoyote
Consiglio generale: (se possibile) è bene non esagerare con gli anchor all'interno delle guide, perché in caso di modifiche corpose c'è sempre il rischio che qualcuno vada perso. Inoltre evita o limita passaggi del tipo «riprendere dal punto 4» o simili (con le riscritture quel numero potrebbe cambiare e se l'editore di turno non se ne accorge...).

[emanuc]

...contrariamente ai pronostici ce l'ho fatta a finirla la pagina di prova!
andreas-xavier/prova4

• aggiunte informazioni nell'intro (unica parte che ho arricchito)
• riorganizzato o riscritto il resto della guida, sforbiciando dove si poteva. Spero che la parte "pratica" sia più chiara e scorrevole da leggere.

Visto che c'ero ho installato una VM Ubuntu in btrfs. Rimangono sempre i dubbi espressi negli interventi precedenti, ossia sull'ultimissima parte con l'ultimo umount. Di buono c'è che almeno sono comandi che non dovrebbero compromettere nulla.

Chiederei di dare un'occhiata anche a @iononsbalgiomai @emanuc che in passato avevano detto la loro, ma come sempre ogni osservazione è benvenuta.

@wilecoyote
Consiglio generale: (se possibile) è bene non esagerare con gli anchor all'interno delle guide, perché in caso di modifiche corpose c'è sempre il rischio che qualcuno vada perso. Inoltre evita o limita passaggi del tipo «riprendere dal punto 4» o simili (con le riscritture quel numero potrebbe cambiare e se l'editore di turno non se ne accorge...).

Siamo su Ubuntu e quindi gli utenti si ritroveranno (ad oggi) con il subvolume "@" e gli utenti non hanno bisogno di montare il toplevel(radice filesystem):

Codice: Seleziona tutto

Per partizioni con file system btrfs con due subvolumi (impostazione predefinita di Ubuntu):

sudo mount -t btrfs -o subvol=@ /dev/sda3 /mnt
Per partizioni con file system btrfs:

sudo mount -t btrfs /dev/sda3 /mnt

Da cambiare con:

Codice: Seleziona tutto

Per partizioni con file system btrfs con due subvolumi (impostazione predefinita di Ubuntu):

sudo mount -t btrfs -o subvol=@ /dev/sda3 /mnt

E l'umount:

Codice: Seleziona tutto

Per partizioni con file system btrfs con due subvolumi (impostazione predefinita di Ubuntu):

sudo umount -t btrfs -o subvol=@ /dev/sda3 /mnt
Per partizioni con file system btrfs:

sudo umount -t btrfs /dev/sda3 /mnt

Con:

Codice: Seleziona tutto

Per partizioni con file system btrfs:

sudo umount /dev/sda3 /mnt

Il comando "umount" non ha nessun flag "-o"

[wilecoyote]

) Salve,

Siamo su Ubuntu e quindi gli utenti si ritroveranno (ad oggi) con il subvolume "@" e gli utenti non hanno bisogno di montare il toplevel(radice filesystem):

Per partizioni con file system btrfs con due subvolumi (impostazione predefinita di Ubuntu):

sudo mount -t btrfs -o subvol=@ /dev/sda3 /mnt
Per partizioni con file system btrfs:

sudo mount -t btrfs /dev/sda3 /mnt

Da cambiare con:

Per partizioni con file system btrfs con due subvolumi (impostazione predefinita di Ubuntu):

sudo mount -t btrfs -o subvol=@ /dev/sda3 /mnt

E l'umount:

Per partizioni con file system btrfs con due subvolumi (impostazione predefinita di Ubuntu):

sudo umount -t btrfs -o subvol=@ /dev/sda3 /mnt
Per partizioni con file system btrfs:

sudo umount -t btrfs /dev/sda3 /mnt

Con:

Per partizioni con file system btrfs:

sudo umount /dev/sda3 /mnt

Il comando "umount" non ha nessun flag "-o"

Konsole non m'hai dato nessun error usando l'opzione -o con umount, mai dubitato della correttezza.

Però l'indicazione del file system, -t btrfs, serve, già avuto grattacapi pella mancanza.

Invece il comando del toplevel(radice filesystem) serve, non è affatto detto che s'usi il Chroot per accedere ad un Ubuntu in panne, mi capita normalmente d'accedere ad altre distro in panne.

@xavier77 basta dattilografarlo di ridurre gli anchor, cercavo di ridurre le ripetizioni già segnalate come prolissità zavorrante la wiki.

:: Ciao

[xavier77]

Adesso che ho una VB btrfs continuo con questa per i miei test.
Sistema "normale" come il seguente:

Codice: Seleziona tutto

Dispositivo    Start     Fine  Settori  Size Tipo
/dev/sda1       2048   487423   485376  237M EFI System
/dev/sda2     487424 33103871 32616448 15,6G Linux filesystem
/dev/sda3   33103872 33552383   448512  219M Linux swap

Disco /dev/sda: 17,2GB
Dimensione del settore (logica/fisica): 512B/512B
Tabella delle partizioni: gpt
Flag del disco: 

Numero  Inizio  Fine    Dimensione  File system     Nome  Flag
 1      1049kB  250MB   249MB       fat32                 avvio, esp
 2      250MB   16,9GB  16,7GB      btrfs
 3      16,9GB  17,2GB  230MB       linux-swap(v1)        swap

Ma andiamo al chroot (da live):

Codice: Seleziona tutto

[manjaro@manjaro ~]$ sudo mount -t btrfs -o subvol=@ /dev/sda2 /mnt
[manjaro@manjaro ~]$ sudo mount -t vfat /dev/sda1 /mnt/boot/efi/
[manjaro@manjaro ~]$ sudo chroot /mnt
root@manjaro:/# lsb_release -d
Description:	Ubuntu 22.04.1 LTS
root@manjaro:/# exit
exit
[manjaro@manjaro ~]$ for i in /dev /proc /sys /run /; do sudo umount -l /mnt$i; done
[manjaro@manjaro ~]$ sudo umount /dev/sda1 /mnt/boot/efi/
umount: /dev/sda1: not mounted.
umount: /mnt/boot/efi/: no mount point specified.
[manjaro@manjaro ~]$ sudo umount -t btrfs -o subvol=@ /dev/sda2 /mnt
umount: opzione non valida -- "o"
Try 'umount --help' for more information.
[manjaro@manjaro ~]$ sudo umount -t btrfs subvol=@ /dev/sda2 /mnt
umount: subvol=@: no mount point specified.
umount: /dev/sda2: not mounted.
umount: /mnt: not mounted.

Considerazioni al volo:

• stesso output "not mounted/no mount point specified" per lo smontaggio della part. EFI. Ma siamo sicuri che sia scritto bene???
• l'opzione "-o" con umount non va bene (e me ne ero accorto già ieri per la cronaca). Come diceva anche emanuc, nonostante wilecoyote affermi che a lui non accade mai........... EDIT: consultato man di umount. "Stranamente" l'opzione "-o" non esiste (esiste solo su mount).
• Rimangono le mie perplessità anche sull'ultimo comando (già espresse negli interventi prima), che a questo punto prescndono anche dal FS in uso.
• Ricordo in passato sporadici casi di errore dopo chroot in cui umount restituiva l'output "target is busy" (o simile), che mi pare si possano bypassare con force o lazy (quando è abbastanza sicuro farlo). Questo però, a rigor di logica, riguarderebbe più una guida su mount/umount che il chroot...

Tolgo solo l'opzione "-o" dalla pagina di prova andreas-xavier/prova4. Aspetto altri pareri per ulteriori modifiche.

PS: @wilecoyote quello sugli anchor era solo un consiglio generale, come infatti avevo scritto.

[wilecoyote]

) Salve, il manuale di umount l'ho consultato dopo aver letto dell'inesistenza dell'opzione -o, confermo la mancanza della segnalazione d'errore in Konsole o Yakuake.

Vedo d'approfondire la questione.

Nel frattempo ho fatto luce sui comandi per smontare i sistemi, è un problema coi miei alias, faccio largo uso del chroot.

Nella wiki è così:

Codice: Seleziona tutto

for i in /dev /proc /sys /run /; do sudo umount -l /mnt$i; done

Nel mio alias invece è così:

Codice: Seleziona tutto

for i in /dev /proc /sys /run; do sudo umount -l /mnt$i; done

Manca il / dopo il /run, probabilmente ho copiato un'altra versione del comando.

:: Ciao

[xavier77]

) Salve, il manuale di umount l'ho consultato dopo aver letto dell'inesistenza dell'opzione -o, confermo la mancanza della segnalazione d'errore in Konsole o Yakuake.

Vedo d'approfondire la questione.

Nel frattempo ho fatto luce sui comandi per smontare i sistemi, è un problema coi miei alias, faccio largo uso del chroot.

Nella wiki è così:

Codice: Seleziona tutto

for i in /dev /proc /sys /run /; do sudo umount -l /mnt$i; done

Nel mio alias invece è così:

Codice: Seleziona tutto

for i in /dev /proc /sys /run; do sudo umount -l /mnt$i; done

Manca il / dopo il /run, probabilmente ho copiato un'altra versione del comando.

:: Ciao

... OK, siamo risaliti alla causa. Bene.
PS: ricordi quando insistevo nel chiederti di usare (per i test per il wiki) sistemi non personalizzati, meglio se macchine virtuali? Ecco, non erano indicazioni date a caso o per capriccio.

[wilecoyote]

) Salve, il mio hardware è idiosincratico a virtualizzazione, wayland e snap…

Mentre io sono idiosincratico a spendere centinaia di euri per sostituire ciò che ancora funziona bene…

:: Ciao

[xavier77]

Salve, il mio hardware è idiosincratico a virtualizzazione, wayland e snap.
Mentre io sono idiosincratico a spendere centinaia di euri per sostituire ciò che ancora funziona bene…

La VM che ho usato prima è di un core e 2 GB di RAM. Che puoi avviare su una qualsiasi Linux host, se hai un PC almeno dual core 4 GB di RAM, chiudendo magari gli altri programmi.
Oppure puoi farti una partizione dedicata con le impostazioni di default.
O anche, quando si può fare ai fini del test, usi una live, un sistema su USB, hdd esterno, ecc. ecc.
Il sistema c'è sicuramente, per non fare test su sistemi ultracustomizzati che danno risultati inattendibili (come hai visto).

[emanuc]

Invece il comando del toplevel(radice filesystem) serve, non è affatto detto che s'usi il Chroot per accedere ad un Ubuntu in panne, mi capita normalmente d'accedere ad altre distro in panne.

Se lasci quel comando dovresti anche scrivere i passaggi per accedere al chroot dal toplevel.

opzione con mount subvolume:

Codice: Seleziona tutto

sudo mount -t btrfs -o subvol=@ /dev/sda3 /mnt

Da qui in poi il percorso dei vari comandi non cambia rispetto a "ext4" perché hai già montato il rootfs.

opzione con il mount del toplevel:

Codice: Seleziona tutto

sudo mount -t btrfs /dev/sda3 /mnt

Codice: Seleziona tutto

sudo mount -t vfat /dev/sda2 /mnt/@/boot/efi/

Codice: Seleziona tutto

for i in dev proc sys run; do sudo mount --bind /$i /mnt/@/$i; done

Codice: Seleziona tutto

sudo chroot /mnt/@

Questo perché quando monti il toplevel di Btrfs su un installazione di Ubuntu standard, ad oggi mostra le cartelle dei subvolumi di rootfs(@) e di home(@home) e non direttamente il rootfs.
Per semplificare la guida toglierei quella parte, altrimenti si deve aggiungere i percorsi giusti e a questo punto la guida diventerebbe troppo lunga e confusa.

Per il resto la guida mi sembra ok.

[xavier77]

Per il resto la guida mi sembra ok.

Grazie!
Stai parlando della guida o della pagina di prova
andreas-xavier/prova4
?

[wilecoyote]

) Salve,

Invece il comando del toplevel(radice filesystem) serve, non è affatto detto che s'usi il Chroot per accedere ad un Ubuntu in panne, mi capita normalmente d'accedere ad altre distro in panne.

Se lasci quel comando dovresti anche scrivere i passaggi per accedere al chroot dal toplevel.

Anche in sistemi senza il subvol=@ ?

Non esiste solo Ubuntu, perché ad oggi sono entrato tranquillamente in sistemi senza il sottovolume @.

:: Ciao

[emanuc]

Per il resto la guida mi sembra ok.

Grazie!
Stai parlando della guida o della pagina di prova
andreas-xavier/prova4
?

Si, scusa mi riferisco alla.pagina di prova

[emanuc]

) Salve,

Invece il comando del toplevel(radice filesystem) serve, non è affatto detto che s'usi il Chroot per accedere ad un Ubuntu in panne, mi capita normalmente d'accedere ad altre distro in panne.

Se lasci quel comando dovresti anche scrivere i passaggi per accedere al chroot dal toplevel.

Anche in sistemi senza il subvol=@ ?

Non esiste solo Ubuntu, perché ad oggi sono entrato tranquillamente in sistemi senza il sottovolume @.

:: Ciao

La wiki non è dedicata a Ubuntu e derivate?
Comunque ad oggi la maggior parte delle distro crea subvolume su btrfs, anche Debian 11.

[xavier77]

Grazie @emanuc!

Disclaimer:
personalmente mi sarei concentrato sui casi "concreti", se no avrei dovuto aggiungere (esempio banale): «con filesystem ext2, con con filesystem ext3 ecc.».

Adotterei quindi la classica soluzione di compromesso: la nota.

L'esempio precedente è relativo ad un sistema btrfs con due subvolumi, impostazione predefinita di Ubuntu e di molte altre distribuzioni GNU/Linux.
Qualora sia invece necessario il chroot del top level, può essere omessa l'opzione -o subvol=@, ma nei comandi successivi andrà specificato il punto di mount /mnt/@ anziché /mnt (anche per le relative sotto-directory).

Confido sul fatto che chi usa btrfs in maniera "avanzata" e consapevole, sarà sicuramente in grado di modificarsi i comandi da solo senza fare meccanicamente il copia/incolla.

Detto ciò:

• controllate se la guida va bene (e che non abbia scritto castronerie nella nota).
• se va tutto bene e non ci sono altre segnalazioni, procederei fra un po' con il copia/incolla.

[emanuc]

Qualora sia invece necessario il chroot del top level, può essere omessa l'opzione -o subvol=@

Specificherei se l'utente non ha nessun subvolume, altrimenti ha sempre senso montare la radice del filesystem, che il subvolume si chiami "ciccio", "@", "root" o "rootfs" nel caso di Debian basta cambiare il parametro: "subvol"*".
Alla fine per fare il chroot devi montare la radice del filesystem.

[xavier77]

Fatto il copia/incolla dalla pagina di prova.
Se c'è ancora altro fare sapere, come al solito.

[emanuc]

Per me va bene

[wilecoyote]

) Salve, a proposito di -o subvolume=@ posto l'esempio del mio Lubuntu Focal 20.04.5 LTS, sì quello che ho usato per provare la conversione da ext4 a Btrfs, e che ho pure massacrato cogli esperimenti più folli.

Stasera non sono riuscito ad avviarlo, provando ad accedervi, per ripararlo, tramite chroot dal Kubuntu Jammy 22.04.1 LTS ottengo questo:

Codice: Seleziona tutto

wilecoyote@CactusField:~$ sudo mount -t btrfs -o subvol=@ /dev/sda3 /mnt
[sudo] password di wilecoyote: 
mount: /mnt: mount(2) system call failed: File o directory non esistente.
wilecoyote@CactusField:~$ sudo mount -t btrfs /dev/sda3 /mnt
wilecoyote@CactusField:~$ for i in dev proc sys run; do sudo mount --bind /$i /mnt/$i; done
wilecoyote@CactusField:~$ sudo chroot /mnt
root@CactusField:/#

Ovverosia in mancanza del sottovolume mi da errore, ovvero proprio ciò che ho cercato di spiegare.

:: Ciao