|
|
|
|
|
|
|
|
|
|
xen-users
RE: [Xen-users] RE: Problem with GPLPV drivers 0.9.11.pre8
> On 20/07/2008 04:31, James Harper wrote:
>
> > I guess you've found out by now that the disk is toasted...
>
> Not as throughly as I expected
Well that's a first. Every time I have had this happen, my disk has been
completely unrecoverable, at least using standard tools. As far as
everything I tried is concerned the filesystem was dead. I guess you
just got lucky (or I've been unlucky :)
> > This will happen if the drivers get installed when /GPLPV is booted.
The
> > thing that concerns me is how easy this is to get wrong...
>
> It will need some considerable pointing out in release notes
Yes, although I'd prefer a system rather than procedure based solution -
as you found, you thought the drivers had been installed successfully
and sobooted up with /GPLPV, only to find that they had not in fact been
installed successfully...
> have you considered automating the boot.ini changes?
Yes, but for the reasons above decided it wasn't such a good idea at
this point so haven't implemented them. Also, if you google with the
right keywords (can't remember what they are) you'll find a few examples
of programs that do this but goofed and left the systems unbootable.
I think what I'll need to do is have xenhide fall back to not gplpv if
it detects that the AddDevice callback is running after boot time. I
don't know how easy it is to detect this though...
> Do you know what the other PV drivers do here to avoid this?
I did see some comments on other solutions stating that they required
modification to the Dom0 side of things to make it work. Something about
qemu only reporting the devices on the first call to the pci detection
(eg the BIOS).
James
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|