[HEADS-UP] adding missing systemd links in rawhide upgrades

[Lennart Poettering]

Heya,

just a little heads up for when you upgrade a rawhide system that is a
few weeks old to current rawhide: since we changed the way how some of
the default symlinks of systemd are created you will end up with an
installation that lacks many of the necessary symlinks -- but only if
you upgrade from a systemd version from older rawhide to current
rawhide. It's really only a problem in this case. It is not a problem
with fresh F14 installations, and it is not a problem with upgrades from
F13. The fix is easy: after upgrading just run this command as root and
the missing links should be created:

    # systemctl enable getty@.service prefdm.service getty.target rc-local.service
remote-fs.target

And that should make things work again.

Sorry for the late heads-up.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Wed, 04.08.10 00:10, Lennart Poettering (mzerqung(a)0pointer.de) wrote:

Small addition. When I was referring to rawhide I meant both F-14 and
the new rawhide. i.e. both F-14 and F-15. 

>  Heya,
>  
>  just a little heads up for when you upgrade a rawhide system that is a
>  few weeks old to current rawhide: since we changed the way how some of
>  the default symlinks of systemd are created you will end up with an
>  installation that lacks many of the necessary symlinks -- but only if
>  you upgrade from a systemd version from older rawhide to current
>  rawhide. It's really only a problem in this case. It is not a problem
>  with fresh F14 installations, and it is not a problem with upgrades from
>  F13. The fix is easy: after upgrading just run this command as root and
>  the missing links should be created:
>  
>      # systemctl enable getty@.service prefdm.service getty.target rc-local.service
> remote-fs.target
>  
>  And that should make things work again.
>  
>  Sorry for the late heads-up.
>  
>  Lennart
>   

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Wed, 04.08.10 02:40, Lennart Poettering (mzerqung(a)0pointer.de) wrote:

>  
>  On Wed, 04.08.10 00:10, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
>  
>  Small addition. When I was referring to rawhide I meant both F-14 and
>  the new rawhide. i.e. both F-14 and F-15.  
And here's another addition: you might also want to run this command
when upgrading from older rwahide to current F-14/rawhide:

  # systemctl enable graphical.target

This makes sure the default.target link is created properly

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Bill Nottingham]

Lennart Poettering (mzerqung(a)0pointer.de) said: 
>  And here's another addition: you might also want to run this
> command
>  when upgrading from older rwahide to current F-14/rawhide:
>  
>    # systemctl enable graphical.target
>  
>  This makes sure the default.target link is created properly 
I still believe that for this particular one (and a few of the others) we
should make the trivial changes to the spec to have it done automatically.

Bill

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Wed, 04.08.10 10:51, Bill Nottingham (notting(a)redhat.com) wrote:

>  
>  Lennart Poettering (mzerqung(a)0pointer.de) said: 
>  > And here's another addition: you might also want to run this command
>  > when upgrading from older rwahide to current F-14/rawhide:
>  > 
>  >   # systemctl enable graphical.target
>  > 
>  > This makes sure the default.target link is created properly
>  
>  I still believe that for this particular one (and a few of the others) we
>  should make the trivial changes to the spec to have it done automatically. 
Hmm, i guess in this case we actually could automate this, without too
much ugliness.

I wonder though: how many people are actually hit by this issue?
i.e. were running rawhide already?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Frank Murphy]

On 04/08/10 16:08, Lennart Poettering wrote:
> >>    # systemctl enable graphical.target
> >>
> >> This makes sure the default.target link is created properly
> >
> > I still believe that for this particular one (and a few of the others) we
> > should make the trivial changes to the spec to have it done automatically.
>
>  Hmm, i guess in this case we actually could automate this, without too
>  much ugliness.
>
>  I wonder though: how many people are actually hit by this issue?
>  i.e. were running rawhide already?
>
>  Lennart
>  
Virt-Manager Guests: F14, F15.

I was running rawhide since 1 or 2 mths Before F14-Branch.

"systemctl enable graphical.target"
this it said we was already linked.

But If, I don't put init=/sbin/upstart on the kernel,
every second thing is a fail or a whinge.

Some errors don't make it to dmesg\boot.log
Wont reboot, have to be forcibly shut.

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Wed, 04.08.10 16:27, Frank Murphy (frankly3d(a)gmail.com) wrote:

>  
>  On 04/08/10 16:08, Lennart Poettering wrote:
>  >>>    # systemctl enable graphical.target
>  >>>
>  >>> This makes sure the default.target link is created properly
>  >>
>  >> I still believe that for this particular one (and a few of the others) we
>  >> should make the trivial changes to the spec to have it done automatically.
>  >
>  > Hmm, i guess in this case we actually could automate this, without too
>  > much ugliness.
>  >
>  > I wonder though: how many people are actually hit by this issue?
>  > i.e. were running rawhide already?
>  >
>  > Lennart
>  >
>  Virt-Manager Guests: F14, F15.
>  
>  I was running rawhide since 1 or 2 mths Before F14-Branch.
>  
>  "systemctl enable graphical.target"
>  this it said we was already linked.
>  
>  But If, I don't put init=/sbin/upstart on the kernel,
>  every second thing is a fail or a whinge. 
Well, can you be more precise? Can you try this bodhi build?

https://admin.fedoraproject.org/updates/dbus-1.3.2-0.1.885483.fc14,system...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Frank Murphy]

On 04/08/10 16:41, Lennart Poettering wrote:

>  Well, can you be more precise? Can you try this bodhi build? 
Just got my daughter to take a video of start up,
so will try grab snaps from it and or upload somewhere.

> https://admin.fedoraproject.org/updates/dbus-1.3.2-0.1.885483.fc14,system...
>  
Hasn't really helped in this situation.


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Frank Murphy]

This from an F13.x86 > F14-Rawhide > F14-Branched Guest
(Host if F13.x86_64)

Some still from the video:

http://www.zimagez.com/zimage/screenshot-040810-185144.php

http://www.zimagez.com/zimage/screenshot-040810-185343.php

http://www.zimagez.com/zimage/screenshot-040810-185650.php

http://www.zimagez.com/zimage/screenshot-040810-185927.php

http://www.zimagez.com/zimage/screenshot-040810-190109.php


The full start up video:
http://www.youtube.com/watch?v=jO8OAr7bzl8


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Jóhann B. Guðmundsson]

  On 08/04/2010 06:05 PM, Frank Murphy wrote:
>  This from an F13.x86>  F14-Rawhide>  F14-Branched Guest
>  (Host if F13.x86_64)
>
>  Some still from the video:
>
>  http://www.zimagez.com/zimage/screenshot-040810-185144.php
>
>  http://www.zimagez.com/zimage/screenshot-040810-185343.php
>
>  http://www.zimagez.com/zimage/screenshot-040810-185650.php
>
>  http://www.zimagez.com/zimage/screenshot-040810-185927.php
>
>  http://www.zimagez.com/zimage/screenshot-040810-190109.php
>
>
>  The full start up video:
>  http://www.youtube.com/watch?v=jO8OAr7bzl8
>
>  
Disable selinux in grub and boot with upstart

Grap the latest systemd packages from koji ( systemd and systemd-units )

Remove systemd and systemd-units ( rpm -e systemd systemd-units )

Reinstall systemd and systemd unit.

reboot and allow selinux to relable the filesystem and voila
( at least that works for me )

JBG

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Frank Murphy]

On 04/08/10 20:41, "Jóhann B. Guðmundsson" wrote:
>  Disable selinux in grub and boot with upstart
>
>  Grap the latest systemd packages from koji ( systemd and systemd-units )
>
>  Remove systemd and systemd-units ( rpm -e systemd systemd-units )
>
>  Reinstall systemd and systemd unit.
>
>  reboot and allow selinux to relable the filesystem and voila
>  ( at least that works for me )
>
>  JBG 
Tried this, no go for me.
Completly borked the system.
even init-/sbin/upstart
won't boot afterwards.

I'll do a fresh F13 > F14-Br

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Jiri Moskovcak]

On 08/04/2010 02:54 AM, Lennart Poettering wrote:
>  On Wed, 04.08.10 02:40, Lennart Poettering (mzerqung(a)0pointer.de)
> wrote:
>  
> >
> > On Wed, 04.08.10 00:10, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
> >
> > Small addition. When I was referring to rawhide I meant both F-14 and
> > the new rawhide. i.e. both F-14 and F-15. 
>  
>  And here's another addition: you might also want to run this command
>  when upgrading from older rwahide to current F-14/rawhide:
>  
>    # systemctl enable graphical.target
>  
>  This makes sure the default.target link is created properly
>  
>  Lennart
>   
Hi,
I tried that with no success.

$ systemctl enable graphical.target
Segmentation faults (core dumped)
-> filled rhbz#621584

If you want some additional info, just send me an email, I'll be happy
to help you debug this.

Jirka

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Rudolf Kastl]

instead of trying to workaround the problem i actually tried to check
if a clean install of latest package would work properly with this
result:

Installing     : systemd-units-5-2.fc15.x86_64
                                                    1/4
/var/tmp/rpm-tmp.sqw1k7: line 25: 19348 Segmentation fault      (core
dumped) /bin/systemctl enable getty@.service prefdm.service
getty.target rc-local.service remote-fs.target 2>&1
/var/tmp/rpm-tmp.sqw1k7: line 25: 19350 Segmentation fault      (core
dumped) /bin/systemctl enable dbus.service dbus.socket 2>&1
  Installing     : systemd-5-2.fc15.x86_64
                                                      2/4
  Installing     : systemd-gtk-5-2.fc15.x86_64
                                                      3/4
  Installing     : systemd-sysvinit-5-2.fc15.x86_64

also if there was that error introduced by a package (missing links)
they also should be repaired by an update package.

kind regards,
Rudolf Kastl

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Jóhann B. Guðmundsson]

  On 08/11/2010 09:02 AM, Rudolf Kastl wrote:
>  instead of trying to workaround the problem i actually tried to
> check
>  if a clean install of latest package would work properly with this
>  result:
>
>  Installing     : systemd-units-5-2.fc15.x86_64 
This is far from being the latest packages ( the latest being 7.1 which 
is in update ) and I do belive the bug you encountered got fixed in 6.1 
and with selinux-policy 3.8.8-10 which also is in update.

JBG

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Rudolf Kastl]

2010/8/11 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  On 08/11/2010 09:02 AM, Rudolf Kastl wrote:
>
>  instead of trying to workaround the problem i actually tried to check
>  if a clean install of latest package would work properly with this
>  result:
>
>  Installing     : systemd-units-5-2.fc15.x86_64
>
>  This is far from being the latest packages ( the latest being 7.1 which is
>  in update ) and I do belive the bug you encountered got fixed in 6.1 and
>  with selinux-policy 3.8.8-10 which also is in update. 
wrong:
http://koji.fedoraproject.org/koji/packageinfo?packageID=10477

the newer versions have only been built for f14 not rawhide.

kind regards,
Rudolf Kastl
>  JBG
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Jóhann B. Guðmundsson]

  On 08/11/2010 10:32 AM, Rudolf Kastl wrote:
>  2010/8/11 "Jóhann B.
> Guðmundsson"<johannbg(a)gmail.com>:
> > On 08/11/2010 09:02 AM, Rudolf Kastl wrote:
> >
> > instead of trying to workaround the problem i actually tried to check
> > if a clean install of latest package would work properly with this
> > result:
> >
> > Installing     : systemd-units-5-2.fc15.x86_64
> >
> > This is far from being the latest packages ( the latest being 7.1 which is
> > in update ) and I do belive the bug you encountered got fixed in 6.1 and
> > with selinux-policy 3.8.8-10 which also is in update.
>  wrong:
>  http://koji.fedoraproject.org/koji/packageinfo?packageID=10477
>
>  the newer versions have only been built for f14 not rawhide. 
Given that this thread was for rawhide/F14 ( not rawhide/F15 ) and 
everyone's being more or less pretty much focused on F14 at this point 
dont be surprised rawhide being pretty much in an unusable state.

I pinged Lennart and ask him to build the latest systemd for F15 untill 
then I guess you have to replace the systemd packages with the ones in 
F14 and exclude systemd for updates until the builds for F15 hit koji.

JBG

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Rudolf Kastl]

2010/8/11 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>   On 08/11/2010 10:32 AM, Rudolf Kastl wrote:
> > 2010/8/11 "Jóhann B. Guðmundsson&quot;&lt;johannbg(a)gmail.com&gt;:
> >> On 08/11/2010 09:02 AM, Rudolf Kastl wrote:
> >>
> >> instead of trying to workaround the problem i actually tried to check
> >> if a clean install of latest package would work properly with this
> >> result:
> >>
> >> Installing     : systemd-units-5-2.fc15.x86_64
> >>
> >> This is far from being the latest packages ( the latest being 7.1 which is
> >> in update ) and I do belive the bug you encountered got fixed in 6.1 and
> >> with selinux-policy 3.8.8-10 which also is in update.
> > wrong:
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=10477
> >
> > the newer versions have only been built for f14 not rawhide.
>
>  Given that this thread was for rawhide/F14 ( not rawhide/F15 ) and 
rawhide/f14 is pretty much interpretable as rawhide and/or f14 too...
and i am on the devel not any test or other list.

>  everyone's being more or less pretty much focused on F14 at this
> point
>  dont be surprised rawhide being pretty much in an unusable state. 
i still expect the latest software to be available in rawhide atleast
at the same time as in some branches, using rawhide longer than fedora
exists because of that reason. for me it doesent make sense to report
bugs for old software components... the alternative wouldnt be to use
some branch but to build the system myself.

>  I pinged Lennart and ask him to build the latest systemd for F15 untill
>  then I guess you have to replace the systemd packages with the ones in
>  F14 and exclude systemd for updates until the builds for F15 hit koji. 
i can build the software myself or exchange the init system ... the
current state is still broken. thanks for pinging.

kind regards,
Rudolf Kastl
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Frank Murphy]

On 11/08/10 11:32, Rudolf Kastl wrote:
<snip>

>  wrong:
>  http://koji.fedoraproject.org/koji/packageinfo?packageID=10477
>
>  the newer versions have only been built for f14 not rawhide. 
<snip>

I guess they are waiting to iron out a few bugs on F14 
systemd\selinux\udev?  Before they push the same broken updates to 
F15(Rawhide)


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Kevin Kofler]

Frank Murphy wrote:
>  I guess they are waiting to iron out a few bugs on F14
>  systemd\selinux\udev?  Before they push the same broken updates to
>  F15(Rawhide) 
Normally, development is supposed to happen in Rawhide FIRST.

        Kevin Kofler

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Adam Williamson]

On Thu, 2010-08-12 at 01:40 +0200, Kevin Kofler wrote:
>  Frank Murphy wrote:
>  > I guess they are waiting to iron out a few bugs on F14
>  > systemd\selinux\udev?  Before they push the same broken updates to
>  > F15(Rawhide)
>  
>  Normally, development is supposed to happen in Rawhide FIRST. 
Frank's guess wasn't correct. Lennart simply pushed the changes to F14
first because we needed them in a hurry for the Alpha RC3 build.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Thu, 12.08.10 01:40, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  
>  Frank Murphy wrote:
>  > I guess they are waiting to iron out a few bugs on F14
>  > systemd\selinux\udev?  Before they push the same broken updates to
>  > F15(Rawhide)
>  
>  Normally, development is supposed to happen in Rawhide FIRST. 
Whats the point again of having to development distributions in
parallel? Double the amount of work? Test how wonderful "git merge"
works?

Wasn't there some kind of automatic migration between the to-be-released
distro and rawhide? What happened to that?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Adam Williamson]

On Thu, 2010-08-12 at 04:11 +0200, Lennart Poettering wrote:
>  On Thu, 12.08.10 01:40, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
>  
>  > 
>  > Frank Murphy wrote:
>  > > I guess they are waiting to iron out a few bugs on F14
>  > > systemd\selinux\udev?  Before they push the same broken updates to
>  > > F15(Rawhide)
>  > 
>  > Normally, development is supposed to happen in Rawhide FIRST.
>  
>  Whats the point again of having to development distributions in
>  parallel? 
Now F14 is feature frozen, you are not supposed to work on major new
features to include in it. In the past, when we hit feature freeze, if
you wanted to work on some shiny new feature for future releases, you
had to do it in some kind of side repository. Now, even though you can't
do that in F14, you can do it in Rawhide and be nice and early for F15.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/11/2010 07:11 PM, Lennart Poettering wrote:
>  On Thu, 12.08.10 01:40, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
>  
> >
> > Frank Murphy wrote:
> >> I guess they are waiting to iron out a few bugs on F14
> >> systemd\selinux\udev?  Before they push the same broken updates to
> >> F15(Rawhide)
> >
> > Normally, development is supposed to happen in Rawhide FIRST.
>  
>  Whats the point again of having to development distributions in
>  parallel? Double the amount of work? Test how wonderful "git merge"
>  works? 
We aren't doing parallel development.  F14 is to be stabilized and
bugfixed, while rawhide is available for future feature development.
When we tried to have just one branch we had too many people trying to
do one or not the other.  That's why we separated the concepts out and
have two branches.

>  
>  Wasn't there some kind of automatic migration between the to-be-released
>  distro and rawhide? What happened to that?
>   
When an F14 build goes stable through bodhi, it'll be inherited into
rawhide.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxjYPQACgkQ4v2HLvE71NX7jwCcCw1AjRdy8kpHaUn8FokY9q0s
> NGgAn26yCKDNAQ3MvdiSFsADc/Py9Plh
> =elod
> -----END PGP SIGNATURE-----

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Andreas Schwab]

Jesse Keating <jkeating(a)redhat.com&gt; writes:

>  When an F14 build goes stable through bodhi, it'll be inherited
> into
>  rawhide. 
Unless there is already a release of the package tagged dist-f15, IIUC.

Andreas.

-- 
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/12/2010 12:42 AM, Andreas Schwab wrote:
>  Jesse Keating <jkeating(a)redhat.com&gt; writes:
>  
> > When an F14 build goes stable through bodhi, it'll be inherited into
> > rawhide.
>  
>  Unless there is already a release of the package tagged dist-f15, IIUC.
>  
>  Andreas.
>   
Yes, that is correct.  An already built version on f15 will always be
"newer" than anything coming up from f14.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxjqDQACgkQ4v2HLvE71NV8uwCfTp1KzTAVMGvvSk8mz2pHnNJ2
> 3qQAnR5hXg+H2jR87Q1W6a2bzBmO3QR5
> =0/7u
> -----END PGP SIGNATURE-----

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Andreas Schwab]

Jesse Keating <jkeating(a)redhat.com&gt; writes:

>  Yes, that is correct.  An already built version on f15 will always
> be
>  "newer" than anything coming up from f14. 
Which is exactly the situation with systemd.

Andreas.

-- 
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Thu, 12.08.10 00:52, Jesse Keating (jkeating(a)redhat.com) wrote:

>  
>  Yes, that is correct.  An already built version on f15 will always be
>  "newer" than anything coming up from f14. 
Can I "undo" such a build? I did that mostly because I forgot that the
branching already happened when I built systemd the first time after the
branching.

I'd prefer having to maintain a single package only, not two.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Mamoru Tasaka]

Lennart Poettering wrote, at 08/12/2010 10:28 PM +9:00:
>  On Thu, 12.08.10 00:52, Jesse Keating (jkeating(a)redhat.com) wrote:
>
> >
> > Yes, that is correct.  An already built version on f15 will always be
> > "newer" than anything coming up from f14.
>
>  Can I "undo" such a build? I did that mostly because I forgot that the
>  branching already happened when I built systemd the first time after the
>  branching.
>
>  I'd prefer having to maintain a single package only, not two.
>
>  Lennart
>  
Instead you can manually tag a build built for dist-f14-updates-candidate
also for dist-f15, for example:

$ koji tag-pkg dist-f15 systemd-7-2.fc14
With this systemd-7-2.fc14 will have dist-f14-updates-candidate and
dist-f15 tags (currently dist-f15 tag is not locked).

Regards,
Mamoru

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Chen Lei]

Hi Lennart,

I found that systemd-units depends on pkgconfig, is this dependency
really needed for minimum systemd?


Regards,
Chen Lei

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Matthew Miller]

On Thu, Aug 12, 2010 at 10:10:25PM +0800, Chen Lei wrote:
>  I found that systemd-units depends on pkgconfig, is this dependency
>  really needed for minimum systemd? 

Please file things like this in bugzilla so they don't get lost in the chaos
of this discussion list.

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Thu, 12.08.10 22:10, Chen Lei (supercyper1(a)gmail.com) wrote:

>  Hi Lennart, 
Heya,

>  
>  I found that systemd-units depends on pkgconfig, is this dependency
>  really needed for minimum systemd? 
Yes, this is intended this way. udev does the same these days. We
consider .pc files simply a nice way to make information about the
system and the packages that are installed avaiulable. While
historically this was mostly used for development stuff it also has its
uses outside of development, and I think it should be used more often
like this.

pkg-config has almost no dependencies and is a tiny C binary, hence I
see little value in optimizing this dependency away.

Quite frankly I'd like to see stuff like "lsb_release" and similar
programs be replaced by little .pc files across the board.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Bill Nottingham]

Lennart Poettering (mzerqung(a)0pointer.de) said: 
>  > Yes, that is correct.  An already built version on f15 will
> always be
>  > "newer" than anything coming up from f14.
>  
>  Can I "undo" such a build? I did that mostly because I forgot that the
>  branching already happened when I built systemd the first time after the
>  branching. 
If the version in dist-f14 is newer, then yes, you can do

koji untag-pkg dist-f15 <whatever is there>

Bill

[HEADS-UP] adding missing systemd links in rawhide/F14 upgrades

[Lennart Poettering]

On Thu, 12.08.10 12:06, Bill Nottingham (notting(a)redhat.com) wrote:

>  
>  Lennart Poettering (mzerqung(a)0pointer.de) said: 
>  > > Yes, that is correct.  An already built version on f15 will always be
>  > > "newer" than anything coming up from f14.
>  > 
>  > Can I "undo" such a build? I did that mostly because I forgot that the
>  > branching already happened when I built systemd the first time after the
>  > branching.
>  
>  If the version in dist-f14 is newer, then yes, you can do
>  
>  koji untag-pkg dist-f15 <whatever is there> 
Ah, nice. I have untagged all systemd f15 versions now. Let's see if
rawhide now properly receives the f14 packages again.

Thank you!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Matthias Runge]

On 04/08/10 00:10, Lennart Poettering wrote:
>  Heya,
>  
>  just a little heads up for when you upgrade a rawhide system that is a
>  few weeks old to current rawhide: since we changed the way how some of
>  the default symlinks of systemd are created you will end up with an
>  installation that lacks many of the necessary symlinks -- but only if
>  you upgrade from a systemd version from older rawhide to current
>  rawhide. It's really only a problem in this case. It is not a problem
>  with fresh F14 installations, and it is not a problem with upgrades from
>  F13. The fix is easy: after upgrading just run this command as root and
>  the missing links should be created:
>  
>      # systemctl enable getty@.service prefdm.service getty.target rc-local.service
> remote-fs.target
>  
>  And that should make things work again.
>  
>  Sorry for the late heads-up.
>  
>  Lennart
>   
Ah, thanks. You've saved my day.

Matthias

[Dave Jones]

On Wed, Aug 04, 2010 at 12:10:11AM +0200, Lennart Poettering wrote:
>  Heya,
>  
>  just a little heads up for when you upgrade a rawhide system that is a
>  few weeks old to current rawhide: since we changed the way how some of
>  the default symlinks of systemd are created you will end up with an
>  installation that lacks many of the necessary symlinks -- but only if
>  you upgrade from a systemd version from older rawhide to current
>  rawhide. It's really only a problem in this case. It is not a problem
>  with fresh F14 installations, and it is not a problem with upgrades from
>  F13. The fix is easy: after upgrading just run this command as root and
>  the missing links should be created:
>  
>      # systemctl enable getty@.service prefdm.service getty.target rc-local.service
> remote-fs.target
>  
>  And that should make things work again. 

even after doing this, I still haven't managed to get a single box running systemd.
They all hang after complaining that it failed to load configuration for default.target
(and a bunch of other services like distcache, livesys-late, cman)

It tells me to see the logs for details, but there's not a single message
from systemd in the logs.


as an aside: it also prints out some bogus messages about autofs and ipv6 being
missing. if you could remove those, that would likely save some pointless bug reports.

	Dave

[Lennart Poettering]

On Wed, 18.08.10 18:15, Dave Jones (davej(a)redhat.com) wrote:

>   >     # systemctl enable getty@.service prefdm.service
> getty.target rc-local.service remote-fs.target
>   > 
>   > And that should make things work again.
>  
>  even after doing this, I still haven't managed to get a single box running systemd.
>  They all hang after complaining that it failed to load configuration for default.target
>  (and a bunch of other services like distcache, livesys-late, cman) 
Have you seen the two follow-up messages I posted to this one? You need
to create the default.target link as well. See those two mails for details.

>  It tells me to see the logs for details, but there's not a single
> message
>  from systemd in the logs. 
There should be an explanation in dmesg, that it cannot find default.target.

>  as an aside: it also prints out some bogus messages about autofs and
> ipv6 being
>  missing. if you could remove those, that would likely save some pointless bug reports.
Well, systemd by default uses autofs for certain "API" vfs mounts, such
as binfmt_misc: we create the mount point and only when it is accessed
we actually mount the file system on it. This has the effect that we'll
load the binfmt kernel module only when somebody actaully writes
something to the fs. i.e. we make the mount points availabale all the
time in the file system, but the backing module is not necessarily
loaded. Something similar applies to a couple of other non-essential
virtual "API" file systems. 

When systemd initializes we will initialize autofs too (by opening
/dev/autofs), and that will fail if the module is not loaded (and the
usual module-autoloading won't work for the autofs device node since
udev isn't around yet, and the device node is hence not created yet).

systemd also configures the lo network device by default as part of
early bootup, as part of its normal startup code (in C). here too module
autoloading doesn't work, since configuring an ipv6 address on lo will
not cause the protocol module to be loaded.

So, in summary, we have to modprobe autofs and ipv6 manually before we
go on with the startup, and given that this is how it is I don't think
it makes much sense compiling them as a module anymore. It's similarly
pointless as compiling unix.ko as a module, or the RTC module. It just
slows down the boot and will be loaded into the kernel anyway. And
that's why we complain.

(note that systemd will still boot if autofs and ipv6 aren't available
at all, it's not essential and we actually do honour the modprobe
blacklist)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Dave Jones]

On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote:
>  On Wed, 18.08.10 18:15, Dave Jones (davej(a)redhat.com) wrote:
>  
>  >  >     # systemctl enable getty@.service prefdm.service getty.target
> rc-local.service remote-fs.target
>  >  > 
>  >  > And that should make things work again.
>  > 
>  > even after doing this, I still haven't managed to get a single box running
> systemd.
>  > They all hang after complaining that it failed to load configuration for
> default.target
>  > (and a bunch of other services like distcache, livesys-late, cman)
>  
>  Have you seen the two follow-up messages I posted to this one? You need
>  to create the default.target link as well. See those two mails for details. 
ah, missed that in the noise. thanks. 

>  > It tells me to see the logs for details, but there's not a
> single message
>  > from systemd in the logs.
>  
>  There should be an explanation in dmesg, that it cannot find default.target. 
at the stage that it stopped, I guess syslog wasn't running, so it never made
it into the boot logs. 

>  > as an aside: it also prints out some bogus messages about autofs
> and ipv6 being
>  > missing. if you could remove those, that would likely save some pointless bug
> reports.
>  
>  Well, systemd by default uses autofs for certain "API" vfs mounts, such
>  as binfmt_misc: we create the mount point and only when it is accessed
>  we actually mount the file system on it. This has the effect that we'll
>  load the binfmt kernel module only when somebody actaully writes
>  something to the fs. i.e. we make the mount points availabale all the
>  time in the file system, but the backing module is not necessarily
>  loaded. Something similar applies to a couple of other non-essential
>  virtual "API" file systems. 
>  
>  When systemd initializes we will initialize autofs too (by opening
>  /dev/autofs), and that will fail if the module is not loaded (and the
>  usual module-autoloading won't work for the autofs device node since
>  udev isn't around yet, and the device node is hence not created yet). 
this seems like a rube goldberg machine to me, but ok.
 
>  systemd also configures the lo network device by default as part of
>  early bootup, as part of its normal startup code (in C). here too module
>  autoloading doesn't work, since configuring an ipv6 address on lo will
>  not cause the protocol module to be loaded.
>
>  So, in summary, we have to modprobe autofs and ipv6 manually before we
>  go on with the startup, and given that this is how it is I don't think
>  it makes much sense compiling them as a module anymore. It's similarly
>  pointless as compiling unix.ko as a module, or the RTC module. It just
>  slows down the boot and will be loaded into the kernel anyway. And
>  that's why we complain.
>  
>  (note that systemd will still boot if autofs and ipv6 aren't available
>  at all, it's not essential and we actually do honour the modprobe
>  blacklist) 
we had to revert the ipv6=y change for rhel6 because someone showed that it's
actually costly in high performance networking cases where ipv6 isn't even used.
rhel7 may be a long ways away, but eventually, systemd will have to
be made to handle that case, so it may as well get it right from the start.

There will always be use cases for disabling ipv6, so building it in
seems ill advised.

	Dave

[Lennart Poettering]

On Wed, 18.08.10 18:45, Dave Jones (davej(a)redhat.com) wrote:

>  
>  On Thu, Aug 19, 2010 at 12:32:01AM +0200, Lennart Poettering wrote:
>   > On Wed, 18.08.10 18:15, Dave Jones (davej(a)redhat.com) wrote:
>   > 
>   > >  >     # systemctl enable getty@.service prefdm.service getty.target
> rc-local.service remote-fs.target
>   > >  > 
>   > >  > And that should make things work again.
>   > > 
>   > > even after doing this, I still haven't managed to get a single box running
> systemd.
>   > > They all hang after complaining that it failed to load configuration for
> default.target
>   > > (and a bunch of other services like distcache, livesys-late, cman)
>   > 
>   > Have you seen the two follow-up messages I posted to this one? You need
>   > to create the default.target link as well. See those two mails for details.
>  
>  ah, missed that in the noise. thanks. 
>  
>   > > It tells me to see the logs for details, but there's not a single message
>   > > from systemd in the logs.
>   > 
>   > There should be an explanation in dmesg, that it cannot find default.target.
>  
>  at the stage that it stopped, I guess syslog wasn't running, so it never made
>  it into the boot logs.  
Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
nothing should get lost -- as long as you manage to get a shell somehow.

BTW, as a side note: a simply fix to bypass the problem with a missing
default.target is to pass "5" on the kernel command line. This will then
boot into gdm regardless whether default.target exists or not.

the git version of systemd will automatically enter signle user mode if
default.target is missing or borked.

>   > When systemd initializes we will initialize autofs too (by
> opening
>   > /dev/autofs), and that will fail if the module is not loaded (and the
>   > usual module-autoloading won't work for the autofs device node since
>   > udev isn't around yet, and the device node is hence not created yet).
>  
>  this seems like a rube goldberg machine to me, but ok. 
Well, we have autofs support anyway, and using it is very simple in
systemd, and given that these API mounts are optional and backed by
seldomly used kernel modules this seemed like a sensible thing to do
these things. This way all those ugly scripts which manually modprobe
and mount the respective modules can go away, everything is available in
the file system namespace right-away and even the privileges problem is
gone.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Dave Jones]

On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
 
>  >  > > It tells me to see the logs for details, but
> there's not a single message
>  >  > > from systemd in the logs.
>  >  > 
>  >  > There should be an explanation in dmesg, that it cannot find default.target.
>  > 
>  > at the stage that it stopped, I guess syslog wasn't running, so it never made
>  > it into the boot logs. 
>  
>  Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
>  nothing should get lost -- as long as you manage to get a shell somehow.
>  
>  BTW, as a side note: a simply fix to bypass the problem with a missing
>  default.target is to pass "5" on the kernel command line. This will then
>  boot into gdm regardless whether default.target exists or not.
>  
>  the git version of systemd will automatically enter signle user mode if
>  default.target is missing or borked. 
 
So I got it booting after creating the default.target symlink, but the network
no longer comes up automatically (nor services dependant upon it, like sshd).
Did I miss another mail ?

	Dave

[Lennart Poettering]

On Wed, 18.08.10 19:00, Dave Jones (davej(a)redhat.com) wrote:

>   > Hmm, could be. Note that we log to kmsg as long as syslog
> isn't up, so
>   > nothing should get lost -- as long as you manage to get a shell somehow.
>   > 
>   > BTW, as a side note: a simply fix to bypass the problem with a missing
>   > default.target is to pass "5" on the kernel command line. This will then
>   > boot into gdm regardless whether default.target exists or not.
>   > 
>   > the git version of systemd will automatically enter signle user mode if
>   > default.target is missing or borked.
>   
>  So I got it booting after creating the default.target symlink, but the network
>  no longer comes up automatically (nor services dependant upon it, like sshd).
>  Did I miss another mail ? 
The NM packages didn't properly enable its service. dcbw has already
fixed this now, but it isn't in f14 yet.

You should be able to work around this by invoking "systemctl enable
NetworkManager.service" and "systemctl start NetworkManager.service".

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Dave Jones]

On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote:
>  On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
>   
>   > >  > > It tells me to see the logs for details, but there's not a
> single message
>   > >  > > from systemd in the logs.
>   > >  > 
>   > >  > There should be an explanation in dmesg, that it cannot find
> default.target.
>   > > 
>   > > at the stage that it stopped, I guess syslog wasn't running, so it never
> made
>   > > it into the boot logs. 
>   > 
>   > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
>   > nothing should get lost -- as long as you manage to get a shell somehow.
>   > 
>   > BTW, as a side note: a simply fix to bypass the problem with a missing
>   > default.target is to pass "5" on the kernel command line. This will then
>   > boot into gdm regardless whether default.target exists or not.
>   > 
>   > the git version of systemd will automatically enter signle user mode if
>   > default.target is missing or borked.
>   
>  So I got it booting after creating the default.target symlink, but the network
>  no longer comes up automatically (nor services dependant upon it, like sshd).
>  Did I miss another mail ? 
related to this I guess  ?

[   44.659412] init[1]: Failed to load configuration for NetworkManager-by-dbus.service:
No such file or directory
[   44.659596] init[1]: D-Bus activation failed for NetworkManager-by-dbus.service:
Invalid argument

	Dave

[Lennart Poettering]

On Wed, 18.08.10 19:35, Dave Jones (davej(a)redhat.com) wrote:

>  
>  On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote:
>   > On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
>   >  
>   >  > >  > > It tells me to see the logs for details, but there's not
> a single message
>   >  > >  > > from systemd in the logs.
>   >  > >  > 
>   >  > >  > There should be an explanation in dmesg, that it cannot find
> default.target.
>   >  > > 
>   >  > > at the stage that it stopped, I guess syslog wasn't running, so it
> never made
>   >  > > it into the boot logs. 
>   >  > 
>   >  > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so
>   >  > nothing should get lost -- as long as you manage to get a shell somehow.
>   >  > 
>   >  > BTW, as a side note: a simply fix to bypass the problem with a missing
>   >  > default.target is to pass "5" on the kernel command line. This will
> then
>   >  > boot into gdm regardless whether default.target exists or not.
>   >  > 
>   >  > the git version of systemd will automatically enter signle user mode if
>   >  > default.target is missing or borked.
>   >  
>   > So I got it booting after creating the default.target symlink, but the network
>   > no longer comes up automatically (nor services dependant upon it, like sshd).
>   > Did I miss another mail ?
>  
>  related to this I guess  ?
>  
>  [   44.659412] init[1]: Failed to load configuration for NetworkManager-by-dbus.service:
> No such file or directory
>  [   44.659596] init[1]: D-Bus activation failed for NetworkManager-by-dbus.service:
> Invalid argument 
Yupp,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Paul W. Frields]

On Thu, Aug 19, 2010 at 01:40:10AM +0200, Lennart Poettering wrote:
>  On Wed, 18.08.10 19:35, Dave Jones (davej(a)redhat.com) wrote:
>  
>  > 
>  > On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote:
>  >  > On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote:
>  >  >  
>  >  >  > >  > > It tells me to see the logs for details, but there's
> not a single message
>  >  >  > >  > > from systemd in the logs.
>  >  >  > >  > 
>  >  >  > >  > There should be an explanation in dmesg, that it cannot find
> default.target.
>  >  >  > > 
>  >  >  > > at the stage that it stopped, I guess syslog wasn't running, so
> it never made
>  >  >  > > it into the boot logs. 
>  >  >  > 
>  >  >  > Hmm, could be. Note that we log to kmsg as long as syslog isn't up,
> so
>  >  >  > nothing should get lost -- as long as you manage to get a shell
> somehow.
>  >  >  > 
>  >  >  > BTW, as a side note: a simply fix to bypass the problem with a missing
>  >  >  > default.target is to pass "5" on the kernel command line. This
> will then
>  >  >  > boot into gdm regardless whether default.target exists or not.
>  >  >  > 
>  >  >  > the git version of systemd will automatically enter signle user mode if
>  >  >  > default.target is missing or borked.
>  >  >  
>  >  > So I got it booting after creating the default.target symlink, but the
> network
>  >  > no longer comes up automatically (nor services dependant upon it, like sshd).
>  >  > Did I miss another mail ?
>  > 
>  > related to this I guess  ?
>  > 
>  > [   44.659412] init[1]: Failed to load configuration for
> NetworkManager-by-dbus.service: No such file or directory
>  > [   44.659596] init[1]: D-Bus activation failed for NetworkManager-by-dbus.service:
> Invalid argument
>  
>  Yupp, 
If any of the problems being discussed are common to people who will
install F14 Alpha, can I ask you guys to put some information on the
Common F14 bugs page please?

https://fedoraproject.org/wiki/Common_F14_bugs

Thanks.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
          Where open source multiplies: http://opensource.com

[Lennart Poettering]

On Thu, 19.08.10 10:02, Paul W. Frields (stickster(a)gmail.com) wrote:

>  > >  > So I got it booting after creating the default.target
> symlink, but the network
>  > >  > no longer comes up automatically (nor services dependant upon it, like
> sshd).
>  > >  > Did I miss another mail ?
>  > > 
>  > > related to this I guess  ?
>  > > 
>  > > [   44.659412] init[1]: Failed to load configuration for
> NetworkManager-by-dbus.service: No such file or directory
>  > > [   44.659596] init[1]: D-Bus activation failed for
> NetworkManager-by-dbus.service: Invalid argument
>  > 
>  > Yupp,
>  
>  If any of the problems being discussed are common to people who will
>  install F14 Alpha, can I ask you guys to put some information on the
>  Common F14 bugs page please?
>  
>  https://fedoraproject.org/wiki/Common_F14_bugs 
To my understanding these bugs are visible only if you upgrade from
odler to newer rawhide/f14, resp. when installing an NM version that
entered f14 post alpha.

People installing a fresh f14 image should not see these issues.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.