Newsgroup: it.comp.os.linux.iniziare
Titolo: initrd.img

Su una debian stretch, ho attuaòmente l'avvio con il kernel 4.9.0-4-686.
Facendo un aggiornamento globale  ora ho il 4.9.0-6-686.
 
In  /boot ci sono:
config-4.9.0-4-686
config-4.9.0-6-686
initrd.img-4.9.0-4-686
System.map-4.9.0-4-686
System.map-4.9.0-6-686
vmlinuz-4.9.0-4-686
vmlinuz-4.9.0-6-686
 
Mancherebbe per l'avvio del nuovo kernel un initrd.img-4.9.0-6-686.
 
Dato lo stesso ramo del kernel, si può copiare l'initrd ...4 in ...6 per
avviare col nuovo kernel?
 
 
 
 
-- 
Piove ?
  Non lo so.
Come non lo sai, guarda in su.
  Non posso, se guardo in su mi arriva l'acqua in faccia...

 avviare col nuovo kernel?
 
Non c'e` qualcosa come "mkinitrd"?
 
Comunque, non so se la copia sia consigliabile.
Forse in quel caso si, ma se l'initrd ha moduli e
questi sono strettamente legati alla versione del
kernel potrebbero esserci problemi.
 
D'altro canto, potresti provare, dovrebbe anche
essere possibile scegliere il kernel di boot,
quindi se il nuovo non funziona, si usa il vecchio,
che *dovrebbe* sempre funzionare.
 
bye,
 
-- 
 
piergiorgio

 che *dovrebbe* sempre funzionare.
 
Si certo, al boot posso scegliere come avviare.
Ho scaricato una iso recente, (2 giga) ed ho estratto il file.
 
Ma volevo vedere se con aggornamenti successivi, potevo saltare di cercare una
iso con un nuovo kernel ed estrarre il file...
 
Perdere 40-50 minuti per scaricare una iso, che poi non mi serve in quanto il
sistema è comunque aggiornato di continuo...
 
E quando aggiorna il kernel, non c'è l'initrd!
 
Sto parlando di una live persistente su chiavetta (debian stretch), forse è da
gestire un pochino diversamente da una installazione residente.
 
Ho in giro una copia che uso per backup e provo a fare esperimenti li.
Grazie.


 gestire un pochino diversamente da una installazione residente.
 
Dipende, e` una live su chiavetta, oppure e`
un'installazione su chiavetta?
 
Nel primo caso, io non farei update, semplicemente
una copia nuova ad ogni release ufficiale.
 
Nel secondo e` come un'installazione qualunque,
quindi soggetta ad update.
 
bye,
 
-- 
 
piergiorgio

 avviare col nuovo kernel?
 
Penso proprio di no. Da me ecco tutto quel che c'e' in /boot:
totale 37280
-rw-r--r-- 1 root root 3183748 23-dic-17 01:39 System.map-4.9.0-4-amd64
-rw-r--r-- 1 root root 3185098 04-gen-18 12:12 System.map-4.9.0-5-amd64
-rw-r--r-- 1 root root 3189623 02-mar-18 08:52 System.map-4.9.0-6-amd64
-rw-r--r-- 1 root root     512 27-lug-17 19:13 boot.0809
-rw-r--r-- 1 root root  113162 27-lug-17 19:13 coffee.bmp
-rw-r--r-- 1 root root  186443 23-dic-17 01:39 config-4.9.0-4-amd64
-rw-r--r-- 1 root root  186473 04-gen-18 12:12 config-4.9.0-5-amd64
-rw-r--r-- 1 root root  186567 02-mar-18 08:52 config-4.9.0-6-amd64
-rw-r--r-- 1 root root   22466 27-lug-17 19:13 debian.bmp
-rw-r--r-- 1 root root   31628 27-lug-17 19:13 debianlilo.bmp
-rw-r--r-- 1 root root   22560 27-lug-17 19:13 debian-de.bmp
-rw-r--r-- 1 root root 4943402 28-dic-17 20:13 initrd.img-4.9.0-4-amd64
-rw-r--r-- 1 root root 4943501 03-feb-18 10:20 initrd.img-4.9.0-5-amd64
-rw-r--r-- 1 root root 4946146 11-mar-18 11:18 initrd.img-4.9.0-6-amd64
-rw-r--r-- 1 root root   22578 27-lug-17 19:13 inside.bmp
-rw------- 1 root root  195072 13-mar-18 15:45 map
-rw-r--r-- 1 root root    6878 27-lug-17 19:13 onlyblue.bmp
-rw-r--r-- 1 root root   33192 27-lug-17 19:13 tuxlogo.bmp
-rw-r--r-- 1 root root 4212512 23-dic-17 01:39 vmlinuz-4.9.0-4-amd64
-rw-r--r-- 1 root root 4216608 04-gen-18 12:12 vmlinuz-4.9.0-5-amd64
-rw-r--r-- 1 root root 4224800 02-mar-18 08:52 vmlinuz-4.9.0-6-amd64
 
e ho purgato a mano il quart'ultimo. Uso dselect, invece di aptitude o
synaptic grafico o altri, oppure spesso direttamente apt o dpkg da riga
di comando. Ma ho solo chiesto di purgare il 3 senza nulla circa
l'initramfs, che invece si e' portato via da /boot insiema al kernel
vmlinuz-4.9.0-3-amd64.
 
Penso che da te dovresti risolvere tutto se installi il pacchetto
linux-image-amd64
che se non ricordo male e' un metapacchetto che ha come dipendenza
l'ultimo kernel.
Inoltre ho questi due pacchetti essenziali per initramfs:
initramfs-tools-core
initramfs-tools
 
Con questi, dopo aver dato come root: 'apt-get update' non ho mai dovuto
pensare ad aggiornare niene a mano per il kernel, l'initramfs e l'
aggiornamento dei link sulla root li fa sempre apt in automatica ciao
(compreso il ridare lilo)
 
-- 
Yoda
 

 linux-image-amd64
 
Vedo ora che hai i386, be' io ne ho 3 di i386 installate: due stretch e
la vecchia jessie, in tutte ho messo il corrispondente: linux-image-686-pae
(tu dovresti metterlo senza il pae se la tua maccina non ha due cpu)
 
/mnt/32_c2:
linux-image-4.9.0-3-686-pae
linux-image-686-pae
initramfs-tools-core
initramfs-tools
 
/mnt/32_b1:
linux-image-4.9.0-3-686-pae
linux-image-686-pae
initramfs-tools-core
initramfs-tools
 
/mnt/jessie:
linux-image-3.16.0-4-686-pae
linux-image-686-pae
initramfs-tools
 
N.B. che son mesi e mesi che non le aggiono, infatti hanno il 3 ciao
 
-- 
Yoda
 

 quindi soggetta ad update.
 
E' un misto.
 
Nel senso che è una live con pacchetti non liberi su chiavetta come base, ma ha
la possibilità di aggiungere (e ne ho aggiunti parecchi), aggiornare pacchetti
come se fosse una installazione normale.
 
Posso avviare la modalità live pura, e si comporta come un cd, usando solo i
files e le configurazioni originali, ma se avvio come "persistente", allora ho
davanti una installazione in cui posso tutto.
 
Il vantaggio di questa soluzione è di avere sempre, qualunque casino si faccia,
una versione funzionante anche se non aggiornata, in modo da poter sempre
ripartire.


 (compreso il ridare lilo)
 
Update ed il conseguente upgrade, li faccio indifferentemente da apt-get o da
synaptic.
 
Ma, come ho detto, è una cnfigurazione mista live/persistente su chiavetta.
