| Summary: | remote upgrade 6->7 using ssh and dnf results in an unusable system | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Jeff Robins <jeffrobinsSAE> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | bequimao.de, mageiatools, marja11, ngompa13 |
| Version: | 7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
dnf_issues1.txt
install.log ddebug.log log.txt latest dnf log dnf system upgrade log dnf log that covers the upgrade period |
||
|
Description
Jeff Robins
2019-07-08 02:06:20 CEST
Created attachment 11163 [details]
dnf_issues1.txt
Jeff Robins
2019-07-12 07:14:18 CEST
Version:
6 =>
7 Hi Jeff,
When you wrote:
> I attempted to do a network install, but that failed after a while with a long
> list of dependency issues.
were you then talking about a clean install, or about an upgrade install.
* If the latter, then the logs from the upgrade attempt with DNF and from the reboot after that, should still be available. Please attach log.txt that is the result of running, as root:
journalctl -a --since="YYYY-MM-DD hh:mm" --until="YYYY-MM-DD hh:mm" > log.txt
and adjust the --since time to right before you started to upgrade with DNF and the --until time to when you saw you couldn't reconnect using ssh.
In the case of a network upgrade install, please do also attach
/root/drakx/report.bug
which has the time stamp of the upgrade. You'll probably need to compress it with xz, but will need to do that in a different directory or need to rename the already existing report.bug.xz (which dates from when you first installed Mageia).
* If you did a clean network install, then please just attach
/root/drakx/report.bug.xzKeywords:
(none) =>
NEEDINFO I did an upgrade and when that failed I tried a clean install. I have my personal data on separate partitions, so I wasn't worried about losing the root partition's data. I have a report.bug.xz, but it's from Aug 2013. I do have recent versions of ddebug.log and install.log. I gzipped them and I attached them to the bug report. I also attached the journal output. I wasn't able to zero in the time very well from when I started to when I finished. Apparently my ssh is constantly under attack and that puts a lot of crap in my log and that made it hard to find the important stuff. Created attachment 11181 [details]
install.log
Created attachment 11182 [details]
ddebug.log
Created attachment 11183 [details]
log.txt
If dnf is working enough for the CLI to run, could you try capturing the output of the system upgrade transaction? # dnf system-upgrade log --number=-1 > dnf-system-upgrade.log Also, a copy of /var/log/dnf.log would be helpful, too. Created attachment 11189 [details]
latest dnf log
Created attachment 11190 [details]
dnf system upgrade log
This is probably from the last time I tried to use the system upgrade option to see if it would fix the issues
Created attachment 11191 [details]
dnf log that covers the upgrade period
Ulrich Beckmann
2019-07-17 15:21:16 CEST
CC:
(none) =>
bequimao.de
Marja Van Waes
2019-10-20 20:35:00 CEST
Keywords:
NEEDINFO =>
(none) So I renamed my /var/lib/dnf directory to /var/lib/dnf.old and now I can run "dnf upgrade" without a problem. I'll close this as resolved once I actually see it update a package (no updates were needed right now). I was able to upgrade a bunch of packages, so I'm closing this as Resolved. The solution was to move the "/var/lib/dnf" directory so a new one was created. Resolution:
(none) =>
FIXED |