Bug 1044128
Summary: | using option --iso failes to mount on reboot | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | L.L.Robinson <junk> | ||||||
Component: | fedup | Assignee: | Will Woods <wwoods> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 20 | CC: | junk, subscribed-lists, tflink, wwoods | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2014-01-23 20:01:00 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
L.L.Robinson
2013-12-17 20:55:09 UTC
mount[697]: mount: /var/isos/Fedora-20-x86_64-DVD.iso: failed to setup loop device: No such file or directory This is the same as bug 1024223, which is fixed. Are you sure you're using *final* F20 media? You might want to check that. The sha256sums are here: https://fedoraproject.org/en/static/checksums/Fedora-20-x86_64-CHECKSUM The sha256 for my iso has checked ok against the one you posted. Strange. Try installing fedup-0.8.0 from updates-testing - does using that change anything? A "me, too" situation. I made a DVD and ran fedup --device --network 20 Everything went OK until I rebooted and selected the fedup upgrade. After thrashing around for a while, the system went into emergency mode, unable to find a file system. Rebooted and tried again with the same result. The SHA256sum for the .iso file matched the value on the verify page. ]$ rpm -qa |grep fedup fedup-0.7.3-4.fc19.noarch Created attachment 837997 [details]
journalctl -xb from failed boot (subscribed-lists)
it has fixed the issue. the machine is now updating. By the way, this is what was in grub.conf: title System Upgrade (fedup) root (hd0,1) kernel /vmlinuz-fedup root=UUID=cb50f2fc-5f16-4a1c-8dc5-2bcc76ab5e80 rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 ro SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 quiet upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0 initrd /initramfs-fedup.img clearing needinfo I wiped out the failed fedup (deleted stuff from grub.con and /var/tmp/) and tried again with fedup from updates-testing. This time, I got errors after fedup ran: WARNING: problems were encountered during transaction test: broken dependencies libreoffice-pdfimport-1:4.1.3.2-12.fc19.x86_64 requires poppler-0.22.1-5.fc19.x86_64 libreoffice-core-1:4.1.3.2-12.fc19.x86_64 requires boost-date-time-1.53.0-14.fc19.x86_64 ufraw-gimp-0.19.2-10.fc19.x86_64 requires cfitsio-3.340-1.fc19.x86_64 gnome-shell-extension-xrandr-indicator-3.8.4-1.fc19.noarch requires gnome-shell-extension-common-3.8.4-1.fc19.noarch Continue with the upgrade at your own risk. I think I'm going to put off a fedup to f20 for a while. FYI: "fedup --resetbootloader" will remove the grub.conf entry without deleting everything you've downloaded. As for the transaction warning - you can still run the upgrade, and everything will very likely be Just Fine, but if you care about being 100% sure that those packages work as expected you might want to wait for the package maintainers to fix the dependency problems. You could also report those things as bugs against the named packages, if you wanted to hurry things along. So I guess nobody's seeing this problem anymore? In that case... *** This bug has been marked as a duplicate of bug 1024223 *** |