Bug 25063 - Upgrade failure mga6 -> mga7
Summary: Upgrade failure mga6 -> mga7
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard: NEEDINFO
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-06 18:14 CEST by David Rapp
Modified: 2020-08-19 22:40 CEST (History)
7 users (show)

See Also:
Source RPM: iso - installer
CVE:
Status comment:


Attachments

Description David Rapp 2019-07-06 18:14:02 CEST
Description of problem:
I have downloaded the iso for mageia 7 using bittorrent twice and from a direct mirror once. I have burned dvd's on three different machines and to a usb stick twice and have had failed every time.

Version-Release number of selected component (if applicable):
Mageia 7 x86_64 iso

How reproducible:
three different computers using k3b have all failed to yield a single usable disc

Steps to Reproduce:
1.download iso
2.burn to dvd or usb stick using k3b or isodumper
3.attempt to install - hangs on installation.
Comment 1 Lewis Smith 2019-07-06 21:46:23 CEST
This is too basic. A few questions:
1. Did you checksum the downloaded ISOs?
2. In what way is the medium (USB or DVD) unusable?
- Is it not recognised for booting?
- Does it start to boot, and if so, how far does it get?
- How does it fail?

CC: (none) => lewyssmith
Whiteboard: (none) => NEEDINFO

Comment 2 David Rapp 2019-07-07 00:36:27 CEST
Hi Lewis,

1.    Yes the checksums match.

2.    I all cases except 1 (of at least 10) attempts to burn the dvd (3
different computers using k3b) k3b reported "Failed". The one dvd that
had successful burn the attempt to upgrade the existing installed Mageia
6 would reach the point in the install where the installer was
attempting to estimate the time for the upgrade it would hang. The dvd
reader would indicate the disc was being read for several seconds then
go silent for several seconds then repeat the cycle. In one case this
behavior was allowed to continue for over an hour. The upgrade attempt
was repeated on three different machines with identical results. I then
used isodumper to create a bootable usb stick (32GB Sandisk usb stick)
with identical results. Upon reboot Mageia 6 was still in place though
the repository list had been altered to include only the usb stick.

If you have further questions please feel free to contact me.

Cheers,

David Rapp
Comment 3 Morgan Leijström 2019-07-08 11:36:32 CEST
OK so all DVD burns exept one failed.  This really indicate your machine have problems burning them.  Probably an aged or dusty DVD writer.

From that i also think that the one that succeeded burn was of bad quality.

Was the install tried using the same DVD reader?


Please try to burn the DVD using another hardware.  Maybe borrow a machine at a friend or work.  Or try burning it to an USB stick instead.


Please repoen this bug if that fails.

Resolution: (none) => INVALID
CC: (none) => fri
Status: NEW => RESOLVED

Comment 4 Morgan Leijström 2019-07-08 11:38:03 CEST
OOPS sorry i missed the part about you did try USB stick.
(I got interrupted here...)

Resolution: INVALID => (none)
Status: RESOLVED => REOPENED

Comment 5 Morgan Leijström 2019-07-08 11:42:13 CEST
How far did the installer go, what choices did you make?

Summary: unable to burn usable dvd from downloaded iso. => Upgrade failure mga6 -> mga7

Comment 6 Rolf Pedersen 2019-07-08 18:06:20 CEST
FYI, Volker Kuhlmann has written a script, writecd, that can be used to verify both optical and usb media for burned isos.  It's in his scriptutils package: http://volker.top.geek.nz/soft/#shellscripts

I have used dd for usb and wodim for optical media, after verifying the checksum of the downloaded file, then writecd to verify the burn for years.  Then, I can start the installation knowing the media is not a problem.  Example:

$ wodim dev=/dev/sr0 xenialpup-7.5-uefi.iso

$ writecd -cmp /dev/sr0 xenialpup-7.5-uefi.iso
Logging to writecd.cmp.log
Mon 08 Jul 2019 14:37:13 UTC
Mon 08 Jul 2019 07:37:13 PDT
Linux z77x4 4.14.131-desktop-1.mga6 #1 SMP Thu Jun 27 11:19:36 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
 07:37:13 up  2:34,  1 user,  load average: 0.78, 0.51, 0.30
writecd version 4.1.5, 10 Feb 2008
Copyright (C) by Volker Kuhlmann <VolkerKuhlmann@gmx.de>
Comparing CD '/dev/sr0' with isofile 'xenialpup-7.5-uefi.iso'
Size of CD is: 340531200 bytes = 166275 sectors
Using buffer size: 2048 bytes, count = 166275
166275+0 records in
166275+0 records out
340531200 bytes (341 MB, 325 MiB) copied, 81.1492 s, 4.2 MB/s
Mon 08 Jul 2019 14:38:34 UTC
Mon 08 Jul 2019 07:38:34 PDT
Total execution time:  0:01:21
Ring bell: [writecd]
Ring bell: [writecd]
Ring bell: [writecd]
Ring bell: [writecd]

# dd if=Mageia-7-netinstall-nonfree-i586.iso of=/dev/sdi

# writecd -cmp Mageia-7-netinstall-nonfree-i586.iso /dev/sdi

There might be an `EOF -` exit message for writecd or just an output like above.  If no error is reported, the burn is verified against the iso, which has been verified against the checksum.

A lot of support time and effort could have been made unnecessary, over the years I have observed this phenomenon, if such a practice were commonplace or, even, made prerequisite.  IMO.

CC: (none) => rolfpedersen

Comment 7 David Rapp 2019-07-08 19:25:37 CEST
Hi Rolf & Morgan,

Please reread my previous post. I used three different computers, therefore three different dvd burners. I used ktorrent to download the iso twice on two different computers. I downloaded the iso once using a direct download from a mirror. I believe it is safe to say that it is not a "dusty dvd burner". I used blank dvds from two different manufactures from packages of blank dvds that have yielded errorless copies, without any failures perhaps 20 times or more. To me this is undeniable evidence that the problem is neither the computer nor the dvd burner. I did use one of the computers and a blank dvd from the same package to burn a copy of Mageia 6 and there was no problem. I feel confident that the problem is NOT with either the computer used or the dvd burner. I am not new to this process which is why I used blank dvds from different sources and multiple computers. I believe that there is undoubtedly an issue with the iso.

David Rapp
Comment 8 Rolf Pedersen 2019-07-08 20:20:54 CEST
(In reply to David Rapp from comment #7)

> Please reread my previous post.

I've read them all and dozens more from users who insist that (multiple) "burn another copy" is the proper procedure, that it provides irrefutable evidence, after the means to avoid the potential errors coming from a complex gui and to 100% verify a single burn have been provided them, only to be disputed.  Efficiency and certainty don't stand a chance.  Have it your way.

I'm not saying your final assessment is incorrect.  I'm saying there are ways to significantly reduce uncertainty and waste.  Waste of (everybody's) time, waste of material.

P.S.  Eject and reload the media before running writecd on it.
Thanks.
Comment 9 Thomas Backlund 2019-07-08 20:51:31 CEST
When you try to create the usb stick and nothing seems to work, go as "low-level" as you can by using "dd" directly to rule out any application issue meesing with you ...

So open a terminal window and then:

So if your usb stick it at /dev/sdb. do:

dd if=Name_of_iso of=/dev/sdb bs=1M

when that command finshes, you must do:

eject /dev/sdb

that will force the kernel to flush any buffering before unmounting / disconnecting the usb.

Then try to boot from that usb stick.

Of course set the correct "Name_of_iso" and "/dev/sdb" to match your setup

CC: (none) => tmb

Comment 10 David Rapp 2019-07-08 21:08:57 CEST
Hi Rolf,

I understand, even though I have used multiple downloads (and checked the checksums) and multiple machines with multiple dvd burners and blank dvds from multiple sources and a usb stick the problem could be at my end. Though I find this very unlikely. I have downloaded and untarred the Volker shellscripts file. I am not an experienced writer/user of shellscripts so could you walk me through the process of using writecd to verify my iso matches the dvd?

David Rapp
Comment 11 David Rapp 2019-07-08 21:10:41 CEST
Hi Thomas,

I have used the usb stick to attempt the upgrade on all three machines. Identical results on all machines.

David Rapp
Comment 12 Thomas Backlund 2019-07-08 21:29:40 CEST
(In reply to David Rapp from comment #11)
> Hi Thomas,
> 
> I have used the usb stick to attempt the upgrade on all three machines.
> Identical results on all machines.
> 
> David Rapp

did you use dd ?
ded you use "eject..." ?
Comment 13 Rolf Pedersen 2019-07-08 22:11:17 CEST
Inside the unpacked archive, I have:

[rolf@z77x4 scriptutils]$ ls
bin/  sbin/  share/

writecd and ringbell, which it uses, are under bin/.  I copy all of bin/ to /usr so that they are available to call simply, as shown above.  You could just copy those two.  You could give the full path to writecd under your /home but you have to call it from the directory where you have verified the iso and called wodim or dd.  If ringbell is not found, not in your $PATH, I think there is just a harmless error.  What is easy, as root in the scriptutils directory:

[root@z77x4 scriptutils]# cp -r bin /usr

Note where there is / and where not.  Then, use wodim or dd as above, with your file and your device.  Eject, as Thomas says, after dd.  I eject from the applet in the panel, then re-plug the key so it will be detected.  Then, run writecd, as shown, with your file and device.  

After wodim completes (without error), eject/reload the disk or, from cli, using your device:

[rolf@z77x4 xenial]$ eject /dev/sr0

[rolf@z77x4 xenial]$ eject /dev/sr0 -T

Otherwise, writecd complains and doesn't work.  Something about clearing buffers or something idk that Thomas can explain.
Comment 14 Stephen Pettin 2019-07-08 23:53:12 CEST
`After reading this report, I just direct downloaded and burned the Classic Installation ISO (Mageia-7-x86_64.iso)and burned it to a DVD disc with no issues. I verified both checksums and using K3B everything went as planned.

CC: (none) => saptech

Comment 15 Morgan Leijström 2019-07-09 01:04:13 CEST
You say you have identical results on three machines.
What kind of machines?
And all was about upgrading from mga6? Or install fresh?
What choices did you make?
How far did the installer go?
Can you attach /root/drakx/install.log compressed?
( you can compress it using the command xz filename and it will create a new file with added .xz extension, please attach that )
Comment 16 Lewis Smith 2019-07-09 22:47:49 CEST
@David
You have certainly been careful to cross-check things since the start: different machines & media. But something is wrong if k3b was unhappy. I think k3b has an option to verify what it has written. Did you use that?

Have you ever tried (given that you have the free disc partition/space) a minimal *install* rather than the upgrade?

Re the DVD, I would certainly do one of:
- Follow Rolf's comments 6 & 13 to verify the DVD.
- From an ISO testing Wiki:
"Verifying a bootable installation DVD
From your working system, note the file size of the original ISO image.
Divide by 2048 to get the *number of blocks*, say xxxxx.
Then copy the CD/DVD back onto disc (assuming the optical drive is /dev/sr0):-
   dd if=/dev/sr0 of=<destination filename> bs=2048 count=xxxxx
If the command shows a wrong total byte count, the medium *was* faulty; good to know. If the byte count is OK, checksum the [read-back] file
   (e.g. md5sum <path-to-ISO-copy.iso>)
and verify the result against the original ISO's given checksum *.md5".
This verifies the checksum of the ISO *as read back from the DVD*.

Regarding ISOdumper, it does its own verification of what it has written to the USB stick; which you know, of course. And it is cautious about saying when it has finished.

When testing ISOs via USB stick, I use ISOdumper and simply leave the stick inserted until re-booting from it. Same for DVD.
------------------------------------------------
From c2:
> the attempt to upgrade the existing installed Mageia 6 would reach the
> point in the install where the installer was attempting to estimate the
> time for the upgrade it would hang. The dvd reader would indicate the disc
> was being read for several seconds then go silent for several seconds then
> repeat the cycle ...
> In one case this behavior was allowed to continue for over an hour ...
> I then used isodumper to create a bootable usb stick (32GB Sandisk usb
> stick) with identical results. Upon reboot Mageia 6 was still in place
> though the repository list had been altered to include only the usb stick.
I recall from testing a big upgrade that at this point the upgrade *seems* to hang, for ages; I deduced that it had a lot of homework to do, thousands of packages to sort out. But not an hour...
Try a minimal install first, though, if possible
Comment 17 David Rapp 2019-07-10 04:59:19 CEST
Hello all,

I have employed most of the suggested steps. I did allow a couple of attempted upgrades to go to completion - an extremely long time - and ultimately a message was displayed saying "Installation Failed" 43 packages could not be installed and then a list of 20-ish pages of such and such package could not be installed because of missing blah-blah package or such and such package could not be installed because of conflicting blah-blah package. Since the installer offers no method of preserving the report I was unable to save it. Ultimately, I went the install route rather than upgrade even though I would have an hour or so of configuration. Success! No Problem! At that point I had wasted close to three days beating my head against a wall. I do not choose to spend any more time attempting to assist you folks particularly since a fair amount of the suggestions indicated that the person offering the suggestion or asking the question had not read what I had already reported. I wish you luck in figuring this problem out because it is a real problem.

Cheers,
David Rapp
Comment 18 Marja Van Waes 2019-07-12 19:46:38 CEST
(In reply to David Rapp from comment #17)
> Hello all,
> 
> I have employed most of the suggested steps. I did allow a couple of
> attempted upgrades to go to completion - an extremely long time - and
> ultimately a message was displayed saying "Installation Failed" 43 packages
> could not be installed and then a list of 20-ish pages of such and such
> package could not be installed because of missing blah-blah package or such
> and such package could not be installed because of conflicting blah-blah
> package. Since the installer offers no method of preserving the report I was
> unable to save it. 

When using a classical ISO for an upgrade, you can find the matching log files on the chosen root partition that you were installing to, in the directory

   /root/drakx/

If you still have a "failed upgrade" system that you didn't overwrite with a  clean install, then please attach all /root/drakx/ files from the day of your last failed upgrade attempt.

CC: (none) => marja11

Comment 19 David Rapp 2019-07-13 17:48:38 CEST
Hi Marja,

Unfortunately, I had done installs on all three Mageia boxes. I have a separate /home partition on each machine, so everything was still there except for the /etc config files. I wish I had known about /root/drakex. I most certainly would have forwarded it. Perhaps the notification at the top of the report " Installation Failed" could include a note that informs the user where to find a log file. It could be quite valuable.

Cheers,

David Rapp
Comment 20 Morgan Leijström 2019-07-14 04:26:51 CEST
Good idea, David :)
-> Bug 25121 - Improve message "Installation Failed"
Comment 21 Aurelien Oudelet 2020-08-19 22:40:18 CEST
Closing this old bugs, seems there is nothing to do to catch this particular bug.

Status: REOPENED => RESOLVED
Resolution: (none) => INVALID
CC: (none) => ouaurelien


Note You need to log in before you can comment on or make changes to this bug.