--- 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