There is dash ( http://en.wikipedia.org/wiki/Debian_Almquist_shell ) and ash-static which - I believe - is the same thing. There is also, of course, busybox. It seems to me that having something like busybox or ash (static) as a shell-of-last-resort is not a horrible idea. On Mon, Apr 1, 2013 at 3:33 PM, Greg Freemyer wrote:

On Mon, Apr 1, 2013 at 4:08 PM, Linda Walsh wrote:

...

I had a problem a few weeks ago where I was having libc problems booting off a rescue disk -- used to be I could usually boot from a rescue disk, mount root on /mnt, chroot /mnt, mount the rest, and look at startup scripts 1-by-1.

Now that doesn't come close to working. But even when I got the paths set right (LDLLIBPATH) etc... BASH/DASH/SH/ were still having problems loading due to suse's adding OW's patches that make linked binaries incompat with standard libc/glibc I.e. -- instead of a dynamic load of OW, and giving reduced functionality, it was hardcoded in to prevent anything from working. Ok... so I thought -- AH

Standalone shell... it doesn't depend on anything.

SURPRISE -- it's now dynamically linked with a custom libc as well...so it wouldn't work either!

Um...

FAIL!!!!

SASH is called SASH because it is supposed to be Stand-Alone and need no libs to link as well as having builtin basic commands:

Manpage: DESCRIPTION The sash program is a stand-alone shell which is useful for recovering from certain types of system failures. In particular, it was created in order to cope with the problem of missing shared libraries or impor- tant executables. ^^^^^^^^^^^^^^^^^^^^^^^^

Um...HELLO... breaking basic functionality?

Had a bitch of a time recovering since xfsdump bumped it's version num to '3' to correct several kernel bugs. For some reason my xfsrestore's even from the disk kept saying '2'... Well it appears I couldn't run xfsrestore from any repair disk as they all had v2 of the libs (v3 appeared in mid Jan). But I couldn't link with the new versions on disk due to libc problems.

Finally was able to rebuild xfs from git running on the repair disk and install xfsrestore onto the repair disk where the libc wasn't corrupted with a non-standard OW extension.

But, that was an aside. Um...main beef .. NOT EVEN SASH?!?! statically linked?

system recovery tools like xfsrestore likely should be too (as an afterthough/aside)...

Linda,

Can't say I've ever worked with sash, but per the changes file it has to dynamically link with libc:

== Wed May 6 15:44:12 CEST 2009 - crrodriguez@suse.de

- while using static libz will work, using static libc wont, due to the use of getgrgid, getgrnam, getpwnam and getpwuid. ==

That's from 4 years ago, so maybe upstream has a fix for that by now. I checked and Fedora doesn't have sash package, so maybe they dropped it since it doesn't build statically anymore.

The home page for the project is http://members.tip.net.au/~dbell/

It doesn't look like there has been an update in 6 years or so. As it stands, I don't see a value in the project, so it seems someone needs to either fix it to be static or drop it.

Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer wrote:

Linda,

Can't say I've ever worked with sash, but per the changes file it has to dynamically link with libc:

--- I hadn't either -- much, but remembered it was supposed to be a last-resort tool... my surprise...

Wed May 6 15:44:12 CEST 2009 - crrodriguez@suse.de

- while using static libz will work, using static libc wont, due to the use of getgrgid, getgrnam, getpwnam and getpwuid. ==

---- Great... if I could reached the CHANGES file (on an unmountable partition due to libc being out of commission)...that would have helped... NOT! Why do getgrgid geeetgrnam getpwnam and getpwuid not build static? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El lun 01 abr 2013 18:56:56 CLST, Cristian Rodríguez escribió:

El 01/04/13 18:23, Linda Walsh escribió:

...

Why do getgrgid geeetgrnam getpwnam and getpwuid not build static?

This is by design, it is intended that way.

see http://www.akkadia.org/drepper/no_static_linking.html bullet points 4 and 5 but I suggest you to read the whole article. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 17:50, Jon Nelson escribió:

There is dash ( http://en.wikipedia.org/wiki/Debian_Almquist_shell ) and ash-static which - I believe - is the same thing. There is also, of course, busybox. It seems to me that having something like busybox or ash (static) as a shell-of-last-resort is not a horrible idea.

Not really, people should just jump into the initrd. If libc is broken nothing will work, your are screwed and that 's the end of the story. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 19:12, Linda Walsh escribió:

I had the standard libc from gnu... latest and greatest -- with complete backwards compat -- just like I told was needed/provided with it... Of course none of the SuSE apps are backwards compat with libc... but hey...can't have everything right?

We have explained to you countless times that there is nothing wrong with libc compatibility ..ad-naseum, stop making stuff up. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 01/04/13 19:29, Linda Walsh escribió:

Show me a reliable source. Not some ranting page.

That's a reliable source, that page was written by Ulrich Drepper, that is the guy who wrote most of actual glibc code. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2 Apr 2013 00:33, Cristian Rodríguez wrote:

El 01/04/13 19:29, Linda Walsh escribió:

...

Show me a reliable source. Not some ranting page.

That's a reliable source, that page was written by Ulrich Drepper, that is the guy who wrote most of actual glibc code.

I know Ulrich since around 1997. He can rant, and he has done so. To be fair, that page was originally written when there was a fad of statically linking nearly ever thing. For a up and running system, with out the "super SUSE special" add-ins, he is still right. Recovery tools are an whole other beast. Every system should have ONE fully static shell for this case. Busybox can be linked fully statically against some other libc (non-gnu), as it will be just one binary file, the hype should not be about a non-gnu libc, but about a fully functionally static standalone shell for recovery. Back to the original point: keeping non-static sash(-static) makes no sense, a replacement is needed. - Yamaban.

On Tue, 2 Apr 2013 01:02, Cristian Rodríguez wrote:

El 01/04/13 19:48, Yamaban escribió:

...

On Tue, 2 Apr 2013 00:33, Cristian Rodríguez wrote:

...

El 01/04/13 19:29, Linda Walsh escribió: [snip] Recovery tools are an whole other beast.

Every system should have ONE fully static shell for this case.

I don't think so, for rescue, the boot process should stop and switch root into the initrd, where you can find a working shell. if the initrd is the broken piece, then you will have to boot with a live cd/dvd/usb to fix the system.

Remember how the initrd is build: broken system, broken initrd. Murphy will really be your bossom friend with such thinking. The availibity of such a extern "rescue media" is diametral to the need of such. - Yamaban. PS: Just how old is the disk in your system? Murphy greets you. PPS: I'm not bitter, just jaded by reality.

On Tuesday 2013-04-02 00:48, Yamaban wrote:

Every system should have ONE fully static shell for this case.

What's the point of having a working shell if you can't call (m)any programs? It is far easier to procure some rescue environment on the same machine. There are various options; I for example keep the installer's kernel+initrd (~39MB) in /boot from which I can load the official rescue image over network. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

El 01/04/13 20:50, Jan Engelhardt escribió:

that's exactly right, to do almost any kind of meaningful repair you need to execute binaries that are dynamically linked, not only to libc but to other different libraries. (libz, lzma, crypto and long etc..)

A modern linux system just does not work in the old-fashioned way that having a shell around was a get-out-of-jail card for mistakes.

By modern, you mean any that are ~ suse 12.2 or later, or about a year old? It's not like it had to be designed that way, but some real bonehead decisions went into to make it so -- like putting in forward symlinks on partitions to ones that aren't mounted yet -- vs. the other way around. Things like that would have gotten most admins severely chastised at one point in time, yet now, distro's do it to cover up bad program design... Or, um yeah.. moving any and all recovery tools off of root to 2ndary partition... Or not having a clue why glibc can't be build statically for files in /bin or /sbin (or some of them anyway?)... Or not having a systemd that supports booting -- only loading system services? (and shoving the rest into hiding in a ramdisk that people are expected/required to use).... Can anyone name the benefits of putting the files that used to be in /bin in /usr/bin and replacing them with symlinks? Same for /sbin and /lib64 that couldn't have been solved by putting the originals in the root dirs and symlinks in /usr? Still haven't seen a good reason for requiring dynamic linking of the libc routines getXXX when the network is down and services aren't running. It's not like NIS/NSS/NSCD/winbind or such are actually working then. an SELINUX system should have a static lib for it's recovery tools. One likely wouldn't want to an SELINUX system w/o it's protections in place if you had a need for that type of system. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

It can link statically.. but dynamic linking is required for certain functionality, this is a design decision, it is the same in all distributions.

1) What functionality? What functionality is needed BEFORE the network is turned on, or Before the the disks are mounted? 2) Realize not all users need said functionality. No NSS/NIS/LDAP here... I do try to use winbind... but not always, because samba-windows don't always play nice. 3) The functionality you want to provide could be provided in run-time loadable binaries -- so they only memory usage would be for those services the user actually is using!

...

Or not having a systemd that supports booting --

Systemd is not a bootloader, however it does interface with UEFI bootloader "gummiboot".

---- That's nice for those wanting to convert to UEFI boot, however, for the majority of users *now*, you required a hack in order to boot.

...

system services? (and shoving the rest into hiding in a ramdisk that people are expected/required to use)....

Yes, an initrd is required, this is also on purpose, a design decision to make maintenance and development of the distribution easier, developer time and resources are limited.

You required it because of the switch to systemd -- This is so typical of suse -- switching to new techs and having to drop support for old techs that people use -- because the new tech's don't support or don't work with the old. GRUB/XFS was the same way. XFS was default choice for FS for a short while, then grub came with it's buggy live-disk modifies that took XFS out of action -- no longer recommended as a boot FS, etc...

...

Can anyone name the benefits of putting the files that used to be in /bin in /usr/bin and replacing them with symlinks? Same for /sbin and /lib64 that couldn't have been solved by putting the originals in the root dirs and symlinks in /usr?

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

---- Yeah... Been there, got the : ERROR The requested URL could not be retrieved The following error was encountered while trying to retrieve the URL: ' http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge Zero Sized Reply ---- The argument was baseless -- nothing could be said that couldn't be turned around, switching the places of /usr and /, EXCEPT, moving to /usr would be certain to cause compatibility problems, where as moving everything to /bin or /sbin, would be far less likely to cause problem (space maybe?, but if /usr wasn't already on your rootfs, you were screwed.

...

Still haven't seen a good reason for requiring dynamic linking of the libc routines getXXX when the network is down and services aren't running.

So you did not really read anything on the link I sent to you, or most likely you dont want to listen.

Did you read my response? I can't replace a DSO without 100 apps complaining that they need some 'SPECIAL' version of the DSO.... I can't upgrade to a newer fixed version that I want to install, I'm on your HOOK -- I'm not allowed to upgrade my libs, I have to wait for a suse patch. Worse, I'm not even allowed to upgrade from suse packages from different versions!... (or so some, including you have told me). You break the 1st reason for having dynamic libs unless they come from you. None of the other stuff he wrote is important if you are in single user. Saving memory? It's running in 'S' or '1'. Security problems? I'm not connected to a network (yet). That page is very Dated..... over 2 years old (2.5 years). If it was that great of a 'meme', why hasn't anyone else spoken up in support showing further support?... a lone wolf posting in 2010.... people don't know how to apply critical thinking skills. Just like [g]vim that supports perl/python & ruby scripting can be build without any of those libraries linked in -- and you can have any of those libs, that you don't use not even present on your system -- but [g]vim still *WORKS* -- THAT's the part you don't seem to understand. Even when your dynamic features aren't working, the product can still work well enough to engage in repair/restore work. But there's nothing in glibc that couldn't be offered via loadable plugins like pam, samba, bash or dovecot (or many other products use) -- even the kernel has run-time config based on what you need. Why not glibc? Now will you read this one? The only reason I speak strongly about these things is I KNOW they can be better. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Apr 2, 2013 at 3:07 AM, Linda Walsh wrote:

I can't replace a DSO without 100 apps complaining that they need some 'SPECIAL' version of the DSO.... I can't upgrade to a newer fixed version that I want to install, I'm on your HOOK -- I'm not allowed to upgrade my libs, I have to wait for a suse patch. Worse, I'm not even allowed to upgrade from suse packages from different versions!... (or so some, including you have told me).

Yes you can. That you don't know how to isn't something to be bitching about. You can't build just any version of the libs, you've been told that, although it's pretty well known. You need a binary-compatible replacement, and for that you may want to start by applying openSuse-specific patches. If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck. Since you seem to love building your own stuff so much it's a wonder why you're not using Gentoo. Really. I don't use Gentoo because I don't want to spend my life building stuff, but you are, so... why not? It's not an attempt to get rid of you, it's just puzzling and I'd like to know. In any case, binary compatibility is a delicate beast. So... you broke it. It's no wonder, it's easy to break. You seem to always start from pristine upstream tarballs, configure && make, that's not the way to get binary-compatible replacements for a whole distro installation. You want to start with RPM sources. You want to read the SPEC file, and follow it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

...

Worse, I'm not even allowed to upgrade from suse packages from different versions!... (or so some, including you have told me).

Yes you can. That you don't know how to isn't something to be bitching about.

Oh, You and Christian need to get on the same page. Try upgrading libperl from 5.16.0 -> 5.16.1, .2 or .3 They are ALL binary API compat -- str8 from the perldev's mouth. Even the major versions, for many purposes, OFTEN have been -- **BUT**, a simple cpan -r or cpan upgrade has never failed to bring modules in sync with the current perl for any of my modules.

You can't build just any version of the libs, you've been told that, although it's pretty well known. You need a binary-compatible replacement,

The above ARE binary compat, but Suse has version checks in the products like gvim to disable their functioning if your version is off. As for libc - the only reason I tried building that myself initially, was to get a version that was 'the latest' that would support 14, 15, 16 the next (17). So I wouldn't have to worry about libc compat if I wanted to switch up in versions. and for that you may want to start by applying

openSuse-specific patches.

Like the ones that break normal functionality applied to BASH or break parallel sorting?

If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.

It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter. If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.

Since you seem to love building your own stuff so much it's a wonder why you're not using Gentoo. Really. I don't use Gentoo because I don't want to spend my life building stuff, but you are, so... why not? It's not an attempt to get rid of you, it's just puzzling and I'd like to know. -- I don't take it as an attempt to get rid of me.

I don't like building EVERYTHING. I have a few things I care about and use in my development or to run my system. I've used shell and perl scripts to automate and run most of the stuff I do on my system Shell for simple, perl for more complex. I generally rebuild my kernel for efficiency and trying out new features.

In any case, binary compatibility is a delicate beast.

Only when it is built in a fragile manner. I didn't have anywhere near these problems the farther back we go. 11.x didn't have so many troublesome interlocks. 10.x and 9.x I remember as being generally golden. 8.x -- 7.x -- 6.x, getting too far back to remember. the details. But never the problems I've had in the 12.X series..

So... you broke it. It's no wonder, it's easy to break.

It wasn't so easy if you just a we bit careful and willing to clean up after yourself back in the 11.x and before series. Now, everything is booby trapped -- no more looking under the hood. You seem to always start from

pristine upstream tarballs, configure && make,

Actually, the only things I have done that for were the kernel, and perl. First exception was when suse released transmission with certain features disabled. Latest version I'm running from a modified rpm. I've got other things I want to be doing than to to do than maintain my computers 24/7, but if they aren't working right, it's hard to do many of the things I like doing.

that's not the way to get binary-compatible replacements for a whole distro installation. You want to start with RPM sources. You want to read the SPEC file, and follow it.

I usually do, but the specs have been a source of problem when they say: req: prod (version=x) Not req prod or rec prod (version>=x), but locking them together. As to return to the title of this email -- IT WASN'T ME who broke binary compatibility --- christian said it was suse that did it by design -- intentionally based on the advice of a 2 year old webpage. If suse can't keep binary compatibility in keeping the Stand Alone Shell, stand alone, why would you lecture *ME* on keeping it? Note -- the SASH isn't standalone just because of linking -- it had many of the basic core util functions built in -- that's what made it stand alone. I.e. replacing it with dash would be entirely inappropriate. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/02/2013 04:57 AM, Linda Walsh wrote:

christian said it was suse that did it by design -- intentionally based on the advice of a 2 year old webpage.

problem is, I never said that.

If suse can't keep binary compatibility in keeping the Stand Alone Shell, stand alone, why would you lecture *ME* on keeping it?

I already explained to you why, I do not know how many times.. you need an initrd which already includes basic libraries and a working shell.if you dont want an initrd, you are using the wrong distribution. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh wrote:

...

If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.

---

It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter.

If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.

No, you're completely wrong there. Take it from someone that actually does some coding for his livelihood, any kind of patch has the potential to break binary compatibility. You'd have to know how C works pretty well to be able to decide whether one in particular does or does not. It's not just about the symbols. If you want to remove patches, remove them one by one and test thoroughly afterwards. Especially patches touching C code. On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh wrote:

and for that you may want to start by applying

...

openSuse-specific patches.

---

Like the ones that break normal functionality applied to BASH or break parallel sorting?

All the ones you don't need to remove, keep them. They're quite likely modifying the lib's ABI, so you have to keep them.

...

In any case, binary compatibility is a delicate beast.

---

Only when it is built in a fragile manner.

No, it's been pretty much the same ever since K&R. Well, it worsened a bit with C++, but it's gotten easier since then thanks to versioned symbols. What you see is the effect of increased systems complexity making stuff less predictable to mere mortals. A compiler knows best, and there's the value of a distribution and automated build systems.

...

that's not the way to get binary-compatible replacements for a whole distro installation. You want to start with RPM sources. You want to read the SPEC file, and follow it.

---

I usually do, but the specs have been a source of problem when they say: req: prod (version=x)

I'm mostly referring to build/install scripts and the patches, not so much about the requirements (though you probably should pay attention to them, just not that specifically).

Not req prod or rec prod (version>=x), but locking them together.

There's probably a reason though. The package's ABI must be especially unstable, and backwards compatibility especially unreliable for the packager to do that. I know I've had to do that for some subpackages because they're tightly coupled with the main package.

As to return to the title of this email -- IT WASN'T ME who broke binary compatibility ---

Yes, it was you. You installed a broken libc, if I read the OP correctly. Broken by you by not building it to openSuse specs. Distros don't promise any kind of binary compatibility, not to upstream and not to other distros, except on LSB components, and, IIRC, there's a separate libc for LSB.

christian said it was suse that did it by design -- intentionally based on the advice of a 2 year old webpage.

OpenSuse broke compatibility with upstream, but that's not breakage of any kind, just a design decision, because libc works just fine within openSuse with openSuse pacakges. So in conext "you broke binary compatibility" means "you built a libc that didn't match opensuse's libc's ABI". It's you the one that has to conform to openSuse's ABI now, when you try to replace an openSuse component, and not the other way around. If that bothers you, really, you need another distro. Not sure there's any distro that will satisfy your wish of upstream-compatible ABIs. I'd wager those would be immature distros, but it's up to you. In any case, you'd be wise to test this not by installing a modified libc on your system, but by mangling LD_LIBRARY_PATH or chrooting or something of the sort. Just saying. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Tuesday, 2013-04-02 at 05:31 -0300, Cristian Rodríguez wrote: ...

There is no hack required, just a bootloader plus an initrd.

...

No, and initrd is required since long time before systemd..

True.

99.9% of our users do not recompile core functionality such as libc, the kernel or perl. what happends here is, you belong to the 0.01%, that is, you are either not the target audience or dare a I say.. a troll.

I have to agree with Cristian here - and he knows I often don't ;-) If on an openSUSE installation with the standard tools emergency mode works, that's fine for me. If I need more complex rescue environment, I can use either an extra bootable partition for recovery, the dedicated rescue image available since 12.3, the text rescue system that I think (I have not checked 12.3) is available on the install DVD, or the installation gnome/kde "CD". I assume they work. If there is broken functionality I want to know about it. But I do not want to see the mail list filled so many times with posts by people that insist on modifying core components because they do not like them for whatever reason (maybe valid, maybe not) and then complain endlessly about some other thing that breaks. I do not want to waste time reading a post thinking that "oh no, something important has broken", then to find out that the breakage is because of modified core parts :-( This is a distribution. Linda, if you want to demonstrate tool breakage, please do so on a system built using openSUSE standard code. Heck, I hate systemd. But I can not create my own sysinit scripts (I might), and then complain if they don't work. I may ask for help, of course, but not complain. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFa8bAACgkQtTMYHG2NR9VQ2wCglTMl/NYZCdUW+hDpyLVJ6+x9 3lAAoJU+WtFTeicvriQCbLUIh/RJhDCh =zDnd -----END PGP SIGNATURE-----

Claudio Freire wrote:

On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh wrote:

...

...

If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.

---

It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter.

If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.

No, you're completely wrong there. Take it from someone that actually does some coding for his livelihood, any kind of patch has the potential to break binary compatibility.

In this case, you are wrong. The same patch went into glib 2.14, 15, 16 and 17. The patch hasn't changed. That means since glibc17 includes binary compat for glib2.14, if suse had put it into a separate library and not modified the standard glibc, there never would have been a problem. You'd have to know how C

works pretty well to be able to decide whether one in particular does or does not. It's not just about the symbols.

I know C pretty well. I've kernel code, compiler code interpreter & graphics code, networking (before TCP/IP). Worked in 8080/8085/x86 assembler as well as I worked at intel in their compiler group. My degree is in computer science -- so I had an engineering degree background to back up my job experience -- not something alot of people writing code today can say. I owned and programmed a and worked on a 4.77MHz PC, original IBM, got through an Intel price break. I have a passable to mediocre knowledge of much of the computer science field. People outside the computer industry consider me an expert, but I wouldn't call myself that. There's way too much to know to be an expert except in very narrow knowledge areas -- and my interests are spread way to widely to become an expert in any of them. In the specific example, suse created unnecessary binary incompatibility between the standard libc and theirs. If they had put it in a separate library, that could be run-time loaded, Perhaps via modification of the LD_LIBPATH, then they could have had the binary compatibility with glibc that vendors would like. But so many utils wouldn't load because they couldn't find a symbol "OWL_1.0" - a 3rd party crypto addition. Most of those utils had no need for encryption. So I maintain that bundling such things is a major headache for users who try to support 3rd party tools (or write them).

...

Like the ones that break normal functionality applied to BASH or break parallel sorting?

All the ones you don't need to remove, keep them. They're quite likely modifying the lib's ABI, so you have to keep them.

Nope they were both bugs that disabled standard functionality.

There's probably a reason though. The package's ABI must be especially unstable, and backwards compatibility especially unreliable for the packager to do that.

Except that it's not. The ABI is guaranteed stable over the minor releases in perl, for example, yet suse locks many products into minor versions requiring upgrading an entire distro to upgrade your perl.

Yes, it was you. You installed a broken libc, if I read the OP correctly. Broken by you by not building it to openSuse specs.

By having 'cat', cp, ls all require a crypto lib, suse is breaking things unnecessarily. You can claim I broke it because I didn't add crypto into a lib for cp or cat or whatever... BUT those things don't use crypto and I don't use the crypto in that lib! Suse broke it first by force all utils to be dependent on mandatory crypto symbols bundled into libc. They are NOT depedant on the crypto CODE, they are only dependent on the extra added symbols added at link time. That's deliberate breakage of 100's of programs that don't need to be broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

It's time to cut the crap.

Yes, it is.

Three packages ... pam... How many packages and libs depend on PAM and will fail to load because the sym isn't there:

the pam one is due to pam_unix2.so

afs5log chage chfn chsh cimmof cimmofl cimprovider cimsub crontab kdm libCIMQueryCapabilitiesProvider.so libCIMQueryCapabilitiesProvider.so.1 libCIMxmlIndicationHandler.so libCIMxmlIndicationHandler.so.1 libCertificateProvider.so libCertificateProvider.so.1 libConfigSettingProvider.so libConfigSettingProvider.so.1 libDefaultProviderManager.so libDefaultProviderManager.so.1 libNamespaceProvider.so libNamespaceProvider.so.1 libProviderRegistrationProvider.so libProviderRegistrationProvider.so.1 libUserAuthProvider.so libUserAuthProvider.so.1 libpam.so libpam.so.0 libpam.so.0.83.1 libpam_misc.so libpam_misc.so.0 libpam_misc.so.0.82.0 libpamc.so libpamc.so.0 libpamc.so.0.82.1 libsnmpIndicationHandler.so libsnmpIndicationHandler.so.1 libuniconf.so libuniconf.so.4.4 libwvstreams.so libwvstreams.so.4.4 libwvutils.so libwvutils.so.4.4 lxdm osinfo passwd pkexec ssh-keyconverter su uni vtysh wbemexec wvdial wvdialconf xdm (55) How many of those are libs? 33... if 1 lib's fail prevents loading of 22 progs and 33 libs, how many more will the rest block? libpam by itself is bad enough -- that affects a much larger number of programs ssh --- However, note, I DID say this happened a few weeks ago when I was still mostly in 12.1 w/a few 12.2 packages to support the virt-machines (kvm?) that was used in every security util before 12.3. 12.3 replaced it with pam_unix... I went through the rpmsaves/rpmnews to fix all of them. with pam_unix2 linked into every security relevant prog, you are pretty well screwed. I count 76 progs in /etc/pam.d... without those progs you are VERY screwed because you are locked out of the system. So um... tell me about this crap you are cutting? If you can't run any prog to do with UID/GID, accounts, authorization or session validation, What can you run? You think I was exaggerating? It was seriously screwed.

$ rpm -e glibc --test 2>&1 | grep OW_ libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) whois-5.0.11-12.1.1.x86_64 libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) pam-modules-12.1-16.1.1.x86_64 libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) yast2-core-2.23.4-2.1.1.x86_64

But you have to put int a special symbol in the heart of your security and sysadmin (yast) to make it incompat with a standard glibc. PERFECTLY SUSE'S right -- but it is a HUGE Gotcha when one is told glibc is upward compat -- and you hope to try loading a glibc that will be 'compat for all'... The OW_CRYPT stuff really can't be in its own lib?

You can blame perl for that, because its default search path contains the exact version only (e.g. "5.16.2" in case of openSUSE_12.3) rather than a generic "5.16".

The **default** build of perl includes all the dirs of the previous release. Suse strips those out. **** So no -- that's SQUARELY a suse thing**** binding libs of perl/python and ruby in w/your system's text editor--- all suse. I even did the legwork for you you and posted the patch in the bug report -- but it's short enough to include here... cleaned up a few bad dependencies while I was at it... diff vim.spec vim.spec.dyn 42d41 < BuildRequires: systemd 57,58c56 < # Explicitly require versioned perl for libperl.so < %define perl_requires perl = %(rpm -q --qf '%{VERSION}' perl) ---

%define perl_requires perl 318,320c316,318 < --enable-perlinterp \ < --enable-pythoninterp \ < --enable-rubyinterp \

--enable-perlinterp=dynamic \ --enable-pythoninterp=dynamic \ --enable-rubyinterp=dynamic \

-------------- gvim didn't not fail due to a directories problem. It specifically looked for an exact version at install and at RUN time.... it was broken by design (it was designed to break if the user tampered with their system perl). You even have a dep on systemd?!?!?? WTF? gvim doesn't require systemd anymore than it required the sysVinit scripts -- but someone was very determined to make systemd required... just try to do an install w/it banned, and watch the 100's of conflicts that run fine w/o it installed! But lets pretend for a moment that perl's default DIDN'T include the previous release's dirs (but it does)... Suse still knows well how to use symlinks: /usr/lib/perl5> ll total 8 lrwxrwxrwx 1 6 Mar 14 11:03 5.16.0 -> 5.16.2/ lrwxrwxrwx 1 6 Apr 2 22:25 5.16.1 -> 5.16.2/ drwxr-xr-x 61 4096 Mar 26 17:21 5.16.2/ drwxr-xr-x 4 76 Apr 2 22:25 site_perl/ drwxr-xr-x 6 117 Apr 2 22:25 vendor_perl/ Have we cut the crap yet? Would you like cheese on that? I'm citing facts here -- I don't care how these things got this way -- but I know they don't have be deliberately broken. and Christian said to 'do' something? I'm submitting bug reports and patches. I'm telling you how it can be done to get what you want and preserve compat... all I get is a HUGE amount of grief. ;^/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Linda Walsh :

...

I have at least 2 services I can think of off the top of my head that I run that suse doesn't provide run scripts for.

transmission-daemon and an ipmi-hw daemon.

Please check Factory again: there is a transmission-daemon package, which brings a systemd service file with it.

---- Hmm.... I see the file... I don't see it handling any configuration or what user it runs as... It references a config file, but the config file doesn't exist. Would it be useful / possible to use my startup script to start it? Mine reads the config file from the daemon and uses those arguments when restarting rather it allows hiding the password in separate location runs as it' own daemon and has support for running more than once instance -- (only tested once). I'll include it below and you can see why I might not want to give up the functionality. I haven't reviewed it for 'release', BUT i've been using it for 3 years... so it's likely in reasonable shape. There's some code to try to see if the user is in group 'torrent', and if so, allow them to run the script as a normal user... Has support for reading from sysconfig or ENV...as well as config files in torrent user dir (by instance if running multiple daemons)... The original is tab'ed @ 2 spaces, so I converted it to 2 spaces for below. to convert back to tabs in vim, set noet, just retab! 2, then the tabs will be set for the proper indentation and if you prefer 4 or 8, then reset your tabstop (ts=3/4/8...etc)... But the retab! with et/noet make it str8 forward to recover original tabbing. Anyway... this is a reasonably good example of a start/stop script...IMO..tried to make it as flexible as possible.... ---- #!/bin/bash # # /etc/rc.d/transmission.rc script by Astara at tlinx.org (c) 2010 # use, modify and derive from, as thou wilt. If you find this useful # that's great! If you want to mention me in credits, that a bonus! Enjoy! # Developed and tested on suse 11.2 - 12.2 # transmission[{XX}] [verb] [{XX}] -- where {XX} can be an an integer and # occur as part of filename or as a # parameter and indicates which instance # or copy to control # When {XX} is noted, for XX>0, home dir directs to 'child{XX}' under # the real home directory # ### BEGIN INIT INFO # Provides: tmd # Required-Start: $network, $local_fs, # Should-Start: upnp $remote_fs named # Required-Stop: # Should-Stop: et e Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: transmission-daemon: a file transfer daemon # Description: transmission-daemon is a file transfer daemon utilizing # the 'bit-torrent' protocol. This allow for transferring # large amounts of data by sharing the network bandwith # among downloaders. Note -- to make effective use of # this client, it is necessary to allow incoming and # outgoing traffic through a firewall. # Only 1 port needs to be open and this can be defined # statically -- so you can manually add rules to your # firewall. The daemon will use upnp to talk to a # compliant firewall to ask it to open a port for it, # allowing for port randomization on startup, if that # is desired. Software upnp programs, like 'linux-igd' # are freely available by searching on the web, will # function as a upnp gateway and will manage connections # through a linux or other firewall. ### END INIT INFO # ## support code & functions Id="$(type -p id)" Sed="$(type -p sed)" Sudo="$(type -p sudo)" unset Groups typeset -Ax Groups function _idparse { # parse output of id: # uid=##(name) gid=##(name) groups=##(name)[,##(name)]... # Note, names may be 'absent' (in which case there are no parens). # grouplist is *comma* separated! -- but only on output of 'id'; # I don't "idnames" can start with a number... (we'll assume not) # if group has no name, put it's number in as it's name # else you wouldn't see you are in those groups while read id ; do [[ $id =~ .?id= ]] && continue; #skip over uid/gid entries id="${id/\(/ }" id="${id/\)/}" gid="${id%% *}" name="${id#$gid}" name=${name##\ } [[ -z $name ]] && name="$gid" Groups[$name]="$gid" done < <($Id|$Sed -r ' s/\) gid/\)\ngid/ ; s/\) groups/\)\ngroups/ ; s/\\/\\\\/g ; s/\),([0-9])/)\n\1/g ; s/\b([0-9]+),/\1\n/g ; s/groups=//') } _idparse ## populate Groups Hash tmd_user=torrent tmd_home="$(eval echo ~$tmd_user)" tmd_base_home="$tmd_home" tmd_group="$(groups torrent 2>/dev/null |cut -d\ -f3)" tmd_child="" if (($EUID != 0)) ; then if [[ -n ${Groups[$tmd_group]:-} ]]; then if [[ -z ${TRIED_ROOT:-} ]]; then export TRIED_ROOT="yes" exec sudo -E -g "$tmd_group" $0 "$@" fi fi echo "Need Root privs to successully run this script..." exit -1 fi unset TRIED_ROOT >&/dev/null || ((0)) #no longer needed #presumably user is root-priv'ed now. #parse command instance prog="$(basename "$0")" core="$(echo $prog |sed -r 's/^.*transmission/trm/ ; s/^.*trm[0]*([1-9][0-9]+)/trm$1/')" [[ ${core:0:3} == trm && ${#core} -gt 3 ]] && tmd_child="${core:3}" [[ $# -gt 1 && $2 =~ ^[0-9]+$ ]] && tmd_child="$2" tmd_child="${tmd_child##0}" [[ $tmd_child ]] && tmd_home="$tmd_home/child$tmd_child" tmd_umask=2 etc_loglevel=error #default logging level #unset tmd_use_proxy # default # don't use these by default if [[ ! ${use_proxy:-} =~ ^y ]]; then unset -v http_proxy unset -v ftp_proxy unset -v https_proxy fi if [[ -r ${tmd_log_level_file:-""} ]]; then nlvl=$(<"$tmd_log_level_file") if [[ $nlvl == info || $nlvl == debug || $nlvl == error || $nlvl == none ]] ; then etc_loglevel=$nlvl fi fi # use prefix 'tmd' = instead of full program/service name; its just too long tmd_bin="/usr/bin/transmission-daemon" tmd_piddir="/var/run/transmission/" if [[ ! -d $tmd_piddir ]]; then mkdir -m 6775 "$tmd_piddir" && chown $tmd_user.$tmd_group $tmd_piddir fi tmd_pidfile="$tmd_piddir/transmission-daemon$tmd_child.pid" tmd_logdir="/var/log/transmission" tmd_log="$tmd_logdir/daemon$tmd_child.log" tmd_output_log="$tmd_logdir/output$tmd_child.log" tmd_nice=-3 tmd_ionicep="-c2 -n7" # best effort; lowest in class tmd_existing_config=$tmd_home/settings.json function read_json_config { local cfg="${1:-}" local fl="${2:-}" typeset -A $cfg perl -wE ' use 5.12.0; $|=1; my $cfg=shift @ARGV; open (my $cfgh, "<", $ARGV[0]) or die "error w/file $!\n"; my $outs="declare -A $cfg=("; while (<$cfgh>) { chomp; m{^\s+\"([^"]+)\":\s+\"?([^"]+)\"?,\s*$} and do { my ($n, $v) = ($1, $2); $n =~ s/-/_/g; $outs .= qq{[$n]=\"$v\" }; }; } print "$outs )\n"; ' "$cfg" "$fl" } if [[ $# -ge 2 ]]; then eval $(read_json_config "$1" "$2") fi eval $(read_json_config Config "$tmd_home/settings.json") ################################################################ # 'default' tmd_a_rgs: # #[[ ${Config[blocklist_enabled]} =~ true ]] && blocklist="--blocklist" [[ -n "${Config[download_dir]}" ]] && ddd="--download-dir ${Config[download_dir]}" tmda_config_dir="--config-dir $tmd_home" tmda_dht="--dht" tmda_encryption="--encryption-tolerated" tmda_foreground="-f" tmda_incomplete_dir="--incomplete-dir $tmd_home/data/Downloading/transmission$tmd_child" tmda_local_peer_discovery="--lpd" tmda_logfile="--logfile $tmd_log" tmda_loglevel="--log-error" if [[ -z "$etc_loglevel" || $etc_loglevel == none ]] ; then tmda_logfile="--logfile /dev/null" else tmda_loglevel="--log-$etc_loglevel" fi tmda_pidfile="--pid-file $tmd_pidfile" tmda_portmap="--no-portmap" tmda_peer_port="${tmda_peer_port_number:+"--peerport $tmda_peer_port_number"}" tmda_port="${tmda_port_number:+"--port $tmda_port_number"}" tmda_rpc_allowed_access="--allowed 192.168.4.*,192.168.3.*,127.0.0.1" tmda_seedratio_glob="--no-global-seedratio" tmda_watchdir="--no-watch-dir" tmd_args=" ${tmda_blocklist:-} ${tmda_complete_dir:-} ${tmda_config_dir:-} ${tmda_dht:-} ${tmda_encryption:-} ${tmda_foreground:-} ${tmda_incomplete_dir:-} ${tmda_local_peer_discovery:-} ${tmda_logfile:-} ${tmda_loglevel:-} ${tmda_peerlimit_glob:-} ${tmda_peerlimit_per_torrent:-} ${tmda_peerport:-} ${tmda_port:-} ${tmda_pidfile:-} ${tmda_portmap:-} ${tmda_rpc_allowed_access:-} ${tmda_rpc_user:-} ${tmda_rpc_userpw:-} ${tmda_rpc_auth:-} ${tmda_seedratio_glob:-} ${tmda_watchdir:-} " ulimit -Hn16384 ulimit -Sn16384 ulimit -n 16384 ionice_bin=/usr/bin/ionice if [[ ! -e $ionice_bin ]]; then ionice_bin=$(which ionice) fi # Check for existence of config files; # read system first test -r "${tmd_sys_config:-""}" && . "$tmd_sys_config" tmd_sys_config="/etc/sysconfig/transmission$tmd_child" # then read home-dir-config if present tmd_home_config="$tmd_home/etc/rc-config" test -r "$tmd_home_config" && . "$tmd_home_config" tmd_etc="${tmd_etc:-"$tmd_home/etc"}" tmd_log_level_file="${tmd_log_level_file:-"$tmd_etc/log_level"}" if [[ -z ${tmd_user:-} ]]; then echo "tmd_user not set!" exit -1 fi if [[ -z ${tmd_group:-} ]]; then echo "User \"$tmd_user\" has no group -- (no /etc/passwd?)" exit -1 fi if [[ -z ${tmd_home:-} ]]; then echo "Configuration error: user \"$tmd_user\" has no home dir " exit -1 fi # read env options... tmd_env="${tmd_env:-"$tmd_home/environ"}" if [[ -d $tmd_env ]]; then if [[ ! -r $tmd_env || ! -x $tmd_env ]]; then echo "Environment directory $tmd_env exists, but isn't readable" echo "Environment variables will be ignored" else cd $tmd_env; readarray vars <<<$(find . -type f -name '[^.]*' -print|tr ) if ((${#vars[*]}>0)); then for var in "${vars[@]}" ; do echo "var=$var" export $var=$(<"$var") done cd - >/dev/null fi fi fi # may be set by tmd_env tmd_secrets="${tmd_secrets:-"$tmd_home/.secrets"}" tmd_usr_file="$tmd_secrets/.tmd_user" tmd_upw_file="$tmd_secrets/.tmd_userpw" if [[ -r $tmd_usr_file ]]; then tmda_rpc_user="$(<$tmd_usr_file)" fi tmda_rpc_user="${tmda_rpc_user:+"--username $tmda_rpc_user"}" if [[ -r $tmd_upw_file ]]; then tmda_rpc_userpw="$(<$tmd_upw_file)" fi tmda_rpc_userpw="${tmda_rpc_userpw:+"--password $tmda_rpc_userpw"}" if [[ -n ${tmda_rpc_user:-""} && -n ${tmda_rpc_userpw:-""} ]]; then tmda_rpc_auth="--auth" fi # non configurable vars go after here... #startproc stprc="/sbin/startproc" [[ ! -e $stprc ]] && stprc=$(which startproc) [[ ! -e $stprc ]] && { echo "Fatal: startproc not found" >&2; exit 1 ; } #startproc's arg list.... startproc_args=" -l $tmd_output_log -p $tmd_pidfile -u $tmd_user -g $tmd_group -n $tmd_nice" test -x $tmd_bin || { echo "$tmd_bin not installed"; if [ "$1" = "stop" ]; then exit 0; else exit 5; fi; } sp_args="$startproc_args" # Shell functions sourced from /etc/rc.status: # rc_check check and set local and overall rc status # rc_status check and set local and overall rc status # rc_status -v be verbose in local rc status and clear it afterwards # rc_status -v -r ditto and clear both the local and overall rc status # rc_status -s display "skipped" and exit with status 3 # rc_status -u display "unused" and exit with status 3 # rc_failed set local and overall rc status to failed # rc_failed <num> set local and overall rc status to <num> # rc_reset clear both the local and overall rc status # rc_exit exit appropriate to overall rc status # rc_active checks whether a service is activated by symlinks set +e +u # rc.status has buggy code . /etc/rc.status #set # Reset status of this service rc_reset cd $tmd_home || { /bin/false rc_status -v rc_exit } running=0 if [[ $1 != status ]]; then /sbin/checkproc -p $tmd_pidfile $tmd_bin running=$? if [[ $running == 0 ]]; then running=1 else running=0 fi fi case "$1" in start) if (($running)) ; then echo -n "Transmission already running... " else echo -n "Starting transmissiond " ## Start daemon with startproc(8). If thikks fails ## the return value is set appropriately by startproc. if [[ -n "$tr_umask" ]]; then umask $tr_umask fi all_args="$startproc_args $tmd_bin $tmd_args" if [[ -x $ionice_bin && -n "${tmd_ionicep:-}" ]]; then $ionice_bin $tmd_ionicep $stprc $all_args else $stprc $all_args fi fi # Remember status and be verbose rc_status -v ;; stop) if ((!$running)) ; then echo -n "Transmission is already stopped... " else echo -n "Shutting down transmissiond " ## Stop daemon with killproc(8) and if this fails ## killproc sets the return value according to LSB. /sbin/killproc -t 10 -p $tmd_pidfile -TERM $tmd_bin || { echo -n "Sending Kill..." /sbin/killproc -p $tmd_pidfile -t 1 -KILL $tmd_bin } fi # Remember status and be verbose rc_status -v ;; try-restart|condrestart) ## Do a restart only if the service was active before. ## Note: try-restart is now part of LSB (as of 1.9). ## RH has a similar command named condrestart. if test "$1" = "condrestart"; then echo -n "${attn} Use try-restart ${done}(LSB)${attn} " echo "rather than condrestart ${warn}(RH)${norm}" fi $0 status if test $? = 0; then $0 restart else rc_reset # Not running is not a failure. fi # Remember status and be quiet rc_status ;; restart) ## Stop the service and regardless of whether it was ## running or not, start it again. $0 stop $0 start # Remember status and be quiet rc_status ;; status) echo -n "Checking for service transmission-daemon${tmd_child} " ## Check status with checkproc(8), if<F5><F5> process is running ## checkproc will return with exit status 0. # Return value is slightly different for the status command: # 0 - service up and running # 1 - service dead, but /var/run/ pid file exists # 2 - service dead, but /var/lock/ lock file exists # 3 - service not running (unused) # 4 - service status unknown :-( # 5--199 reserved (5--99 LSB, 100--149 distro, 150--199 appl.) # NOTE: checkproc returns LSB compliant status values. /sbin/checkproc -p $tmd_pidfile $tmd_bin # NOTE: rc_status knows that we called this init script with # "status" option and adapts its messages accordingly. rc_status -v ;; probe) ## Optional: Probe for the necessity of a reload, print out the ## argument to this init script which is required for a reload. ## Note: probe is not (yet) part of LSB (as of 1.9) if [[ $tmd_sys_config -nt $tmd_pidfile || $tmd_home_config -nt $tmd_pidfile ]]; then echo reload fi ;; *) echo "Usage: $0 {start|stop|status|try-restart|restart|probe}" exit 1 ;; esac rc_exit # vim: ts=2 sw=2 syntax=sh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

--- sudo -p broke because someone added a line to the config in pam. It's added in 12.3 and factory but wasn't in 12.2 or before.

Yes, I saw you reported this in a bugzilla.

But you have to show that these problems exist in a system using only packages as distributed by openSUSE. If you, for example, remove initrd, you can not complain that things do not work, you are on your own. ===== That's where you are entirely wrong -- that is not the suse

Carlos E. R. wrote: philosophy. When building and testing, only the minimal products necessary to build and test the product are used to minimize interactions with other products. initrd is not running nor present when the system is up and functioning normally, so it doesn't even come into consideration.

You have to swim inside the current, as we try to do, and then cry out at the rocks for everybody to see.

---- Sorry, the fault I documented is in the source code. You can squirm and wriggle anyway you want, but it's in the installed rpm as incorrect. It has nothing to do initrd.

If you say that something does not work, and then we find out that you use an atypical boot system without initrd for your own reasons, well, after sometime people stop listening to you.

Why do I need to use initrd -- why is a product being forced on me that I don't need or want and will degrade my system's performance? Let me tell you about the suse boot system: This is from the system administrators manual that pops up as a first result when searching for suse boot concept: Abstract Booting and initializing a UNIX system can challenge even an experienced system administrator. This chapter gives a short overview of the SUSE LINUX boot concept. The new implementation is compatible with the System Initialization section of the LSB specification (Version 1.3.x). Refer to Section 12.1.1. “Linux Standard Base (LSB)” for more information about LSB. The message “Uncompressing Linux...” signals that the kernel is taking control of your hardware. It checks and sets your console — more precisely: the BIOS registers of graphics cards and output format — to read BIOS settings and to initialize basic hardware interfaces. Next, your drivers probe existing hardware and initialize it accordingly. After checking the partitions and mounting the root file system, the kernel starts init, which boots (Unix jargon) the main system with all its programs and configurations. The kernel controls the entire system, including hardware access and the CPU time programs use. 13.1. The init Program The program init is the process responsible for initializing the system itself in the required way. All other processes are considered child processes of init. init takes a special role. It is started directly by the kernel and resists signal 9, which normally kills processes. All other programs are either started directly by init or by one of its “child” processes. init is centrally configured via the /etc/inittab file. Here, the runlevels are defined (see Section 13.2. “Runlevels”). It also specifies which services and daemons are available in each of the levels. Depending on the entries in /etc/inittab, several scripts are run by init. For reasons of clarity, these scripts all reside in the directory /etc/init.d. The entire process of starting the system and shutting it down is maintained by init. From this point of view, the kernel can be considered a background process whose task it is to maintain all other processes and to adjust CPU time and hardware access according to requests from other programs. ---------------------------------------------------------------------------------------------------- No where do I see evidence of some long term requirement for initrd.

...

...

Heck, I hate systemd. But I can not create my own sysinit scripts (I might), and then complain if they don't work. I may ask for help, of course, but not complain.

---

How does one start third party or their own services?

I don't know. I'm using 12.1 with systemv or 11.4 evergreen, precissely because of this...

---- I don't stand still -- because if I do, they people will say I said nothing when these things were being done decided and changed. I'm speaking out against problems as they happen and trying to repair damage where I can. Your eventual move to 12.3 or 13.x may eventually be easier because of my hell -- ever thought of that?

Please do, but using openSUSE standards. If you don't, nobody will care or listen.

Sorry, Just because I don't where a susu hat & skirt, doesn't mean my reports are invalid. The rpms are buggie as installed. No interaction with initrd comes into play. You might as easily claim my bugs are invalid because I skipped an update, or ran stuff from factory. You can make up any excuse you want to -- if that is your desire. I can't stop you. But whether or not your justifications are engineeringly sound -- at all, would be more the point. I wasn't wearing my lucky suse decoder ring that day either... If you keep complaining about my reports, I'm going to ask for proof that you are wearing your lucky suse decoder ring, or all your reports are invalid. Yup! Sounds like sound logic to me. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

He's probably talking about adding to glibc all the features required by the openSUSE distribution. If you remove OWL, you're not using openSUSE standards.

If you remove OWL, you won't be able to login and your system will be non-functional, so that's a rather moot point. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2013-04-03 07:47, Linda Walsh wrote:

...

Three packages ... pam... How many packages and libs depend on PAM and will fail to load because the sym isn't there:

afs5log chage chfn chsh cimmof cimmofl cimprovider cimsub crontab kdm libCIMQueryCapabilitiesProvider.so libCIMQueryCapabilitiesProvider.so.1

My point was that `ldd -r` on all those programs will succeed and thus they will start to execute, not that they may unwind because authentication fails at runtime. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org