This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------aN7POPJjHvDp0UMeJ1F2bgE4
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

U2FsdmUgYSB0dXR0aS4NCkNvbiBsbyByaWVtcGlyc2kgZGkgLyBhdmV2byBzcG9zdGF0byAv dXNyIHN1IHVuYSBudW92YSBwYXJ0aXppb25lIA0KY29uZmlndXJhdGEgaW4gZnN0YWIgY29u DQoNClVVSUQ9Li4uIC91c3IgZXh0NCBkZWZhdWx0cyAwIDENCg0KVHV0dG8gb2suDQpPcmEg YWxsbyByaWVtcGlyc2kgZGkgL3VzciBobyBwcm92YXRvIGEgZmFyZSBsYSBzdGVzc2EgY29z YSBwZXIgL3Vzci9saWINCg0KVVVJRD0uLi4gL3VzciBleHQ0IGRlZmF1bHRzIDAgMQ0KVVVJ RD0uLi4gL3Vzci9saWIgZXh0NCBkZWZhdWx0cyAwIDENCg0KbWEgdHV0dG8gcXVlbGxvIGNo ZSBvdHRlbmdvIMOoIHVuIGtlcm5lbCBwYW5pYy4NCg0KQ29tZSBwZXIgaWwgcHJpbW8gc3Bv c3RhbWVudG8sIGhvIHVzYXRvIHVuYSBsaXZlIGUgY29waWF0byBjb24gY3AgLWEsIA0KaW1w b3N0YXRvIGZzdGFiIGUgcmlhdnZpYXRvLg0KDQpRdWFsY2hlIGlkZWE/DQoNCkdyYXppZSBw ZXIgbCdhdHRlbnppb25lLg0KUm9iZXJ0bw0K

--------------aN7POPJjHvDp0UMeJ1F2bgE4--

-----BEGIN PGP SIGNATURE-----

wnsEABEIACMWIQSfwWDHyPnBYemFelY1z9LQALRuwAUCY864rQUDAAAAAAAKCRA1z9LQALRuwCYA AP4rhPdr0wxTQoMRp5RIeC9fWNDonWqzgOvlBbaIpUQRmgEA3TMyE93vfbapFh8XXBSATJdzvoIC WMVGma2EcgtzEb8=
=741z
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Penso che il kernel panic dipenda dal fatto che /usr/lib e gia presente in
/usr e qundi risulta gia montata.

Il Lun 23 Gen 2023, 17:41 Roberto Balbi <roberto.balbi@aruba.it> ha scritto:

Salve a tutti.
Con lo riempirsi di / avevo spostato /usr su una nuova partizione
configurata in fstab con

UUID=... /usr ext4 defaults 0 1

Tutto ok.
Ora allo riempirsi di /usr ho provato a fare la stessa cosa per /usr/lib

UUID=... /usr ext4 defaults 0 1
UUID=... /usr/lib ext4 defaults 0 1

ma tutto quello che ottengo è un kernel panic.

Come per il primo spostamento, ho usato una live e copiato con cp -a, impostato fstab e riavviato.

Qualche idea?

Grazie per l'attenzione.
Roberto

<div dir="auto">Penso che il kernel panic dipenda dal fatto che /usr/lib e gia presente in /usr e qundi risulta gia montata.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il Lun 23 Gen 2023, 17:41 Roberto Balbi &lt;<a href="mailto:
roberto.balbi@aruba.it">roberto.balbi@aruba.it</a>&gt; ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Salve a tutti.<br>
Con lo riempirsi di / avevo spostato /usr su una nuova partizione <br> configurata in fstab con<br>

UUID=... /usr ext4 defaults 0 1<br>

Tutto ok.<br>
Ora allo riempirsi di /usr ho provato a fare la stessa cosa per /usr/lib<br>

UUID=... /usr ext4 defaults 0 1<br>
UUID=... /usr/lib ext4 defaults 0 1<br>

ma tutto quello che ottengo è un kernel panic.<br>

Come per il primo spostamento, ho usato una live e copiato con cp -a, <br> impostato fstab e riavviato.<br>

Qualche idea?<br>

Grazie per l&#39;attenzione.<br>
Roberto<br>
</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

La cosa bella dei panic e` che contengono un sacco di
informazione. Vedendo cosa dice il sistema sicuramente
qualcuno qui capisce cosa e` andato storto.

Escludo che sia "mount". E` possibile montare un albero su
una directory gia` popolata: semplicemente il nuovo albero
copre quello vecchio che non risulta piu` visibile (ma i file
gia` aperti restano aperti). Inoltre nessuna operazione normale
puo` dare panic, al massimo fallisce.

Mi aspetto, piuttosto, che manchi una delle librerie dinamiche
necessarie a /sbin/init per partire: se non si avvia init la cosa
e` fatale. E systemd ne usa tante, anche se nessuna sotto /usr
che puo` essere montato successivamenfe.

ps: /usr/lib non e` pensata per essere una parrizione separata: gli
eseguibili in /usr/bin usano librerie dinamiche che stanno in
/usr/lib, quindi separarle non e` una buona idea: durante l'avvio
abbiamo una fase in cui il sistema e` instabile.

/alessandro e devuan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il problema è quello che ha detto il rubi*, systemd richiede un sacco di moduli e librerie che si trovano dentro a /usr/lib e quando parte questi
non sono disponibili. Inoltre se usi una Debian moderna, probabilmente
hai già "usrmerge", ovvero /bin e /lib sono due link simbolici che
puntano a /usr/bin e /usr/lib. L'initrd utilizzato durante l'avvio sa
questa cosa e monta /usr immediatamente ma non può sapere che /usr/lib
sta da un'altra parte.

Se vuoi che tutto funzioni devi:

1) personalizzare il codice che va in initrd per eseguire il mount di
/usr/lib; oppure

2) fare un backup, formattare e reinstallare.

La prima opzione è più divertente, la seconda probabilmente più veloce e
dal risultato garantito.

federico

* per chi non lo conoscesse, il rubi ha sempre ragione.


On 24/01/23 10:02, Tarqui wrote:

Grazie per le risposte.
1. il montaggio di /usr in / non crea problemi quindi (dal mero punto di vista di mount) non dovrebbe crearne neanche il montaggio di /usr/lib in /usr.
2. mantenendo i dati della directory lib sulla partizione /usr, il boot avviene correttamente anche col successivo montaggio della partizione /usr/lib su di essa (contiene copie dei file).
3. il kernel panic indica "attempted to kill init!" che sarebbe il
processo pid 1 che fisicamente si chiama /usr/lib/systemd/systemd.
Ho provato a lasciare nella partizione di /usr solo la directory
lib/systemd, ma non risolve il problema. Probabile che servano altri contenuti collegati al processo di avvio (moduli, firmware, librerie, ...).

Dovrebbe essere possibile montare separatamente /usr/lib subito dopo una installazione minimale, senza toccare il contenuto della partizione
originale /usr ma clonandola sulla nuova partizione per /usr/lib. Però
in caso di variazioni a programmi di sistema suppongo che i dati
installati nella /usr/lib non essendo disponibili al successivo riavvio potrebbero ripresentare il problema.
Ergo: montare /usr/lib separatamente NON è una buona idea.

Opterò per link esterni a singole directory di programmi applicativi "spaziovori".

Grazie ancora a tutti. Buona giornata.
Roberto

Il 23/01/23 17:41, Roberto Balbi ha scritto:

Salve a tutti.
Con lo riempirsi di / avevo spostato /usr su una nuova partizione
configurata in fstab con

UUID=... /usr ext4 defaults 0 1

Tutto ok.
Ora allo riempirsi di /usr ho provato a fare la stessa cosa per /usr/lib

UUID=... /usr ext4 defaults 0 1
UUID=... /usr/lib ext4 defaults 0 1

ma tutto quello che ottengo è un kernel panic.

Come per il primo spostamento, ho usato una live e copiato con cp -a,
impostato fstab e riavviato.

Qualche idea?

Grazie per l'attenzione.
Roberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grazie per le risposte.
1. il montaggio di /usr in / non crea problemi quindi (dal mero punto di
vista di mount) non dovrebbe crearne neanche il montaggio di /usr/lib in
/usr.
2. mantenendo i dati della directory lib sulla partizione /usr, il boot
avviene correttamente anche col successivo montaggio della partizione
/usr/lib su di essa (contiene copie dei file).
3. il kernel panic indica "attempted to kill init!" che sarebbe il
processo pid 1 che fisicamente si chiama /usr/lib/systemd/systemd.
Ho provato a lasciare nella partizione di /usr solo la directory
lib/systemd, ma non risolve il problema. Probabile che servano altri
contenuti collegati al processo di avvio (moduli, firmware, librerie, ...).

Dovrebbe essere possibile montare separatamente /usr/lib subito dopo una installazione minimale, senza toccare il contenuto della partizione
originale /usr ma clonandola sulla nuova partizione per /usr/lib. Però
in caso di variazioni a programmi di sistema suppongo che i dati
installati nella /usr/lib non essendo disponibili al successivo riavvio potrebbero ripresentare il problema.
Ergo: montare /usr/lib separatamente NON è una buona idea.

Opterò per link esterni a singole directory di programmi applicativi "spaziovori".

Grazie ancora a tutti. Buona giornata.
Roberto

Il 23/01/23 17:41, Roberto Balbi ha scritto:

Salve a tutti.
Con lo riempirsi di / avevo spostato /usr su una nuova partizione
configurata in fstab con

UUID=... /usr ext4 defaults 0 1

Tutto ok.
Ora allo riempirsi di /usr ho provato a fare la stessa cosa per /usr/lib

UUID=... /usr ext4 defaults 0 1
UUID=... /usr/lib ext4 defaults 0 1

ma tutto quello che ottengo è un kernel panic.

Come per il primo spostamento, ho usato una live e copiato con cp -a, impostato fstab e riavviato.

Qualche idea?

Grazie per l'attenzione.
Roberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Inoltre se usi una Debian moderna, probabilmente
hai gia` "usrmerge", ovvero /bin e /lib sono due link simbolici che
puntano a /usr/bin e /usr/lib.

Che brutta cosa. Ci spieghi il razionale[1]? Sulle mie macchine tendo a
non usare initrd e usare kernel compilati da me (anche se ammetto che
nelle ultime installazioni non l'ho fatto) e questa cosa da`
fastidio. Sono della vecchia scuola "/ piccolo e /usr grande per
limitare i danni quando il disco si rompera`, perche` i dischi si
rompono sempre, come tutto il resto".

* per chi non lo conoscesse, il rubi ha sempre ragione.

ehe. Una volta. Ora il mondo e` troppo complesso e sono rimasto
indietro. Per esempio quando ho detto che systemd non linka liberie
in /usr/lib era sbagliato, perche` sulla macchina (non mia) in cui
ho verificato c'e` proprio quel usrmerge che tu dici.

[1] si, e` vero, lo si trova in rete, ma sentirlo da chi ci lavora davvero
e` diverso

grazie, saluti
/alessandro

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/01/23 11:51, Alessandro Rubini wrote:

Inoltre se usi una Debian moderna, probabilmente
hai gia` "usrmerge", ovvero /bin e /lib sono due link simbolici che
puntano a /usr/bin e /usr/lib.

Che brutta cosa. Ci spieghi il razionale[1]? Sulle mie macchine tendo a

Non sono un esperto della cosa ma il razionale che più mi convince è che
da sempre le varie distribuzioni hanno scelto in maniera completamente arbitraria cosa mettere in "/bin" e cosa in "/usr/bin". Tipo "dai,
Python è di sistema , mettiamolo in /bin/python" rispetto a "ma che
schifo fa Python? vabbè, gli utenti lo vogliono, mettiamolo come add-on
in /usr/bin". Questo causa alcuni problemi di portabilità di vari script
e/o eseguibili che chiamano programmi esterni. Si, OK, esisterebbe "env"
ma tanto nessuno lo usa... Mettendo tutto assieme si evita questo problema.

Poi c'è chi dice che così è più facile esportare "/usr" da rete per i
thin client ma sinceramente l'ultimo thin claient l'ho visto 20 anni fa...

non usare initrd e usare kernel compilati da me (anche se ammetto che
nelle ultime installazioni non l'ho fatto) e questa cosa da`
fastidio. Sono della vecchia scuola "/ piccolo e /usr grande per
limitare i danni quando il disco si rompera`, perche` i dischi si
rompono sempre, come tutto il resto".

Io uso initrd perché è comodo, anche con kernel compilati da me. Mi è successo più di una volta di avere un server che non partiva (dopo un aggiornamento lasciato a metà causa black-out per esempio) e di metterlo
a posto partendo in modalità "rescue" direttamente da initrd, senza
bisogno di chiavette USB, etc.

Sul "/" piccolo e "/usr" grande non saprei. Con initrd non importa molto
se quando si spacca il disco si spacca "/" o "/usr". Configurazione in
"/etc" ne faccio pochissima (4-5 file) e posso ricostruirla quasi a
memoria. Tutto il resto è praticamente read-only. Basta che non mi si
rompa la "/home" e sono contento... (tanto per dirti l'orrore a cui sono arrivato, sul portatile faccio una unica partizione con tutto dentro,
"/usr", "/home", tanto non ho la minima idea di come funzioni un NVMe e
di come possa rompersi!)

federico

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ciao,
mi intrometto anche io con i miei "2 cents"

Il giorno mar, 24/01/2023 alle 16.48 +0100, Federico Di Gregorio ha scritto:

On 24/01/23 11:51, Alessandro Rubini wrote:

Inoltre se usi una Debian moderna, probabilmente
hai gia` "usrmerge", ovvero /bin e /lib sono due link simbolici che puntano a /usr/bin e /usr/lib.

Che brutta cosa. Ci spieghi il razionale[1]? Sulle mie macchine tendo a

Non sono un esperto della cosa ma il razionale che più mi convince è che da sempre le varie distribuzioni hanno scelto in maniera completamente arbitraria cosa mettere in "/bin" e cosa in "/usr/bin". Tipo "dai,
Python è di sistema , mettiamolo in /bin/python" rispetto a "ma che
schifo fa Python? vabbè, gli utenti lo vogliono, mettiamolo come add-on
in /usr/bin". Questo causa alcuni problemi di portabilità di vari script e/o eseguibili che chiamano programmi esterni. Si, OK, esisterebbe "env"
ma tanto nessuno lo usa... Mettendo tutto assieme si evita questo problema.

Poi c'è chi dice che così è più facile esportare "/usr" da rete per i thin client ma sinceramente l'ultimo thin claient l'ho visto 20 anni fa...

Credo che la FHS indichi /bin per tutto quello che deve funzionare finché non ci sono gli altri file system montati (per il boot, per montare gli altri fs, una shell, eccetera). /usr/bin per tutti gli altri comandi. Con l'aggiunta che la /usr può essere esportata e condivisa, ma non solo per i thin client, anche per tutti i server diskless (questi sono un po' più diffusi dei thin client, anche se solo in alcuni contesti).

Aggiungo che systemd ha la unit local-fs.target. Chi parte al boot prima di questo target dovrebbe usare solo /bin, chi parte dopo dovrebbe poter usare anche /usr/bin e quindi dipendere da essa.

Ciao,
Giuseppe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)