To reproduce: 1. Do a minimal install of F16 from DVD. 2. Upgrade it to F17, using F17 Beta RC1 DVD. 3. Boot upgraded system. It hangs at a black screen with a cursor. I've tested this three times. Upgrade of a default install works okay. I'm guessing there is some kind of missing package, but I've no idea what. This probably isn't an anaconda bug, but I'm unsure what else to report it against as of yet. Not really a blocker as we only require *default* install upgrade to work, but obviously one we should fix if possible.
If you boot without rhgb quiet it seems to just kind of stop, late in startup. I think it may just be stuck on the plymouth-wait service: I see a 'Starting Wait for Plymouth Boot Screen to Quit...' but no equivalent 'Started' message. It may eventually boot after that times out, I guess. I'll wait. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
What happens if you do a yum upgrade of the same setup?
Okay, systemd debug parameters help. It seems, for some reason, that systemd is trying to fire prefdm.service. I have a series of 'prefdm.service entered failed state.', 'prefdm.service: main process exited', 'prefdm.service holdoff time over' messages, then it gives up with 'repeated too quickly, refusing to start'. What I don't know is why prefdm.service would get enabled...
Created attachment 573180 [details] output of /bin/systemd --test --system --log-level=debug
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
proposing as NTH and marking as commonbugs (this is the kind of thing we ought to fix and/or document).
Should be fixed using notting's suggested trigger scriptlets in systemd-44-4: http://koji.fedoraproject.org/koji/buildinfo?buildID=310039
okay, after somewhat-tortuous testing that looks good. it seems more or less impossible to get anaconda to use a supplemental repository for an upgrade, so I tested with yum upgrades instead. did it twice, once with a supplemental repo containing systemd 44-4, once without. the upgrade without 44-4 behaves exactly as described in the bug. the upgrade with 44-4 works correctly and I can confirm that /etc/systemd/system/default.target still exists and points at runlevel3.target. excellent! can you submit the build as an update? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
systemd-44-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-4772/systemd-44-4.fc17
Package systemd-44-4.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-4.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4772/systemd-44-4.fc17 then log in and leave karma (feedback).
Discussed at 2012-03-28 go/no-go meeting, acting as an NTH review meeting. Accepted as NTH: this is a big visible breakage in upgrades (esp. minimal upgrades) and can't be fixed with an update, at least for the case of upgrading via DVD. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
systemd-44-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Dropping commonbugs nomination, as this ought to be fixed in Beta (though really, I should re-test).