Chinese raring desktop images have different format of media-info to that of standard desktop images

Bug #1085918 reported by Para Siva on 2012-12-03
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
Undecided
Unassigned

Bug Description

Chinese raring desktop images obtained from china-images.ubuntu.com/raring/daily-live/current have disk-info files in the format of
                                'Ubuntu "Raring" - Build amd64 LIVE Binary 20121202-22:55'

Where as the standard images have disk-info files
                                'Ubuntu 13.04 "Raring-Ringtail" - Alpha amd64 (20121202)'

Althought this might seem a minor impact issue, it makes the automation of smoke tests for chinese images impossible using utah because utah uses second format above strictly to create the xml for vm provisioning. UTAH throws the following error

'libvirt.libvirtError: internal error os type 'hvm' & arch 'Binary' combination is not supported.

from http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/iso.py
This is what utah assumes
       # Info file looks like this:
        # Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
        # or this:
        # Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120820)
        # i.e. Ubuntu Version (LTS) "Series Codename" - Alpha/Beta/Release
        # arch (buildnumber)

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: ubiquity 2.13.6
ProcVersionSignature: Ubuntu 3.7.0-4.12-generic 3.7.0-rc7
Uname: Linux 3.7.0-4-generic x86_64
ApportVersion: 2.6.3-0ubuntu2
Architecture: amd64
CasperVersion: 1.329
Date: Mon Dec 3 11:48:15 2012
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash -- locale=zh_CN keyboard-configuration/layoutcode?=cn
LiveMediaBuild: Ubuntu "Raring" - Build amd64 LIVE Binary 20121202-22:55
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=zh_CN.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Para Siva (psivaa) wrote :
summary: Chinese raring desktop images have different format of media-info to
- that of English desktop images
+ that of standard desktop images
Para Siva (psivaa) on 2012-12-03
description: updated
affects: ubiquity (Ubuntu) → ubuntu-cdimage
Para Siva (psivaa) on 2012-12-03
tags: added: rls-r-incoming
Para Siva (psivaa) wrote :

This issue is still present in the latest raring desktop installations.

i.e. The media-info in Chinese images says - Ubuntu "Raring" - Build amd64 LIVE Binary 20130116-22:55
as opposed to the standard images where it says - Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130116)

This issue is blocking automation of Chinese image installations for smoke tests. Is there any chance that it could be looked at please?

It could easily be worked around in automation, so I don't see why it
needs more urgent attention than things that can't be worked around.

Max Brustkern (nuclearbob) wrote :

To add support for this in utah, we'd need examples of the media info files from Chinese desktop, server, alternate, and mini images, for daily, milestone, and release versions. We could use those to build a profile of what that media info looks like, and probably autodetect Chinese vs. non-Chinese images. Worst case, we could add a configuration option to specify Chinese images. This would probably entail 2-3 hours of work, most of which would be testing to ensure we detect all existing and newly supported image types correctly.

Steve Langasek (vorlon) wrote :

On Fri, Jan 18, 2013 at 03:04:04PM -0000, Max Brustkern wrote:
> To add support for this in utah, we'd need examples of the media info
> files from Chinese desktop, server, alternate, and mini images, for
> daily, milestone, and release versions.

There are only Chinese desktop images, you shouldn't need to worry about any
of the other types of images here.

The .disk/info format is the same for both daily and release versions of
these images:

  Ubuntu "Raring" - Build amd64 LIVE Binary 20130116-22:55

Para Siva (psivaa) wrote :

Thank you all for the comments.

@Max: Can we not change getarch() function to be more flexible rather than being so strict in its assumption of the media-info file format. i.e. Assuming that two arch strings wont be present in the infofile at the same time, rather than looking at a specific location for arch can we not do something like,
               if 'i386' in open(self.infofile).read()
                   arch = 'i386'
                  etc.?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers