Hi,
Hoping I am posting in the right forum.
I tried all means and ways to stay on F14 as long as practically possible as it suited me and my users but we can no longer hold onto it and tried to upgrade.
We followed preupgrade method described on the project's web and chose to upgrade to F17 as it was on the menu of choices.
After wasting hours downloading thru the preupgrade GUI we rebooted and only were presented with an error message stating that we could not upgrade to F17 and had to upgrade to the previous version. That must be some sophisticated bait-and-switch bullying preupgrade devs engaged into.
Do we have to perform some kind of cleanup of all the [beep] that preupgrade downloaded in order to run preupgrade again?
Should we do F14 - F15 - F16 - F17 or is there a possibility to skip versions? Is that documented anywhere? The only reference to a target version I found was:
EDIT: It looks like target version is not necessarily the cause of grief.
Re-running preupgrade and choosing F15 still brings up the same error message after reboot telling us version mismatch on sda2 and instructing us to upgrade to an intermediate version. Guess there was something in between F14 and F15 in their opinion. Not that I could find it.
That reinforces the earlier question: do I have to perform some kind of cleanup after unsuccessful upgrade attempt? I noticed that downloading for target F15 took a lot less time than initial download for target F17.
After attempting to press Continue on the error message we were given another one, telling us that root was not found. We are not running any kind of volume manager, RAID or any other weirdness.
Is there anything wrong with the disk partitioning?
The only crazy idea that comes to mind after seeing it could not find root was that my Gigabyte GA-890XA-UD3 mobo's SATA was somehow not supported by the next kernel, but again - it's just a crazy idea. I am at a loss to understand what is wrong. The only option I want to avoid like a plague is to d/l entire DVD burn it and upgrade, hoping it will not wipe out entire system clean (it happened to me in the past).
Hoping I am posting in the right forum.
I tried all means and ways to stay on F14 as long as practically possible as it suited me and my users but we can no longer hold onto it and tried to upgrade.
We followed preupgrade method described on the project's web and chose to upgrade to F17 as it was on the menu of choices.
After wasting hours downloading thru the preupgrade GUI we rebooted and only were presented with an error message stating that we could not upgrade to F17 and had to upgrade to the previous version. That must be some sophisticated bait-and-switch bullying preupgrade devs engaged into.
Do we have to perform some kind of cleanup of all the [beep] that preupgrade downloaded in order to run preupgrade again?
Should we do F14 - F15 - F16 - F17 or is there a possibility to skip versions? Is that documented anywhere? The only reference to a target version I found was:
Quote:
2. On the Choose desired release screen, select the Fedora release you want to upgrade to , and click the Apply button. |
Re-running preupgrade and choosing F15 still brings up the same error message after reboot telling us version mismatch on sda2 and instructing us to upgrade to an intermediate version. Guess there was something in between F14 and F15 in their opinion. Not that I could find it.
That reinforces the earlier question: do I have to perform some kind of cleanup after unsuccessful upgrade attempt? I noticed that downloading for target F15 took a lot less time than initial download for target F17.
After attempting to press Continue on the error message we were given another one, telling us that root was not found. We are not running any kind of volume manager, RAID or any other weirdness.
Is there anything wrong with the disk partitioning?
Code:
# fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9e0140c9
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 41986047 20480000 83 Linux
/dev/sda3 41986048 50374655 4194304 82 Linux swap / Solaris
/dev/sda4 50374656 976773167 463199256 5 Extended
/dev/sda5 50376704 312580095 131101696 83 Linux
/dev/sda6 312592833 976768064 332087616 83 Linux
# mount
rootfs on / type rootfs (rw)
/proc on /proc type proc (rw,relatime)
/sys on /sys type sysfs (rw,relatime)
udev on /dev type devtmpfs (rw,relatime,size=4055660k,nr_inodes=1013915,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime)
/dev/sda2 on / type ext4 (rw,relatime,barrier=1,data=ordered)
/proc/bus/usb on /proc/bus/usb type usbfs (rw,relatime)
/dev/sda1 on /boot type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=0,data=ordered)
/dev/sda5 on /home type ext4 (rw,relatime,barrier=1,data=ordered)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)