After hearing of mostly positive experiences with fedup I decided to give it a try again after my two horrible experiences myself from 17->18 which required installation from scratch.
So far I'm not warm and fuzzy. I'm upgrading a pretty much stock laptop with one hard drive and default partitioning from anaconda and once again I'm getting the REALLY long list of packages it can't find, but then tries the upgrade anyway...
We'll see.
Richard
So much for this upgrade...
Perhaps if fedup can't find HUNDREDS of packages, it SHOULD'T GO THROUGH WITH THE UPGRADE...
Reboot:
systemd[1]: Failed to load SELinux policy. Freezing.
Richard
Anyone selling "I survived fedup" t-shirts?
Anyway, the saga is over... Had to boot to a F19 install dvd in rescue mode, chrooted into my system, yum didn't work (no libffi.so.6, I assume I had .5).
Tried using yum from the DVD w/ --installroot to /mnt/sysimage...
yum was there but couldn't import the python module yummain (or whatever it's called) which brings up the point. Isn't a functional yum kinda important as a tool to rescue your system?
got libffi installed with rpm -r /mnt/sysimage and a few other things to get a mostly working yum in the chroot...
yum update / distro-sync
package-cleanup --problems showed a bunch of unsatisfied dependencies but I couldn't find a way to get package-cleanup or yum to handles these automatically (that would be nice)
manually installed dependencies or just yum reinstalled the parent app... Problems gone! (mostly)
F18 kernel was newer than F19 and caused my system to continuously reboot after partially loading
yum erase F18 kernel, yum install F19 kernel
Now it works! Whew, I'm glad that's over
Richard
On 7/21/2013 8:51 PM, Richard Shaw wrote:
Anyone selling "I survived fedup" t-shirts?
Anyway, the saga is over... Had to boot to a F19 install dvd in rescue mode, chrooted into my system, yum didn't work (no libffi.so.6, I assume I had .5).
Tried using yum from the DVD w/ --installroot to /mnt/sysimage...
yum was there but couldn't import the python module yummain (or whatever it's called) which brings up the point. Isn't a functional yum kinda important as a tool to rescue your system?
got libffi installed with rpm -r /mnt/sysimage and a few other things to get a mostly working yum in the chroot...
yum update / distro-sync
package-cleanup --problems showed a bunch of unsatisfied dependencies but I couldn't find a way to get package-cleanup or yum to handles these automatically (that would be nice)
manually installed dependencies or just yum reinstalled the parent app... Problems gone! (mostly)
F18 kernel was newer than F19 and caused my system to continuously reboot after partially loading
yum erase F18 kernel, yum install F19 kernel
Now it works! Whew, I'm glad that's over
Richard
I am happy for you. I have no idea just why you had these troubles. I did three updates, one desktop machine and two very different laptops, and I had absolute;y no problems.
On 07/21/2013 09:03 PM, David wrote:
On 7/21/2013 8:51 PM, Richard Shaw wrote:
Anyone selling "I survived fedup" t-shirts?
Anyway, the saga is over... Had to boot to a F19 install dvd in rescue mode, chrooted into my system, yum didn't work (no libffi.so.6, I assume I had .5).
Tried using yum from the DVD w/ --installroot to /mnt/sysimage...
yum was there but couldn't import the python module yummain (or whatever it's called) which brings up the point. Isn't a functional yum kinda important as a tool to rescue your system?
got libffi installed with rpm -r /mnt/sysimage and a few other things to get a mostly working yum in the chroot...
yum update / distro-sync
package-cleanup --problems showed a bunch of unsatisfied dependencies but I couldn't find a way to get package-cleanup or yum to handles these automatically (that would be nice)
manually installed dependencies or just yum reinstalled the parent app... Problems gone! (mostly)
F18 kernel was newer than F19 and caused my system to continuously reboot after partially loading
yum erase F18 kernel, yum install F19 kernel
Now it works! Whew, I'm glad that's over
Richard
I am happy for you. I have no idea just why you had these troubles. I did three updates, one desktop machine and two very different laptops, and I had absolute;y no problems.
It may be an artifact of people who have trouble being more likely to write to the list, but it seems that people who have Fedup problems seem to outnumber those who have success outright with no problems first try. That's probably not the case though.
The issues are probably caused by people who add stuff from foreign repos. How else would you end up with an F18 kernel that was newer than the F19 kernel that you were trying to replace it with? That doesn't happen to all F18 users does it? My money is on NO.
On Sun, Jul 21, 2013 at 8:26 PM, Mark LaPierre marklapier@aol.com wrote:
It may be an artifact of people who have trouble being more likely to write to the list, but it seems that people who have Fedup problems seem to outnumber those who have success outright with no problems first try. That's probably not the case though.
The issues are probably caused by people who add stuff from foreign repos. How else would you end up with an F18 kernel that was newer than the F19 kernel that you were trying to replace it with? That doesn't happen to all F18 users does it? My money is on NO.
No custom kernels... for some reason F18 ended up with 3.9.10 and F19 is still on 3.9.9 (or something like that).
I do have some custom packages, but nothing that would prevent basic functionality, mostly end user apps, and they're all in a local repository which I rebuild F19 packages in most cases.
fedup only updated about 500 packages. When I got my system fixed enough to run yum update, it still needed about 1100.
My guess at this point is that fedup assumed that because my local repository was "local" (over nfs) that it didn't need to add these packages to /var/lib/fedora-upgrade. If this is indeed the case that is a VERY bad assumption. It's nuts to not include ALL the packages needed for the upgrade transaction. And even if there's a good reason not to (I can't think of one) then if you're missing 1100 packages, it should refuse to do the upgrade.
Richard
On 07/21/2013 10:41 PM, Richard Shaw wrote:
On Sun, Jul 21, 2013 at 8:26 PM, Mark LaPierre <marklapier@aol.com mailto:marklapier@aol.com> wrote:
It may be an artifact of people who have trouble being more likely to write to the list, but it seems that people who have Fedup problems seem to outnumber those who have success outright with no problems first try. That's probably not the case though. The issues are probably caused by people who add stuff from foreign repos. How else would you end up with an F18 kernel that was newer than the F19 kernel that you were trying to replace it with? That doesn't happen to all F18 users does it? My money is on NO.
No custom kernels... for some reason F18 ended up with 3.9.10 and F19 is still on 3.9.9 (or something like that).
I do have some custom packages, but nothing that would prevent basic functionality, mostly end user apps, and they're all in a local repository which I rebuild F19 packages in most cases.
fedup only updated about 500 packages. When I got my system fixed enough to run yum update, it still needed about 1100.
My guess at this point is that fedup assumed that because my local repository was "local" (over nfs) that it didn't need to add these packages to /var/lib/fedora-upgrade. If this is indeed the case that is a VERY bad assumption. It's nuts to not include ALL the packages needed for the upgrade transaction. And even if there's a good reason not to (I can't think of one) then if you're missing 1100 packages, it should refuse to do the upgrade.
Richard
FWIW, I used a straight network upgrade. It upgraded more than 3000 packages and took two and one-half hours to do it after I booted into System Upgrade.
I have no problems. The only strange thing was that libdvdcss2 is still an F18 version--but when I ran rpmsearch that happens to be the latest version it returned.
Also FWIW, I upgraded within two days of the announcement. Since then I've taken two kernel updates, so now I have three F19 kernel versions, plus the rescue option that I understand is the preferred method when adding new hardware.
Temlakos
Hi
My guess at this point is that fedup assumed that because my local
repository was "local" (over nfs) that it didn't need to add these packages to /var/lib/fedora-upgrade. If this is indeed the case that is a VERY bad assumption. It's nuts to not include ALL the packages needed for the upgrade transaction. And even if there's a good reason not to (I can't think of one) then if you're missing 1100 packages, it should refuse to do the upgrade.
Richard
Have you filed a bug report?
Rahul
On 07/22/2013 04:41 AM, Richard Shaw wrote:
On Sun, Jul 21, 2013 at 8:26 PM, Mark LaPierre <marklapier@aol.com mailto:marklapier@aol.com> wrote:
It may be an artifact of people who have trouble being more likely to write to the list, but it seems that people who have Fedup problems seem to outnumber those who have success outright with no problems first try. That's probably not the case though. The issues are probably caused by people who add stuff from foreign repos. How else would you end up with an F18 kernel that was newer than the F19 kernel that you were trying to replace it with? That doesn't happen to all F18 users does it? My money is on NO.
No custom kernels... for some reason F18 ended up with 3.9.10 and F19 is still on 3.9.9 (or something like that).
No surprize. The current f18 kernel rpm-version-wise is greater than the current f19 kernel:
http://dl.fedoraproject.org/pub/fedora/linux/updates/18/x86_64/kernel-3.9.10...
http://dl.fedoraproject.org/pub/fedora/linux/updates/19/x86_64/kernel-3.9.9-...
This is one of the situations, which never ever should happen in Fedora. Apparently several people haven't done their homework :(
Ralf
Rahul Sundaram metherid@gmail.com writes:
Hi
My guess at this point is that fedup assumed that because my local
repository was "local" (over nfs) that it didn't need to add these packages to /var/lib/fedora-upgrade. If this is indeed the case that is a VERY bad assumption. It's nuts to not include ALL the packages needed for the upgrade transaction. And even if there's a good reason not to (I can't think of one) then if you're missing 1100 packages, it should refuse to do the upgrade.
Richard
Have you filed a bug report?
Making a bug report would be a good idea, with /var/log/fedup.log attached.
On Sun, Jul 21, 2013 at 10:31 PM, Rahul Sundaram metherid@gmail.com wrote:
Have you filed a bug report?
Not yet, but I will after things are discussed here... I was hoping someone who knows about fedup would chime in. Am I right in assuming that repository packages that are considered "local" are not copied into /var/lib/fedora-upgrade?
Richard
On 22/07/13 13:44, Richard Shaw wrote:
On Sun, Jul 21, 2013 at 10:31 PM, Rahul Sundaram <metherid@gmail.com mailto:metherid@gmail.com> wrote:
Have you filed a bug report?
Not yet, but I will after things are discussed here... I was hoping someone who knows about fedup would chime in. Am I right in assuming that repository packages that are considered "local" are not copied into /var/lib/fedora-upgrade?
Richard
Richard: I don't fit into your hoped-for category of knowledgeable responders, but I'm not clear what is happening.
Do the packages in your local f18 repo also exist in external f18 repos that you also have enabled? If not, are you requiring fedup to identify the corresponding f19 packages without further help?
That seems more complex than just switching external repos from f18 to f19, which is, I imagine, what it would usually do.
Cheers,
John P
On Mon, Jul 22, 2013 at 10:04 AM, John Pilkington J.Pilk@tesco.net wrote:
On 22/07/13 13:44, Richard Shaw wrote:
On Sun, Jul 21, 2013 at 10:31 PM, Rahul Sundaram <metherid@gmail.com mailto:metherid@gmail.com> wrote:
Have you filed a bug report?
Not yet, but I will after things are discussed here... I was hoping someone who knows about fedup would chime in. Am I right in assuming that repository packages that are considered "local" are not copied into /var/lib/fedora-upgrade?
Richard
Richard: I don't fit into your hoped-for category of knowledgeable responders, but I'm not clear what is happening.
Do the packages in your local f18 repo also exist in external f18 repos that you also have enabled? If not, are you requiring fedup to identify the corresponding f19 packages without further help?
I keep two local (via nfs) repositories. One is just all the packages from the install dvd to save bandwidth (called local-install, which I have setup for F17, 18, and 19), the other repo is for more experimental packages or updates (called local) I want to test before building them for Fedora (I'm a Fedora and RPM Fusion packager). In the latter repo there is a few libraries but mostly end user applications and none of them are critical to basic functionality, so the packages in my local repo were not updated, it shouldn't cause too much of a problem.
I pretty much had the same experience with two computers trying fedup from 17 to 18 (basically, it couldn't find all the upgrade packages, but tried to upgrade anyway) which is why I'm wondering if it doesn't copy in packages that it thinks are local.
I just tried running fedup on my desktop (not the actual reboot/upgrade part, just the first part) to test this hypothesis and counted the packages:
$ ls /var/lib/fedora-upgrade/ | wc -l 1023
None of which are symbolic links. Now I assume that many packages my not need to be upgraded but this seems strange:
$ rpm -qa | wc -l 2362
So less than half of the packages will be updated... Something just seems wrong about that.
This time I tried running "fedup --network 19 -v --disablerepo local*"
and it's downloading an additional 1350 packages, so it appears my hypothesis has some merit.
Richard
Hi
On Mon, Jul 22, 2013 at 8:44 AM, Richard Shaw wrote:
On Sun, Jul 21, 2013 at 10:31 PM, Rahul Sundaram wrote:
Have you filed a bug report?
Not yet, but I will after things are discussed here... I was hoping someone who knows about fedup would chime in. Am I right in assuming that repository packages that are considered "local" are not copied into /var/lib/fedora-upgrade?
Probably. I dont think your setup is that common. You can file it with the logs and let the fedup developer handle that. Dont think anyone here knows fedup more for this discussion to add more info.
Rahul
lee wrote:
Rahul Sundaram metherid@gmail.com writes:
Hi
My guess at this point is that fedup assumed that because my local
repository was "local" (over nfs) that it didn't need to add these packages to /var/lib/fedora-upgrade. If this is indeed the case that is a VERY bad assumption. It's nuts to not include ALL the packages needed for the upgrade transaction. And even if there's a good reason not to (I can't think of one) then if you're missing 1100 packages, it should refuse to do the upgrade.
Richard
Have you filed a bug report?
Making a bug report would be a good idea, with /var/log/fedup.log attached.
If any of my filesystems were left functional I would have, but that seems not to be the case.
Am 22.07.2013 04:41, schrieb Richard Shaw:
On Sun, Jul 21, 2013 at 8:26 PM, Mark LaPierre <marklapier@aol.com mailto:marklapier@aol.com> wrote:
It may be an artifact of people who have trouble being more likely to write to the list, but it seems that people who have Fedup problems seem to outnumber those who have success outright with no problems first try. That's probably not the case though. The issues are probably caused by people who add stuff from foreign repos. How else would you end up with an F18 kernel that was newer than the F19 kernel that you were trying to replace it with? That doesn't happen to all F18 users does it? My money is on NO.
No custom kernels... for some reason F18 ended up with 3.9.10 and F19 is still on 3.9.9 (or something like that).
and that is why i use yum "distro-sync" is what it says and does even downgrades
On Sun, Jul 21, 2013 at 7:41 PM, Richard Shaw hobbes1069@gmail.com wrote:
On Sun, Jul 21, 2013 at 8:26 PM, Mark LaPierre marklapier@aol.com wrote:
It may be an artifact of people who have trouble being more likely to write to the list, but it seems that people who have Fedup problems seem to outnumber those who have success outright with no problems first try. That's probably not the case though.
The issues are probably caused by people who add stuff from foreign repos. How else would you end up with an F18 kernel that was newer than the F19 kernel that you were trying to replace it with? That doesn't happen to all F18 users does it? My money is on NO.
No custom kernels... for some reason F18 ended up with 3.9.10 and F19 is still on 3.9.9 (or something like that).
I do have some custom packages, but nothing that would prevent basic functionality, mostly end user apps, and they're all in a local repository which I rebuild F19 packages in most cases.
fedup only updated about 500 packages. When I got my system fixed enough to run yum update, it still needed about 1100.
My guess at this point is that fedup assumed that because my local repository was "local" (over nfs) that it didn't need to add these packages to /var/lib/fedora-upgrade. If this is indeed the case that is a VERY bad assumption. It's nuts to not include ALL the packages needed for the upgrade transaction. And even if there's a good reason not to (I can't think of one) then if you're missing 1100 packages, it should refuse to do the upgrade.
Richard
--
In reading this my hopefully helpful hint / question would be: did you enter the fedup command correctly?
Richard