My Xen project seems to fail badly, I have been struggling with an
unknown-block(0,0) using the latest xen-sources, 2.6.21, everything
compiles well. I tried some other distributions like sabayon, which
indicated that the nforce 780 wasn't supported in kernel 2.6.22 (which
is used in sabayon mini cd), I would need at least a 2.6.23, but the
problem is the lack of interest/will/time to make a 2.6.23+ dom0 kernel.

In case someone had managed to spend some time fixing the xen patches
for a later kernel version, I would be happy if someone could share
those patches... or I have to spend money on yet another computer :(


--

//Aho

On Sunday 29 June 2008 22:13, someone who identifies as *J.O. Aho* wrote
in /alt.os.linux.gentoo:/

> My Xen project seems to fail badly, I have been struggling with an
> unknown-block(0,0) using the latest xen-sources, 2.6.21, everything
> compiles well. I tried some other distributions like sabayon, which
> indicated that the nforce 780 wasn't supported in kernel 2.6.22 (which
> is used in sabayon mini cd), I would need at least a 2.6.23, but the
> problem is the lack of interest/will/time to make a 2.6.23+ dom0 kernel.
>
> In case someone had managed to spend some time fixing the xen patches
> for a later kernel version, I would be happy if someone could share
> those patches... or I have to spend money on yet another computer :(

Due to my decision to wait for the official Gentoo 2008.0 release so I could
make a clean start without having to go through b0rkage hell if I were to
use an older install and then use Portage to pull in the new release when
it's ready, I still haven't been able to proceed with my plans.

However, what I can tell you is that 2.6.23 does not need patching - at
least not for use in /domU/ - because 2.6.23 has Xen /domU/ support
built-in, albeit that this support is far less extensive than in the
Xen-supplied kernel sources. However, if you were to use a later kernel
for /domU,/ then I would suggest going with the current vanilla kernel, due
to the fact that 2.6.23 was not available as a Xen /domU/ on 64-bit
machines.

That said, for /dom0/ you are stuck with either 2.6.18 (as per the Xen
sources tarball), 2.6.20 (with the RedHat patches) or 2.6.22 (with the
Ubuntu patches). You can't patch anything later than that yourself because
of the huge differences between pre-2.6.23 and post-2.6.23 kernels with
regard to paravirtualization, and so the Xen patches wouldn't work as
expected.

However, you may be able to find a stock distro 2.6.22 kernel somewhere that
has been patched with support for that particular chipset as a backport
from the later vanilla kernels, and then you would be able to use the
Ubuntu Xen patches on that kernel.

Hmm... Maybe the Ubuntu kernel has this support built-in already? If so,
it would save you the trouble of patching the kernel yourself. After all,
they're the ones who supply a Xen-ready 2.6.22 kernel...

Just my two cents, though... Hope it's worth something... ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:

> Due to my decision to wait for the official Gentoo 2008.0 release so I could
> make a clean start without having to go through b0rkage hell if I were to
> use an older install and then use Portage to pull in the new release when
> it's ready, I still haven't been able to proceed with my plans.

I did download the beta2, it works but you get a really annoying message
for each package you emerge. I guess it will be out soon.

> However, what I can tell you is that 2.6.23 does not need patching - at
> least not for use in /domU/ - because 2.6.23 has Xen /domU/ support
> built-in,

Yes, if it had been just the domU, it hadn't been any problems, but
RedHat hasn't been working that much on the Xen dom0 patches and it
seems they have ditched Xen and replacing it with KVM.

http://java.sys-con.com/read/594249.htm
(annoying commercials warning!!)


I was even going for trying OpenSolaris as they have Xen support since
build 76 or something (current version is 91), but for some strange
reason I can't anymore login on my Sun account and tried to create a new
one with the same result (yes, did check that I allowed cookies), I
really hate how it's with downloads at Sun and IBM nowadays, they want
to be open source friendly, then they should also allow people to
download things in a normal fashion and allow mirror sites.

Checking for supported chipsets is doomed to fail when it comes to
OpenSolaris, they don't list any chipsets, they list 90 something
motherboards and you have to do the research for the chipset on the
motherboard yourself.

I know that NetBSD4 has Xen, but it's quite old now and I doubt it has
support for my motherboards chipset, FreeBSD seems to think jails is the
way to go...


> That said, for /dom0/ you are stuck with either 2.6.18 (as per the Xen
> sources tarball), 2.6.20 (with the RedHat patches) or 2.6.22 (with the
> Ubuntu patches). You can't patch anything later than that yourself because
> of the huge differences between pre-2.6.23 and post-2.6.23 kernels with
> regard to paravirtualization, and so the Xen patches wouldn't work as
> expected.

I did some download of kernels and patches, downloaded the Ubuntu 2.6.22
kernel source and then applied the "Xen" patch, but it seems it's
nothing more than a standard kernel, no dom0 options as far as I can find.


> However, you may be able to find a stock distro 2.6.22 kernel somewhere that
> has been patched with support for that particular chipset as a backport
> from the later vanilla kernels, and then you would be able to use the
> Ubuntu Xen patches on that kernel.

IMHO nowadays you see only Debian to do back porting of drivers as they
are quite slow on releasing new versions of applications and stuff for
the stable version, while others rush to release the new version and
saving a lot of work.


> Hmm... Maybe the Ubuntu kernel has this support built-in already? If so,
> it would save you the trouble of patching the kernel yourself. After all,
> they're the ones who supply a Xen-ready 2.6.22 kernel...

I'll make another try, but I'm not hopeful here... I guess I would have
better luck with OpenSolaris as dom0, but then it's the question if I
will be able to get hold of a copy...


> Just my two cents, though... Hope it's worth something... ;-)

At least I get a reply :)
I'm starting to think of getting a second machine, but I have the
trouble of finding a mATX motherboard with dual PCIe and SLI...




--

//Aho

On Monday 30 June 2008 21:25, someone who identifies as *J.O. Aho* wrote
in /alt.os.linux.gentoo:/

> Aragorn wrote:
>
>> Due to my decision to wait for the official Gentoo 2008.0 release so I
>> could make a clean start without having to go through b0rkage hell if I
>> were to use an older install and then use Portage to pull in the new
>> release when it's ready, I still haven't been able to proceed with my
>> plans.
>
> I did download the beta2, it works but you get a really annoying message
> for each package you emerge. I guess it will be out soon.

If my memory serves me right, then 2008.0 final was already scheduled for
the beginning of March or April. :-/

Perhaps they should do a little more than convene to plan on talking when
they'll be scheduling the next meeting for the discussion about just how
great they think they are. :-/

>> However, what I can tell you is that 2.6.23 does not need patching - at
>> least not for use in /domU/ - because 2.6.23 has Xen /domU/ support
>> built-in,
>
> Yes, if it had been just the domU, it hadn't been any problems, but
> RedHat hasn't been working that much on the Xen dom0 patches and it
> seems they have ditched Xen and replacing it with KVM.
>
> http://java.sys-con.com/read/594249.htm
> (annoying commercials warning!!)

I'm not too keen on RedHat because of some discriminatory decision they've
made in the past and are still making today. At first, they refused to
support KDE because KDE 1.x - although free in itself - was built using
non-free Qt libraries.

Then Qt became licensed under a free license and they still refused to
support KDE - pretending to be /the/ politically correct GNU/Linux company,
while their distro included loads of other non-free software and they also
don't use the name GNU/Linux for the entire operating system.

Now, for some reason - and I know this because we use CentOS for our
organization's servers - they refuse to support /XFS,/ /JFS/
and /reiserfs./ The installer won't let you create such filesystems,
although it will recognize them if you have them preformatted already, but
then it refuses to let you mount them anywhere in the tree.

> I was even going for trying OpenSolaris as they have Xen support since
> build 76 or something (current version is 91), but for some strange
> reason I can't anymore login on my Sun account and tried to create a new
> one with the same result (yes, did check that I allowed cookies), I
> really hate how it's with downloads at Sun and IBM nowadays, they want
> to be open source friendly, then they should also allow people to
> download things in a normal fashion and allow mirror sites.

I'm not too familiar with the latest developments in OpenSolaris. I was
rather under the impression even that Sun preferred the Solaris Zones - a
concept similar to zServer on GNU/Linux - over Xen, and I don't know
whether OpenSolaris can already be used as a /dom0/ either.

> Checking for supported chipsets is doomed to fail when it comes to
> OpenSolaris, they don't list any chipsets, they list 90 something
> motherboards and you have to do the research for the chipset on the
> motherboard yourself.

Yeah, I know. It's called OpenSolaris but it's anything _but_ open. :-/

> I know that NetBSD4 has Xen, but it's quite old now and I doubt it has
> support for my motherboards chipset, FreeBSD seems to think jails is the
> way to go...

Hardware support in the *BSDs is far behind on the Linux kernel, I'm afraid.

>> That said, for /dom0/ you are stuck with either 2.6.18 (as per the Xen
>> sources tarball), 2.6.20 (with the RedHat patches) or 2.6.22 (with the
>> Ubuntu patches). You can't patch anything later than that yourself
>> because of the huge differences between pre-2.6.23 and post-2.6.23
>> kernels with regard to paravirtualization, and so the Xen patches
>> wouldn't work as expected.
>
> I did some download of kernels and patches, downloaded the Ubuntu 2.6.22
> kernel source and then applied the "Xen" patch, but it seems it's
> nothing more than a standard kernel, no dom0 options as far as I can find.

Well, I've already configured and compiled the Gentoo-supplied 2.6.22
kernels, which _are_ in fact the Ubuntu kernels, and I did clearly see the
difference between that kernel and a vanilla stock kernel. Apart from the
Xen-specific options, it also now lacks support for a number of things that
have already been in the Linux kernel for quite some time, e.g. NUMA
support - i.e. the "sparse memory" and "discontiguous memory" options.

So I think you've probably done something wrong there. Mind you, the Xen
patches from Xen.org can only be applied to a 2.6.18 kernel, and so those
patches had to be adapted /to/ the 2.6.22 kernel by the Ubuntu guys before
the patches could be /applied/ to the kernel.

So if you're going to use the Ubuntu kernel, you have to use the Ubuntu Xen
patches. They're the only ones who've already adapted 2.6.22 to usage with
Xen. Other than that, it's like I said: a RedHat-patched 2.6.20 or the
Xen.org-supplied 2.6.18.

>> However, you may be able to find a stock distro 2.6.22 kernel somewhere
>> that has been patched with support for that particular chipset as a
>> backport from the later vanilla kernels, and then you would be able to
>> use the Ubuntu Xen patches on that kernel.
>
> IMHO nowadays you see only Debian to do back porting of drivers as they
> are quite slow on releasing new versions of applications and stuff for
> the stable version, while others rush to release the new version and
> saving a lot of work.

Ubuntu leans heavily on Debian, so it's possible that their kernels have
that support then too.

>> Hmm... Maybe the Ubuntu kernel has this support built-in already? If
>> so, it would save you the trouble of patching the kernel yourself. After
>> all, they're the ones who supply a Xen-ready 2.6.22 kernel...
>
> I'll make another try, but I'm not hopeful here... I guess I would have
> better luck with OpenSolaris as dom0, but then it's the question if I
> will be able to get hold of a copy...

Like I said, I don't know whether OpenSolaris can be used as a /dom0/ on
Xen. Given the delay in the release of Gentoo 2008.0, I haven't really
looked through the documentation anymore.

Hmm... Just looked around on my favorite mirror, and there is no
OpenSolaris repository there. :-/

>> Just my two cents, though... Hope it's worth something... ;-)
>
> At least I get a reply :)
> I'm starting to think of getting a second machine, but I have the
> trouble of finding a mATX motherboard with dual PCIe and SLI...

Does it have to be Micro ATX? I'm not a fan of all those crammed-into-
small-space motherboards. The Tyan motherboard in my monster machine is an
E-ATX even, albeit that E-ATX is not an official standard. It's actually
an SSI 12" x 13" motherboard. Well, it's a dual-socket NUMA board, so it
has to be roomy. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:
> On Monday 30 June 2008 21:25, someone who identifies as *J.O. Aho* wrote
> in /alt.os.linux.gentoo:/

>>> That said, for /dom0/ you are stuck with either 2.6.18 (as per the Xen
>>> sources tarball), 2.6.20 (with the RedHat patches) or 2.6.22 (with the
>>> Ubuntu patches). You can't patch anything later than that yourself
>>> because of the huge differences between pre-2.6.23 and post-2.6.23
>>> kernels with regard to paravirtualization, and so the Xen patches
>>> wouldn't work as expected.
>> I did some download of kernels and patches, downloaded the Ubuntu 2.6.22
>> kernel source and then applied the "Xen" patch, but it seems it's
>> nothing more than a standard kernel, no dom0 options as far as I can find.
>
> Well, I've already configured and compiled the Gentoo-supplied 2.6.22
> kernels, which _are_ in fact the Ubuntu kernels, and I did clearly see the
> difference between that kernel and a vanilla stock kernel. Apart from the
> Xen-specific options, it also now lacks support for a number of things that
> have already been in the Linux kernel for quite some time, e.g. NUMA
> support - i.e. the "sparse memory" and "discontiguous memory" options.
>
> So I think you've probably done something wrong there. Mind you, the Xen
> patches from Xen.org can only be applied to a 2.6.18 kernel, and so those
> patches had to be adapted /to/ the 2.6.22 kernel by the Ubuntu guys before
> the patches could be /applied/ to the kernel.
>
> So if you're going to use the Ubuntu kernel, you have to use the Ubuntu Xen
> patches. They're the only ones who've already adapted 2.6.22 to usage with
> Xen. Other than that, it's like I said: a RedHat-patched 2.6.20 or the
> Xen.org-supplied 2.6.18.

I did download the patch from ubuntu and it felt like a domU patch, the
same way as Redhat has gone with the latest Fedora releases.


>>> However, you may be able to find a stock distro 2.6.22 kernel somewhere
>>> that has been patched with support for that particular chipset as a
>>> backport from the later vanilla kernels, and then you would be able to
>>> use the Ubuntu Xen patches on that kernel.
>> IMHO nowadays you see only Debian to do back porting of drivers as they
>> are quite slow on releasing new versions of applications and stuff for
>> the stable version, while others rush to release the new version and
>> saving a lot of work.
>
> Ubuntu leans heavily on Debian, so it's possible that their kernels have
> that support then too.

There is a big gap between the kernel used in Debian and ubuntu.


>>> Hmm... Maybe the Ubuntu kernel has this support built-in already? If
>>> so, it would save you the trouble of patching the kernel yourself. After
>>> all, they're the ones who supply a Xen-ready 2.6.22 kernel...
>> I'll make another try, but I'm not hopeful here... I guess I would have
>> better luck with OpenSolaris as dom0, but then it's the question if I
>> will be able to get hold of a copy...
>
> Like I said, I don't know whether OpenSolaris can be used as a /dom0/ on
> Xen. Given the delay in the release of Gentoo 2008.0, I haven't really
> looked through the documentation anymore.

Take a look here:
http://opensolaris.org/os/community/xen/


> Hmm... Just looked around on my favorite mirror, and there is no
> OpenSolaris repository there. :-/

I guess your favorite mirror isn't sun.com and you aren't using a stupid
and slow http download.


>>> Just my two cents, though... Hope it's worth something... ;-)
>> At least I get a reply :)
>> I'm starting to think of getting a second machine, but I have the
>> trouble of finding a mATX motherboard with dual PCIe and SLI...
>
> Does it have to be Micro ATX? I'm not a fan of all those crammed-into-
> small-space motherboards.

I spent quite a lot of money on the machine I bought and would like to
reuse as much of what I already have and the case I have is just a mATX
board (time to replace my old Pegasos).


> The Tyan motherboard in my monster machine is an
> E-ATX even, albeit that E-ATX is not an official standard. It's actually
> an SSI 12" x 13" motherboard. Well, it's a dual-socket NUMA board, so it
> has to be roomy. ;-)

I guess it's not fan-less, gosh I miss those good old days when you
didn't have fans to cool down personal computers, they worked fine with
passive cooling.


--

//Aho

On Tuesday 01 July 2008 07:31, someone who identifies as *J.O. Aho* wrote
in /alt.os.linux.gentoo:/

> I guess your favorite mirror isn't sun.com and you aren't using a stupid
> and slow http download.

No, it's ftp://ftp.belnet.be, and it's on a backbone. :-)

> I spent quite a lot of money on the machine I bought and would like to
> reuse as much of what I already have and the case I have is just a mATX
> board (time to replace my old Pegasos).

Well, Micro ATX is normally not designed for use with many expansion cards.
Those motherboards are typically used in those small microtower chassis and
generally have lots of on-board chips - comparable to laptops - so that one
wouldn't need plug-in cards. Unfortunately, the functionality of those
on-board chips quite often does not even begin to match plug-in cards.

>> The Tyan motherboard in my monster machine is an E-ATX even, albeit that
>> E-ATX is not an official standard. It's actually an SSI 12" x 13"
>> motherboard. Well, it's a dual-socket NUMA board, so it has to be
>> roomy. ;-)
>
> I guess it's not fan-less, [...

No, it isn't. I'm not sure how many fans are in the PSU - normally that
would be one, but my dual Xeon box has two - but there are also two
processor fans, one 12 cm fan for the disk bay holding the four SAS disks,
a fan for each videocard and three more 12 cm case fans.

Apart from one of the case fans which has picked up some dust, the machine
is relatively quite though. It's even more quiet than the PC I'm typing
this from.

> ...] gosh I miss those good old days when you didn't have fans to cool
> down personal computers, they worked fine with passive cooling.

You mean back in the days of the i386? :p Well, mine - a Brother BCN3386
slimline desktop model - still made a lot of noise because of that tiny
little fan in the power supply. :-)

--
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:
> On Tuesday 01 July 2008 07:31, someone who identifies as *J.O. Aho* wrote
> in /alt.os.linux.gentoo:/
>
>> I guess your favorite mirror isn't sun.com and you aren't using a stupid
>> and slow http download.
>
> No, it's ftp://ftp.belnet.be, and it's on a backbone. :-)

Ftp:s reminds me of the good old days, when you could write mp3 at any
search engine and you got a load of anonymous ftp sites from where you
could download what ever you wanted, no need to register, keep track of
10 million different 123456-passwords.

Gosh, getting quite off topic here.

Tried to play a bit with OpenVZ yesterday, the latest kernel for that is
2.6.24, must be some regression patch there or something, as the OpenVZ
kernel didn't recognize my sata, while the gentoo boot cd seemed to work
(if I don't remember it wrong, it too used 2.6.24), but reading from the
wiki it seems they will release a new OpenVZ kernel as soon as 2.6.26
has been released, sadly it won't give me direct access to the graphics
cards in a container.
I guess all I can try is to order that opensolaris cds/dvd and see what
happens, if it works or not.


>> ...] gosh I miss those good old days when you didn't have fans to cool
>> down personal computers, they worked fine with passive cooling.
>
> You mean back in the days of the i386? :p Well, mine - a Brother BCN3386
> slimline desktop model - still made a lot of noise because of that tiny
> little fan in the power supply. :-)

Back in those days I used Amiga, even the PSU was fanless, that was the
reason I bought the Pegasos in the first place, but it starts to feel a
bit lagish for my use and the IDE interface ain't the best one, but it
had three PCI and one AGP, which seems to be a lot more than the two PCI
and one PCIe on those mATX boards I have seen.

When talking about noisy, I have to nominate my UltraSparc 10, I have
switched to a quiet PSU, but the 120mm front fan (not figured out how to
get it disconnected) is extremely loud, it's almost like being in a
server hall, one packed with loud servers.
Don't use that so often, think it's 9 months since last.

--

//Aho

On Tuesday 01 July 2008 21:10, someone who identifies as *J.O. Aho* wrote
in /alt.os.linux.gentoo:/

> Aragorn wrote:
>> On Tuesday 01 July 2008 07:31, someone who identifies as *J.O. Aho* wrote
>> in /alt.os.linux.gentoo:/
>>
>>> I guess your favorite mirror isn't sun.com and you aren't using a stupid
>>> and slow http download.
>>
>> No, it's ftp://ftp.belnet.be, and it's on a backbone. :-)
>
> Ftp:s reminds me of the good old days, when you could write mp3 at any
> search engine and you got a load of anonymous ftp sites from where you
> could download what ever you wanted, no need to register, keep track of
> 10 million different 123456-passwords.
>
> Gosh, getting quite off topic here.

There's no harm in that. :-)

> Tried to play a bit with OpenVZ yesterday, the latest kernel for that is
> 2.6.24, must be some regression patch there or something, as the OpenVZ
> kernel didn't recognize my sata, while the gentoo boot cd seemed to work
> (if I don't remember it wrong, it too used 2.6.24), but reading from the
> wiki it seems they will release a new OpenVZ kernel as soon as 2.6.26
> has been released, sadly it won't give me direct access to the graphics
> cards in a container.

Isn't it possible to hide the graphics card PCI address from the host kernel
at boot time?

> I guess all I can try is to order that opensolaris cds/dvd and see what
> happens, if it works or not.

Well, I'd be interested in learning about your progress there, as there is a
(very slim) chance that I too would be picking OpenSolaris for the /dom0,/
provided that it even supports all my hardware, which I have explicitly
gathered with the intention of using GNU/Linux only.

>>> ...] gosh I miss those good old days when you didn't have fans to cool
>>> down personal computers, they worked fine with passive cooling.
>>
>> You mean back in the days of the i386? :p Well, mine - a Brother BCN3386
>> slimline desktop model - still made a lot of noise because of that tiny
>> little fan in the power supply. :-)
>
> Back in those days I used Amiga, even the PSU was fanless, that was the
> reason I bought the Pegasos in the first place, but it starts to feel a
> bit lagish for my use and the IDE interface ain't the best one, but it
> had three PCI and one AGP, which seems to be a lot more than the two PCI
> and one PCIe on those mATX boards I have seen.

Yeah, it's the good old consumerism/manufacturism again... Build something
that sells well to the grey unwashed masses, rather than something that
actually would be useful. :-/

> When talking about noisy, I have to nominate my UltraSparc 10, I have
> switched to a quiet PSU, but the 120mm front fan (not figured out how to
> get it disconnected) is extremely loud, it's almost like being in a
> server hall, one packed with loud servers.
> Don't use that so often, think it's 9 months since last.

The noisiest one I have is that dual Xeon machine, but I'm no longer using
that until *somebody* wants to thoroughly check that hardware. There is
something wrong with that machine - either one of the processors or the
motherboard itself, or possibly both - that makes it crash without any
apparent cause and regularly causes the kernel to recognize only three of
the four hyperthreads during boot.

If the mobo is flaky, then it would be a shame because of the money and
trouble that machine has cost me - it's a long story that basically comes
down to my being ripped off without that there was a damn thing I could do
about it - and because it's only just been upgraded with a hardware U320
SCSI RAID controller and two 73 GB U320 disks (in RAID 1), and it's got 4
GB of ECC registered pc2100 (working at pc1600 spec).

I've had the machine checked and tested, but nobody tested it with one of
those hardware test cards. Apparently those are very expensive, even for
computer hardware vendors. Yet I'm convinced that this is the only way
they'll ever be able to ascertain the problem.

As for the noise, that chassis has four 8 cm fans - two in the front and two
in the back - and especially the ones in front sound like a vacuum cleaner.
Well, they suck up dust like one too. :p

--
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:
> On Tuesday 01 July 2008 21:10, someone who identifies as *J.O. Aho* wrote
> in /alt.os.linux.gentoo:/

>> Tried to play a bit with OpenVZ yesterday, the latest kernel for that is
>> 2.6.24, must be some regression patch there or something, as the OpenVZ
>> kernel didn't recognize my sata, while the gentoo boot cd seemed to work
>> (if I don't remember it wrong, it too used 2.6.24), but reading from the
>> wiki it seems they will release a new OpenVZ kernel as soon as 2.6.26
>> has been released, sadly it won't give me direct access to the graphics
>> cards in a container.
>
> Isn't it possible to hide the graphics card PCI address from the host kernel
> at boot time?

I have to say I don't know too much about OpenVZ to give a proper answer
on that, but I watched (listened half hearted) to an one hour long
presentation about OpenVZ by one of the devels and he mentioned
something about you can't load kernel modules inside the container, and
for getting nVidia (closed source driver) to work, you need to use the
kernel module, but at the same time he told that there was people who
had succeeded to dedicate a NIC to a container, so maybe it's possible
to make things work in a OpenVZ container in the same manner as in Xen,
but I would guess that would require some work on the OpenVZ code.


>> I guess all I can try is to order that opensolaris cds/dvd and see what
>> happens, if it works or not.
>
> Well, I'd be interested in learning about your progress there, as there is a
> (very slim) chance that I too would be picking OpenSolaris for the /dom0,/
> provided that it even supports all my hardware, which I have explicitly
> gathered with the intention of using GNU/Linux only.

Yes, I had the same intention too, until it turned out that I couldn't
use my SATA drives, I may be able to use IDE drives, but at the moment
I'm in a moment 22 catch, where I can't use my IDE to the new machine
until I copied it over to the new machines SATA, but I can't do that
until I have the new machine up and running, so it can replace the old
machine (can't shrink the JFS on the LVM).

If I could get things work from IDE, then I would need to set up one
extra domU, to share the SATA disks content over NFS, which I had
thought i would do from the dom0.

if the opensolaris would work, I don't expect it to be much worked on,
all I would do would be to keep it up and running, the idea is that no
one would access the dom0 except physically sitting in front of the
machine, so wouldn't be too worried over exploits.



--

//Aho

Aragorn wrote:

>> I guess all I can try is to order that opensolaris cds/dvd and see what
>> happens, if it works or not.
>
> Well, I'd be interested in learning about your progress there, as there is a
> (very slim) chance that I too would be picking OpenSolaris for the /dom0,/
> provided that it even supports all my hardware, which I have explicitly
> gathered with the intention of using GNU/Linux only.

It installs to my hard drives as I write, but one thing I noticed at
once was that you couldn't make one huge zfs at once, you can LVM
everything on most Linux distributions today... so why not give the same
option in opensolaris... I'll post again as soon as I have something to
report.

--

//Aho