The instructions on this page are for the Testing of Fedup, not for upgrading your system. The URLs here point to code that probably hasn't been released and may not have been tested which could result in a non-bootable system. If you want to upgrade a system that you care about, see the main FedUp documentation
This page is still a bit of a draft and will be changing over time, if you find something wrong; please fix it or tell someone
Overview
Fedup is a new tool for upgrading Fedora installations that is replacing preupgrade and the DVD methods of upgrading that have been used in previous Fedora releases. It utilizes systemd for much of the upgrade functionality and will eventually be able to source packages from a DVD and use the regular install repos instead of needing a specially created side repo.
State
Fedup is currently complete for Fedora 18 - there is no GUI client but the following features are working
- Souring packages
- From network repos
- From ISO file
- From mountpoint (optical disk, USB drive etc.)
- Automatic detection of repos needed for install
Testing and Filing Bugs
Since fedup is still very young, there may still be bugs in the code. If you run into problems, please file bugs in bugzilla under the 'fedup' component.
Test Results
The test cases for F18 fedup are all variants of the FedUp CLI Upgrade Test Case with different setups prior to upgrade
Final RC2
| Variant | x86_64 | i386 | References |
|---|---|---|---|
| Default Desktop Install | |||
| Minimal Install | |||
| Software RAID | |||
| Encrypted Disk | |||
| Non-US Keyboard Layout | |||
| EFI | |||
| Intel Mac | |||
| SecureBoot |
Known Issues
At the moment, there are several known issues with fedup.
Upgraded system does not reboot if a kernel upgrade is part of the upgrade
Bug 873459
If a kernel upgrade is included as part of the package set to upgrade (which shouldn't happen until the f18 kernel from updates-testing hits stable), the upgraded system doesn't boot due to kernel panic. The error messages shown indicate that the kernel is unable to load the initramfs.
fedup giving grubby backtrace
Bug 872088 Sometimes, fedup will exit with the following backtrace:
setting up system for upgrade
Traceback (most recent call last):
File "/bin/fedup-cli", line 267, in <module>
main(args)
File "/bin/fedup-cli", line 244, in main
prep_boot(kernel, initrd, bootloader=args.bootloader)
File "/usr/lib/python2.7/site-packages/fedup/download.py", line 330, in prep_boot
modify_bootloader(kernel, initrd)
File "/usr/lib/python2.7/site-packages/fedup/download.py", line 300, in modify_bootloader
default = bootloader.default_entry()
File "/usr/lib/python2.7/site-packages/fedup/grubby.py", line 74, in default_entry
return self.get_entry(self.default_index())
File "/usr/lib/python2.7/site-packages/fedup/grubby.py", line 50, in get_entry out = self._grubby("--info", index)
File "/usr/lib/python2.7/site-packages/fedup/grubby.py", line 45, in _grubby
return check_output(cmd + [str(a) for a in args], stderr=PIPE)
File "/usr/lib64/python2.7/subprocess.py", line 544, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['grubby', '--info', '-3']' returned non-zero exit status 1
This has been fixed in git but the fix hasn't been pushed to the fedora package
TypeError: argument of type 'NoneType' is not iterable
Bug 872899.
If the --instrepo arg isn't used, fedup will exit with the following traceback:
Traceback (most recent call last):
File "/bin/fedup-cli", line 253, in <module>
args = parse_args()
File "/bin/fedup-cli", line 179, in parse_args
if '://' in args.instrepo:
TypeError: argument of type 'NoneType' is not iterable
At the moment, fedup requires the --isntrepo argument in order to find the kernel and initramfs needed for the upgrade process. This will change once the initramfs changes make it into the regular tree but until that happens, the --instrepo command will be required.
Requested Information in Filed Bugs
If you do file a bug, please include the following information:
- upgrade.out from the upgraded system
- /var/log/upgrade.out from the booted system
- /sysroot/var/log/upgrade.out from the dracut shell
- system log from the upgraded system
- fedupdebug.log from running fedup-cli
- should be in the same directory that you ran fedup from
- Full fedup-cli command with all args used during upgrade prep
Where to ask questions
The following are good places to ask questions about upgrades:
#fedora-qaon Freenode IRC- The Fedora Test List
If you really need to find someone specifc, you can try the following people, but remember that we're not always online and are often busy:
Doing an Upgrade
This is the current process for doing an upgrade from F17 to F18 using fedup. This documentation will change over time as the process evolves.
The commands listed below use sudo but could also be run as root
It is possible to install fedup on an F17 system using either git or the fedora package (in updates-testing at the time of this writing). Choose one method or the other, preferably using git only if there are problems with using the fedora package.
Preparation With Fedora Package
On an f17 system, run the follwoing command:
sudo yum --enablerepo=updates-testing install fedup
Preparation Using Git
On an f17 system, make sure that all of the dependencies are installed:
sudo yum install python-devel make
Update the F17 system using yum, packagekit or however you prefer to update but don't use updates-testing
sudo yum --disablerepo=updates-testing update
Clone the fedup git repo
git clone git://github.com/wgwoods/fedup.git
Install fedup on the F17 system
sudo make install
Running Fedup
Using the fedup-cli command, prepare the upgrade using the following command:
Make sure that you replace <insert-arch-here> below with the arch that you're upgrading - either x86_64 or i386
sudo fedup-cli --network 18 --debuglog fedupdebug.log --instrepo=http://tflink.fedorapeople.org/fedup/f18-upgrade/<insert-arch-here>/
At this point, the F17 system is pretty much ready for upgrade. However, if you want to be able to montor the upgrade process or otherwise interact with the system during the upgrade, you need to enable the upgrade debug shell.
Enabling the Upgrade Shell
In order to enable the Upgrade shell, you need to edit the grub config file (/boot/grub2/grub.cfg on BIOS systems, /boot/EFI/redhat/grub.conf on UEFI systems)
Under the heading "System Upgrade":
- add the following to the end of the kernel boot args
rd.upgrade.debugshell
- These kernel boot params can also be useful for debugging
rd.debug systemd.log_target=console systemd.jounald.forward_to_console=1 systemd.log_level=debug console=tty0 console=ttyS0,115200n8
Running the Upgrade
Once you reboot, there will be a 'System Upgrade' boot option at the grub prompt. Note that it is not the default and will need to be selected manually in order for the upgrade process to continue.
If all goes as it should, you might see a few boot messages but will eventually see the fedup plymouth theme Insert screenshot here
The upgrade process usually takes a while (anywhere from 45-90 minutes, depending on the system), be patient and wait for it to finish
If you enabled the upgrade debug shell, you can access that by switching to VT2 (ctl-alt-F2). Note that you won't be able to access the debug shell until after the upgrade process has started, so you'll want to wait a minute or two before switching.
Once you've switched to VT2, you should see the dracut prompt:
dracut#
In order to get into the actual upgrade debug shell, you may need to exit the currently running shell (another will start up right afterwards) so that you can access all the binaries present in the initramfs
exit
To view the upgrade progress, use:
cat /sysroot/var/log/upgrade.out
If you want to see the system logs, use journalctl
journalctl -a -o cat
Post Upgrade
Once the upgrade process is complete, the system will automatically reboot. At this time, you will still be running a kernel from F17 due to repository status but the system should mostly work.