Bug 628241

Just a note:  I installed using the "reduced graphics "  option from the DVD,  Not sure if that'd have any bearing on this at all.

And to clarify: 
   I used the Fedora 14 Alpha media ( not the live dvd)
    Reduced graphics mode on the DVD install :  works
    Post installation vesa graphics in Xorg:  corrupted
    
rpm -q kernel xorg-x11-drv-nouveau xorg-x11-server-Xorg xorg-x11-drv-vesa

kernel-2.6.35.2-9.fc14.x86_64
kernel-2.6.35.4-12.fc14.x86_64
xorg-x11-drv-nouveau-0.0.16-9.20100615gitdb98ad2.fc14.x86_64
xorg-x11-server-Xorg-1.9.0-4.fc14.x86_64
xorg-x11-drv-vesa-2.3.0-1.fc14.x86_64

(In reply to comment #2)


Disregard, filed this to the wrong bug.

I'm seeing this after an F14-Alpha net install with a few non-graphics packages removed from the install.

First I worked around this problem using the install disc in rescue mode:
systemd package update breaks default boot target
https://fedoraproject.org/wiki/Common_F14_bugs#systemd-update
Specifically, with:
cd /etc/systemd/system
ln -sf /lib/systemd/system/graphical.target default.target

I removed graphical boot options on the kernel command line, added
"selinux=0 5", and booted with "nomodeset" and the vesa xorg driver.

The gdm login dialog is displayed with "Other..." as the only option.
Typing "ctrl-alt-f6" brings the firstboot dialog to the front.

I'm not sure how to get log files, because it is not possible to switch to a console. Typing "ctrl-alt-fN" has no effect. The firstboot dialog is always displayed.

After (In reply to comment #4)
...
> I'm not sure how to get log files, because it is not possible to switch to a
> console. Typing "ctrl-alt-fN" has no effect. The firstboot dialog is always
> displayed.

After completing the firstboot process, the display goes black, except for a blinking white underscore. "ctrl-alt-fN" has no effect. The capslock and numlock keys have no effect. There are no flashing lights on the keyboard.

Reboot by pressing the reset button.

Created attachment 442462 [details]
messages.1.log with some firstboot messages at the end

Sep  1 10:48:16 pecan init[1]: [/lib/systemd/system/firstboot-text.service:11] Unknown lvalue 'ValidNoProcess' in section 'Service'. Ignoring.

I just did a netinstall of F14.

Seems that /etc/systemd/system/default.target is linked to /etc/systemd/system/runlevel5.target - which doesn't exist.

Removing this link and creating a new link to /lib/systemd/system/runlevel5.target will fix boot errors and allow the system to boot normally.

Without doing this, the system will boot straight to a sushell prompt.

The basic problem here is that firstboot hasn't been updated for a change to systemd - the line Type=finish in the firstboot systemd service files needs to be changed to Type=oneshot . With that fixed firstboot ought to behave properly again as it did in Alpha, I think. The systemd service files being broken causes all the wackiness people notice with firstboot. I'm going to mark other systemd/firstboot issues reported after the systemd semantic change as dupes of this.

Martin, please make the change mentioned above immediately. I emailed you about this on August 25th, BTW. It will block the Beta.

*** Bug 631658 has been marked as a duplicate of this bug. ***

*** Bug 631584 has been marked as a duplicate of this bug. ***

What are the plans for addressing and assessing this bug?  We'd love to have more information before the next blocker meeting this Friday.

Also, it would be helpful to put the package version of the affected firstboot/systemd in here so people can keep track of a newer release for testing. At the moment, I'm not sure what versions are affected to test newer builds.

I already fixed the systemd service files, and make a new build on Aug 26th. It should be fixed in firstboot-1.113-1

Silly question but was the update pushed? All the mirrors I see still seem to have firstboot-1.112-3.fc14.i686.rpm.

Martin: you never submitted that build as an update. Remember, all F14 builds have to be submitted through Bodhi as updates. Just building it in Koji is not enough.

firstboot-1.113-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/firstboot-1.113-1.fc14

Sorry guys, I forgot about Bodhi, I hope it's ok now.

firstboot-1.113-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update firstboot'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/firstboot-1.113-1.fc14

After installing firstboot-1.113-1.fc14, I tried booting to runlevel 5.  firstboot was successfully triggered and the /etc/sysconfig/firstboot file was created.
I deleted the file to try again in runlevel 3 to see if the text mode firstboot works, but now firstboot doesn't start in either runlevel 3 or 5.  The /etc/sysconfig/firstboot file is still gone.

Is there somewhere else that firstboot checks to determine whether it needs to launch?

Yes. When it's been run successfully one time, it disables both the systemd services. You'd have to re-enable them in addition to wiping /etc/sysconfig/firstboot to turn it back 'on'.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** Bug 632685 has been marked as a duplicate of this bug. ***

*** Bug 632880 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> Yes. When it's been run successfully one time, it disables both the systemd
> services. You'd have to re-enable them in addition to wiping
> /etc/sysconfig/firstboot to turn it back 'on'.

In order to re-enable firstboot on boot, I also had to run the following command:

# systemctl enable firstboot-graphical.service

Still an issue with Beta.TC1  DVD-image.   This time, firstboot starts, but doesn't complete. (once you get to the last step, it just hangs). 

Rebooting into single user, applying updates (firstboot among the things that gets updated) and it never executes again, I'm assuming it had completed then.

tc1 is known broken, it didn't have a good firstboot. I've tested  since then and this is OK now.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

RC1 is now out: if you like, please test and confirm that this is working correctly.

http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Beta.RC1/Fedora/

Thanks!

Works for me in a default graphical install in both i386 and x86_64.

F14 Beta RC1 firstboot works as it should, closing the bug.

Please don't. The update has still not been pushed to stable. Can a firstboot maintainer please submit the update to stable ASAP? Thanks.

(In reply to comment #29)
> Please don't. The update has still not been pushed to stable. Can a firstboot
> maintainer please submit the update to stable ASAP? Thanks.

Thanks, Adam.

If we don't watch out, we will end up like Ubuntu, whipsawing the bug status all in the interest of openness ... :-)

Steve: it's important because if we close the bug we might forget to push the stable update, and then it'd get missed out of future image builds.

firstboot-1.113-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14

https://admin.fedoraproject.org/updates/firstboot-1.113-3.fc14,metacity-2.30.0-8.fc14,kdebase-workspace-4.5.1-3.fc14 is now queued for stable. (1.113-4.fc14 is an even later update which is now queued for testing.)