Linux Virtualization - Apr 2007 - lhype booting debootstrapped debian image over nfsroot, partial success

On Sun, 2007-01-07 at 23:46 +0100, bert hubert wrote:
> However, TCP/IP was working, so I installed an ssh server so I could log in
> over the network, but no dice:
> Starting OpenBSD Secure Shell server: sshdPRNG is not seeded
OK, this is now fixed: I was making a mess of the FPU.  That also caused
the "nan" in "uptime" and fast dd's.

The goodness is in 633a4a692d44 and later.

Thanks for the interesting bug report!
Rusty.

On Sun, 2007-01-07 at 23:46 +0100, bert hubert wrote:
> When it does work, things sort of work, but it looks like timing is
> seriously off:
> 
> intel:~# uptime
>  01:52:22 up -24855 days, -3:-14,  1 user,  load average: nan, nan, 0.03
> 
> The clock appears to run around 5 times too slow.
OK, a one-character typo meant I was returning "usec" not
"sec" through
the "get_wallclock" hypercall.  Hence time was completely random;
I'm
amazed it booted!

I've also made the guest use the TSC, and now time runs at normal speed.
ssh still does not install due to lack of randomness; the next patch
will fix this (the host will tell us which devices are capable of
supplying randomness, ie. not ones connecting to other guests).

Thanks!
Rusty.

Hi!

Bored by previous lhype success, I tried to boot a debootstrapped debian
over nfsroot, and lo, this almost works!

Commandline:
# drivers/lhype/lhype_add 256m 0 ./vmlinux --tunnet=192.168.1.20
 root=/dev/root nfsroot=/home/ahu/lhype-root
ip=192.168.1.21:192.168.1.20:192.168.1.20

This with lhype.patch current as of this message and 2.9.20-rc4.

The boot process stops after:
Starting periodic command scheduler: crond.

Trying to use the console yields:
lhype_add: Failed to get DMA buffer from (nil): No such file or directory
lhype_add: console: no dma buffer!: No such file or directory

/dev/tty does exist on the root: crw-rw-rw- 1 root tty 5, 0 Jan  7  2007
/dev/tty

However, TCP/IP was working, so I installed an ssh server so I could log in
over the network, but no dice:
Starting OpenBSD Secure Shell server: sshdPRNG is not seeded
 
Installing telnet, and removing /etc/securetty allowed me to login as root,
but this doesn't always work. When I try to, lhype prints out the following,
if it works or not:

lhype_add: Failed to get DMA buffer from 0xb7fff008: No such file or directory
lhype_add: network: no dma buffer!: No such file or directory
lhype_add: Failed to get DMA buffer from 0xb7fff008: No such file or directory
lhype_add: network: no dma buffer!: No such file or directory
(8 more of these 2)
lhype_add: Pending dma 0x7906c0, addr 0xb7fff000

When it does work, things sort of work, but it looks like timing is
seriously off:

intel:~# uptime
 01:52:22 up -24855 days, -3:-14,  1 user,  load average: nan, nan, 0.03

The clock appears to run around 5 times too slow.

But things are looking pretty nice! Booting from nfsroot beats a fixed image
any day for me.

Keep up the good work!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

On Sun, 2007-01-07 at 23:46 +0100, bert hubert wrote:
> Hi!
Hi Bert!
> Bored by previous lhype success, I tried to boot a debootstrapped debian
> over nfsroot, and lo, this almost works!
8)
> Commandline:
> # drivers/lhype/lhype_add 256m 0 ./vmlinux --tunnet=192.168.1.20
>  root=/dev/root nfsroot=/home/ahu/lhype-root
> ip=192.168.1.21:192.168.1.20:192.168.1.20
> 
> This with lhype.patch current as of this message and 2.9.20-rc4.
> 
> The boot process stops after:
> Starting periodic command scheduler: crond.
> 
> Trying to use the console yields:
> lhype_add: Failed to get DMA buffer from (nil): No such file or directory
> lhype_add: console: no dma buffer!: No such file or directory
That's strange!  I can't reproduce that here 8(.  Even if noone listens
on the console it's still registered...  Hmm, but I did fix a
theoretical bug in the console with my latest patch.  I doubt that's
happening to you though 8(

I've also changed the console to be raw: press ^C three times in a row
within 1 second to exit.  I still got "-bash: no job control in this
shell" until I attached the console to /dev/hvc0
not /dev/console...(thanks sfr!)
> /dev/tty does exist on the root: crw-rw-rw- 1 root tty 5, 0 Jan  7  2007
/dev/tty
> 
> However, TCP/IP was working, so I installed an ssh server so I could log in
> over the network, but no dice:
> Starting OpenBSD Secure Shell server: sshdPRNG is not seeded
Hmm, good catch!  Nothing in the guest contributes entropy
to /dev/random; something needs to or this kind of thing will happen.
I'll need to think harder about what the right answer is, but it almost
certainly involves me fixing up time in the guest (a good thing in
itself!).
> Installing telnet, and removing /etc/securetty allowed me to login as root,
> but this doesn't always work. When I try to, lhype prints out the
following,
> if it works or not:
> 
> lhype_add: Failed to get DMA buffer from 0xb7fff008: No such file or
directory
> lhype_add: network: no dma buffer!: No such file or directory
OK, these just mean the guest wasn't receiving networking.  On my
system, IPv6 sends probes from the guest as soon as the device comes up,
so this happens.  I've silenced the warnings, at least until we've seen
some output from the guest device...
> lhype_add: Pending dma 0x7906c0, addr 0xb7fff000
This is unusual, but harmless by itself.  We exhausted the guest's (8!)
network buffers, and when it refilled it sent a useful ping to tell us.
This will be greatly alleviated (and network speed greatly improved!) in
the coming I/O rewrite, where guests will be able to have arbitrary
numbers of registered buffers.
> When it does work, things sort of work, but it looks like timing is
> seriously off:
> 
> intel:~# uptime
>  01:52:22 up -24855 days, -3:-14,  1 user,  load average: nan, nan, 0.03
> 
> The clock appears to run around 5 times too slow.
Wow, I haven't seen that before!  But the clock *is* really slow.  It's
time for the guests to have a real clock.  
> But things are looking pretty nice! Booting from nfsroot beats a fixed
image
> any day for me.
> 
> Keep up the good work!
Thanks for the report!  I'll install sshd tomorrow and fix that issue
too.  And I'll study up on struct clocksource and time...

Thanks!
Rusty.