[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release notes addition for Xen support in Debian



I'll treat this and Thomas Goirand's rewrite as separate requests
for review and let someone else decide how to merge them.

Ben Finney wrote:
> Martin Zobel-Helas <zobel@debian.org> writes:
>> | 4.7.4. Upgrading with Xen installed, and Kernel enumeration order issue with
>> | Xen
> 
> For a section title in the context of this document, I think “issue” is
> redundant.

Also, the capitalisation is a bit random.
 
>> | In Lenny, using grub legacy, the following kernel order was respected: - Xen
>> | hypervisor with Xen dom0 kernel - Normal (eg: without dom0 support) kernel -
>> | Xen dom0 kernel (without they hypervisor)
> 
> s/they hypervisor/the hypervisor/
> 
> I am fairly sure “eg: without dom0 support” is meant to be “i.e.,
> without dom0 support”. The original author should explain whether this
> is meant to be “for example” (“e.g.”), or “that is” (“i.e.”).
> 
> Those are supposed to be a bulleted list, I presume? Perhaps editing has
> collapsed the paragraph. Here it is as a bulleted list:
> 
>     […] the following kernel order was respected:
> 
>     * Xen hypervisor with Xen dom0 kernel
>     * Normal (i.e., without dom0 support) kernel
>     * Xen dom0 kernel (without the hypervisor)

And to avoid further abbreviatory confusion, make the middle one
      * Normal kernel (without dom0 support)
(Here and later.)

>> | This order was the natural expected one, because if you installed Xen, it will
>> | simply boot the hypervisor and it's dom0 by default as expected.
> 
> Maybe easier to scan:
> 
>     This was the default order, because Xen's default configuration was
>     to boot the hypervisor and it's dom0.

Whoops, you mean "its" (possessive).  Otherwise, agreed.  Maybe you
could put back some of the "natural expected" bit like this:

      This made a natural default order, because Xen's default configuration
      was to boot the hypervisor and its dom0.
 
>> | Unfortunately, in Squeeze, when running with Grub2, this isn't what is
>> | happening. By default, the order is the exact opposite: - Xen dom0 kernel
>> | (without they hypervisor) - Normal (eg: without dom0 support) kernel - Xen
>> | hypervisor with Xen dom0 kernel
> 
> Briefer and perhaps more neutral (and again assuming a bulleted list was
> the intent):
> 
>     This does not happen under GRUB 2 in Squeeze. Instead, the order is
>     the exact opposite:
> 
>     * Xen dom0 kernel (without the hypervisor)
>     * Normal (i.e., without dom0 support) kernel
>     * Xen hypervisor with Xen dom0 kernel
> 
> The spelling and capitalisation of “GRUB 2” should be as I have written
> it there, to conform with <URL:http://www.gnu.org/software/grub/>.

(In Lenny someone might have argued for the packagename "grub2", all
lowercase, but that's a dummy package in Squeeze anyway.)

>> | As a consequence, if you have Xen installed and expect to boot with it by
>> | default, you have to tweak grub2 configuration. One of the way to hack before
>> | the grub maintainers can fix it the proper way could be to simply do:
> 
> My suggestion:
> 
>     As a consequence, if you have Xen installed and expect to boot with
>     it by default, you have to either wait for the GRUB 2 maintainers to
>     fix the sequence or tweak the GRUB 2 configuration. One work-around
>     is to simply do:

(In fact I find "workaround" in more dictionaries than
"work-around", presumably because it was never a "work around")
 
>> | ln -s 20_linux_xen /etc/grub.d/09_linux_xen_first dpkg-reconfigure grub-pc
>> | 
>> | so that Xen is loaded first, by default, when using Grub2.
> 
> s/Grub2/GRUB 2/
> 
>> | Another thing that you have to take care about when upgrading from Lenny, is
>> | that currently, Xen isn't upgraded to the 4.0 version that you should be
>> | expecting in Squeeze. So, after you finished the dist-upgrade, it is advised to
>> | check that Xen 4.0 and the corresponding dom0 kernel are installed. Under the
>> | 64 bits architecture, the following command will fix this:
> 
> The ‘dist-upgrade’ subcommand is deprecated; ‘full-upgrade’ is now
> recommended. Here is my suggestion:
> 
>     Also, when upgrading from Lenny, Xen is not upgraded to the 4.0
>     version that you should be expecting in Squeeze. So, after the
>     ‘full-upgrade’ is complete, you are advised to check that Xen 4.0
>     and the corresponding dom0 kernel are installed.
> 
> The official recommended package installation tool is ‘aptitude’, so
> that's what our official notes should be recommending:

It's not clear that that's true for this release; it's what I've
always used (and its full-screen mode has given me some painless
test Lenny-to-Squeeze upgrades), but I've seen claims on
debian-devel or somewhere that apt's resolver is currently more
robust.
 
>     * For the ‘amd64’ architecture, use the following command:
> 
>       aptitude install xen-utils-common xen-utils-4.0 xenstore-utils libxenstore3.0 xen-hypervisor-4.0-amd64 linux-image-2.6.32-5-xen-amd64
> 
>     * For the ‘i686’ architecture, use the following command:

"The i386 architecture" or "the i686 CPU architecture"?
 
>       aptitude install xen-utils-common xen-utils-4.0 xenstore-utils libxenstore3.0 xen-hypervisor-4.0-i686 linux-image-2.6.32-5-xen-i686
> 
>> | Also, if you require HVM support, you will need to install the Xen Qemu device
>> | model, which is now a separate package:
>> | 
>> | apt-get install xen-qemu-dm-4.0
> 
> s/apt-get/aptitude/
> 
>> | It is also important to notice that your domU wont be able to use sda1 (for
>> | example) as device name for their HDD. This naming scheme has been removed from
>> | Xen because of a request from the mainline kernel maintainers. Instead, you
>> | should use xvda1 (as a corresponding example) instead.
> 
> This last paragraph reads fine to me.

Fixing some trivial linguistic glitches:

     Be aware that your domU won't be able to use (for example) sda1 as a device
     name for its hard drive. This naming scheme has been removed from Xen because
     of a request from the mainline kernel maintainers. Instead you should use
     (as a corresponding example) xvda1.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: