Newsgroup: it.comp.os.linux.iniziare
Titolo: Partizionare per triplo boot Linux

Ciao a tutti,
 
ho necessità di formattare un hard disk SATA da 240 GB ospitare
 tre sistemi operativi Linux differenti.
 
/boot      1GB
/swap     4GB (= RAM)
/OS1       10GB
/OS2       20GB
/,OS3      200GB
 
Domande:
 
1) Va bene la dimensione della partizione di boot?
 
2) Mi ricordo che una volta veniva indicato il doppio della RAM
 come dimensione, nel mio caso però è probabile che la SWAP non
 venga mai usata, sia per il modesto carico di lavoro, sia perché
 i sistemi non andranno mai in ibernazione;
 
3) Come mi devo comportare con GRUB? Devo installarlo ad ogni
 installazione per ciascun sistema operativo o lo posso installare
 solo alla fine quando installo il terzo?
 
Grazie a tutti per i consigli.

 ha scritto:

4) GPT o MBR?
-- 

 venga mai usata
Se sei certo di avere sufficiente ram, nulla ti obbliga ad avere swap.
 
r2...@outer.space:~$ free -mh
              total        used        free      shared  buff/cache   available
Mem:          7.7Gi       4.3Gi       758Mi       319Mi       2.6Gi       2.5Gi
Swap:            0B          0B          0B
 
Eventualmente suggerisco una partizione swap unica per tutti i SO.

 /,OS3      200GB
 
Che tu voglia partizionere/formattare è un conto, e ovviamente sei
libero di farlo, ma non è strettamente necessario perché durante
l'installazione sarà l'installer stesso a chiederti al momento opportuno
se vuoi partizionare il disco, formattare o eventualmente ridimensionare
qualche partizione già esistente.
 
Noto una estrema disparità nelle dimensioni delle partizioni; perché? e
quali distro per /OS1, /OS2 e /OS3 hai intenzione di installare?
 
Una partizione separata per /boot non è necessaria. Non è per caso che
ti stai confondendo con la partizione formattata FAT32 per EFI?
Nel qual caso l'installer di Ubuntu 20.04 me l'ha creata da 500 MB.
 
Nelle ultime versioni di Ubuntu anche la swap non è più necessaria
perché usa uno swapfile che genera automaticamente durante
l'installazione. Da me su un portatile non troppo recente con 4 GB di
RAM ha una dimensione di 2.1 GB.
 

 solo alla fine quando installo il terzo? 
 
grub è problematico per gestire multiple installazioni linux e non è la scelta migliore. in ogni caso, lo devi installare *solo* alla prima installazione mentre le altre dovrai gestirle a mano, ogni volta entrando nella prima installazione. 

 di aver esaurito la ram disponibile.
 
lo fa anche linux se è per questo. il comportamento dello swap è regolato da parametri del kernel e di default inizia ad usare lo swap quando la memoria fisica arriva ad essere occupata al 60%.
considera che ad occupare memoria concorre anche la cache, quindi a quella quota ci arriva facilmente anche a sistema scarico.
diciamo che se gli metti a disposizione lo swap lui di default cerca di usarlo per riservare la memoria fisica a quello che lui valuta ottimale per le performance. poi ovviamente tutto è tunabile in base alle esigenze.
 

 concorre anche la cache,
 
Questa cosa non l'ho mai capita. Perché scrivere su disco quando c'è la ram
libera al 40%? Cache o non cache, non vedo il vantaggio. Infatti vivo felice
senza swap.
 

 ha scritto:

https://chrisdown.name/2018/01/02/in-defence-of-swap.html
 
-- 

 senza swap.
 
Perche` per motivi prestazionali e`
meglio scrivere prima di arrivare
al 99.99% di memoria occupata.
 
Ad ogni modo, l'uso dello swap
dipende dal tipo di uso che si
puo` prevedere il PC faccia.
 
E` spesso sconsigliato per i server,
perche` nel momento in cui vanno in
swap, non servono piu` niente (in tempo
utile, chiaramente).
 
Nel caso, pero`, si abbiano diversi
programmi aperti (ma non attivi) allora
meglio mettere su disco i dati di quelli
che non sono in funzione, e far andare
gli altri con la massima memoria disponibile.
 
Poi ci sono cose come "zram", che fanno
lo swap... in RAM...
 
In pratica lo swap e` in RAM, ma le pagine
copiate vengono compresse prime.
Di fatto si scambia memoria per CPU.
 
bye,
 
-- 
 
piergiorgio

 
Ottimo grazie dell'informazione.
 
 
-- 

 senza swap.
 
ma infatti mica dico si viva male senza swap, anzi diverse applicazioni (vedi orchestratori di container o hypervisor) non lo digeriscono proprio.
ovviamente però non è così semplice. linux sfrutta volutamente gran parte della ram non in uso per la cache allo scopo di migliorare le performance e lo swap viene usato per "parcheggiare" processi in idle proprio per fare spazio alla cache. quindi per quanto possa sembrare paradossale lo swap ha un suo ruolo nel migliorare le prestazioni.
se fosse banale non ci sarebbero decine di parametri del kernel per il tuning di questa parte, dallo swappiness all'overcommit passando per la gestione cache.
 
 


1 GB per /boot è ok, potrebbe risultare un po' sovradimensionata, ma
va bene. Se farai cose particolari come provare N kernels ricompilati
in modo diverso per testing e roba del genere, credo non avrsti chiesto
qui. Per cui sì, 1 GB va benone.
 
Anche la Swap pari alla ram è ok.
 
Grub lo devi installare solo al primo giro, quando installi il primo
dei tre sistemi. A quel punto lo devi mettere per forza altrimenti
non riesci ad avviare il primo sistema.
 
All'installazione del secondo sistema e del terzo andrai a modificare
la configurazione di grub, in modo da aggiungere alla config originaria
le voci realtive ai nuovi sistemi, quindi la loro partizione, il loro
kernel e le varie initrd.
 
A seconda del tipo di macchina di cui stiamo parlando cambia un po' il
partizionamento e l'instalazione di grub (la parte del bootloader
propriamente detto diciamo):
 
- UEFI per macchine moderne, in questo caso grub vuole la sua partizione
  EFI
 
- BIOS con partizionamento tradizionale MBR, in questo caso viene
  installato nel MBR
 
- BIOS con partizionamento in formato GPT, qua serve una partizioncina
  da 1MB sul disco e grub andrà ad installarsi lì. Potrebbe non
  funzionare con alcuni Bios, tipo intel se non ricordo male...
  (io avevo scelto questa via all'acquisto dell'SSD che avevo messo sul
  mio vecchio PC).
 
https://wiki.archlinux.org/index.php/GRUB_(Italiano)#Generazione_automatica_utilizzando_il_file_/etc/grub.d/40_custom_e_grub-mkconfig
 
http://docs.slackware.com/howtos:slackware_admin:installing_with_gpt_without_uefi
 
 
 
Detto questo, tutti i files di configurazione e corredo di grub li potrai
poi mettere in /boot, quella da 1GB.
 
All'avvio del PC grub si avvia e va a pescare la configurazione nella
partizione /boot/ (nel tuo esempio). Con quelle istruzioni avvia poi
i vari sistemi a seconda della scelta dell'utente.
Quindi lo installi una volta, ma lo dovrai configurare N volte, una per
ogni installazione di ogni sistema più aggiunte varie di kernel
ricompilati ecc ecc...


Sì questo mi pare più che sensato. Cozza un po' in caso di suspend to
disk? Non ne sono sicurissimo ma mi pare di sì, ad ogni modo se a lui
non serve, perché mai buttare via tanto spazio...


GPT se puoi.
 
Che computer è?
La scheda madre supporta UEFI? o c'è un vecchio BIOS tradizionale?

 non serve, perché mai buttare via tanto spazio...
 
Piu` che altro mi chiedo se non
sarebbe piu` sensato usare VirtualBox
e farla finita con quello.
 
Molto piu` flessibile, consente di
avere tutti e 3 contemporaneamente...
Varie ed eventuali...
 
bye,
 
-- 
 
piergiorgio


Depende, sul mio ferro vecchio ad esempio assolutemente no,
qui i sistemi virtualizzati fanno pena, ma tieni conto che
ho tirato il PC da cui scrivo per ormai troppo tempo, parliamo
di core 2 duo E8200.
Nella fattispecie ho una fulgida immagine di xp per far
girare un vecchio programma. E ogni volta che l'avvio con
qemu/kvm si attende... Non che sia inusabile, ma avere
il tutto installato baremetal è un'altra cosa.
 
Dipende cosa ci deve fare con quei sistemi.
Se deve solo avviarli per "gurdare" com'è colorato il desktop
è un conto, allora va bene la virtualizzazione, ma altriemnti
metti che devi compilare un po' di pacchetti... Be' non so ma
io non ci proverei neanche su macchina virtuale, già arranca
così il core 2.
 
L'OP dice di avere 4GB di ram se ricordo bene (come da me).
Non credo sia un PC all'ultimo grido.
 
Certo giocare a mr.holmes si potrebbe evitare se l'OP
mettesse il f****** modello del PC e la dotazione hardware,
CPU, scheda madre, RAM, disco.
 
Anche perché come dicevo il partizionamento cambia un po'
se parliamo di macchina UEFI rispetto ad "obso-BIOS".

Joe <J...@e.invalid> ha scritto:

:°D ok, ok: è un NUC con 4,GB di RAM, va bene? Voglio mollare i
 vari Raspberry con retropie/kodi/mpd server per accorpare tutto
 su un unico ferro.
-- 

 suo ruolo nel migliorare le prestazioni...
Ok, tutto vero e condivisibile, ma basato sull'ipotesi che la ram possa non
essere sufficiente e che all'n-esimo processo si esaurisca di botto crashando
tutto. Ma se si ha la certezza che la ram sia sufficiente, swappare non serve ad
una beata mazza. Se sono campato anni con 2GB di ram e 4 di swap, perché adesso
che faccio esattamente le stesse cose non dovrei lavorare tranquillamente con
8GB di ram e 0 swap? Chissenefrega se processi idle restano in ram, se ce l'ho
ancora mezza vuota.
 
Sto usando Slackware, con KDE e Thunderbird. Sotto ho due sessioni citrix con
altrettante macchine remote connesse, Teams, Signal e Chromium:
 
r2...@outer.space:~$ free -mh
              total        used        free      shared  buff/cache   available
Mem:          7.7Gi       3.4Gi       2.6Gi       117Mi       1.7Gi       3.8Gi
Swap:            0B          0B          0B
 
 
Alzi la mano chi pensa veramente che una macchina con 64GB di ram abbia bisogno
di 128GB di swap "per la performance".
 
Ulteriore riflessione: se avete dischi ssd, siete sicuri che sia una buona idea
scriverci su continuamente invece di farlo in ram?
 

  su un unico ferro.
 
Con triple boot?
 
Secondo me conviene avere 3 ferri...
 
Oppure virtualizzare, cosa che un NUC
consente di fare decentemente, visto
che sono macchine generalmente recenti.
 
Mancano sempre le specifiche HW...
 
bye,
 
-- 
 
piergiorgio

 scriverci su continuamente invece di farlo in ram?
 
beh se ci scrive continuamente è un grosso problema a prescindere, vuol dire che hai la macchina in sofferenza e probabilmente piantata. 
 

 su un unico ferro. 
 
guarda che tre sistemi in multiboot non puoi avviarli simultaneamente a differenza dei vari raspberry. non so se l'hai messo in conto.

 guarda che tre sistemi in multiboot non puoi avviarli simultaneamente a differenza dei vari raspberry. non so se l'hai messo in conto.
 
Aspetta, spiega questa cosa.
 
Sui RPi si possono far girare piu` SO
contemporaneamente?
 
Ho capito bene?
 
bye,
 
-- 
 
piergiorgio

 ha scritto:

Ma io non li voglio usare contemporaneamente! Non mi serve
 virtualizzare, davvero!

  virtualizzare, davvero!
 
Il punto della virtualizzazione non e` (solo)
che li puoi usare contemporaneamente.
 
Bensi` che ti eviti tutte le complicazioni
che stai cercando di risolvere chiedendo qui.
 
Installi un SO, in maniera normale, senza
troppi pensieri, installi un virtualizzatore
e tutti gli altri SO, sempre in maniera
normale (o quasi).
 
Se vuoi cambiare un SO, basta cambiarlo, non
devi toccare niente di cio` che e` installato.
 
Quindi, a meno che non serva un accesso diretto
all'HW, avere un multi-boot e` perfettamente
inutile e complicato.
 
bye,
 
-- 
 
piergiorgio

 ha scritto:

Guarda, l'unica complicanza è che non ho mai installato sistema
 operativi in multi-boot con UEFI. 
 
Ho mollato il Raspberry Pi per passare al NUC per ovviare alle
 limitazioni hardware (una su tutte: bus condiviso fra scheda di
 rete e USB). E tutto solo per fare girare un mpd server. È qui
 che non voglio "sovrastrutture", deve fare solo quello e farlo il
 meglio possibile.

  meglio possibile.
 
Il RPi4 non ha questo problema con
la rete.
 
Il RPi3 ha una WiFi che va piu`
veloce della scheda di rete...
 
D'altro canto, che trasferimento
incredibile di dati hai, che la
condivisione crea problemi?
 
Io ho un 3 con libreelec, collegato
in rete ethernet (quindi condivisa
con il bus USB), non vi e` nessun
problema a fare streaming video da
piu` sorgenti a piu` destinatari.
 
E lo streaming parte da un tuner TV,
collegato via USB...
 
bye,
 
-- 
 
piergiorgio

  meglio possibile.
 
Che poi, "mpd" e` "Music Player Daemon"?
 
Io non conosco "mpd", ma mi domando quanta
banda richieda.
 
Voglio dire, uno stream audio CD non
compresso sono 1.4Mbit/s, 10 stream
sono 14Mbit ed un RPi, con ethernet
condivisa, non ha sicuramente problemi.
Con 100 stream, cioe` 140Mbit/s,
potrebbero esserci problemi, dato
che lo stream potrebbe venire da
un USB storage e quindi occupare
altri 140Mbit, un po' troppo...
 
bye,
 
-- 
 
piergiorgio

 
 
È il DAC USB che ho a cuore.

 È il DAC USB che ho a cuore.
 
Ancora meglio, quanta banda richiede?
1.4Mbit?
 
Oppure hai notato problemi dovuti a
latenze causate dalla condivisione?
 
bye,
 
-- 
 
piergiorgio

 Ho mollato il Raspberry Pi per passare al NUC
 
Uno di questi? Quale di preciso?
https://www.intel.com/content/www/us/en/products/boards-kits/nuc/mini-pcs.html
 
 
Tanto per curiosità... Ci metti anche il prezzo?

 Grazie a tutti per i consigli.
 
Non so esprimermi sulla grandezza di /boot, però posso darti un
consiglio, riduci /OS3 (che suppongo sara' il so preferito) a 20 o 30
Gb ed il resto dedicalo a /home che così avrai a disposizione da tutti
e 3 i linux i tuoi dati.
-- 
Ciao
Andrea Malfatti

 che hai la macchina in sofferenza e probabilmente piantata.
 
No, vuol dire che comincia a swappare al 60% di ram occupata, e non è per niente
piantata. L'ha detto Torvalds. :-)
 
Ti pongo la questione in un altro modo. Qualsiasi cosa deva fare il tuo server,
preferisci avere 64GB di ram e 128 di swap, o 192GB di ram, e perché?

 preferisci avere 64GB di ram e 128 di swap, o 192GB di ram, e perché?
 
è una domanda molto stupidina, sai? 
 
 
 

 è una domanda molto stupidina, sai?
 
Può darsi, ma sono ancora qua che aspetto una qualunque rispostina
intelligentina, che non sia "certificati" o "l'ha detto Linus".

 intelligentina, che non sia "certificati" o "l'ha detto Linus".
 
non c'è rispostina intelligentina ad una domandina stupidina. una macchina con 64gb di ram è palesemente inferiore ad una macchina con 192gb di ram, che razza di risposta ti aspetti?
 
 

 razza di risposta ti aspetti?
 
Toh! Mi aspettavo qualcosa del tipo "meglio la seconda, perché così la ram può
essere utilizzata dalla cache, cioè quella roba che ti fa aprire velocemente
file e programmi..."
 
Lo capisci che il tuo tentativo di rispostina intelligentina sopra (meglio roba
in swap) cozza male con la rispostina intelligentina sotto (meglio in ram)?

 in swap) cozza male con la rispostina intelligentina sotto (meglio in ram)?
 
cozza male per te che di tutto questo discorso non hai capito una beata fava.  il che ci può anche stare, per carità, visto che siamo su icoli. solo che la supponenza te la dovresti risparmiare.
 
 
 

 vuoi dirmi che se scrivo pagine in swap invece che in ram qualcosa va più veloce?
 
Chiaramente la risposta e`: si.
 
bye,
 
-- 
 
piergiorgio

 O vuoi dirmi che se scrivo pagine in swap invece che in ram qualcosa va più veloce?
 
   Si.  Ci sono più fattori che possono contribuire a rendere l'uso 
della swap vantaggioso rispetto al lavorare sempre e solo in RAM.  Tre 
che conosco e che so spiegare(1) sono:
 
A) le pagine parcheggiate in swap che possono restarci a lungo (pagine 
cui raramente si fa accesso) danno al kernel tutto il tempo di 
organizzare l'allocazione delle pagine della RAM (ora in numero e 
dimensioni maggiori) per renderne le allocazioni più veloci con il minor 
numero di spostamenti/compattamenti. Statisticamente parlando, il tempo 
perso a scrivere sul disco lo recuperi man mano con i tempi di 
allocazione di RAM più veloci dei processi che usano più frequentemente 
la RAM;
B) le pagine parcheggiate in swap che sono invece presto richiamate in 
RAM, se sono richiamate indietro presto abbastanza succede una cosa 
sorprendente: considerati i vari livelli di I/O buffering (di Linux, del 
controller e dell'unità di massa) i dati possono tornare indietro senza 
essere stati in realtà mai scritti fisicamente sul disco. E quindi vanno 
e tornano solo tra memorie RAM;
C) anche in assenza di contesa delle poche pagine RAM disponibili tra 
processi avidi, le operazioni di I/O sulla swap effettuate per liberare 
altra RAM (in linea di principio inutile) potrebbero liberare RAM che, 
usata per aumentare i buffer di I/O o le cache di dati frequentemente 
usati dai processi, arriva (di nuovo, statisticamente) a ridurre 
complessivamente il numero di operazioni di I/O sul disco.
 
   Un esempio del caso C: hai un sistema con 4GiB di RAM, con gli 
applicativi attivi che ne usano la metà.  Sembrerebbe inutile 
parcheggiare alcune loro pagine in RAM.  Ma se certi applicativi 
eseguono molte operazioni di I/O sugli stessi dati (GiB al minuto), 
mettere 100MiB delle loro pagine nella swap (25 pagine scritte) potrebbe 
permettermi di tenere in cache ancora più dati di quelli più 
frequentemente utilizzati risparmiando così, supponiamo, 46 operazioni 
di I/O al secondo, in media.  Se quelle pagine messe in RAM non le devo 
ricaricare dalla swap più volte ogni secondo, mi conviene tenerle li 
perché così, complessivamente, usando la swap quando non strettamente 
necessario, *riduco* le operazioni di I/O sul disco per intervallo di tempo.
 
Le cose sono ancora più complesse di come le ho esposte, ma spero che ti 
sia chiaro che esistono almeno certi casi in cui "abusare" della swap, 
usandola quando c'è ancora RAM libera, permette di fare meno, non più, 
operazioni di I/O sul dispositivo più lento, migliorando così le 
prestazioni complessive del sistema.
 
 
1) perché non sono uno sviluppatore del kernel e quindi varie altre non 
le conosco o ne ho letto ma non le ho capite e non ho approfondito 
perché non mi serve per il mio lavoro.
 
 
   Ciao,
 
 
Alessandro
 

   partizione di boot, MBR e via dicendo.
 
Lo sai che tra i vari vantaggi di UEFI c'è la ridondanza dei settori di 
boot e che forzando il sistema ad usare il vecchio MBR hai un sistema 
più vulnerabile alla corruzione del boot-loader o della tabella delle 
partizioni?
 
 

   Supponi, ad esempio,...

 di quella in swap. Questa mia convinzione era sbagliata.
 
Il fatto e` che tu non ragioni
quadridimensionalmente, come
direbbe il Dr. Brown.
 
La RAM e` sempre piu` veloce, ma
il sistema cerca di anticipare le
richieste future.
 
Il punto di quello che Alessandro
scrive e` che, mettendo pagine in
swap in anticipo, si hanno pagine
libere per un uso immediato veloce,
invece di dover aspettare in seguito.
 
bye,
 
-- 
 
piergiorgio

 partizioni?
 
Non e` UEFI, e` GPT (che e` usata anche
da UEFI, ma non necessariamente) che ha
due partition table, una all'inizio ed
una alla fine dello spazio (del disco
o quello che e`).
 
bye,
 
-- 
 
piergiorgio

Il 16/12/20 17:16, Piergiorgio Sartor ha scritto:

   Già, mi sono "acconfusionato"!
 
   Alessandro
 
 

 aspettare in seguito.
 
Ok, chiaro. Abbiamo convenuto che un po' di swap serve. Questa cosa la trovo
maledettamente interessante. La domanda che mi sorge è un'altra, puramente
accademica. Perché nessuno ha pensato ad un sistema per swappare in una ram?
Cioè, se si riuscisse a fare su una ram apposita tutto ciò che si fa su un
disco, non lo si farebbe più velocemente? Quelle pagine anticipate in swap, non
sarebbero fruibili più velocemente da uno spazio ram? Qual è il motivo di questa
scelta architetturale?


Sicurmente non solo, ma anche per motivi di costi: dedicare tipo 2 GB o
4 GB di RAM a SWAP costa (o costava) molto di più che non dedicarci
spazio disco... Soprattutto storicamente penso fosse un buon motivo per
far swappare il sistema su disco in caso di troppo carico o come
deposito di pagine considerate a più bassa priorità.
 
Credo anche di non sbagliare dicendo che questo comportamento si ha
tanto più marcatamente quanto minore è la RAM di sistema: tanta più RAM
installata e libera rispetto al carico di lavoro, tanto meno viene
coinvolto lo swap.
 
Cioè se io devo mettere 1 GB di pagine in swap per far posto ad
eventuali 2GB di nuove pagine in RAM, ma di RAM ne ho libera 10 GB,
non credo che usare lo swap apporti miglioramenti, tanto che credo
anche che in una situazione del genere non viene proprio utilizzato
dal kernel che si arragerà con la RAM e stop.
 
Poi siccome non ho seguito tutta la discussione e non ne so molto in
merito, mi fermo lì.

 dal kernel che si arragerà con la RAM e stop.
 
È quel che succede su un server Oracle che gestisco, 64G di ram, 10G di swap. La
swap è sempre inutilizzata.
 
Swappiness 60.
 

 accademica. Perché nessuno ha pensato ad un sistema per swappare in una ram?
 
Esiste (su Linux), si chiama "zram".
 
Comprime le pagine e le mette da parte.
E` un compromesso tra spazio e CPU.
 
bye,
 
-- 
 
piergiorgio

   Già, mi sono "acconfusionato"!
 
Credo GPT sia il "default" di UEFI,
ad ogni modo.
 
Non vale la proprieta` transitiva, pero`... :-)
 
bye,
 
-- 
 
piergiorgio

 dal kernel che si arragerà con la RAM e stop. 
 
eppure se hai (esempio) 16g di ram e lo swap abilitato vedrai che dopo un certo numero di ore di utilizzo il sistema avrà cominciato ad utilizzare lo swap.
e se guardi bene dopo un certo tempo di utilizzo la ram realmente libera tenderà ad essere relativamente poca, anche a parità di programmi aperti. quella che sarà cresciuta molto è la buffer/cache.
quindi qual'è il ragionamento che fa linux? via via che utilizzi il computer "impara" quali sono i processi che accedono poco e niente alla ram e li parcheggia nello swap, nel frattempo arricchisce la cache dei file di lavoro via via che li utilizzi. 
il vantaggio che ne trai è che la seconda volta che apri libreoffice ci mette un quinto del tempo rispetto alla prima (ad esempio).
tu dirai: ma non potrebbe fare tutto in memoria visto che ne ha di libera? sì ma anche no, un po' di previdenza la deve avere, perché se poi un programma reclama quella ram potrebbe diventare problematico. se fa tutto in ram deve allocare meno cache, il che può anche andare bene, ma non sempre e comunque.