 |
Other languages English ; Français ; |
Working on pre-release ISOs Seems obsolete. Keep it?
| Synopsis: This Wiki page aimed to explain everything you need to know to participate in testing Pre-release Mageia ISO images. This is especially important to people who have not done it before. It got too big, so now:
|
Contents
Joining Up & Participating
If you are looking at this wiki page, you probably have passed via
"The Mageia QA Team" introduction page https://wiki.mageia.org/en/QA_Team
and followed its advice to
"subscribe to the QA-Discuss mailing list" at
https://ml.mageia.org/l/info/qa-discuss, e-mail address qa-discuss@ml.mageia.org
and "joined the #mageia-qa IRC channel on libera" at
irc.libera.chat:6697, channel #mageia-qa
(for which you will need to invent a nickname for yourself);
and introduced yourself on one or both of these.
The mailing list is the main permanent communication channel; easiest via your normal e-mail client. It will generate a lot of e-mail, but it is quick to delete messages which do not concern you. To raise a new topic - like asking a question - simply send an e-mail to it; everyone will see it. To reply to a message, just do so normally. Everyone will see the reply, and it may yield further responses. The mailing list is the main channel for all necessary pre-release information, like the announcement of new ISOs.
The IRC channel meets every Thursday at 19.00 UTC/GMT [N summer] 20.00 [N winter]. Sessions normally start with 'Anyone new?' to introduce yourself. Try and attend; it is instructive just to 'lurk'. At other times, someone *may* be online, so if you want a quick answer to something, try your luck signing on and asking if anyone is there. But be ready to wait some time before you are noticed & someone replies.
Feel free to ask questions about *anything* via both channels. It is a QA maxim that "No question is silly except the question that is not asked". People are very helpful.
Additionally, (you already did this if you're subscribed to the qa-discuss mailing list) you will need to get a Mageia.org user account at identity.mageia.org to be able to login and edit some QA Wiki pages as follows:
- to add yourself as a real ISO tester (easy to edit)
"QA ISO testers" at https://wiki.mageia.org/en/QA_ISO_testers
- to add the details of your hardware
"QA iso hardware list" at https://wiki.mageia.org/en/QA_iso_hardware_list which is tricky to edit. Easiest is to copy an existing entry then edit that for your system.
Your Mageia-ID also serves for write access to the Bugzilla system at https://bugs.mageia.org/ if you need that e.g. to raise or add to a bug. Anyone can look at this read-only.
What Are You Testing?
Mageia is available in a large number of formats known as ISOs, each of which needs to be tested. Although traditionally aimed at creating bootable CD/DVD installation, increasingly they are used for creating bootable USB sticks. The ISOS are:-
- Classical Installation Flavours which can be used to upgrade from the previous Mageia release.
- DVD 32bit 3.7GB
- DVD 64bit 3.7GB
- LiveDVDs which cannot be used to upgrade a system.
- LiveDVD Plasma-x86_64 All languages 2.4GB
- LiveDVD GNOME-x86_64 All languages 2.1GB
- LiveDVD Xfce-i586 All languages 1.9GB
- LiveDVD Xfce-x86_64 All languages 2.0GB
- Wired Network-based Installation CD.
- Network installer, Free Software CD 32bit ~35MB
- Network installer, Free Software CD 64bit ~20MB
- Network installer + nonfree firmware CD 32bit ~55MB
- Network installer + nonfree firmware CD 64bit ~30MB
Terminology
Conventionally the word 'release' applies to the major release of a distribution, say Mageia 3 or Mageia 5. Each major release involves a number of pre-release 'versions' (which encompass all the ISOs), typically alpha1, alpha2, beta1, beta2, RC (Release Candidate), final. Externally one talks in terms of "Mageia 5 is available in its Beta2 version".
In the world of Mageia ISOs, the word Release combines the two: release-version, like mageia4-final or mageia5-beta1. (This may be because each such [pre] Release is in fact ultimately released to the public). This convention is used in the organization of the pre-release ISOs, and the tools for downloading & updating them, and hence also in this document. A final release is preceded by all the named [pre] Releases, mageiax-alpha1 -> mageiax-final.
In addition, each Release evolves through a number of Rounds before it is finally made public. All the ISOs need testing for every Round of every Release ! However, one individual should not expect nor attempt to test more than a subset of the ISOs appropriate to his/her circumstances - even if just one.
What Resources Do You Need?
Real Hardware
Testing is always preferred on real hardware; see the following section for using instead Virtual Machines. Clearly, as a bare minimum, you need a working system with enough free disc space (see below); and a fast Internet connection - downloading ISOs can take many hours. You should know how to manage disc partitions. It is handy - but not essential - to have a second computer so that you always have a working system independent of the testing one, and can access the Internet independently of the test setup.
The test computer must be able to boot from CD/DVD or USB stick, and you must know how to manage the BIOS to make it do so. (Note that currently EFI booting is not officially supported, even though it is possible to install on an EFI system; read the UEFI How-to). If you intend to 'multi-boot' the test system with your normal working system, you should know how to handle this aspect, and get back to booting your normal system: Linux installations tend to want to take over booting the machine unless you coerce them not to.
A 'live' rescue CD such as SystemRescueCD (or a Mageia Live DVD) is advisable for accessing a non-booting system; or perhaps archiving & restoring a Mageia installation to test-upgrade.
Disc Partitions & Space
On real h/w, you will need a spare partition of at least 8Gb to install Mageia into.
For other space in your normal working system (whether on the same or another machine), you need enough free space to contain all the ISO images you anticipate testing plus the largest of those: say 20Gb for the whole lot, 15Gb for all one architecture, less if you narrow your choice. If you will be testing upgrades, say from Mageia 3 to 4, you would be well advised to have also enough space to conserve a copy of the 'old' version's partition; this is discussed in the "Testing Upgrades" section later. If you are short of hard disc space, a USB disc or USB stick is a good way of coping.
Virtual Machines (VMs)
This requires a machine with lots of memory, plus a fast Internet connection. You must know how to manage VMs. They are convenient for basic installation and usage testing, and obviate the need for dedicated h/w. You will need spare disc space for the ISOs you want to test as per the previous paragraph, plus enough for the VM(s). Your VM host system will always be available whatever the behaviour of the Mageia test installation; handy! But at the end of the day, real h/w is called for.
Managing the ISO Images
This is a major part of the process. If the description appears long, it is because it pays to understand what is going on.
The raw material
ISOs exist (and are preserved) distinctly for each Release, for example:
mageia4-final mageia4-v2 mageia5-alpha1 mageia5-alpha2 mageia5-beta1
A typical ISO set for one is:-
Mageia-5-beta1-LiveCD-GNOME-en-i586-CD Mageia-5-beta1-LiveCD-KDE4-en-i586-CD Mageia-5-beta1-LiveDVD-GNOME-i586-DVD Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD Mageia-5-beta1-LiveDVD-KDE4-i586-DVD Mageia-5-beta1-LiveDVD-KDE4-x86_64-DVD Mageia-5-beta1-dual-DVD Mageia-5-beta1-i586-DVD Mageia-5-beta1-x86_64-DVD
In fact each so-called ISO is a directory which contains not only the actual ISO image file *.iso, but additional files like date, checksums. For example (the Classic DVD):-
DATE.txt Mageia-5-beta1-x86_64-DVD.idx Mageia-5-beta1-x86_64-DVD.iso Mageia-5-beta1-x86_64-DVD.iso.md5 Mageia-5-beta1-x86_64-DVD.iso.sha1
or (a Live ISO):-
DATE.txt Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.iso Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.iso.md5 Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.iso.sha1 Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.langs Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.lst Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.lst.full Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.lst.leaves Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.lst.names
Note well that both the ISO directory and subordinate file names incorporate the Release. This has consequences for you discussed later in "Directory/file name changes at Release changes".
To see the contents of the DATE.txt, iso.md5 or iso.sha1 files, simply
cat <filename>
How it is organised & evolves
The ISOs are hosted on a server: 'bcd.mageia.org/isos'.
Here there is a directory for each Release e.g. mageia5-beta1. [First list above]
Each such directory contains the full ISO set. [Second list above]
As a Release progresses from its current version to the next, a new directory for it (appropriately named) is created on the server, fully populated with the ISOs. All the new ISO directory names, and their subordinate file names, change correspondingly. Look again at the lists above. The previous Release rests intact, as it was.
What happens for the Rounds which constitute re-issues of the ISOs within the current version? They simply replace the previous ISOs, and do not involve creating anything new, nor changing any directory/file names. Hence individual Rounds are not preserved, only the latest survive.
So how do you cope with all this?
Start by creating your own 'umbrella' directory to contain the ISOs you wish to test; this can be anywhere and have any name you like e.g. isos/, mageia/, mageia/isos/.
Your local ISO directories become populated with the ISOs you want the first time you ' synchronize' them, which includes creating them if necessary.
The main thing to keep in mind is that you maintain just one copy of the ISOs you wish to test, keeping them up-to-date (synchronised) with their latest versions on the server - whether that be the latest Round in the ongoing Release, or a new Release - rather than downloading them entirely again.
Both the initial download (priming) & subsequent updating of your local ISOs are done using rsync, which has the powerful & important ability to download only the changed parts of files, notably the large ISO images, greatly reducing download times. The use of rsync is very exact: it requires great care to make it do just what you want, and the long ISO directory names make difficult parameters. If you get it wrong, you will probably download entire ISOs you do not want. For this reason, there are several tools to make it easy to manage your own ISO set, keep it up-to-date: synchronized with the server. There is a separate Wiki page "https://wiki.mageia.org/en/ISO_testing_rsync_tools" devoted to these easy tools, which also covers hands-on use of naked rsync. Take a look *now*.
New Releases, and the issue of new Rounds of ISOs within the ongoing Release, are announced on the QA mailing list; together with other related information. These announcements are the signal for you to update your local ISOs.
Rsync requires a password, which is given out as needed by private e-mail whenever it changes. This is one item at least that you will have to maintain, whichever ISO synchronization tool you use.
Directory/file name changes at Release changes
Look again at the last three lists above. Because ISO directory names and their subordinate file names incorporate the Release, when a Release changes, all these names change also - on the server. [The download source changes, and its content].
The business of synchronizing your local ISOs with those on the server necessitates that the elements you are synchronizing must be identically named. You must follow server changes.
In all circumstances, all your local ISO subsidiary *filenames* will need updating. The main ISO updating tools work with the same ISO [directory] names as on the server, so using these will necessitate updating your local *ISO directory names* also.
Whether you need to do this by hand depends on the update tool you use: see that Wiki page. Roughly:
- If you rely on mageiasync or onesync, they can do the name-changing for you when you next synchronize ISOs.
- If you use dorsync, or rsync directly, you must change the names yourself.
Don't panic! The exact necessary commands are given on the QA mailing list. Ensuring that you are in your own ISO umbrella directory, it is quickly done in a few seconds by copy/paste into a terminal window.
Checksumming
It is important after downloading/updating an ISO that its ISO image file *.iso is checksummed. All the rsync tools in "ISO_testing_rsync_tools" do this for you. If you want to do it directly, go to the ISO directory, and simply (avoiding long complicated filenames) do:
md5sum -c *.md5 sha1sum -c *.sha1
[it is shaONE, not L].
Any failure is bad news, and necessitates re-synchronizing the ISO before using it. Sometimes this is because the checksum files themselves are incorrect, which will be notified on the MailList. If the download went wrong, you can suspect your *.iso file.
Making the boot media
Virtual machines
VMs offer a real advantage here: you do NOT have to make a boot medium. Hooray! This is because they can install the test system into a VM directly from the ISO image disc *.iso file (which is also faster). This is discussed later.
Burning a CD/DVD
Easiest is to use the normal program of your working system to Burn ISO image: K3B, Brasero, XFBurn.
Creating a bootable ISO USB stick
| Note: On some older systems it is not possible to set a USB key as a boot device. If the BIOS doesn't give this option, you won't be able to do this |
Dorsync
The dorsync tool is downloaded by
$ wget https://dl.dropboxusercontent.com/u/4147101/QA/dorsync
See the "ISO_testing_rsync_tools" Wiki page for a fuller note, and setting it up ("Dorsync->Preparation"). If you only want it as an ISO dumping tool, then just the following item should need defining:
# location is where you stored the ISOs # location=""
It can quickly & easily make bootable ISO USB sticks for you; either after completing ISO synchronizations or when launched directly. After selecting "dump to usb", d|D, it asks which USB device to use [a warning is output if it finds none]:
$ dorsync
Do you want to Rsync (R), skip Rsync and just dump to usb (D) or quit (Q): d
USB drives found:
Device Size When Found Model
1) /dev/sdb 4Gb Dydd Llun 17 mis Tachwedd 2014 18:29:29 CET CBM Flash Disk
Please choose which USB to use or Q to quit and press <enter>: 1
Then it shows a list of ISO images it finds in your ISO directories, for you to chose which one to write out, e.g.
List of ISOs: 1) Mageia-5-beta1-x86_64-DVD.iso 2) Mageia-5-beta1-LiveDVD-GNOME-x86_64-DVD.iso 3) Mageia-5-beta1-LiveDVD-KDE4-x86_64-DVD.iso 4) anyOldISO.iso Please choose which ISO to use or Q to quit and press <enter>: 3
And off it goes:
About to dump /mnt/common/Mageia/KDE64/Mageia-5-beta1-LiveDVD-KDE4-x86_64-DVD.iso onto /dev/sdb (4Gb CBM Flash Disk found at Dydd Llun 17 mis Tachwedd 2014 18:29:29 CET) This will destroy any data already on the USB device. Press Y to confirm or Q to quit: y Please be patient this can take a while This operation requires root privileges Please enter your root password.. Password: ... Completed OK.
IsoDumper
Otherwise the new GUI tool IsoDumper is the easiest way to not only write an ISO boot image to a USB stick, but preserve & restore its previous contents. Being a generic utility, it is fully documented on its own page.
It is available as a normal package isodumper to install as you like. Launched from menu or "isodumper" console command, it can variously do:
- Writing out a selected *.iso image.
- Backup the USB stick to a chosen *.img file, then write out the selected *.iso image.
- Restore the USB stick from its backup *.img file (achieved by selecting this file to write out).
Note: The warning dialogue that "the USB stick contents will be destroyed" is currently displayed even when a backup is requested.
Doing it by hand
If you need/want to do this by hand, here is how. You need to be aware of one fundamental precaution: correctly identify the *device* that the USB stick represents, e.g. sdb. If you get this wrong, you may well overwrite a disc partition. There are several ways of finding out the USB stick device-ID, some of which only work in certain cases. This method should work everywhere:
- Insert the USB stick (which will be entirely overwritten), and in a terminal do:
$ dmesg | tail
which will show something like:
[ 7554.121825] usb 4-1: SerialNumber: AU2C1200B0000063 [ 7554.123971] usb-storage 4-1:1.0: USB Mass Storage device detected [ 7554.124280] scsi7 : usb-storage 4-1:1.0 [ 7555.128059] scsi 7:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 4 [ 7555.136666] sd 7:0:0:0: [sdb] 15536128 512-byte logical blocks: (7.95 GB/7.40 GiB) [ 7555.137795] sd 7:0:0:0: [sdb] Write Protect is off [ 7555.137809] sd 7:0:0:0: [sdb] Mode Sense: 23 00 00 00 [ 7555.138940] sd 7:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 7555.145178] sdb: sdb1 [ 7555.153251] sd 7:0:0:0: [sdb] Attached SCSI removable disk
No doubt: here it is sdb. Disregard references to its partition e.g. sdb1, which serve only to confirm the device-ID.
- The USB stick needs to be unmounted but present, *not* Ejected/SafelyRemoved. Different systems & Desktops react differently when a USB stick is inserted. Some mount it automatically, others do not; some immediately show a file manager window for it; some show a desktop icon for it; some pop up an alert asking what to do. You need to explore by right-clicking its desktop icon, or its icon in the LH panel of a file manager window, its state and available actions; and adjust these so that it remains visible but UNmounted.
- As root, give the following command, replacing "(x)" with the correct letter for your USB key and giving the correct ISO image filename:
# dd if=path/to/ISOfile.iso of=/dev/sd(x) bs=1M
Allow some time after it appears to have finished ensuring that all data has been written. Then use the normal Desktop/file manager right-click menu to Eject/SafelyRemove it.
This page is continued on Pre-release ISO testing: Part 2 which covers booting, running, installing, upgrading, recording results.
