| Summary: | 6RC classic iso upgrade from mga5 stalls on package installation after some 300 packages | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Len Lawrence <tarazed25> |
| Component: | Release (media or process) | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | cae, marja11, sysadmin-bugs, thierry.vignaud |
| Version: | Cauldron | Keywords: | 6sta1.5 |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | Not sure; could be dracut or drakx11 installer | CVE: | |
| Status comment: | |||
| Attachments: |
report.bug for mga5 to 6RC round 3 upgrade
report.bug for mga5 to 6RC round 3 upgrade Latest 6RC report.bug, part 1 Second part of report.bug for mga5 -> 6RC upgrade Install log for mga5 upgrade -> 6RC |
||
|
Description
Len Lawrence
2016-07-23 19:25:50 CEST
Should have said that the system started as a mixed desktop system, probably up-to-date.
Len Lawrence
2016-07-23 19:32:58 CEST
Keywords:
(none) =>
6RC Mixed system or not this is an issue that any user doing a 5 to 6 upgrade using either of the dvd iso may face. The dvd's contain only a "fixed" selection of rpms whereas the system being upgrade could contain numerous other pkgs which also need to be upgraded to prevent failed dependency errors. Possible solutions: Re-add the ability to add online media at the beginning of the install. Except for a selected number of core pkgs disregard "failed install" errors and allow the installation to complete. Work arounds: When the upgrade fails reboot the system with the Mga5 kernel, add Mga6 sources, and complete the upgrade using urpmi. Strongly recommend that the dvd.iso be used Only for installs Not for upgrades. CC:
(none) =>
cae Could you provide the file /root/drakx/report.bug.xz if you have it as an attachment ? Keywords:
(none) =>
NEEDINFO Sorry Manuel. I was looking elsewhere for logs. Installed Plasma right after that. I could roll back I guess and dump the report if you really need it. Problem is lack of time just now, seriously. @Manuel Started again but see no /root/drakx. While the upgrading is going on all /root contains is non-chrooted-marker.DrakX. There is a /mnt/root/drakx which does contain the report.debug.xz and report.debug which has a later timestamp. I am guessing that report.debug is compressed at intervals. report.debug contains all the hardware checks and a list of unknown packages. Been watching this for two hours now and it has installed only 250 of 1175 packages. I am going to have to dump the file and shut down. Created attachment 8244 [details]
report.bug for mga5 to 6RC round 3 upgrade
This was obtained from /mnt/run/drakx about two hours into the upgrade. The timestamp indicated that it was generated right at the beginning of the process.
Upgrade abandoned.
Charles suggestion about ignoring the failed components seems like a good idea providing the system is not compromised by doing that, as he points out. g/debug/bug/ It is the middle of the night! (In reply to Len Lawrence from comment #7) > Created attachment 8244 [details] > report.bug for mga5 to 6RC round 3 upgrade > > This was obtained from /mnt/run/drakx about two hours into the upgrade. The > timestamp indicated that it was generated right at the beginning of the > process. > Upgrade abandoned. I think you attached a different one, this one contains * second stage install running (DrakX v16.105) That should be DrakX v17.52 now. Besides, instead of abandoning, you completely finished it: * starting step `exitInstall' It was a report.bug.xz that you attached, report.bug.xz is neither deleted nor overwritten when upgrading. The file you need is report.bug (and, yes, it is likely that you need to compress it, so you might want to rename report.bug.xz to report.bug.xzOLD or so, first) CC:
(none) =>
marja11, thierry.vignaud @marja Luckily I did dump report.bug as well before shutting down having noted the difference in timestamps. It is not much bigger than the compressed file. Created attachment 8246 [details]
report.bug for mga5 to 6RC round 3 upgrade
Attachment 8244 is obsolete:
0 =>
1 That's very weird, that also has * second stage install running (DrakX v16.105) :-( Are you sure you were using an 6RC iso? What is the time stamp of the iso, and were the checksums ok? Ah, no, you reached the exitInstall step, so this is just old again, sorry :-( [lcl@belexeuli Mageia-6-RC-x86_64-DVD]$ checksums Current directory is /data/isos/mageia6-RC/Mageia-6-RC-x86_64-DVD Fri Jul 22 23:00:00 CEST 2016 md5 sumcheck ba559aeb2402969de56badcfaeaaf81d Mageia-6-RC-x86_64-DVD.iso ba559aeb2402969de56badcfaeaaf81d Mageia-6-RC-x86_64-DVD.iso sha1 sumcheck c2adc675072d4527b208301e7d0eb062afd458ae Mageia-6-RC-x86_64-DVD.iso c2adc675072d4527b208301e7d0eb062afd458ae Mageia-6-RC-x86_64-DVD.iso sha512 sumcheck cce5def2ba186b93eafed465d30a565451f95054765574c53747ee5fc60fe2227f6fdbb25237239311c026479b4225ae5559688141eca679ecd688ac819fc00d Mageia-6-RC-x86_64-DVD.iso cce5def2ba186b93eafed465d30a565451f95054765574c53747ee5fc60fe2227f6fdbb25237239311c026479b4225ae5559688141eca679ecd688ac819fc00d Mageia-6-RC-x86_64-DVD.iso And this is what the USB drive holds: [lcl@belexeuli Mageia-6-RC-x86_64]$ ls -l total 19 -r--r--r-- 1 lcl lcl 80 May 27 2011 autorun.inf -r--r--r-- 1 lcl lcl 2048 Jul 22 21:21 boot.catalog dr-xr-xr-x 1 lcl lcl 2048 May 27 2011 dosutils dr-xr-xr-x 1 lcl lcl 2048 Jan 29 2015 EFI dr-xr-xr-x 1 lcl lcl 10240 Jul 9 00:00 isolinux dr-xr-xr-x 1 lcl lcl 2048 Jul 22 21:21 x86_64 The preceding Plasma install would have wiped the root partition and left a report.bug.xz, the one with the earlier timestamp, dated yesterday evening. The uncompressed report file was dated just before midnight, the time when the second attempt at upgrading started. So I have no idea what is going on here. This is isolinux/x86_64 $ ls -l total 79925 -r--r--r-- 1 lcl lcl 48932376 Jul 22 21:11 all-nonfree.rdz -r--r--r-- 1 lcl lcl 28268288 Jul 22 21:11 all.rdz -r--r--r-- 1 lcl lcl 4641232 Jul 22 21:11 vmlinuz $ cat x86_64/VERSION Mageia Mageia vanda 20160722 20:21 As I said earlier, I am out of time now. Probably off the grid for weeks but shall probe a bit more when I can. Real life cannot be avoided. Sorry the report did not help. no problem, thanks for the great job you're doing here :) i'll set this report to unconfirmed for now. if you're away for holidays, then: enjoy them! if not: good luck with whatever takes your time. Status:
NEW =>
UNCONFIRMED Thanks Marja. Not holidays - I wish. Entertaining kid sister (70) from New Zealand and things like that. Resumed the upgrade. Looked at mnt/root/drakx/ddebug.log: install stage2 running DrakX v17.52 That confirms that the report.bug files are stale. No later reports available. When is report.bug supposed to be started or is it created at the the finish? Any other logs useful? The hardware side will probably not change much from one report to another. install.log and ddebug.log are the only files concurrent with this latest run. (In reply to Len Lawrence from comment #17) > Thanks Marja. Not holidays - I wish. Entertaining kid sister (70) from New > Zealand and things like that. Nice :-) > > Resumed the upgrade. Looked at mnt/root/drakx/ddebug.log: > > install stage2 running DrakX v17.52 That's good.... please attach that file, then > > That confirms that the report.bug files are stale. > No later reports available. When is report.bug supposed to be started or is > it created at the the finish? Come to think of it, it is probably created when issuing the "bug" command in tty2 during installation, and else at the end of install. > Any other logs useful? The hardware side > will probably not change much from one report to another. install.log and > ddebug.log are the only files concurrent with this latest run. ddebug.log with DrakX v17.52 is fine, thanks for having checked! OK, this is my final tilt at this particular windmill. The upgrade eventually ran into the open file limit. Each failure entails user input and the time between entering the install stage and the next failure, which may be one or two packages later, is several minutes long. So what is going on in that period? No timeout needs to be that long. The only log files available are ddebug.log and install.log so please find these attached. And thanks Marja for your constant presence. (In reply to Len Lawrence from comment #19) > > The only log files available are ddebug.log and install.log so please find > these attached. Maybe bugzilla played a trick on you? I don't see a new attachment. Created attachment 8249 [details]
Latest 6RC report.bug, part 1
Thanks marja for the gentle reminder. Ran bug /dev/sde1, so this time it should be current. Had to split the file in two (169291 lines).
Created attachment 8250 [details]
Second part of report.bug for mga5 -> 6RC upgrade
Attachment 8246 is obsolete:
0 =>
1 Created attachment 8251 [details]
Install log for mga5 upgrade -> 6RC
The install log may be redundant now. Holding ddebug.log for now because it too needs to be split and may also be redundant. Near the end of attachment 8250 [details], there are many lines about:
cannot open [Obsolete|Conflict|Provide|Requiere]name index using db5 - Too many open files (24)
@ tv
That means nothing to me, guessing it's for youKeywords:
NEEDINFO =>
(none) (In reply to Len Lawrence from comment #21) > Had to split the file in two (169291 lines). It's better to just compress it next time... (In reply to Marja van Waes from comment #25) It means rpm is failing to open its rpmdb in /var/lib/rpm... (really /mnt/var/lib/rpm when chrooted in the installer) @marja re comment 20. No trick, just me being slow aka interrupted. In reply to Thierry Vignaud in comment 26 The compressed file exceeded the 1 MB limit so I had to split it and compress the two halves. (In reply to Len Lawrence from comment #29) > In reply to Thierry Vignaud in comment 26 > > The compressed file exceeded the 1 MB limit so I had to split it and > compress the two halves. I considered telling you about compressing with xz, bug wasn't sure how much better it compresses. Now I know, I copied an old report.bug to report.bug2 and report.bug3, and then I ran "gzip report.bug3" and "xz report.bug2", here are my results: -rw-r--r-- 1 marja marja 2354075 apr 27 13:17 report.bug -rw-r--r-- 1 marja marja 179920 jul 24 17:43 report.bug2.xz -rw-r--r-- 1 marja marja 347409 jul 24 17:45 report.bug3.gz so xz compresses almost twice as much as gzip lol, I should have renamed tham to report2.bug and report3.bug ;-) Good to know. xz from now on. This applied to an old release and is certainly not relevant anymore. Resolution:
(none) =>
OLD |