richard.elkins at gmail.com
Wed Jan 29 19:21:55 UTC 2014
I am not trying to be picky but it is not just an issue of "settings".
There are issues about mixtures of MBR boot loaders, VBR boot loaders,
boot managers, their ages, and what order partition boot chaining is
performed. To whatever degree that folks have time and energy and
resources, there are subtleties that are worth verifying. Of course, I
respect that we all need to prioritize our time.
A useful if simplified reference:
More detailed description of the MBR:
and the partition-resident Volume Boot Record (VBR) i.e. partition boot
For example, imagine a circa 2007 PC running Windows XP that had 12.04
added in 2012 as a dual-boot machine. Both OSes are stable. The MBR is
probably a 2005 bootloader created by Windows XP. The boot manager is
probably the Windows XP NTLDR. The user, based on the Windows
C:\boot.ini file, selects either Windows or 12.04 to boot. If Windows
is selected, then NTLDR initiates the loading of the rest of Windows
from the current partition. If 12.04 is selected, the 12.04 Linux
kernel in the destination partition is booted.
Depending on how 12.04 was installed, it is also possible that the boot
manager invoked by the MBR is the 12.04 Grub. In this case, the user
selects either Windows or 12.04 from the Grub menu. Grub boots up
Windows in the destination partition or 12.04 in the current partition.
So, in just this example, we can see the interaction of at least 3
different bootloaders and there are two different orders in which either
OS can be invoked.
Note that I inadvertently forgot the multi-boot with MACOSX scenario in
the previous mail. I have done this successfully in the past with an
iMac but dare not attempt this today with my wife's Macbook Air without
risking being exiled to the couch!
On 01/29/2014 11:11 AM, Pasi Lallinaho wrote:
> On 29/01/14 18:47, Richard Elkins wrote:
>> The test cases documented
>> a) Execute `update-manager -d -c` from a terminal
>> b) ISO-based upgrade
>> apply to at least 4 distinct upgrade scenarios:
>> 1. 12.04 occupies a full HDD or SSD.
>> 2. 12.04 is dual-booted with Windows.
>> (Dual-booting and Windows should still function as before
>> after the upgrade of 12.04 to 14.04)
>> 3. 12.04 is dual booted with another Linux distribution (E.g. fedora).
>> (Dual-booting and the other Linux should still function as
>> before after the upgrade of 12.04 to 14.04)
>> 4. 12.04 is dual booted with Unix (E.g. netbsd).
>> (Dual-booting and Unix should still function as before after
>> the upgrade of 12.04 to 14.04)
> Basically there shouldn't be any difference between these scenarios,
> except maybe the bootloader settings. I'm pretty sure the upgrade will
> respect whatever config is in place regarding that as well.
> That's not to say different kind of tests aren't welcome; they most
> definitely are.
>> #1 is probably the most common scenario.
>> #2 is unique because of the requirement to coexist with the Microsoft
>> #3 and #4 are different from #1 because of potential boot-loader and
>> grub version differences (potential conflicts).
>> NOTE: I left out Android because the probability of someone
>> dual-booting Android (Linux kernel but yet another boot-loader
>> scenario) and Xubuntu 12.04 at the moment is not significant. Other
>> opinions? However, next time (16.04?) could be a different matter.
>> #2 can be set-up by downloading a legal evaluation copy of Windows
>> 8.1 from here:
>> Note that you will be prompted my Microsoft to login or register if
>> you are not already logged in. Registering is legally cost-free.
>> Please do not use illegal bitorrent methodologies.
>> I'll do all 4x2=8 cases as soon as all of my "day jobs" permit, in
>> the above priority order (other opinions about order?). I am
>> downloading W-oink as I type.
> No other priorities, but please mention the scenario you were
> upgrading from in the comments section of the test report.
>> Someone else PLEASE do as much as possible of the same as I my
>> test-rig is still an Intel-abandoned Intel CedarTrail/PowerVR
>> motherboard (D2550MUD2). Yes, I am going to get rid of it during
>> 1Q2014 since nothing fully makes use of the hardware including
>> Windows. Still kicking myself for poor research 12 months ago! (-:
>> https://launchpad.net/~texadactyl <https://launchpad.net/%7Etexadactyl>
>> On 01/29/2014 06:11 AM, Elfy wrote:
>>> In a few months time we will be releasing 14.04 Trusty Tahr LTS.
>>> Up to now we have been concentrating on package and image testing
>>> for Trusty.
>>> Now, we need to start running upgrade tests, most importantly the
>>> LTS to LTS upgrades (from 12.04 to 14.04) and as usual, the regular
>>> upgrades (from 13.10 to 14.04).
>>> Testcases are present for both 64 and 32 bit at
>>> As there is no specific testcase available at present for the _LTS
>>> to LTS_ upgrade - please use the comment area of the tracker report
>>> to note which type of upgrade you tested - LTS or non-LTS
>>> It would be infinitely better to be have upgrades tested with real
>>> data, but at worst tests via Virtual Machines will check the basic
>>> upgrade path.
>>> *_NOTE: If you are testing with real data, please make backups first!_*
>>> Ubuntu Forum Council Member
>>> Xubuntu QA Lead
> Pasi Lallinaho (knome) » http://open.knome.fi/
> Leader of Shimmer Project and Xubuntu » http://shimmerproject.org/
> Graphic artist, webdesigner, Ubuntu member » http://xubuntu.org/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xubuntu-devel