Hi,
ich hatte ne Theorie und war so naseweis, sie ausprobieren
zu wollen. Also habe ich die initrd vom Epidemic ausgepackt
und an ihr rumgespielt.
-------------------------------------------------------
Erkenntnisse:
Der erste Steckenbleiber ist raetselhaft.
Ein Ding namens /sbin/plymouthd kommt nicht zurueck.
Es hat wohl die Aufgabe, das zweite Zylonenwappen darzustellen.
Nachdem ich den Start von plymouthd uebersprungen habe,
bleibt es als naechstes in /scripts/epd stecken. Funktion
findpendrive(). Ganz kurz bevor sich meine Theorie beweisen
wuerde. Grrrr ...
Die Funktion hat gerade fast alle /dev/sda* durchprobiert,
da bleibt sie bei /dev/sda15 stecken. Meine Platte hat sowas
garnicht ! (... naja, wer weiss schon, was FreeBSD und Solaris
in ihren MBR Partitionen angerichtet haben.)
Wie auch immer, bei /dev/sda15 bleibt das Kommando
Code: Select all
mount -o rw -t ext3 /dev/sda15 /mnt/device
offenbar stecken.
Ok. Lassen wir sda15 also ueberspringen ...
Jetzt kann meine Theorie antreten:
Funktion findpendrive() akzeptiert naemlich keine Geraete,
bei denen blkid -o value -s TYPE den Type "iso9660" meldet.
"ext2", "reiserfs", ja sogar "xfs" wuerde genommen.
Das hier schafft Abhilfe:
Code: Select all
xfs) mount -o rw -t xfs /dev/${pendrive} /mnt/device > /dev/null 2>&1;;
+ iso9660) mount -o ro -t iso9660 /dev/${pendrive} /mnt/device > /dev/null 2>&1;;
*) continue;;
Und damit bootet es bis hin zum graphischen Desktop, obwohl
ich plymouthd uebersprungen habe.
Hurra ! Desligar !
-------------------------------------------------------
Was Epidemic machen muesste:
In den Funktionen findpendrive() und findiso() aus
/boot/initrd.img : /scripts/epd das mounten von
"iso9660" einbauen.
Rausfinden, warum plymouthd steckenbleibt, wenn nicht von
DVD gebootet wird. Man braucht ihn offenbar nicht. Da
sollte er einen Timeout haben, oder sowas.
Das hier koennte eine individuelle Macke meines
Versuchsrechners sein (er muss manches ertragen):
Rausfinden, wie man mount davon abhaelt, mit meinem
/dev/sda15 haengenzubleiben. Es passiert auch im gebooteten
Epidemic. Ctrl+C bricht es auch nicht mehr ab.
Ich weiss noch nicht mal, warum der Kernel von Epidemic es
sieht. fdisk meldet nur sda1 bis sda8.
sda15 scheint den selben Start zu haben wie sda14.
Zumindest hat es die selbe UUID. Aber viel weniger Blocks.
Ich sehe noch drei "ufs" Partitionen vom FreeBSD und
eine "zfs_member", die nur von Solaris sein kann.
Mein Debian 6 mountet sda15 zwar nicht, wegen ext3 Journal
Problemen, bleibt aber auch nicht stecken.
Das mount-Kommando des gebooteten Epidemic bleibt bei
zwei von 13 Partitionen unwiederruflich stecken.
Insofern muss man doch von einer Gurke sprechen.
Unstabil ... steht ja auch aufm Downloadlink.
-------------------------------------------------------
Der after-GRUB Teil des Bootens laeuft so:
In der initial ramdisk /boot/initrd.img gibts ein Skript
/init, das wegen dem Inhalt von /conf/conf.d/boot dann
auch mal das die Funktion mountroot() aus dem Skript
/scripts/epd ausfuehrt. Diese Funktion ruft findepidemic()
et.al. auf. In findpendrive() werden die Partitionen aus
/proc/partitions probeweise gewmountet und es wird in ihnen
nach einem File /core/epidemic gesucht.
Wird dieser File gefunden, dann gilt die Partition bzw.
das Geraet als Quelle des Live-Systems.
(Mir fallen da nette Fallgruben zu ein. Sie haetten wirklich
einen eindeutigeren Filenamen, wie epidemic-4.1-b1-1-amd64,
ins ISO packen sollen.)
-------------------------------------------------------
Die initrd ist natuerlich etwas umstaendlich zu manipulieren.
Erst packt man den File /boot/initrd.img aus dem ISO auf
die Platte aus:
Code: Select all
mkdir ~/manip_initrd
cd ~/manip_initrd
gunzip </mnt/boot/initrd.img | cpio -i
Dann editiert man die Skripte und packt sich danach eine
neue initrd zusammen, und haengt sie mit einer neuen ISO
Session an den USB Stick an:
Code: Select all
(echo . ; for i in * ; do find $i ; done) | \
cpio -H newc -o | gzip >~/new_initrd.img
xorriso -boot_image any keep \
-dev stdio:/dev/sdb \
-map ~/new_initrd.img /boot/initrd.img
Am USB Stick /dev/sdb muss man natuerlich rw-Rechte haben.
Die erteilt der Superuser. Die komplizierten Befehle fuehrt
besser der Normaluser aus. (Wegen Fuss erschiessen und so.)
Die MBR-Partition waechst nicht mit. Man muesste sie von
Hand mit fdisk nachstellen. Bei meinem BIOS geht es aber
auch, wenn die initrd ausserhalb der Partition liegt.
(Die Partition faengt ja auch einen 512-Block zu spaet
an, weil GRUB2 seinen MBR ausserhalb der Partition haben
will.)
-------------------------------------------------------
Have a nice day
Thomas
Das zieht ja Kreise...