 |
Other languages English ; Français ; |
| 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. From Mageia 10 onwards Council decided we allow greater than the previous DVD limit of 4.7GB, will try hard to fit any in "8 GB" USB drive but absolutely within DVD-R_DL size, 8.5GB. The ISOs are: (sizes of Mageia 10 alpha1)
- Classical Installation Flavours which can be used to upgrade from the previous Mageia release:
- DVD 32bit i686 4.3 GB
- DVD 64bit 5.0 GB
- LiveDVDs which can not be used to upgrade a system:
- LiveDVD Plasma-x86_64 4.5 GB
- LiveDVD GNOME-x86_64 4.2 GB
- LiveDVD Xfce-i686 3.5 GB
- LiveDVD Xfce-x86_64 4,0 GB
- Network-based Installation ISOs:
Note that they are generated independently from the big install images, so often not refreshed at the same date.
Find them at https://www.mageia.org/en/downloads/alternative/#Cauldron
And also with your favourite mirror at
- 32 bit: /mirror/mageia/distrib/10/i686/install/images/
- 64 bit: /mageia/distrib/10/x86_64/install/images/
At the latter places you also find some *img installer images.
Terminology
Conventionally the word 'release' applies to the major release of a distribution, say Mageia 8 or Mageia 9. 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 10 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-10-alpha1-i686 Mageia-10-alpha1-x86_64/ Mageia-10-alpha1-Live-GNOME-x86_64 Mageia-10-alpha1-Live-Plasma-x86_64 Mageia-10-alpha1-Live-Xfce-i686 Mageia-10-alpha1-Live-Xfce-x86_64
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-10-alpha1-x86_64.idx Mageia-10-alpha1-x86_64.iso Mageia-10-alpha1-x86_64.iso.md5 Mageia-10-alpha1-x86_64.iso.sha3 Mageia-10-alpha1-x86_64.iso.sha512
or for a Live ISO:
DATE.txt Mageia-10-alpha1-Live-Xfce-x86_64.iso.sha3 Mageia-10-alpha1-Live-Xfce-x86_64.lst Mageia-10-alpha1-Live-Xfce-x86_64.lst.names Mageia-10-alpha1-Live-Xfce-x86_64.iso Mageia-10-alpha1-Live-Xfce-x86_64.iso.sha512 Mageia-10-alpha1-Live-Xfce-x86_64.lst.full Mageia-10-alpha1-Live-Xfce-x86_64.iso.md5 Mageia-10-alpha1-Live-Xfce-x86_64.langs Mageia-10-alpha1-Live-Xfce-x86_64.lst.leaves
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 other files than the large .iso 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.
Use our tools !
For reason above, we have several tools to make it easy to manage your own ISO set, keep it up-to-date: synchronized with the server. Our Wiki page ISO testing rsync tools is devoted to these easy tools, which also covers hands-on use of naked rsync. Take a look *now*.
Directory/file name changes at Release changes
New Releases, and the issuing 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.
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 boot from USB. the setting may be a bit convoluted on modern BIOSes, amongst security settings. |
IsoDumper
We recommend our GUI tool IsoDumper. It can not only write an ISO boot image to a USB stick, but preserve & later restore its contents, and also simply format the stick for another use. Being a generic utility, it is fully documented on its own page. A speciality is that you can by a checkmark tell it to create a partition for persistence on Live ISOs, and optionally make it encrypted.
It is available as a normal package isodumper to install as you like. Launched from menu or "isodumper" console command.
Dorsync
Our command line tool dorsync can both fetch and update the ISOs, and also create bootable USB from downloaded file. In contrast to IsoDomper, it can not make persistence for Live ISOs.
See the "ISO_testing_rsync_tools" here for further instructions.
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.
