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 <zo...@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
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101228201751.ga13...@xibalba.demon.co.uk
