Re: thanks for F15 mdadm systemd unit
On Wed, 27.07.11 07:40, Genes MailLists (li...@sapience.com) wrote: On 07/27/2011 01:23 AM, Adam Williamson wrote: What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. Be a little wary. This is not really fine - systemd should do one thing and do it well Yupp, that thing is parallelize boot. It's pretty good at that. It now even can parallelize fsck/mount/daemon startup, thanks to the minimalistic support of direct automount points we have in there. How awesome is that? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Wed, 2011-07-27 at 06:43 -0400, Ric Wheeler wrote: What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? [adamw@adam ~]$ rpm -q autofs package autofs is not installed [adamw@adam ~]$ apparently not. I really don't know - all's I know is it works, perfectly, for my simple case, and doesn't delay boot, which is more than any NFS mounting setup I could manage / be arsed to figure out prior to systemd. (also, you owe me a beer for egregious use of the word 'leverage' as a verb. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 06:20 PM, Adam Williamson wrote: On Wed, 2011-07-27 at 06:43 -0400, Ric Wheeler wrote: What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? [adamw@adam ~]$ rpm -q autofs package autofs is not installed [adamw@adam ~]$ apparently not. I really don't know - all's I know is it works, perfectly, for my simple case, and doesn't delay boot, which is more than any NFS mounting setup I could manage / be arsed to figure out prior to systemd. (also, you owe me a beer for egregious use of the word 'leverage' as a verb. :) You have lost that battle long ago, it is in some dictionaries as a verb already :) ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 01:23 AM, Adam Williamson wrote: On Tue, 2011-07-26 at 07:07 -0400, Ric Wheeler wrote: On 07/26/2011 02:15 AM, Adam Williamson wrote: On Sat, 2011-07-23 at 07:24 -0400, Ric Wheeler wrote: should not be surprised that you see resistance (what new capability does NFS get from the systemd changes for example!). reliable on-demand automounting, for a start. for which you already owe Lennart about three kegs of beer, by my calculation. =) (try 'noauto,comment=systemd.automount' as mount parameters for an NFS share) We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 01:23 AM, Adam Williamson wrote: What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. Be a little wary. This is not really fine - systemd should do one thing and do it well ... when it starts to bleed off and try do too many things (with little to zero rationale or benefit) then the chances of things going wrong increase. Just because something 'can' do something does not make it a sensible design. Since systemd is running daemon it could take over any daemon - it could even do everything pulse does :-) Hell any rooted capable daemon process can do the same - autofs could just as easily start other services for that matter ... doesn't make it a good design. Just coz it is doing some mount stuff doesn't mean it should do all mount stuff ... autofs should be left alone to do what it does best. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 11:43 AM, Ric Wheeler wrote: On 07/27/2011 01:23 AM, Adam Williamson wrote: On Tue, 2011-07-26 at 07:07 -0400, Ric Wheeler wrote: We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? It appears to use the kernel autofs support but replaces the userspace daemon (and replaces the traditional automounter map file format with system.automount unit files). I can appreciate a benefit for personal systems from systemd managing network file system mounts since it's in a position to know when the network is up (this has been a problem with /etc/fstab, NFS/CIFS and NetworkManger for some time) but I'm not sure that large deployments with existing autofs infrastructures will be so keen to make the switch. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Wed, Jul 27, 2011 at 01:11:24PM +0100, Bryn M. Reeves wrote: On 07/27/2011 11:43 AM, Ric Wheeler wrote: On 07/27/2011 01:23 AM, Adam Williamson wrote: On Tue, 2011-07-26 at 07:07 -0400, Ric Wheeler wrote: We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? It appears to use the kernel autofs support but replaces the userspace daemon (and replaces the traditional automounter map file format with system.automount unit files). NB they're not mutually exclusive. You can run the regular autofs userspace daemon at the same time as systemd. Systemd will look after any mount points in its unit files, while autofs will look after the mount points from the traditional /etc/auto.master files. They're both just leveraging the same kernel API for automounting. Also systemd is only doing direct autofs mounts, if you want indirect autofs mounts then the regular automount is the one to use. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 05:10 PM, Genes MailLists wrote: Be a little wary. This is not really fine - systemd should do one thing and do it well ... when it starts to bleed off and try do too many things (with little to zero rationale or benefit) then the chances of things going wrong increase. There is rationale and benefit. Read the blog posts from Lennart Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Wed, 27.07.11 06:43, Ric Wheeler (rwhee...@redhat.com) wrote: (try 'noauto,comment=systemd.automount' as mount parameters for an NFS share) We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? systemd uses the kernel interfaces directly. It only does direct mounts, not indirect mounts, and it's all designed to be trivially simple to use (i.e. just add comment=systemd.automount to your fstab options), pulling in no further deps for this, and integrate well with the rest of systemd, i.e. doing the full dependency mumbo-jumbo as soon as an automount is triggered. The idea is that it just works, is tiny, and makes autofs something you want to use without having to think about NIS or LDAP or other configuration maps. (yeah, I know, you don't need NIS/LDAP to configure maps in autofs.) automounting support in systemd is attractive for a number of reasons. The main one is that it allows us to cheaply establish mount points without having to back them with real file systems right-away. That means we can leave the early boot phase much earlier than we traditionally could, since we don't actually need to wait for fsck/mount to complete for all file systems listed in /etc/fstab. This allows us to parallelize fsck/mount and daemon start-up in a fashion previously not possible. This is not necessarily particularly interesting on general purpose systems but on embedded systems it is. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Wed, 27.07.11 13:11, Bryn M. Reeves (b...@redhat.com) wrote: It appears to use the kernel autofs support but replaces the userspace daemon (and replaces the traditional automounter map file format with system.automount unit files). I can appreciate a benefit for personal systems from systemd managing network file system mounts since it's in a position to know when the network is up (this has been a problem with /etc/fstab, NFS/CIFS and NetworkManger for some time) but I'm not sure that large deployments with existing autofs infrastructures will be so keen to make the switch. The traditional autofs installtions tend to focus on indirect mounts, not direct mounts. systemd does not cover indirect mounts, and it is very unlikely that it ever will. Replacing exisiting autofs installations with the built-in systemd stuff is not possible and out of focus for us. Direct automounts: you establish an automount point /home, and on access a file system is mounted to /home. (i.e. if I access /home/lennart the fs will be mounted to /home) Indirect automounts: you establish an automount point /home, and on access of directory beneath it a file system is mounted on it. (i.e. if I access /home/lennart the fs will be mounted to /home/lennart). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Sat, 2011-07-23 at 07:24 -0400, Ric Wheeler wrote: should not be surprised that you see resistance (what new capability does NFS get from the systemd changes for example!). reliable on-demand automounting, for a start. for which you already owe Lennart about three kegs of beer, by my calculation. =) (try 'noauto,comment=systemd.automount' as mount parameters for an NFS share) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/26/2011 02:15 AM, Adam Williamson wrote: On Sat, 2011-07-23 at 07:24 -0400, Ric Wheeler wrote: should not be surprised that you see resistance (what new capability does NFS get from the systemd changes for example!). reliable on-demand automounting, for a start. for which you already owe Lennart about three kegs of beer, by my calculation. =) (try 'noauto,comment=systemd.automount' as mount parameters for an NFS share) We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Tue, 2011-07-26 at 07:07 -0400, Ric Wheeler wrote: On 07/26/2011 02:15 AM, Adam Williamson wrote: On Sat, 2011-07-23 at 07:24 -0400, Ric Wheeler wrote: should not be surprised that you see resistance (what new capability does NFS get from the systemd changes for example!). reliable on-demand automounting, for a start. for which you already owe Lennart about three kegs of beer, by my calculation. =) (try 'noauto,comment=systemd.automount' as mount parameters for an NFS share) We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Thu, 2011-07-21 at 22:01 -0400, Doug Ledford wrote: They have some valid reasons for wanting to avoid the risk of rendering machines inoperable or insecure because something didn't start, but I have to agree with you that the half systemd, half sysv init thing is pretty damn fugly. Well, the design for F15 was pretty much to use systemd as the daemon, but leave all the services as sysv, just as we've been using upstart for years. The only things which were converted to be native were things that it turned out we *had* to convert, because - due to various boring little details about how systemd works - leaving them as sysv-native would have caused significant bugs. the design for f16 is to convert all the 'stock' services you get with a default install, and on the live image (aiui). how else could we do it? it would be impractical to convert every single service in the entire distro in a single six month cycle. unless you're volunteering. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
R: Re: thanks for F15 mdadm systemd unit
Messaggio originale Da: drago01 Inviato: 22/07/2011, 19:16 A: Development discussions related to Fedora Oggetto: Re: thanks for F15 mdadm systemd unit On Fri, Jul 22, 2011 at 4:53 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.07.2011 16:33, schrieb drago01: On Thu, Jul 21, 2011 at 1:38 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years this is poor argumentation which too many peopole follow unreflected Its not any poorer then it has been like that for 28 years so don't dare to change it. Where the sole reason for this kind of arguments seem to be I can't/don't want to learn anything new ... which is really tiresome. Working with technology like this requires change and / or learning something new at some point. You cant just get used to one thing and think you can stick to that for the rest of your life. -- 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: thanks for F15 mdadm systemd unit
On 07/23/2011 11:24 AM, Ric Wheeler wrote: What I think that you and others are not given credit is that most upstream maintainers have very long lists of things to do. The NFS team is swamped doing support for pNFS (version 4.1) and has been going through massive change for example. And? I think you and others fail to understand is that we too are very busy as well and given your responce I see now how this game is played I guess you are the only one who's allowed to be busy When you have a very invasive feature that requires the entire world to change and brings no domain specific advantages to users of impacted subsystems, you should not be surprised that you see resistance (what new capability does NFS get from the systemd changes for example!). Seriously am I supposed to play that dance yet again the merits over the legacy sysv init system as been explained to death more then once. Converting the nfs legacy sysv init script to native systemd one is not a technical problem nor requires any code changes to the nfs code base it's a human one and there is no point for me trying to explain things to an indvidual that is not willing to listen that is just a waste of my time which is better spent with people that actually are willing to listen, learn adapt and move on. And it's just going to make my day that if the only component that requires absolutely no code changes is going to block the alpha release because the maintainer refused to get with the program and make the changes like everyone else all because he did not want to inconvenient the little sysadmin. That is where you need to use charm and persuasion to move things along :) Encase you have not noticed thou I'm pretty sure everyone else has, the score on charisma on my character sheet is relatively low and given that I'm not a lucky man especially with dices then it should be pretty obvious that I wont be charming anyone... ;) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Sat, 2011-07-23 at 00:09 +, Jóhann B. Guðmundsson wrote: On 07/22/2011 05:02 PM, Ric Wheeler wrote: I don't have it backwards - my day job is to work on exactly getting this kind of cutting edge feature out to end users. Which feature of this magnitute have you put out to your users? Serously if you have some motivation tips to get things moving I and others would gladly like to hear them.. When you propose and implement a massive change, you need to make sure that the system as a whole still works. Certanly. Of course, the developers of code components *should* work with the systemd team, but if they don't (don't like it, have higher priorities, whatever), then the proponents of change need to do the heavy lifting. Heavy lifting can involve education, convincing others in a *nice* way or actually having to do the code. Regarding your education response we have man pages upstream documentation Lennart's blog posts and various interviews he has done along with very active upstream mailings and irc channel and if man pages or other documentation are *vague* about any issue only thing people need to do is ask. You don't receive answers if you don't ask and we can't force knowledge upon people or have them to educate themselves. Regarding your convincing people this is the third release cycle that we have to act nice repeat answers to both end users sysadmins and developers alike and at the same time be our work ridiculed belittled and we subdued to personal attacks. Brace yourself, I think you should take it with philosophy and expect the same to continue for another 3 releases. Changes that re this disruptive upset many, take a deep breath and don't take it personally even when people attack you. If you do otherwise you'll only have a bad life and nothing else. You may think third time is the charm and I honestly don't how Lennart does cope with this but I decided to draw the nice line here the third release cycle we are put through this. As much as I would like us to have the authority to do the code that unfortunately wont cut it since we lack the expertise, the experience and insight that maintainers have through maintaining their component so having us walsing in and do the conversion might actually be doing more harm then good however working together will deliver the best result. That's where's Ric suggestion comes into place. You have to go a knock to the door of these developers and have a discussion to let them understand the importance of the work to be done. It is time consuming and sometimes awkward but you gotta do it. We simply cannot ship something that would lose data or cause critical components to fail for our users. I completly agree and from my pov it's like maintainers do not understand how important that is for us to manage to convert all the 500 - 600 daemons in one release cycle. Beside the obvious unfortinate experience our user may go through like the one Reindl Harald and perhaps others have experienced then this may also break and hinder work for other developers that build their application stack on top of those daemons. One such example is the freeipa stack where the freeipa team needs to rewrite/replace and or add seperated systemd spesific code and if I'm not mistaken they will only support sysv on sysv platforms and systemd on systemd platforms instead of trying to support mixed match of both init system ( Freeipa guys feel free to correct me if I'm wrong ). That's the plan supporting a mix seems too difficult. Freeipa is built on top of 389 Directory Server, MIT Kerberos, NTP, DNS,and Dogtag ( which I dont recall having any daemons ) of that only the NTP has been converted work is being done on converting 389 and I think the native systemd units for freeipa server daemons are ready but they are not being shipped yet however that leaves out bind and mit kerberos with no movement what so ever on those two components atleast there has been no respons on the relevant bug report for those two components as is with so many others and I have not heard a word from either of those maintainers on irc. We'll get those components converted in time hopefully we (FreeIPA) are in close contact with both the MIT Kerberos and Bind maintainers. What you forgot there is that Dogtag is not daemonless, on the countrary it depends on Tomcat, which looks like a mess to convert to systemd. Tomcat seem to be the bit that may stall the whole conversion to be honest. The other issue we have is that we need to dynamically generate the list of service when the first component (dirsrv) starts, as we keep the list of active services per FreeIPA server in LDAP. But we seem to have a solution for that, more or less... Now their new code depends on all of those components to be converted and it does not take more then one of those components to not convert and their whole work
Re: thanks for F15 mdadm systemd unit
On Thu, Jul 21, 2011 at 1:38 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 22.07.2011 04:01, schrieb Doug Ledford: They have some valid reasons for wanting to avoid the risk of rendering machines inoperable or insecure because something didn't start and while making a dist-upgrade to F16 where the whole system is changed comes a helping angel or god himself holding our hands and then nothing will go wrong? have you ever heard release early, release often? greetings to QA, release early works well, but the release often to fix with the early thing introduced bad behavior is since a long time forgotten and has probably died but I have to agree with you that the half systemd, half sysv init thing is pretty damn fugly this is simply unacceptable and such things must not go GA not in business world nor in free software normally in free software world i heard it is released when it is ready seems this times are over abd marketing has won :-( signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 22.07.2011 16:33, schrieb drago01: On Thu, Jul 21, 2011 at 1:38 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years this is poor argumentation which too many peopole follow unreflected with your argumentation we could throw away ls, touch, grep, find and thousands of other tools which will be working the next 28 years as long peopole not start breaking any backward-compatibility just for fun if you like this credo you are the perfect customer for Apple Inc. i am using linux because it is NOT Apple and NOT Microsoft for the same reason i use KDE and not a Mac or GNOME where the developers think reduce options is coll because their users are to dumb to use them what results in getting users which are really to dumb sooner or later because they never learned to really use a computer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/22/2011 10:53 AM, Reindl Harald wrote: Am 22.07.2011 16:33, schrieb drago01: On Thu, Jul 21, 2011 at 1:38 PM, Reindl Haraldh.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years this is poor argumentation which too many peopole follow unreflected with your argumentation we could throw away ls, touch, grep, find and thousands of other tools which will be working the next 28 years as long peopole not start breaking any backward-compatibility just for fun if you like this credo you are the perfect customer for Apple Inc. i am using linux because it is NOT Apple and NOT Microsoft for the same reason i use KDE and not a Mac or GNOME where the developers think reduce options is coll because their users are to dumb to use them what results in getting users which are really to dumb sooner or later because they never learned to really use a computer I completely support moving to new technology and think that systemd is quite attractive in many ways. That said, we must insure that critical services all work, especially for storage and file systems where screws will lose data and we will end up losing users. MD, NFS, clustering have complicated and complex needs. The systemd team - not just the developers of those subsystems - need to be directly engaged and proactive in getting all of these critical systems converted cleanly Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/22/2011 04:37 PM, Ric Wheeler wrote: MD, NFS, clustering have complicated and complex needs. The systemd team - not just the developers of those subsystems - need to be directly engaged and proactive in getting all of these critical systems converted cleanly I think you actually got this backwards the developers of those subsystems not just the systemd team that needs to be directly engage and proactive in getting all of these critical systems converted cleanly anyway the end result is the same we need to work together to convert to systemd cleanly. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/22/2011 12:47 PM, Jóhann B. Guðmundsson wrote: On 07/22/2011 04:37 PM, Ric Wheeler wrote: MD, NFS, clustering have complicated and complex needs. The systemd team - not just the developers of those subsystems - need to be directly engaged and proactive in getting all of these critical systems converted cleanly I think you actually got this backwards the developers of those subsystems not just the systemd team that needs to be directly engage and proactive in getting all of these critical systems converted cleanly anyway the end result is the same we need to work together to convert to systemd cleanly. JBG I don't have it backwards - my day job is to work on exactly getting this kind of cutting edge feature out to end users. When you propose and implement a massive change, you need to make sure that the system as a whole still works. Of course, the developers of code components *should* work with the systemd team, but if they don't (don't like it, have higher priorities, whatever), then the proponents of change need to do the heavy lifting. Heavy lifting can involve education, convincing others in a *nice* way or actually having to do the code. We simply cannot ship something that would lose data or cause critical components to fail for our users. Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Fri, Jul 22, 2011 at 4:53 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.07.2011 16:33, schrieb drago01: On Thu, Jul 21, 2011 at 1:38 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years this is poor argumentation which too many peopole follow unreflected Its not any poorer then it has been like that for 28 years so don't dare to change it. Where the sole reason for this kind of arguments seem to be I can't/don't want to learn anything new ... which is really tiresome. Working with technology like this requires change and / or learning something new at some point. You cant just get used to one thing and think you can stick to that for the rest of your life. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/22/2011 01:16 PM, drago01 wrote: On Fri, Jul 22, 2011 at 4:53 PM, Reindl Haraldh.rei...@thelounge.net wrote: Am 22.07.2011 16:33, schrieb drago01: On Thu, Jul 21, 2011 at 1:38 PM, Reindl Haraldh.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years this is poor argumentation which too many peopole follow unreflected Its not any poorer then it has been like that for 28 years so don't dare to change it. Where the sole reason for this kind of arguments seem to be I can't/don't want to learn anything new ... which is really tiresome. Working with technology like this requires change and / or learning something new at some point. You cant just get used to one thing and think you can stick to that for the rest of your life. I don't think there would be so much push back if it was painless to people and didn't break things. I know it is very frustrating to me when stuff that worked now all of sudden doesn't because somebody decided that we have better, faster, newer way of doing things so lets do it! Sound in fedora a few years ago under went this exact scenario and it took a couple of releases for me before it became somewhat stable again. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 22.07.2011 19:16, schrieb drago01: On Fri, Jul 22, 2011 at 4:53 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.07.2011 16:33, schrieb drago01: On Thu, Jul 21, 2011 at 1:38 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now Still way too old ... technology has advanced a lot in the past 28 years this is poor argumentation which too many peopole follow unreflected Its not any poorer then it has been like that for 28 years so don't dare to change it. Where the sole reason for this kind of arguments seem to be I can't/don't want to learn anything new ... which is really tiresome. Working with technology like this requires change and / or learning something new at some point. You cant just get used to one thing and think you can stick to that for the rest of your life you do not know anything what i am learning and working every day i am learning, optimizing and rewriting software all day long but not with a good reason or if some liked improvement is not bigger than the bad things coming with it if fedora as distribution decides to change things than the distribution with ALL packages have to be fixed / improved why? normally a user can not rebuild / fix packages if things worked for a long time and after replacing them packages of the distribution are broken this is not really my area - it should not happen learning: THIS is the state of learning on fedora/redhat-side, a little late! * https://bugzilla.redhat.com/show_bug.cgi?id=714426#c33 * https://bugzilla.redhat.com/show_bug.cgi?id=714426#c33 * https://bugzilla.redhat.com/show_bug.cgi?id=714426#c40 NOBODY has clear ideas what the guidelines are saying and F15 is GA since a longer time https://bugzilla.redhat.com/show_bug.cgi?id=714426#c47 so please do not tell me what is tiresome i tell you: a release like F15 is tiresome topic learning: as long the whole distribution is a wild mix of systemd/lsb/sysvinit there is nothing to learn because the whole system is currently diry in my eyes and after ALL fedora packages using the from fedora decided init-system and all the bugs going with this are fixed starts the time to learn for users currently many packagers seems to be in a early learning state, but no probmem we release unfinished things, break basiscs like df and writing guidelines for unbaken cakes - wonderful! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Fri, 22 Jul 2011 19:48:29 +0200 Reindl Harald wrote: and the same guy who pushed pulseaudio in a total unuseable state to fedora instead finish his work and push it after that does is the maintainer of systemd - so maybe if we would not have the expierience how long it takes until the things are working as expected we would not be so hard with our comments his attitude in case of usability is sometimes strange https://bugzilla.redhat.com/show_bug.cgi?id=714525#c3 Hey, that's my comment and it shows no attitude at all. It's a completely neutral question with the purpose to understand what the problem is. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 22.07.2011 23:18, schrieb Michal Schmidt: On Fri, 22 Jul 2011 19:48:29 +0200 Reindl Harald wrote: and the same guy who pushed pulseaudio in a total unuseable state to fedora instead finish his work and push it after that does is the maintainer of systemd - so maybe if we would not have the expierience how long it takes until the things are working as expected we would not be so hard with our comments his attitude in case of usability is sometimes strange https://bugzilla.redhat.com/show_bug.cgi?id=714525#c3 Hey, that's my comment and it shows no attitude at all. It's a completely neutral question with the purpose to understand what the problem is. sorry - yes THIS is your comment but i know many answers of Lennart in contect of systemd which are unacceptable and showing that he means that the world should be turned around systemd and all existing things which do not work as clean as they did before systemd are faulty and have to be fixed look at my othe rpoints from today - this are all things which were never a problem now we are some months after F15/systemd and they are still dirty, ugly or call it waht you like signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
I'd like to suggest: a) Please avoid getting personal, stick to technical arguments/issues. b) Is there any further useful discussion to be had in this thread? Perhaps it's time to give it a rest for the weekend (or longer). kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 23.07.2011 00:17, schrieb Kevin Fenzi: I'd like to suggest: a) Please avoid getting personal, stick to technical arguments/issues. it is not my intention to get personally and hurt anybody as person, really! i try to get borked things fixed which i can not fix by myself and had to learn that things are only changed if they are hurting enough people believe me, there are thousands of users out there which are perfectly happy with F14 in different environemnts and waiting until F14 is EOL for upgrading to F15 in the hope most of things are fixed until then b) Is there any further useful discussion to be had in this thread? Perhaps it's time to give it a rest for the weekend (or longer) no problem, no rush NOW but the time goes fast and F14-EOL will affect users in many ways what i hardly need is a relieable mysqld in a way that every service (and not only shipped with fedora ones) will 100% start clean and much more feedback of systemctl after that is clean and there is a way to backport to F15 i am partly happy, but as long systemctl start some.service wil give no feedback if the start was sucessful or not this is not acceptable for me because in the time typing systemctl status some.service i ccould start to think and look why it has failed and i think you will also agree that it is boring restart a machine over Lights-Out-Managment with some TB disks and the beast starts filesystem-check without feedback and you can not hear if the machine is frozen or still working, for someone this might be a little probmem - for a perfectionist it is unacceptable __ the myslqd.service/mysqld.socket MUST working perfectly and after that i am much more relaxed than now because my whole work of the last 10 years depends on that and tjere was no single problem until systemd came in my life https://bugzilla.redhat.com/show_bug.cgi?id=714426 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/22/2011 05:02 PM, Ric Wheeler wrote: I don't have it backwards - my day job is to work on exactly getting this kind of cutting edge feature out to end users. Which feature of this magnitute have you put out to your users? Serously if you have some motivation tips to get things moving I and others would gladly like to hear them.. When you propose and implement a massive change, you need to make sure that the system as a whole still works. Certanly. Of course, the developers of code components *should* work with the systemd team, but if they don't (don't like it, have higher priorities, whatever), then the proponents of change need to do the heavy lifting. Heavy lifting can involve education, convincing others in a *nice* way or actually having to do the code. Regarding your education response we have man pages upstream documentation Lennart's blog posts and various interviews he has done along with very active upstream mailings and irc channel and if man pages or other documentation are *vague* about any issue only thing people need to do is ask. You don't receive answers if you don't ask and we can't force knowledge upon people or have them to educate themselves. Regarding your convincing people this is the third release cycle that we have to act nice repeat answers to both end users sysadmins and developers alike and at the same time be our work ridiculed belittled and we subdued to personal attacks. You may think third time is the charm and I honestly don't how Lennart does cope with this but I decided to draw the nice line here the third release cycle we are put through this. As much as I would like us to have the authority to do the code that unfortunately wont cut it since we lack the expertise, the experience and insight that maintainers have through maintaining their component so having us walsing in and do the conversion might actually be doing more harm then good however working together will deliver the best result. We simply cannot ship something that would lose data or cause critical components to fail for our users. I completly agree and from my pov it's like maintainers do not understand how important that is for us to manage to convert all the 500 - 600 daemons in one release cycle. Beside the obvious unfortinate experience our user may go through like the one Reindl Harald and perhaps others have experienced then this may also break and hinder work for other developers that build their application stack on top of those daemons. One such example is the freeipa stack where the freeipa team needs to rewrite/replace and or add seperated systemd spesific code and if I'm not mistaken they will only support sysv on sysv platforms and systemd on systemd platforms instead of trying to support mixed match of both init system ( Freeipa guys feel free to correct me if I'm wrong ). Freeipa is built on top of 389 Directory Server, MIT Kerberos, NTP, DNS,and Dogtag ( which I dont recall having any daemons ) of that only the NTP has been converted work is being done on converting 389 and I think the native systemd units for freeipa server daemons are ready but they are not being shipped yet however that leaves out bind and mit kerberos with no movement what so ever on those two components atleast there has been no respons on the relevant bug report for those two components as is with so many others and I have not heard a word from either of those maintainers on irc. Now their new code depends on all of those components to be converted and it does not take more then one of those components to not convert and their whole work is being thrown out the window and they are forced to rewrite their code to support a mixed batch of sysv legacy scripts and native systemd units and they have the time from from Beta to GA to test that code on that mixed batch of init files which at the same time those unit files might be subdued to various testing and rewriting as an indvidual standalone services. See my point on how vital it can be to convert to those unit files as soon as possible and that's just one application stack built on top of five components. The main problem here are the maintainers that do not respond to the bug report or when I ping them on irc because then I dont get the status from them which in turn FESCO wont either since I deliver them progress report on each meeting along with keeping [1] updated. I'm not asking for much of maintainers *valuable* time (apparently others people time does not matter here. We are all busy with work life and what not, expecial those of us that are not working full time on fedora and are doing this work on our freetime and apparently it's not considered rude on maintainers behalf to not respond to bug reports to the people reporting them ) only that they respond if they are looking at this or not or will be after a week for that matter. ( which is like minute of two
Re: thanks for F15 mdadm systemd unit
On Thu, 2011-07-21 at 13:38 +0200, Reindl Harald wrote: in the past there were real developers which was able to ah, the True Scotsman rears its head! -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now the last ten years subsystems are coming and going every incarnation/replacment is hyped as so much better, has a lot of bugs which are fixed over some years and if most of them are fixed the next guy thinks he has a better replacement in the past there were real developers which was able to maintain and optimize code over a long time without permanently break backward-compatible, these days people start to throw away and begin from scratch in the hope they will not make old mistakes and suboptimal software-design again what is true, they all make a lot of new/other mistakes and as d said - as soon as they fixed it is called outdated and will be replaced again signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/21/2011 07:38 AM, Reindl Harald wrote: Am 21.07.2011 13:14, schrieb Bryn M. Reeves: On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). so let it be 28 years now the last ten years subsystems are coming and going every incarnation/replacment is hyped as so much better, has a lot of bugs which are fixed over some years and if most of them are fixed the next guy thinks he has a better replacement in the past there were real developers which was able to maintain and optimize code over a long time without permanently break backward-compatible, these days people start to throw away and begin from scratch in the hope they will not make old mistakes and suboptimal software-design again what is true, they all make a lot of new/other mistakes and as d said - as soon as they fixed it is called outdated and will be replaced again +100 -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/20/2011 4:13 PM, Jeff Spaleta wrote: On Wed, Jul 20, 2011 at 12:06 PM, Doug Ledford dledf...@redhat.com wrote: Unfortunately, I was told I should remove the systemd support in particular, so I did. Glad to hear it worked for you though ;-) You mean in F15? Or do you mean in rawhide as well? I just pulled it from f15. I was told to remove it because it's critical path, which isn't entirely true. The sysv init part is the monitoring, not the bring up, so it wouldn't render anyone's machine unbootable, they would just need to make sure monitoring was up and running (well, the mdmon handover part is pretty necessary on imsm arrays, but that's a whole other topic). - -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4o2ZsACgkQQ9aEs6Ims9gulACgt+bU5rpnpjR9/5q+6JYKKKa5 fsQAoNMPu9SuBKyeEe8nr5IehyvWczsi =0q75 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/20/2011 6:05 PM, Reindl Harald wrote: Am 20.07.2011 22:06, schrieb Doug Ledford: On 07/15/2011 05:20 PM, Reindl Harald wrote: http://koji.fedoraproject.org/koji/buildinfo?buildID=253031 * Fri Jul 15 2011 Doug Ledforddledf...@redhat.com - 3.2.2-5 - Merge rawhide mdadm to f15. Rawhide changelog preserved even though - the referenced versions do not exist in f15, rawhide specific builds - are from 3.2.1-1 through 3.2.2-4 FYI: works on my F15 machine as expected, thank you! Unfortunately, I was told I should remove the systemd support in particular, so I did. Glad to hear it worked for you though ;-) i noticd with real anger and was able to restore the systemd-files from my second machine before update there Sorry about that. I just does what the man tells me. it makes me really sad to see that F15 was released as a br**ead mix auf sysv/lsb/systemd and there is no way to get this clean without making all yourself They have some valid reasons for wanting to avoid the risk of rendering machines inoperable or insecure because something didn't start, but I have to agree with you that the half systemd, half sysv init thing is pretty damn fugly. - -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4o2gMACgkQQ9aEs6Ims9j5FgCgkrKP1T0iYmj/sLgBRg7u8gHa WogAoOhc0j9+P0J/5tLzAs6lCyVRUS2G =nZj5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/15/2011 05:20 PM, Reindl Harald wrote: http://koji.fedoraproject.org/koji/buildinfo?buildID=253031 * Fri Jul 15 2011 Doug Ledforddledf...@redhat.com - 3.2.2-5 - Merge rawhide mdadm to f15. Rawhide changelog preserved even though - the referenced versions do not exist in f15, rawhide specific builds - are from 3.2.1-1 through 3.2.2-4 FYI: works on my F15 machine as expected, thank you! Unfortunately, I was told I should remove the systemd support in particular, so I did. Glad to hear it worked for you though ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On Wed, Jul 20, 2011 at 12:06 PM, Doug Ledford dledf...@redhat.com wrote: Unfortunately, I was told I should remove the systemd support in particular, so I did. Glad to hear it worked for you though ;-) You mean in F15? Or do you mean in rawhide as well? Id be interested in using unofficial F15 systemd enabled packages if there was some need to test on F15 systems as well as rawhide. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
Am 20.07.2011 22:06, schrieb Doug Ledford: On 07/15/2011 05:20 PM, Reindl Harald wrote: http://koji.fedoraproject.org/koji/buildinfo?buildID=253031 * Fri Jul 15 2011 Doug Ledforddledf...@redhat.com - 3.2.2-5 - Merge rawhide mdadm to f15. Rawhide changelog preserved even though - the referenced versions do not exist in f15, rawhide specific builds - are from 3.2.1-1 through 3.2.2-4 FYI: works on my F15 machine as expected, thank you! Unfortunately, I was told I should remove the systemd support in particular, so I did. Glad to hear it worked for you though ;-) i noticd with real anger and was able to restore the systemd-files from my second machine before update there it makes me really sad to see that F15 was released as a br**ead mix auf sysv/lsb/systemd and there is no way to get this clean without making all yourself hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
thanks for F15 mdadm systemd unit
http://koji.fedoraproject.org/koji/buildinfo?buildID=253031 * Fri Jul 15 2011 Doug Ledford dledf...@redhat.com - 3.2.2-5 - Merge rawhide mdadm to f15. Rawhide changelog preserved even though - the referenced versions do not exist in f15, rawhide specific builds - are from 3.2.1-1 through 3.2.2-4 FYI: works on my F15 machine as expected, thank you! Starting Software RAID Monitor Takeover... Starting Software RAID monitoring and management... Started Software RAID Monitor Takeover. Started Software RAID monitoring and management. root41 0.0 0.0 0 0 ?S 23:12 0:00 [md] root66 0.0 0.0 0 0 ?SN 23:12 0:00 [ksmd] root 429 0.0 0.0 0 0 ?S23:12 0:00 [md0_raid1] root 440 0.0 0.0 0 0 ?S23:12 0:00 [md1_raid10] root 457 0.0 0.0 0 0 ?S23:12 0:00 [md2_raid10] root 487 0.0 0.0 0 0 ?S23:12 0:00 [jbd2/md1-8] root 938 0.0 0.0 0 0 ?S23:13 0:00 [jbd2/md0-8] root 951 0.0 0.0 0 0 ?S23:13 0:00 [jbd2/md2-8] root 1040 0.0 0.0 6900 628 ?Ss 23:13 0:00 /sbin/mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid Personalities : [raid1] [raid10] md2 : active raid10 sda3[0] sdd3[3] sdc3[2] sdb3[1] 3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [] bitmap: 0/29 pages [0KB], 65536KB chunk md1 : active raid10 sda2[0] sdd2[3] sdc2[2] sdb2[1] 30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [] bitmap: 0/1 pages [0KB], 65536KB chunk md0 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1] 511988 blocks super 1.0 [4/4] [] unused devices: none signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
