Multi boot: alcune distro cercano /dev/root

[raffaele181188]

Codice: Seleziona tutto

root@antares:/mnt/image# find . -name 'rootdev'
root@antares:/mnt/image#

Sembra di no... O sbaglio qualcosa?

[conraid]

Codice: Seleziona tutto

root@antares:/mnt/image# find . -name 'rootdev'
root@antares:/mnt/image#

Sembra di no... O sbaglio qualcosa?

Non lo so, magari l'initrd serve per altro. Io usandolo per vedere la partizione di root in LVM ho questo

Codice: Seleziona tutto

# cat rootdev
/dev/blanklvm/root

Da quel che ho capito, ma prendilo con beneficio di inventario, /dev/root serve proprio ad indicare un percorso standard per root in modo da non doverlo specificare. Anche se come hai letto in quel link che ho postato lo stesso Pat si domanda a cosa realmente serva, nonostante in alcuni unix è usato da molto

[zoros]

...
Da quel che ho capito, ma prendilo con beneficio di inventario, /dev/root serve proprio ad indicare un percorso standard per root in modo da non doverlo specificare. Anche se come hai letto in quel link che ho postato lo stesso Pat si domanda a cosa realmente serva, nonostante in alcuni unix è usato da molto

Questo post mi rassicura ... ho riletto più volte quella discussione, senza capire il senso di tanta complicazione, anche perché poi non sembra ci siano problemi nella 12.2 originale, che tengo come riferimento ... o forse non ho capito niente ...

allora, si è visto che non c'è alcuna LABEL nei dischi quindi il suggerimento era sbagliato ... sempre in tema di complicazioni, visto che fstab di SuSE è così complicato nella prima parte, perché non tornare ad una mappatura classica ? tipo

Codice: Seleziona tutto

/dev/sda5    /   ext3    rw,errors=continue

mi raccomando Raffaele, non mollare (tipo provando un altro boot manager) ... una soluzione per SuSE-Lilo c'è sicuramente (una volta trovata ... era così banale) ...

[zoros]

mi raccomando Raffaele, non mollare (tipo provando un altro boot manager) ... una soluzione per SuSE-Lilo c'è sicuramente (una volta trovata ... era così banale) ...

Immagino, appunto, che le prove per far partire questa OpenSuSE si siano interrotte ... siamo un po' alle solite (in un discorso più generale in merito alle richieste di aiuto nei casi di boot failure) in cui si intavola una discussione alla buio e si danno un sacco di suggerimenti spesso errati, non avendo informazioni sufficienti ...
tutto sommato il suggerimento di tigerwalk (che rimandava ad un mio topic) è ancora il più valido ... infatti la ramdisk che ho proposto tenta varie strade per il boot e, se non riesce a montare la root, almeno apre una console con gli strumenti sufficienti a capire come si comporta il kernel appena avviato ... quindi se usi quella ramdisk potrai scoprire da solo perché questa SuSE non monta il disco ...

ti ripropongo così il post con tutte le indicazioni necessarie ... il bello che quello script puoi farlo girare da user, ti creerà cumunque una initrd.igz funzionante ...

[Mario Vanoni]

[OT] forse ...

Slackware 12.2 aggiornata,
kernel statici, sempre lo stesso .config

/etc/fstab:
/dev/sda1 / ext2 defaults 1 1

df:
/dev/root 961432072 45111864 867482208 5% /

2.6.29.1
2.6.28.9
2.6.28.8
2.6.27.21
2.6.26.8
tutti perfettamente uguali e sempre /dev/root

2.6.16.62
VHS: Cannot open root device "801" ...
Please append ...
kernel panic ...

Facendo un boot con il DVD-12.1, kernel 2.6.24.5, df:
/dev/root 961432072 45111864 867482208 5% /

Facendo un boot con il DVD-12.0, kernel 2.6.21.5, df:
/dev/root 961432072 45111864 867482208 5% /

Il DVD-11.0 non boota nel con il kernel 2.4 (sata.i)
ne con il 2.6 (huge26), kernel panic

KNOPPIX_V5.3.1DVD, kernel 2.6.24.4,
lo vede quale /dev/sda1 (konqueror)

Solo per comunicare esperienze curiose.

[raffaele181188]

Scusa Zoros, ho sospeso le prove
1) Per mancanza di tempo
2) Perchè SuSE con la mia NVidia non va ... dovrei informarmi pure su come gestire quella distro, quindi per ora ho rimandato la prova

Non marco il topic come "Risolto" e mi riservo di FAR FUNZIONARE lilo come dovrebbe... Ma mi serve un po' di tempo per raccogliere qualche suggerimento... Ho letto il il tuo link e ti prometto che prima possibile provo a fare quello che c'è scritto Per ora (non me ne volere) ho trooooooooppo da fare

[zoros]

Scusa Zoros, ho sospeso le prove
1) Per mancanza di tempo
2) Perchè SuSE con la mia NVidia non va ... dovrei informarmi pure su come gestire quella distro, quindi per ora ho rimandato la prova

Non marco il topic come "Risolto" e mi riservo di FAR FUNZIONARE lilo come dovrebbe... Ma mi serve un po' di tempo per raccogliere qualche suggerimento... Ho letto il il tuo link e ti prometto che prima possibile provo a fare quello che c'è scritto Per ora (non me ne volere) ho trooooooooppo da fare

A dire il vero se c'è qualcuno che deve delle scuse allora quello sono io ... infatti il tono dei miei interventi non è stato dei più gradevoli, ma non era assolutamente indirizzato a te ... cerco di spiegare:

Linux è sempre più performante e completo, eppure ancora a tanta gente l'installazione fallisce nella fase di boot ... se per i meno esperti la cosa può essere comprensibile (anche se non dovrebbe accadere così spesso), rimango piuttosto sconcertato dal fatto che vengano messi in difficoltà anche gli esperti, come sei sicuramente tu ... e questo perché semplicemente non abbiamo a disposizione uno "straccio" di strumento che ci permetta (a chi è esperto) di fare almeno un paio di test in fase di boot ...
ecco allora migliaia di lilo.conf (vale anche per grub e altri) replicati su questo e altri forum per risolvere (spesso a tentativi) dei problemi che forse uno potrebbe risolvere da se ...

insomma, possibile che la "mancata root" si debba concludere il più delle volte con un "kernel panic" ? ... visto che kernel e initrd sono in RAM, basterebbe aprire un stupidissima console per trovare la soluzione ... ma questa cosa non è di serie e di volta in volta ci dobbiamo inventare qualcosa ...

in merito al "Risolto", non sarà certo grazie ai miei interventi (finora non ho mai risolto niente con i miei post ) ... invece ho sempre avuto utili informazioni nel partecipare alle discussioni ... per cui, appunto, sono proprio curioso di conoscere la soluzione che troverai (quando hai tempo ovviamente)

... quindi: grazie !

[submax82]

scusate la mia ignoranza , ma perchè il mio fstab è

/dev/sda1 swap swap defaults 0 0
/dev/sda2 / ext3 defaults 1 1
/dev/sda3 /home ext3 defaults 1 2
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0

mentre df dà:

df -H -m
Filesystem blocchi di 1M Usati Disponib. Uso% Montato su
/dev/root 18778 4959 12866 28% /
/dev/sda3 281436 64999 202142 25% /home
tmpfs 1007 0 1007 0% /dev/shm

perchè c'è /dev/root e non /dev/sda2

grazie

[ZeroUno]

scusate la mia ignoranza , ma perchè il mio fstab è

/dev/sda2 / ext3 defaults 1 1

df -H -m
Filesystem blocchi di 1M Usati Disponib. Uso% Montato su
/dev/root 18778 4959 12866 28% /

perchè c'è /dev/root e non /dev/sda2

La fstab viene letta DOPO l'avvio del processo init, e di conseguenza DOPO il mount della root partition.
La voce nella fstab serve esclusivamente per dirgli di fare il re-mount del filesystem durante il boot, infatti il kernel lo monta inizialmente in readonly e init lo rimonta in readwrite, ma questa operazione di remount NON è "umount /" e "mount /", nel qual caso si, df dovrebbe mostrare sda2, bensì "mount -o remount /" che NON cambia l'informazione sul device ma solamente le informazioni sugli attributi.
Ah, comunque chi fa testo non è df ma cat /proc/mounts

insomma, possibile che la "mancata root" si debba concludere il più delle volte con un "kernel panic" ? ... visto che kernel e initrd sono in RAM, basterebbe aprire un stupidissima console per trovare la soluzione ... ma questa cosa non è di serie e di volta in volta ci dobbiamo inventare qualcosa ...

L'initrd di slackware non manda in kernel panic! se c'è qualche fallimento carica /bin/sh:

Codice: Seleziona tutto

  if [ ! -r /mnt/sbin/init ]; then
    echo "ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead."
    echo "        You can try to fix it. Type 'exit' when things are done."
    echo
    /bin/sh
  fi

in ogni caso è sufficiente passare al prompt di lilo la stringa 'rescue' per avviare una shell durante l'initrd e fare un po' di debug.

Per quanto riguarda il post iniziale:

Ho installato OpenSuSE skippando la parte relativa al bootloader.

questa è una operazione che MAI va saltata perchè l'installer (yast2 in questo caso) crea il suo initrd col suo kernel con i suoi moduli e con i suoi /dev/root o uuid o label o /dev/sdaX o /dev/hdaX che sia e inizializza tutto il necessario. Che la distribuzione installi grub o lilo, gli si specifica di non metterlo nell'mbr (okkio a ubuntu; lo installa nell'mbr senza chiederlo, a meno che non prendi una ubuntu alternate) ma nella sua root partition.
A questo punto hai due soluzioni che DEVONO funzionare.
1) boot in slack; mount della partizione di suse; prelievo delle righe utili in lilo.conf (o in menu.lst se grub) e adattamento nel lilo di slackware.
2) (la mia preferita); boot in slack; edit di lilo.conf e aggiungere:

Codice: Seleziona tutto

other=/dev/hda2
    label=suse

Personalmente preferisco la seconda perchè è meno intrusiva, inoltre se aggiorno il kernel di suse non ho la necessità di riconfigurare lilo di slackware. Inoltre nella (probabilmente remota) possibilità che venga eliminato slackware, basterebbe cambiare la partizione attiva con fdisk per permettere il boot. E' da un po' di tempo che non metto più lilo nell'mbr; semplicemente installo lilo nella root partition e rendo attiva la partizione.

- A questo punto la riparazione a suo tempo sarebbe dovuto essere: boot cd di suse in rescue mode => ripristino bootloader
- Boot in slack, modifica di lilo.conf come sopra
- Fine

Ciao,
01

[submax82]

ma allora df avrà sempre la linea con /dev/root? te lo chiedo perchè in openoffice-autobuilder c'è il check dello spazio su disco e mi serviva per sapere lo spazio libero su la partizione di root...

[ZeroUno]

ma allora df avrà sempre la linea con /dev/root?

su slackware sembra di si (credo sia impostato nel kernel, quindi a meno di non ricompilarlo...), su altre distribuzioni no (ma non so quali)

te lo chiedo perchè in openoffice-autobuilder c'è il check dello spazio su disco e mi serviva per sapere lo spazio libero su la partizione di root...

che centra /dev/root con lo spazio libero per l'autobuilder?
su qualsiasi device sia, per avere lo spazio libero sulla root dai

Codice: Seleziona tutto

df /|awk '{print $4}'|tail -1

meglio ancora

Codice: Seleziona tutto

df /directory/di/lavoro|awk '{print $4}'|tail -1

così se quella directory si trova sul rootfs ti restituisce lo spazio libero sulla root, se si trova in un altro filesystem ti dice lo spazio libero sull'altro (in caso vado a compilare nella /home per esempio). In pratica fa un autodetect della partizione che contiene quella directory. Attento che se vuoi sapere lo spazio libero nel rootfs perchè vuoi compilare in /tmp sei fuori strada; non è scontato che la /tmp si trovi nel root filesystem; io per esempio la tengo in tmpfs (in ram, così è più rapida e mi si svuota al reboot); in tal caso, quindi

Codice: Seleziona tutto

df /tmp|awk '{print $4}'|tail -1

Ciao,
01

[submax82]

GRAZIE MOLTISSIMO spiegazione eccellente!

autobuilder con supporto x86_64 in arrivo

[zoros]

...
La fstab viene letta DOPO l'avvio del processo init, e di conseguenza DOPO il mount della root partition.
La voce nella fstab serve esclusivamente per dirgli di fare il re-mount del filesystem durante il boot, infatti il kernel lo monta inizialmente in readonly e init lo rimonta in readwrite, ma questa operazione di remount NON è "umount /" e "mount /", nel qual caso si, df dovrebbe mostrare sda2, bensì "mount -o remount /" che NON cambia l'informazione sul device ma solamente le informazioni sugli attributi.
Ah, comunque chi fa testo non è df ma cat /proc/mounts

insomma, possibile che la "mancata root" si debba concludere il più delle volte con un "kernel panic" ? ... visto che kernel e initrd sono in RAM, basterebbe aprire un stupidissima console per trovare la soluzione ... ma questa cosa non è di serie e di volta in volta ci dobbiamo inventare qualcosa ...

L'initrd di slackware non manda in kernel panic! se c'è qualche fallimento carica /bin/sh:

Codice: Seleziona tutto

  if [ ! -r /mnt/sbin/init ]; then    echo "ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead."
    echo "        You can try to fix it. Type 'exit' when things are done."
    echo
    /bin/sh
  fi

in ogni caso è sufficiente passare al prompt di lilo la stringa 'rescue' per avviare una shell durante l'initrd e fare un po' di debug.
...

hey ZeroUno,
hai puntualizzato diverse cose, tutte vere ... però vorrei far notare che le cose che hai scritto sono verità relative:

La fstab viene letta DOPO l'avvio del processo init, e di conseguenza DOPO il mount della root partition.

questo è vero se parti con un kernel-huge, senza initrd ... altrimenti gli /sbin/init sono due, il primo è uno script e tutto dipende da cosa c'è scritto dentro a questo script ...

La voce nella fstab serve esclusivamente per dirgli di fare il re-mount del filesystem durante il boot ...

anche questo è relativo: il problema è che lo script /etc/rc.d/rc.S di Slackware, forse da aggiornare ormai, contiene un automatismo che si "incasina" col check del disco se non c'è una voce minima in fstab a marcare la partizione di root ... se non fosse per questo problemino su rc.S nelle ultime release di Slackware fstab potrebbe essere vuoto, non serve proprio ...

L'initrd di slackware non manda in kernel panic! se c'è qualche fallimento carica /bin/sh:

a meno di particolari esigenze meglio un kernel-huge e questo non usa l'initrd ... io ragionavo su quello ... o meglio: l'installer di Slackware carica il kernel-huge per default e funziona sempre, installazioni col generic e initram non sempre si concludono con successo ...

comunque sia, il mio intervento in questo thread voleva sottolineare che il "kernel panic" in fase di boot è ancora troppo frequente nelle varie distro ... cioè mi sembra che ci sia ancora una certa confusione nelle soluzioni adottate ...

[raffaele181188]

Posso chiedere ulteriori delucidazioni sul /dev/root di SuSE? La cosa non mi è chiara di per sè (il /dev/root non mi è simpatico per i fati suoi), ed è ancora più confusa perchè sul forum di SuSE mi avevano detto che non lo usano (ma non l'ho mai avviata quindi non saprei) e perchè pensavo che l'"installazione del bootloader" servisse unicamente a configurare LiLO/Grub (e quindi usando un bootloader "esterno" alla distribuzione questa fase si può saltare a piè pari)

[ZeroUno]

però vorrei far notare che le cose che hai scritto sono verità relative:

vero. visto che utilizziamo slackware ho parlato del kernel di slackware e visto che parliamo di initrd ho parlato dell'initrd di slackware. E' chiaro che gli altri kernel e gli altri initrd si comportano in modo diverso (basti vedere che il 99% delle distribuzioni non conoscono i dischi /dev/hda ma solo /dev/sda anche se questi sono ide)

questo è vero se parti con un kernel-huge, senza initrd ... altrimenti gli /sbin/init sono due, il primo è uno script e tutto dipende da cosa c'è scritto dentro a questo script ...

Il processo /init dell'initrd ai fini nostri non fa testo perchè è un processo che è un processo che muore al suo termine; comunque si, per quanto riguarda slackware è lui che definisce la /dev/root e credo che lo faccia con:

Codice: Seleziona tutto

  echo 0x0100 > /proc/sys/kernel/real-root-dev
  mount -o ro -t $ROOTFS $ROOTDEV /mnt

in cui $ROOTDEV deriva da tutta una ricerca effettuata in precedenza (se si utilizza label o raid ecc)

La voce nella fstab serve esclusivamente per dirgli di fare il re-mount del filesystem durante il boot ...

anche questo è relativo: il problema è che lo script /etc/rc.d/rc.S di Slackware, forse da aggiornare ormai, contiene un automatismo che si "incasina" col check del disco se non c'è una voce minima in fstab a marcare la partizione di root ... se non fosse per questo problemino su rc.S nelle ultime release di Slackware fstab potrebbe essere vuoto, non serve proprio ...

no. la entry nell'fstab ci deve essere perchè se (e non lo ritengo corretto) fsck può determinare automaticamente il device su cui effettuare il check e il relativo tipo di filesystem (ext3, reiserfs ecc), e questi stessi parametri (e continuo a non essere daccordo) li può autorilevare anche mount, di sicuro non può indovinare che attributi l'utente gli vuole abilitare, per esempio "acl,errors=panic" ecc. questi non li può indovinare. e non si possono nemmeno indovinare i due numeretti in fondo (1 1 nel caso del root filesystem è standard, ma non è d'obbligo). Io ritengo che quella parte di rc.S è fatta bene; ci sono altre parti obsoletate o da cambiare, ma non sono quelle.

L'initrd di slackware non manda in kernel panic! se c'è qualche fallimento carica /bin/sh:

a meno di particolari esigenze meglio un kernel-huge e questo non usa l'initrd ... io ragionavo su quello ... o meglio: l'installer di Slackware carica il kernel-huge per default e funziona sempre, installazioni col generic e initram non sempre si concludono con successo ...

Anche io personalmente preferisco kernel-huge a initrd ma le direttive ufficiali di pat sono quelle di optare per generic+initrd (v. CHANGES_AND_HINTS.TXT). Inoltre quì si faceva un discorso generale; poichè si parlava del fatto che quasi tutte le distribuzioni (initrd o meno) mandano in kernel panic, io ho affermato che con slackware in panic non ci vai se scegli initrd (se scegli huge al 90% dei casi ci vai solo se sbagli a mettere root= in lilo.conf; in tal caso basta che al boot passi a manina root=/dev/part-corretta e la macchina parte correttamente, poi fai la correzione, senza bisogno di bootcd o incasinamenti vari.

comunque sia, il mio intervento in questo thread voleva sottolineare che il "kernel panic" in fase di boot è ancora troppo frequente nelle varie distro ... cioè mi sembra che ci sia ancora una certa confusione nelle soluzioni adottate ...

confermo, e a chi dice che windows non ha questi problemi lo invito ad installare xp su dischi sata; se non sai veramente cosa stai facendo impazzisci; per non parlare della riparazione del boot loader; ad un amico non funzionava nemmeno il boot da cd.

Posso chiedere ulteriori delucidazioni sul /dev/root di SuSE?

Personalmente non uso più suse da un pezzo, ma non so se abbia mai utilizzato /dev/root. Per un bel periodo di tempo ha utilizzato l'uuid (ora non lo so) che io però odio e la prima cosa che faccio è la conversione manuale in /dev/sdaX

il /dev/root non mi è simpatico per i fati suoi

A me si; mi ha risparmiato un sacco di casini

pensavo che l'"installazione del bootloader" servisse unicamente a configurare LiLO/Grub (e quindi usando un bootloader "esterno" alla distribuzione questa fase si può saltare a piè pari)

Ni. Slackware con il kernel huge non ha bisogno di un initrd quindi quando si installa slackware tale passo è skippabile tranquillamente se si vuole utilizzare un bootloader alternativo.
La stragrande maggioranza delle altre distribuzioni vogliono un initrd che viene creato in fase di configurazione di lilo/grub; sebbene non sia _strettamente_ indispensabile questa operazione va effettuare con un kernel running identico a quello della distribuzione, e questo stato ce l'hai solamente a distribuzione up o da boot cd; se bootti da slackware e chrootti hai una situazione che rende possibile la creazione dell'initrd ma è più complicato.

Ciao
01