Description of problem: fedup --network 18 downloads all packages and done preparations. All seams good and reboot suggested. On reboot it hangs with last string like: [ 13.687138] system-journald[45]: Received SIGTERM According to forums, not only I experience that ptoblem: http://forums.fedoraforum.org/showthread.php?t=287425 I'll try update it manually via yum, but I think termination of journal system must not stop upgrade process in any case. Or at least more information for user should pbe provided what happerned. Version-Release number of selected component (if applicable): rpm -q fedup fedup-0.7.2-1.fc17.noarch How reproducible: Always.
I'm experiencing the same issue, where the upgrade seems to be booting the system, but then stops after the system-journald SIGTERM message. The OS is alive enough that it logs when I switch to another machine and back using the USB KVM, but the keyboard will only allow me to CTRL-ALT-DEL to reboot the system. It does seem to shutdown cleanly... After the system-journald SIGTERM message it strangely puts out the "Welcome to Fedora 17 Beefy Miracle!" message. I can still boot to Fedora 17, and ended up cleaning up grub2 to remove the fedup option so I have a usable machine. This is also fedup-0.7.2-1.fc17.noarch, and it reproduces every time. It was a network upgrade, and no problems showed up in the debug log for the RPM's.
(In reply to comment #1) > I can still boot to Fedora 17, and ended up cleaning up grub2 to remove the > fedup option so I have a usable machine. For the record, fedup provides the '--resetbootloader' flag to do that for you. > After the system-journald SIGTERM message it strangely puts out the "Welcome > to Fedora 17 Beefy Miracle!" message. This is expected. fedup sets up the system for the upgrade by starting just enough of the Fedora 17 system to get all the disks mounted, then switching back to the upgrade.img. If something goes wrong while mounting the disks or switching back to upgrade.img, the system will seem to hang after the "Welcome to Fedora 17 Beefy Miracle!" message. There are a few known problems that will cause this: a) mdraid disks that require mdadm.conf to be configured (bug 895805) b) multiple encrypted partitions (bug 896010) c) encrypted /home only (bug 894242) d) old version of systemd in F17 (bug 910326) Does your system match any of these situations?
My system had one hard drive that was split using LVM. Nothing was encrypted. It might have had an old version of systemd, since that machine was rarely upgraded. The machine itself was only used as a network backup server to my primary machines. I ended up doing a clean, wipe-it-out&start-over install from a DVD. My first attempt using the DVD was to keep the existing LVM partitions, but it really didn't like that. So I reformatted and resized everything and stopped using LVM. Then it installed ok from the DVD. I wasn't aware of the --resetbootloader option to fedup. Your explanation helps describe what is supposed to happen. I didn't see that anywhere in the documentation. So my backup machine is up and running F18 without fedup. After a month or so I'll try my primary linux machine.
I have a working, current, Fedora 17 LVM system that gives this situation when trying to boot the system prepared with `fedup --network 18`. Grub2 is the bootloader (because of grub maintenance issues by fedopra). Just swap is encrypted. It gives no message about why systemd-journald fails. How to fix?
Adding selinux=0 to the boot line via the crappy grub2 editor (tip from bug 904253) made the PC boot but it simply boots into X with an old 3.6 kernel from fc18 and no upgrade happens. (!?) We do not use SElinux. We cannot upgrade this way.
1) Shutting down (and then restarting) systemd-journald is a normal part of switching from the old system to the upgrade tool. That isn't the problem. 2) Don't use 'selinux=0'; fedup (0.7.2 and later) should handle this automatically. 3) Do your systems have graphical boot up, or just text? 4) Is it hung, or dropping to an emergency shell? (Wait ~2 minutes to be sure..)
1) ok, but weird as no reason, cause etc is shown but the sigterm is. 2) it doesn't: 3) it normally boots to 'runlevel' 5. 4: without disablign selinux it just sits (textmode), but the kernel is alive. (sysrq thingie etc); with selinux=0 is boots into X. no upgrade.
I upgraded manually using rpm -Uvh --force --nodeps. See my otehr bugs for the comments. No fedup for me. Who to contact about the weird upgrade strategies? (why reboot? why write external media, then copy back?)
Tried to upgrade 3 laptops. Have used the exact same procedure 2 months ago to upgrade 13 laptops succesfully. Today the procedure fails with the system-journald SIGTERM message. Everything is up2date. No mdraid disks or encrypted partitions. I could try the yum upgrade procedure but since fedup is the one-and-only supposed-to-be-used tool I would rather use that one. Anybody any idea what is causing this and/or if there is a workaround?
I have succesfully upgraded 1 laptop in the end. Not quite sure which of these 2 workarounds worked (I will know definitely on Tuesday), I have used them both at the same time: 1. Edit fstab and disable all partitions except for / (laptop has a seperate /data partition with the main users $HOME 2. Add enforcing=0 to grub2.cfg to the upgrade entry Hopefully this is useful for someone.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
For what it is worth, upgrading from Fedora 18 to Fedora 19 using fedup shows no problem at all, everything went smoothly. No hassle with extra mount points or kernel parameters this time.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.