Sinds kort is de nieuwe SuSE Linux Enterprise Server 9 (SLES9) uit. Ik heb 'm braaf gekocht, en zit nu wat te spelen met de User Mode Linux support. Natuurlijk kan je zelf een UML bouwen, maar SLES9 heeft een YaST module hiervoor. Mooi meegenomen.
Nu ben ik inmiddels een aantal uurtjes verder, met de volgende bevindingen:
Installatie bestanden
de YaST module vraagt waar de installatie bestanden staan. Hier moet je de ftp locatie van CD2 opgeven. 2 minuten later gaat de uml het installatieproces in. Zonder dat er dan duidelijk om gevraagd wordt, moet je de locatie van CD1 aangeven. Slordig, maar niet dodelijk
Starten
de uml wordt vervolgens gestart met /etc/init.d/uml start umlx, waarbij x staat voor het nummer van de uml.
het script /usr/lib/YaST2/bin/start-uml is uiteindelijk verantwoordelijk voor het uiteindelijk starten van de uml. Hiervoor gebruikt deze bij uml0 het commando:
Probleem 1: con
Hoewel hier gebruik wordt gemaakt van een default installatie, wil de uml niet starten met de default scripts.
Bij het initialiseren van de stdio driver stopt de uml er mee zonder verdere foutmelding. Maar haal ik de parameter con=pts weg, dan komt hij wel verder.
Wat blijkt, direct na het laden van de stdio driver wordt de root gemount. Hier gaat het fout. Maar omdat alle console output naar pts wordt gestuurd, zie je niets meer. Het lijkt dus alsof de stdio driver fout gaat.
Je kan vervolgens de uml console openen door te kijken wie de eigenaar is van de /dev/pts/* en dan screen /dev/pts/n te starten (n=nummer). Je moet nog wel even op enter rammen voor je een login prompt te zien krijgt.
Probleem 2: ook con
Bij het gebruik van con=pts zie je niets. De testbak die ik gebruik is maar 400MHz, en ik moet dus echt 2 minuten wachten voor de uml is opgestart. Gebruik het commando top om te kijken of de uml gestart is. Staat het commando 'linux' in de top 10 van CPU gebruik, verwacht dan nog niet dat je een console kan krijgen.
Probleem 3: udba2
Kijk ik nu naar de eerste 5 regels van de kernel output, dan zie ik staan dat als command line is opgegeven:
Waar komt dat root=98:0 vandaan? Dat is beslist niet iets wat uit het aanroepende script komt, want ook als ik de uml direct vanaf de command line start verzint de kernel dat er bij. Overigens is het major number wel goed, minor niet. 98:2 (=udba2) zou wel werken.
Het suffe: het init script in initrd kijkt juist naar de commandline waarmee de uml gestart is. En als er geen root opgegeven is, kiest deze automatisch /dev/ubda2. Dus dat de kernel er parameters bij verzint, sloopt automatisch het initrd boot script.
De oplossing is de volgende regel in /etc/sysconfig/uml/uml0.conf:
EXTRA_ARGS="root=98:2"
Probleem 4: ncups
ik vroeg me al af wat ncups op de argument line betekent... als je naar het boot script kijkt, zie je dat daar ncpus moet staan, slordige tikfout die SMP-emulatie uitsluit.
Dit kán opgelost worden door ncpus=x toe te voegen aan de EXTRA_ARGS... maar het nut zie ik er niet van, want CONFIG_UML_SMP staat uit in de config van de supported default kernel. Zelf opnieuw compilen kan, maar dat maakt het package management en support er niet makkelijker op.
Conclusie
De conclusie: SuSE heeft de uml support niet goed getest. Maar als je dan eenmaal zelf hebt uitgevonden waar alle fouten zitten, is het toch wel makkelijk in gebruik.
Eigenlijk wilde ik een aantal vragen stellen in dit topic, maar ik heb de problemen zelf dus al opgelost
Vooral probleem 3 was lastig, tot ik besloot de initrd te mounten. Wel post ik dit ter verrijking van de knowledge base.
Nu ben ik inmiddels een aantal uurtjes verder, met de volgende bevindingen:
Installatie bestanden
de YaST module vraagt waar de installatie bestanden staan. Hier moet je de ftp locatie van CD2 opgeven. 2 minuten later gaat de uml het installatieproces in. Zonder dat er dan duidelijk om gevraagd wordt, moet je de locatie van CD1 aangeven. Slordig, maar niet dodelijk
Starten
de uml wordt vervolgens gestart met /etc/init.d/uml start umlx, waarbij x staat voor het nummer van de uml.
het script /usr/lib/YaST2/bin/start-uml is uiteindelijk verantwoordelijk voor het uiteindelijk starten van de uml. Hiervoor gebruikt deze bij uml0 het commando:
code:
1
2
3
| /bin/su -s /bin/bash -c ./linux \ umlid=uml0 mem=256m ncups=1 ubd0=ubd0 initrd=./initrd \ eth0=daemon,fe:fd:fd:f4:21:34,unix,uml0.ctl ssl=none con=pts selinux=0 |
Probleem 1: con
Hoewel hier gebruik wordt gemaakt van een default installatie, wil de uml niet starten met de default scripts.
Bij het initialiseren van de stdio driver stopt de uml er mee zonder verdere foutmelding. Maar haal ik de parameter con=pts weg, dan komt hij wel verder.
Wat blijkt, direct na het laden van de stdio driver wordt de root gemount. Hier gaat het fout. Maar omdat alle console output naar pts wordt gestuurd, zie je niets meer. Het lijkt dus alsof de stdio driver fout gaat.
Je kan vervolgens de uml console openen door te kijken wie de eigenaar is van de /dev/pts/* en dan screen /dev/pts/n te starten (n=nummer). Je moet nog wel even op enter rammen voor je een login prompt te zien krijgt.
Probleem 2: ook con
Bij het gebruik van con=pts zie je niets. De testbak die ik gebruik is maar 400MHz, en ik moet dus echt 2 minuten wachten voor de uml is opgestart. Gebruik het commando top om te kijken of de uml gestart is. Staat het commando 'linux' in de top 10 van CPU gebruik, verwacht dan nog niet dat je een console kan krijgen.
Probleem 3: udba2
Kijk ik nu naar de eerste 5 regels van de kernel output, dan zie ik staan dat als command line is opgegeven:
code:
1
2
| umlid=uml0 mem=256m ncups=1 ubd0=ubd0 initrd=./initrd \ eth0=daemon,fe:fd:fd:f4:21:34,unix,uml0.ctl ssl=none con=pts selinux=0 root=98:0 |
Waar komt dat root=98:0 vandaan? Dat is beslist niet iets wat uit het aanroepende script komt, want ook als ik de uml direct vanaf de command line start verzint de kernel dat er bij. Overigens is het major number wel goed, minor niet. 98:2 (=udba2) zou wel werken.
Het suffe: het init script in initrd kijkt juist naar de commandline waarmee de uml gestart is. En als er geen root opgegeven is, kiest deze automatisch /dev/ubda2. Dus dat de kernel er parameters bij verzint, sloopt automatisch het initrd boot script.
De oplossing is de volgende regel in /etc/sysconfig/uml/uml0.conf:
EXTRA_ARGS="root=98:2"
Probleem 4: ncups
ik vroeg me al af wat ncups op de argument line betekent... als je naar het boot script kijkt, zie je dat daar ncpus moet staan, slordige tikfout die SMP-emulatie uitsluit.
Dit kán opgelost worden door ncpus=x toe te voegen aan de EXTRA_ARGS... maar het nut zie ik er niet van, want CONFIG_UML_SMP staat uit in de config van de supported default kernel. Zelf opnieuw compilen kan, maar dat maakt het package management en support er niet makkelijker op.
Conclusie
De conclusie: SuSE heeft de uml support niet goed getest. Maar als je dan eenmaal zelf hebt uitgevonden waar alle fouten zitten, is het toch wel makkelijk in gebruik.
Eigenlijk wilde ik een aantal vragen stellen in dit topic, maar ik heb de problemen zelf dus al opgelost
Vooral probleem 3 was lastig, tot ik besloot de initrd te mounten. Wel post ik dit ter verrijking van de knowledge base.
[ Voor 3% gewijzigd door Verwijderd op 08-09-2004 14:29 ]