Description of problem: Perform Initial Install of LXDE from anaconda19 Version-Release number of selected component (if applicable): 19-tc3 How reproducible: every time Steps to Reproduce: 1. Install LXDE , do not create non-root-user and reboot 2. Arrive at multi-user.target not graphical.target 3. Actual results: LXDE boots to multi-user.target Expected results: LXDe boots to graphical.target and launches initial.setup Additional info:
What makes you think initial-setup should be launched? I was under the impression this was a GNOME-only thing and the other spind and desktops are still using firstboot.
P.S.: By definition, only KDE and GNOME are blocking a released. Therefor, this bug should not block F19AlphaBlocker. Please correct me if I am wrong.
(In reply to comment #1) > What makes you think initial-setup should be launched? I was under the > impression this was a GNOME-only thing and the other spind and desktops are > still using firstboot. It was my understanding that firstboot was deprecated in F19 and that all DE either launched Gnome-Iniital-Setup in the case of Gnome or initial-setup in the case of all others. Either way, after an install of LXDE no post install user setup gui was offered. Either FirstBoot or Initial-Setup shpuld have been offered depending on which direction we are going in.
(In reply to comment #2) > P.S.: By definition, only KDE and GNOME are blocking a released. Therefor, > this bug should not block F19AlphaBlocker. Please correct me if I am wrong. According to https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_TC3_Desktop?rd=Test_Results:Current_Desktop_Test the Desktops under test for F19 are Gnome, Gnome-Fallback, KDE, XFCE, LXDE and Sugar. I've yet to find in the release criteria where the desktops are enumerated. But I'll defer to the criteria whereever they're published.
this bug may need to be expanded. I just did a KDE Install without creating a non-root-user and was not presented with either FirstBoot or InitialSetup on the reboot. I should have received one of these gui setup tools on the first reboot.
(In reply to comment #5) > this bug may need to be expanded. I just did a KDE Install without creating > a non-root-user and was not presented with either FirstBoot or InitialSetup > on the reboot. I should have received one of these gui setup tools on the > first reboot. I have same issue with install alpha-tc3 with kde. In the first attempt, I create an user with anaconda, but when I reboot after complete installation this user don't work, in the kde login screen this user with password don't work... I can see in the /home directory there are no user directory. In the second attempt I don't create an user but after reboot I have no Firstboot screen.
(In reply to comment #6) > (In reply to comment #5) > > this bug may need to be expanded. I just did a KDE Install without creating > > a non-root-user and was not presented with either FirstBoot or InitialSetup > > on the reboot. I should have received one of these gui setup tools on the > > first reboot. > > I have same issue with install alpha-tc3 with kde. > > In the first attempt, I create an user with anaconda, but when I reboot > after complete installation this user don't work, in the kde login screen > this user with password don't work... > > I can see in the /home directory there are no user directory. > > In the second attempt I don't create an user but after reboot I have no > Firstboot screen. Try logging in as root and "initial-setup" in terminal. should let you add user and set TZ
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > this bug may need to be expanded. I just did a KDE Install without creating > > > a non-root-user and was not presented with either FirstBoot or InitialSetup > > > on the reboot. I should have received one of these gui setup tools on the > > > first reboot. > > > > I have same issue with install alpha-tc3 with kde. > > > > In the first attempt, I create an user with anaconda, but when I reboot > > after complete installation this user don't work, in the kde login screen > > this user with password don't work... > > > > I can see in the /home directory there are no user directory. > > > > In the second attempt I don't create an user but after reboot I have no > > Firstboot screen. > Try logging in as root and "initial-setup" in terminal. > should let you add user and set TZ screenshot: http://wiki.sugarlabs.org/go/File:KDE-initial-setup_from_root.png
(In reply to comment #7) > Try logging in as root and "initial-setup" in terminal. > should let you add user and set TZ I can not log in root, I don't know why. When I boot in init 3 and attempt log in root, the answer is bad password... (and I am sure I hit the good password, which has only numbers)
*** Bug 929435 has been marked as a duplicate of this bug. ***
The problem is simply that the initial-setup service is not enabled by default. I noted this a way back but forgot to file it. +1 blocker, as this affects KDE.
Discussed at 2013-04-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt . Accepted as a blocker per criterion ""A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account." (which is being read to cover i-s and g-i-s while we update it).
initial-setup-0.3.4-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/initial-setup-0.3.4-2.fc19
Package initial-setup-0.3.4-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initial-setup-0.3.4-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5021/initial-setup-0.3.4-2.fc19 then log in and leave karma (feedback).
Maybe I am slow, but how does peforming yum update on an existing system let me test this patch/fix. The bug shows itself when you perfrom and install and reboot the new system for the first time. We need this patch/fix to be used by the installer to test it, IHMO. Can someone describe for me how that could be accomplished. I'd be glad to do the test if I understood how to do it.
I tested on a Basic Desktop install but doing: # yum remove initial-setup-0.3.4-1.fc19 # yum install initial-setup-0.3.4-2.fc19 # reboot and rebooted into initial-setup so looks like it is working for me. Would be good if someone could test with KDE. I am not sure but maybe doing the above in a Live instance before installing might also work. Or you could install it like above by hand in /mnt/sysimage of an installer instance I suppose.
I have tested with F19-Alpha-TC5 both i386 and x86_64 and with both Gnome and KDE installs. Test Procedure as follows: 1. Wait for GUI Install to reach <REBOOT> point. 2. Switch to text tty with <CTRL><ALT><F2> 3. chroot /mnt/sysimage 4. yum update initial-setup --enablerepo=updates-testing 5. Respond as needed to yum and let it complete 6. Reboot the System. Saw the following results: Gnome no regressions KDE still does not trigger initial-setup gui
OK, I looked at the spec. Not sure whether Bob's test is legitimate, but either way, this seems to have been done wrong: %post if [ $1 -ne 2 -a ! -f /etc/sysconfig/initial-setup ]; then platform="$(arch)" if [ "$platform" = "s390" -o "$platform" = "s390x" ]; then echo "RUN_INITIAL_SETUP=YES" > /etc/sysconfig/initial-setup else /bin/systemctl enable initial-setup-graphical.service >/dev/null 2>&1 /bin/systemctl enable initial-setup-text.service >/dev/null 2>&1 fi fi That doesn't look correct even for pre-F18, as it doesn't run the 'enable' operation only on initial install. The guidelines are here: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd "If your package includes one or more systemd units that need to be enabled by default on package installation, they need to be covered by the default Fedora preset policy. The default fedora preset policy is shipped as part of systemd.rpm. If your unit files are missing from this list, please file a bug against the systemd package." So I think you need to undo the last change, go back to using the macro triggers, and request a preset for initial-setup in systemd.
Also, I believe we intentionally did _not_ enable firstboot-text in Fedora. Is there a reason to enable initial-setup-text? Will it do something useful?
I have retested with F19-Alpha-TC5 i386 with KDE install. Test Procedure as follows: 1. Wait for GUI Install to reach <REBOOT> point. 2. Switch to text tty with <CTRL><ALT><F2> 3. chroot /mnt/sysimage 4. yum erase initial-setup 5. yum install initial-setup --enablerepo=updates-testing 6. Respond as needed to yum and let it complete 7. Exit chroot and Reboot the System. Saw the following result: KDE does trigger initial-setup gui
I have retested with F19-Alpha-TC5 i386 with XFCE install. Test Procedure as follows: 1. Wait for GUI Install to reach <REBOOT> point. 2. Switch to text tty with <CTRL><ALT><F2> 3. chroot /mnt/sysimage 4. yum erase initial-setup 5. yum install initial-setup --enablerepo=updates-testing 6. Respond as needed to yum and let it complete 7. Exit chroot and Reboot the System. Saw the following result: XFCE does trigger initial-setup gui
I have tested with F19-Alpha-TC5 i386 with LXDE install. Test Procedure as follows: 1. Wait for GUI Install to reach <REBOOT> point. 2. Switch to text tty with <CTRL><ALT><F2> 3. chroot /mnt/sysimage 4. yum erase initial-setup 5. yum install initial-setup --enablerepo=updates-testing 6. Respond as needed to yum and let it complete 7. Exit chroot and Reboot the System. Saw the following result: LXDE does trigger initial-setup gui
The patch works when incorporated in a local repo built from the DVD package set and the update.rpm.
#fedora-qa 6:00PM 04/07/2013: ... <satellit_e> I just did a x86_64 Netiinstall of TC5 used gnome defaults root password no user password; at end of install it rebooted to initial-setup ; I selected button [finish initial-setup] and went to gnome-initial-setup which completed sucessfully looks fixed ;) <BobLfoot> satellit_e: thats busted then initial-setup should not run on a gnome install just gnome-initial-setup .... <satellit_e> but it does flow thru correctly showed root password and no user in initial-setup... <satellit_e> then g-i-s worked as expected <BobLfoot> that sounds like a good discussion for review meeting ...
there's no mechanism to prevent them both from running. comps is set up such that initial-setup should not get installed with a default GNOME package set, though.
I can confirm that both i-s and g-i-s now run after a gnome install. Whereever the fault lies {in i-s or comps} it is wrong.
That is not this bug, please don't discuss it any further here. I'm trying to get the actual bug here addressed, but the bug report is becoming something of a mess :(
I did a x86_64 LXDE install of Alpha TC5 and initial-setup started up. It seems the install scripts have been fixed to follow the guidelines in initial-setup-0.3.4-2.fc19, but since the bug seems fixed I think this can be moved to Verified or closed.
(In reply to comment #28) > It seems the install scripts have been fixed to follow the guidelines > in initial-setup-0.3.4-2.fc19 Erm okay no they haven't! Somehow I only saw %preun and %postun. I think %post can easily be fixed like this: %post %ifnarch s390 s390x %systemd_post initial-setup-graphical.service %systemd_post initial-setup-text.service %endif Anyway the current behaviour looks okay to me so I still feel this blocker bug could be moved to verified.
Okay let me move it back to Assigned then if %post needs to be improved. .(In reply to comment #18) > it doesn't run the 'enable' operation only on initial install. I think it does actually, but I agree using the systemd macros following the guidelines would be better and cleaner. To also handle s390 then I suggest using: %post %ifarch s390 s390x if [ $1 -eq 1 -a ! -f /etc/sysconfig/initial-setup ]; then echo "RUN_INITIAL_SETUP=YES" > /etc/sysconfig/initial-setup fi %else %systemd_post initial-setup-graphical.service %systemd_post initial-setup-text.service %endif
(In reply to comment #18) > So I think you need to undo the last > change, go back to using the macro triggers, and request a preset for > initial-setup in systemd. Confirmed with systemd guys - the last change has to be reverted and initial setup has to be added to default preset. I'm going to report a bug for systemd, so this one can be used to cleanup the initial-setup change.
(In reply to comment #19) > Also, I believe we intentionally did _not_ enable firstboot-text in Fedora. > Is there a reason to enable initial-setup-text? Will it do something useful? firstboot-text no longer exists. intitial-setup-text is a new, working code and I think it could be enabled by default.
initial-setup-0.3.4-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/initial-setup-0.3.4-3.fc19
Package initial-setup-0.3.4-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initial-setup-0.3.4-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5141/initial-setup-0.3.4-3.fc19 then log in and leave karma (feedback).
Verified in RC1, initial-setup runs after install from the DVD.
initial-setup-0.3.4-3.fc19, systemd-200-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.