Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 30, 2010 at 14:05, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-07-28 at 21:56 -0700, darrell pfeifer wrote: I also had the same problem with one core using 100% CPU, in my case for Xorg. I've filed a bug on this - https://bugzilla.redhat.com/show_bug.cgi?id=619889. -- Speaking of blockers, I don't know if this qualifies, but it pretty much makes X unusable. https://bugzilla.redhat.com/show_bug.cgi?id=602910 I've also had trouble with the latest X not being usable at all on my laptop (Just a small start of a gnome window in about 1/6 of the screen) I haven't filed a bug yet (gun-shy since restoring after a dead X is really tedious, even with my working X rpm's backup. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, 2010-07-30 at 14:41 -0700, darrell pfeifer wrote: On Fri, Jul 30, 2010 at 14:05, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-07-28 at 21:56 -0700, darrell pfeifer wrote: I also had the same problem with one core using 100% CPU, in my case for Xorg. I've filed a bug on this - https://bugzilla.redhat.com/show_bug.cgi?id=619889. -- Speaking of blockers, I don't know if this qualifies, but it pretty much makes X unusable. https://bugzilla.redhat.com/show_bug.cgi?id=602910 I've also had trouble with the latest X not being usable at all on my laptop (Just a small start of a gnome window in about 1/6 of the screen) I haven't filed a bug yet (gun-shy since restoring after a dead X is really tedious, even with my working X rpm's backup. Hardware specific bugs are judgment calls (that's what the 'in most cases' weasel phrase in some of the release criteria means). It depends how many people the issue is likely to effect. We'd need a hardware-specific issue to affect a huge amount of people to consider it an alpha blocker, usually. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote: On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote: On 7/23/2010 20:26, Lennart Poettering wrote: - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. Yes, this is the case. Normal users can and should start it and it might even be invoked by scripts such as gnomerc or suchlike. On most distributions (with the exception of Fedora) /sbin/ is not in $PATH and hence the right place for the systemd binary is /bin/ and nothing else. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Hi On Wed, Jul 28, 2010 at 6:26 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote: On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote: On 7/23/2010 20:26, Lennart Poettering wrote: - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. Yes, this is the case. Normal users can and should start it and it might even be invoked by scripts such as gnomerc or suchlike. On most distributions (with the exception of Fedora) /sbin/ is not in $PATH and hence the right place for the systemd binary is /bin/ and nothing else. Could put systemd in /sbin and have a symlink to it called /bin/sessiond That would also allow the daemon to know which mode it's running in. Still, probably not worth it. --Ray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, Jul 24, 2010 at 23:34, Kevin Fenzi ke...@scrye.com wrote: First it seems that my boot would fail. It was unable to find or run a 'default.target' and would hang. Unfortunately it advises you to check the logs, but since syslog isn't up yet and you can't do anything to look at dmesg thats not very helpfull. ;( If there is no /etc/systemd/system/default.target could we fall back to a single user target? Also, in my switchover, I got no getty's setup by default. Happily I was able to figure out how to add them here by looking at the FAQ (once I found it. ;) What symbolic link did you set to get a graphical target? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
I installed the latest systemd and added the appropriate symbolic link to graphical startup. My system hangs when almost complete at the plymouth throbber. In text mode it gets to the end of starting services and hangs. gdm never starts. In /var/log/messages, these seem to be the suspicious lines Jul 28 14:21:26 darrell init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:26 darrell kernel: init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:35 darrell init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s tart timed out. Jul 28 14:21:35 darrell kernel: init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c. device/start timed out. df shows the volume as /dev/mapper/vg_darrell-lv_root Any suggestions? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Add init=/sbin/upstart to the end of the kernel line and it will boot up using upstart. Last lines in my boot read failing to load default.service and then failing to start default.service. -Original Message- From: darrell pfeifer darrel...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wed, Jul 28, 2010 5:59 pm Subject: Re: [HEADS-UP] systemd is now the default init system in rawhide I installed the latest systemd and added the appropriate symbolic link to graphical startup. My system hangs when almost complete at the plymouth throbber. In text mode it gets to the end of starting services and hangs. gdm never starts. In /var/log/messages, these seem to be the suspicious lines Jul 28 14:21:26 darrell init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:26 darrell kernel: init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:35 darrell init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s tart timed out. Jul 28 14:21:35 darrell kernel: init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c. device/start timed out. df shows the volume as /dev/mapper/vg_darrell-lv_root Any suggestions? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, Jul 28, 2010 at 19:33, goinea...@aol.com wrote: Add init=/sbin/upstart to the end of the kernel line and it will boot up using upstart. Last lines in my boot read failing to load default.service and then failing to start default.service. Check one of the recent previous messages. ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target Will solve that problem and get you a bit further along the way. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
I found a fix on bugzilla: rpm -e --nodeps systemd-units yum install systemd-units Which created the symlinks and default.service which seemed to be missing, and allowed the boot to finish, but I may have been to quick to use it. One CPU core is at maximum and Chrome won't open, so I'm temporarily back to upstart till I get time to look at it further. https://bugzilla.redhat.com/show_bug.cgi?id=618315 -Original Message- From: darrell pfeifer darrel...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wed, Jul 28, 2010 6:46 pm Subject: Re: [HEADS-UP] systemd is now the default init system in rawhide On Wed, Jul 28, 2010 at 19:33, goinea...@aol.com wrote: Add init=/sbin/upstart to the end of the kernel line and it will boot up using upstart. Last lines in my boot read failing to load default.service and then failing to start default.service. Check one of the recent previous messages. ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target Will solve that problem and get you a bit further along the way. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, Jul 28, 2010 at 21:20, goinea...@aol.com wrote: I found a fix on bugzilla: rpm -e --nodeps systemd-units yum install systemd-units Which created the symlinks and default.service which seemed to be missing, and allowed the boot to finish, but I may have been to quick to use it. One CPU core is at maximum and Chrome won't open, so I'm temporarily back to upstart till I get time to look at it further. https://bugzilla.redhat.com/show_bug.cgi?id=618315 Thanks for the info and the bugzilla. Reinstalling systemd-units got me a mostly working system. I also had the same problem with one core using 100% CPU, in my case for Xorg. Added my comments to the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@redhat.com) said: The 'not separating the scripts into a separate subpackage' bit. Ah. I thought the point of separating them wasn't to allow for multiple init systems, but because our current guidance was to use sysvinit scripts by default, not upstart scripts; so with them separated off, you only get the upstart native script if you manually install it. The referenced packages aren't using upstart jobs as a replacement for traditional SysV service scripts... they're using upstart for things that don't really fit in the service paradigm. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, Jul 27, 2010 at 12:55:17AM -0700, Matt McCutchen wrote: The next sentence says, /bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). systemd qualifies on both counts: it may be used by users, and it is needed before other filesystems are mounted. The usefulness in the distinction between /bin and /sbin is largely in what goes in the path. Generally, daemons don't belong in normal user's paths. not want in the user path because a user itsself should never have to execute it. Messing up the distinction between */bin and */sbin in the name of cleaner path completion is not progress. But that's the point of the distinction. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 11:34 -0400, Bill Nottingham wrote: Adam Williamson (awill...@redhat.com) said: The 'not separating the scripts into a separate subpackage' bit. Ah. I thought the point of separating them wasn't to allow for multiple init systems, but because our current guidance was to use sysvinit scripts by default, not upstart scripts; so with them separated off, you only get the upstart native script if you manually install it. The referenced packages aren't using upstart jobs as a replacement for traditional SysV service scripts... they're using upstart for things that don't really fit in the service paradigm. Ah, I see, that makes sense then. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/2010 09:39 PM, Matt McCutchen wrote: On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. Still belongs in /sbin, unless it's meant to actually be executed directly by end-users. No. If that were the criterion, update-mime-database would belong in /sbin . The FHS puts it like this: (a) /bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts. (b) /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. So if the intent is that systemd will eventually be invoked (indirectly by some script/daemon) by users this seems justified by (a). On the other hand the page has this to say on init: The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed: ... init It's arguable though whether this refers to SysV's init or is intended to be more general. http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNVfQACgkQ6YSQoMYUY95UngCgxoS3//7yzpXZriKSCZMFnun+ 1qoAn107myHo05jderCykLfKsSmqYAmS =iYOx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, 2010-07-24 at 03:26 +0200, Lennart Poettering wrote: Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: Aside from the noted conflict, I see this in the build logs for the 20100726 nightly live (http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/logs/20100726.15-x86_64.log ): Installing: systemd-units### [ 113/1075]/var/tmp/rpm-tmp.3xbHei: line 11: /bin/ln: No such file or directory ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty1.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty2.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty3.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty4.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty5.service' ln -s '/lib/systemd/system/ge...@.service' '/etc/systemd/system/getty.target.wants/ge...@tty6.service' ln -s '/lib/systemd/system/prefdm.service' '/etc/systemd/system/graphical.target.wants/prefdm.service' ln -s '/lib/systemd/system/getty.target' '/etc/systemd/system/multi-user.target.wants/getty.target' ln -s '/lib/systemd/system/rc-local.service' '/etc/systemd/system/multi-user.target.wants/rc-local.service' ln -s '/lib/systemd/system/remote-fs.target' '/etc/systemd/system/multi-user.target.wants/remote-fs.target' Looks like it's missing a Requires(post), I guess. It also doesn't seem that systemd is yet kicking in as the default for the live builds. Even though the installed systemd-units package is systemd-units-4-3.fc14.x86_64 , indicating a version new enough to be intended to be the default was available, systemd-units is the *only* systemd package installed, and upstart-sysvinit-0.6.5-7.fc14 is installed, so it seems upstart still gets to be the default. Not sure if that's another packaging issue, or just that the live spin kickstart file needs to be changed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Mon, 2010-07-26 at 17:45 -0700, Adam Williamson wrote:
It also doesn't seem that systemd is yet kicking in as the default for
the live builds. Even though the installed systemd-units package is
systemd-units-4-3.fc14.x86_64 , indicating a version new enough to be
intended to be the default was available, systemd-units is the *only*
systemd package installed, and upstart-sysvinit-0.6.5-7.fc14 is
installed, so it seems upstart still gets to be the default. Not sure if
that's another packaging issue, or just that the live spin kickstart
file needs to be changed.
Addendum - I just checked spin-kickstarts and AFAICT it doesn't
explicitly specify an init system, I guess it relies on dependencies.
I note that initscripts has an explicit dependency on upstart:
%define with_upstart 1%{nil}
...
if with_upstart
Requires: upstart = 0.6.0
%else
Requires: SysVinit = 2.85-38
%endif
seems like something that should be changed. readahead,
system-setup-keyboard and vpnc also have direct dependencies on upstart,
presumably because they (I think incorrectly) include upstart-style
scripts in their main packages rather than separating them into a
-upstart subpackage.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: --- Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed -- Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit -- Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit I built a local systemd-sysvinit and updated and did some testing. First it seems that my boot would fail. It was unable to find or run a 'default.target' and would hang. Unfortunately it advises you to check the logs, but since syslog isn't up yet and you can't do anything to look at dmesg thats not very helpfull. ;( If there is no /etc/systemd/system/default.target could we fall back to a single user target? Also, in my switchover, I got no getty's setup by default. Happily I was able to figure out how to add them here by looking at the FAQ (once I found it. ;) Does systemd allow you to query for root password before doing single user? With upstart/sysvinit you can do a 'chkconfig --list | grep 3:on' or the like to get a in order list of services. Is there something similar for systemd? I ask because I see people who have problems booting and often can see the last service that did work before the hang, then can look at the order and find out the trouble service. If systemd is just starting them all, is there any way to debug what one didn't finish or was next in the order? The shutdown/reboot commands don't seem to wall by default or output anything. You type them and the machine goes down. Could you at least add a Shutting down system at 2010-07-25 xx;xx;xx or something? With sysvinit/upstart the command would return back to a prompt and you could logout or do some few things before the machine was totally down. It's anoying to have to kill your ssh manually instead of being able to logout gracefully. Whats the status on selinux integration? We must get that working before release if it's going to be default... As a side note, systemd is an unfortunate name, google wise. It took me a while to find it's home page for the FAQ. ;( Anyhow, I sure hope we can get all the issues ironed out in time for F14. If not, we can always try again next cycle. I personally really want to make sure things are as stable and working and clear as we can make them before committing to making this default. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 25 July 2010 07:34, Kevin Fenzi ke...@scrye.com wrote: Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: --- Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed -- Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit -- Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit I built a local systemd-sysvinit and updated and did some testing. First it seems that my boot would fail. It was unable to find or run a 'default.target' and would hang. Unfortunately it advises you to check the logs, but since syslog isn't up yet and you can't do anything to look at dmesg thats not very helpfull. ;( If there is no /etc/systemd/system/default.target could we fall back to a single user target? Also, in my switchover, I got no getty's setup by default. Happily I was able to figure out how to add them here by looking at the FAQ (once I found it. ;) Does systemd allow you to query for root password before doing single user? With upstart/sysvinit you can do a 'chkconfig --list | grep 3:on' or the like to get a in order list of services. Is there something similar for systemd? I ask because I see people who have problems booting and often can see the last service that did work before the hang, then can look at the order and find out the trouble service. If systemd is just starting them all, is there any way to debug what one didn't finish or was next in the order? The shutdown/reboot commands don't seem to wall by default or output anything. You type them and the machine goes down. Could you at least add a Shutting down system at 2010-07-25 xx;xx;xx or something? With sysvinit/upstart the command would return back to a prompt and you could logout or do some few things before the machine was totally down. It's anoying to have to kill your ssh manually instead of being able to logout gracefully. Whats the status on selinux integration? We must get that working before release if it's going to be default... As a side note, systemd is an unfortunate name, google wise. It took me a while to find it's home page for the FAQ. ;( What about sysd? It would save sysadmins typing 3 characters. Anyhow, I sure hope we can get all the issues ironed out in time for F14. If not, we can always try again next cycle. I personally really want to make sure things are as stable and working and clear as we can make them before committing to making this default. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 25/07/10 09:16, Piscium wrote: snip Please try and trim replied to post(s)* to relevant parts. What about sysd? It would save sysadmins typing 3 characters. Still doesn't help with Google, which I feel is just maybe it's newness? -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 25/07/10 07:34, Kevin Fenzi wrote: Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: --- Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed -- Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit -- Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit thank Seth? for yum --exclude=systemd\* Will systemd be default in F14-Branched, or be kept with devel? -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri 23 July 2010 18:26:29 Lennart Poettering wrote: [snip] - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) [snip] If systemd does not work for you and you need a temporary fix, pass init=/bin/upstart on the kernel command line. Hmmm? :) -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 07/24/2010 04:39 PM, Matt McCutchen wrote: On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. Still belongs in /sbin, unless it's meant to actually be executed directly by end-users. No. If that were the criterion, update-mime-database would belong in /sbin . I suspect the argument is likely the other way round - namely its replacing init - therefore probably belongs in /sbin - no ? Oh - and may also do user session management as an additional feature in addition to being the init daemon ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tangent! [was Re: [HEADS-UP] systemd is now the default init system in rawhide]
On Sat, Jul 24, 2010 at 01:39:20PM -0700, Matt McCutchen wrote: Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. Still belongs in /sbin, unless it's meant to actually be executed directly by end-users. No. If that were the criterion, update-mime-database would belong in /sbin . It looks like it probably _does_. From the gnome.org docs: Understanding how to refresh the MIME database is important for administrators who wish to add new MIME types to the system, or otherwise modify information about a MIME type. The application update-mime-database is intended for this purpose. But that's a long thread I don't want to sidetrack this with. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS-UP] systemd is now the default init system in rawhide
Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: - upstart and systemd are now parallel installable. When you upgrade rawhide you will get both installed. (we'll drop upstart eventually, but during the testing phase i made sure to explicitly install both, so that there is a safe backup init system) - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) - Since there can only be one implementation providing the /sbin/init file name, I have split off -sysvinit packages from both packages which symlink this to either /bin/systemd (in the systemd-sysvinit pkg) or /sbin/upstart (in the upstart-sysvinit pkg). Something similar is done for /sbin/reboot and the other well-known SysV client utilities. That basically means you can choose which init system to use by default simply by installing either of these two packages. By default systemd-sysvinit will now be installed. As mentioned the upstart and systemd packages do not conflict -- but upstart-sysvinit and systemd-sysvinit do. The former two packages include all the actual code, and the latter then install them under the well-known names via symlinks. - Note that using the upstart client tools on a systemd system will of course make certain functionality unavailable. Vice versa it is similar: using the systemd client tools on an upstart boot will of course make certain functionality unavailable, too. However, I carefully made sure that both tool sets work well enough to be able to at least bring up and reboot the machine. So, to put this in shorter words: If systemd does not work for you and you need a temporary fix, pass init=/bin/upstart on the kernel command line. If systemd does not work for you and you need a non-temporary fix, install upstart-sysvinit. I think this offers a good and soft transition for rawhide. I have tested all this quite extensibly on my machines, but of course, I am not sure how this will break on other people's machines. I sincerly hope I didn't break anything major with this transition. So please report bugs and don't rip off my head because I might have broken your boot... I didn't do it on purpose, promised! ;-) systemd.4-3 is the package version this switch of defaults has taken place in. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 18:26, Lennart Poettering mzerq...@0pointer.dewrote: Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: - upstart and systemd are now parallel installable. When you upgrade rawhide you will get both installed. (we'll drop upstart eventually, but during the testing phase i made sure to explicitly install both, so that there is a safe backup init system) Just gave it a try with the koji of moments ago. --- Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed -- Processing Dependency: systemd = 4-3.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 -- Processing Dependency: upstart = 0.6.5-6.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 --- Package systemd-units.x86_64 0:4-3.fc14 set to be updated -- Running transaction check --- Package systemd.x86_64 0:4-3.fc14 set to be installed --- Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated -- Processing Dependency: sysvinit-userspace for package: upstart-0.6.5-7.fc14.x86_64 -- Running transaction check --- Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed -- Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit -- Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit -- Finished Dependency Resolution Error: systemd-sysvinit conflicts with upstart-sysvinit Error: upstart-sysvinit conflicts with systemd-sysvinit You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 7/23/2010 20:26, Lennart Poettering wrote: - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) Why is the systemd executable in /bin instead of /sbin? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 08:04:48PM -0700, darrell pfeifer wrote: On Fri, Jul 23, 2010 at 18:26, Lennart Poettering mzerq...@0pointer.dewrote: Heya, I have just uploaded a new systemd and a new upstart package which make systemd the default init system for Rawhide. The scheme I followed makes sure that in case systemd actually breaks systems there is an easy path back to upstart. And here's how it works: - upstart and systemd are now parallel installable. When you upgrade rawhide you will get both installed. (we'll drop upstart eventually, but during the testing phase i made sure to explicitly install both, so that there is a safe backup init system) Just gave it a try with the koji of moments ago. --- Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed -- Processing Dependency: systemd = 4-3.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 -- Processing Dependency: upstart = 0.6.5-6.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 What?! --- Package systemd-units.x86_64 0:4-3.fc14 set to be updated -- Running transaction check --- Package systemd.x86_64 0:4-3.fc14 set to be installed --- Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated -- Processing Dependency: sysvinit-userspace for package: Aand this is the other half of the problem. Change I made before Lennart was around to make a complementary change in the systemd package unfortunately. It shouldn't have caused a big issue except for the really bizzare dependency mentioned above. upstart-0.6.5-7.fc14.x86_64 -- Running transaction check --- Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed -- Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit -- Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit -- Finished Dependency Resolution Error: systemd-sysvinit conflicts with upstart-sysvinit Error: upstart-sysvinit conflicts with systemd-sysvinit You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote: On 7/23/2010 20:26, Lennart Poettering wrote: - You can boot into either of them by setting the init= kernel cmdline option according to your wishes. If you pass init=/bin/systemd you will boot into systemd, if you pass init=/sbin/upstart you will boot into upstart (note the /sbin vs. /bin!) Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
