Bug 929403 - initial-setup-graphical.service is not enabled by default, so initial-setup does not run after install (KDE, LXDE, Xfce...)
Summary: initial-setup-graphical.service is not enabled by default, so initial-setup d...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initial-setup
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 929435 (view as bug list)
Depends On: 949450
Blocks: F19Alpha, F19AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-03-30 12:07 UTC by Robert Lightfoot
Modified: 2013-04-12 07:56 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-12 01:13:22 UTC


Attachments (Terms of Use)

Description Robert Lightfoot 2013-03-30 12:07:01 UTC
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:

Comment 1 Christoph Wickert 2013-03-30 17:52:08 UTC
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.

Comment 2 Christoph Wickert 2013-03-30 17:54:10 UTC
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.

Comment 3 Robert Lightfoot 2013-03-31 17:38:15 UTC
(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.

Comment 4 Robert Lightfoot 2013-03-31 17:40:03 UTC
(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.

Comment 5 Robert Lightfoot 2013-03-31 17:45:44 UTC
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.

Comment 6 dominique 2013-03-31 18:05:42 UTC
(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.

Comment 7 satellitgo 2013-03-31 21:04:31 UTC
(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

Comment 8 satellitgo 2013-03-31 21:06:46 UTC
(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

Comment 9 dominique 2013-04-01 04:45:50 UTC
(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)

Comment 10 Jens Petersen 2013-04-02 09:09:25 UTC
*** Bug 929435 has been marked as a duplicate of this bug. ***

Comment 11 Adam Williamson 2013-04-02 15:49:29 UTC
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.

Comment 12 Adam Williamson 2013-04-03 18:06:13 UTC
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).

Comment 13 Fedora Update System 2013-04-05 21:55:41 UTC
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

Comment 14 Fedora Update System 2013-04-06 05:17:11 UTC
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).

Comment 15 Robert Lightfoot 2013-04-06 06:57:34 UTC
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.

Comment 16 Jens Petersen 2013-04-06 07:41:35 UTC
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.

Comment 17 Robert Lightfoot 2013-04-07 02:40:34 UTC
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

Comment 18 Adam Williamson 2013-04-07 17:49:54 UTC
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.

Comment 19 Adam Williamson 2013-04-07 17:51:51 UTC
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?

Comment 20 Robert Lightfoot 2013-04-07 17:58:37 UTC
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

Comment 21 Robert Lightfoot 2013-04-07 20:20:29 UTC
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

Comment 22 Robert Lightfoot 2013-04-07 21:38:20 UTC
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

Comment 23 Robert Lightfoot 2013-04-08 00:38:10 UTC
The patch works when incorporated in a local repo built from the DVD package set and the update.rpm.

Comment 24 satellitgo 2013-04-08 01:54:00 UTC
#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
...

Comment 25 Adam Williamson 2013-04-08 03:06:31 UTC
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.

Comment 26 Robert Lightfoot 2013-04-08 03:26:20 UTC
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.

Comment 27 Adam Williamson 2013-04-08 03:36:42 UTC
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 :(

Comment 28 Jens Petersen 2013-04-08 04:48:39 UTC
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.

Comment 29 Jens Petersen 2013-04-08 05:05:16 UTC
(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.

Comment 30 Jens Petersen 2013-04-08 05:40:00 UTC
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

Comment 31 Jaroslav Reznik 2013-04-08 08:19:53 UTC
(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.

Comment 32 Vratislav Podzimek 2013-04-08 11:22:44 UTC
(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.

Comment 33 Fedora Update System 2013-04-08 11:59:40 UTC
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

Comment 34 Fedora Update System 2013-04-08 16:04:37 UTC
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).

Comment 35 Adam Williamson 2013-04-09 01:46:24 UTC
Verified in RC1, initial-setup runs after install from the DVD.

Comment 36 Fedora Update System 2013-04-12 01:13:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.