Recuperare vecchi .config della -current

[Burroughs]

Salve a tutti. Avrei intenzione di aggiornare il kernel di default presente sul portatile di un amico (huge-smp-2.6.24.5). Nel contempo vorrei installare anche il suspend2. Ora, visto che non è stata ancora rilasciata la patch per il ramo 2.6.27.x per abilitare la sospensione, sarò costretto ad optare per un kernel del ramo 2.6.26.x. Mi piacerebbe utilizzare allo scopo un config di Pat già funzionante ma ho notato che sulla -current, al momento, sono presenti file di configurazione relativi solo al ramo 2.6.27.x. Qualcuno sa se è possibile recuperare dei config meno recenti che, come nel caso in specie, probabilmente risalgono a qualche settimana/mese fa?

[JohnnyMnemonic]

Se non sbaglio Conraid qualche tempo fa aveva messo l'indirizzo di un mirror della current che tiene una "cronologia" dei pacchetti, e non solo gli ultimi rilasciati
Prova a fare una ricerca o alla peggio chiedigli direttamente

[Burroughs]

Se non sbaglio Conraid qualche tempo fa aveva messo l'indirizzo di un mirror della current che tiene una "cronologia" dei pacchetti, e non solo gli ultimi rilasciati
Prova a fare una ricerca o alla peggio chiedigli direttamente

Grazie per l'imbeccata, Johnny. Sì, penso di aver recuperato il post di cui parli (al momento però non posso pubblicare il link perché sono sul treno). Ad ogni modo, sembra che, sulla -current, Pat abbia virato bruscamente dal ramo 2.6.24.x al 2.6.27.x. Beh, se le cose stanno davvero così (lo ripeto, sono sul treno e la manualità è quella che è) mi sa che dovrò aspettare la patch per il 2.6.27.x.

[conraid]

http://riksun.riken.go.jp/pub/pub/Linux ... e-current/

Ma la current non ha mai avuto un tale kernel, è passata dal 2.6.24.7 al 2.6.27.5

Hai letto bene anche sul treno

[Burroughs]

http://riksun.riken.go.jp/pub/pub/Linux ... e-current/

Ma la current non ha mai avuto un tale kernel, è passata dal 2.6.24.7 al 2.6.27.5

Hai letto bene anche sul treno

Preciso e puntuale come sempre, conraid.

[Luci0]

Quando Pat aggiorna il kernel é probabile che sia in arrivo la nuova release ... in questo caso la 12.2 !
Inoltre la maggior parte degli hard disk IDE /dev/hdX verrà riconosciuto come /dev/sdX come accade per debian & co.
Quindi attenzione quando aggiornate il kernel e sopratutto sappiate che le partizioni nei dischi "SCSI" /dev/sdXY sono al massimo 15 mentre per gli EIDE /dev/hdXY possono essere anche 31.
... con la solita fortuna che ho di poter testare di persona queste "differenze di implementazioni"... io avevo un disco con una /dev/hda16 mettendolo su un adattatore USB non riuscivo ad accederci ...

[conraid]

Quando Pat aggiorna il kernel é probabile che sia in arrivo la nuova release ... in questo caso la 12.2 !
Inoltre la maggior parte degli hard disk IDE /dev/hdX verrà riconosciuto come /dev/sdX come accade per debian & co.
Quindi attenzione quando aggiornate il kernel e sopratutto sappiate che le partizioni nei dischi "SCSI" /dev/sdXY sono al massimo 15 mentre per gli EIDE /dev/hdXY possono essere anche 31.
... con la solita fortuna che ho di poter testare di persona queste "differenze di implementazioni"... io avevo un disco con una /dev/hda16 mettendolo su un adattatore USB non riuscivo ad accederci ...

Io invece volevo vedere il cambiamento ed in due pc, in cui uno può utilizzare pata-sis continuo a vedere hdX

[conraid]

Visto che ormai abbiamo accennato alla cosa, in fase di aggiornamento come cerchereste di "risolvere" il problema del cambio di nome degli HD?
Io avevo pensato a due sezioni di lilo identiche ma con la root diversa

per esempio

Codice: Seleziona tutto

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/hda2
  label = Slackware
  read-only
# Linux bootable partition config ends

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = SlackSD
  read-only
# Linux bootable partition config ends

potrebbe essere una "soluzione"?
Fermo restando che una volta capito come il sistema vede gli HD si sistema lilo per usarne una sola

[ildiama]

Visto che ormai abbiamo accennato alla cosa, in fase di aggiornamento come cerchereste di "risolvere" il problema del cambio di nome degli HD?
Io avevo pensato a due sezioni di lilo identiche ma con la root diversa

per esempio

Codice: Seleziona tutto

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/hda2
  label = Slackware
  read-only
# Linux bootable partition config ends

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = SlackSD
  read-only
# Linux bootable partition config ends

potrebbe essere una "soluzione"?
Fermo restando che una volta capito come il sistema vede gli HD si sistema lilo per usarne una sola

Questo presuppone che il file /etc/fstab contenga delle LABEL al posto dei soliti /dev/xxx, giusto? Altrimenti credo sia comunque inutile..

[conraid]

Questo presuppone che il file /etc/fstab contenga delle LABEL al posto dei soliti /dev/xxx, giusto? Altrimenti credo sia comunque inutile..

Beh, in effetti se fstab non trova poi i device... ma senza modificare lilo rischia di non leggerlo nemmeno fstab
Ma una soluzione così, mettendo che in fstab abbia label o uuid funzionerebbe?

[urka58]

[

Visto che ormai abbiamo accennato alla cosa, in fase di aggiornamento come cerchereste di "risolvere" il problema del cambio di nome degli HD?
Io avevo pensato a due sezioni di lilo identiche ma con la root diversa

per esempio

Codice: Seleziona tutto

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/hda2
  label = Slackware
  read-only
# Linux bootable partition config ends

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = SlackSD
  read-only
# Linux bootable partition config ends

potrebbe essere una "soluzione"?
Fermo restando che una volta capito come il sistema vede gli HD si sistema lilo per usarne una sola

Non credo che possa funzionare così come proposto. Se lilo non trova la partizione root (perchè denominata in altro modo), da un errore e non scrive sul MBR o altro. Se vuoi che che possa funzionare indipendentemente da quale sia la denominazione della partizione di root devi passare il valore come parametro al kernel (es append = root=/dev/hda2.
Ciao

[Mario Vanoni]

man 5 lilo.conf

# global options:
boot=/dev/hda

nel mio caso
boot=/dev/sda

i susseguenti
root = /dev/[hs]da#

devono corrispondere!

[slucky]

Inoltre la maggior parte degli hard disk IDE /dev/hdX verrà riconosciuto come /dev/sdX come accade per debian & co.
Quindi attenzione quando aggiornate il kernel

io ho aggiornato la current kernel compreso, e sia prima che dopo l'aggiornamento fstab e lilo.conf restano con hdx non sdx e tutto funge benissimo, quando ci sarà questa modifica?

saluti

[urka58]

man 5 lilo.conf

# global options:
boot=/dev/hda

nel mio caso
boot=/dev/sda

i susseguenti
root = /dev/[hs]da#

devono corrispondere!

Non è necessario, es lilo su un floppy

boot = /dev/fd0
root = /dev/[hs]da#

o su un altro disco

boot = /dev/hda
root = /dev/sdb#

Ciao

[urka58]

Un'altra possibilità è di utilizzare lo UUID o LABEL anzichè il nome del nodo del dispositivo. Andrebbe verificato perchè non so se ad un nodo di dispositivo diverso (sebbene per lo dispositivo) corrisponda lo stesso UUID.
Ciao