On Tuesday, November 08, 2011 01:38:23 Felix Miata wrote:

...

Not quite that bad, but way too many for an RC2.

Many KDE base packages apparently depend on bootsplash, many more than in previous KDE releases, which, along with splashy, I taboo on every install.

Grub failed to finish installing. I booted 11.4 and finished it myself with the Grub shell. Menu.lst had two copies of the default stanza, non-identical, besides a useless HD stanza and two failsafes.

Startx as root failed even after fixing permissions.local and doing 'SuSEconfig --module permissions'. How it failed I couldn't tell. It appeared the default X session was icewm, and it gave some wacko lack of space error, then shut down after I clicked OK, the only thing on the screen to click.

AllowRootLogin=true in kdmrc was apparently ignored (once it could be found squirreled away somewhere in the /usr rats nest instead of logically where config files belong in /etc), so getting into KDE via runlevel 5 was initially impossible, since I create no users on test systems, and even when not test systems I only create users after base installation is complete in order to assign user and group IDs appropriately to match all the other installed distros on the system.

Too many failed deps to remember, most probably based upon taboo of *kde*branding-openSUSE and *splash*.

So, you're doing something outside the normal way. Please fix it yourself. Fixes to packages are welcome but I doubt anybody will help debugging all this,

Andreas I would have to agree with Andreas. Your setup is outside of the usual and anticipated usecase scenarios. However, if you are willing to work some of

On Tuesday, November 08, 2011 12:33:54 AM Andreas Jaeger wrote: these problems out and submit the patches we can perhaps include your usecase at least partially. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Nov 9, 2011 at 08:17, Thomas Taylor wrote:

Personally, I find the installation to be difficult for a "newbie".  I've used openSUSE since version 5 or 6 and find the most recent (11.3 thru 12.1) to be very user antagonistic.  Yes, I know how to make modifications during the install process but how many users just starting to experiment with linux (and therefore SUSE) would know that?

Exactly what modifications do you think a new user needs to make? If you assume an average computer (which we have to assume in the installer) and a new user who is first experimenting with Linux.... all they need to do is burn the ISO to CD/DVD or USB stick and pop it in a drive/USB port. Boot it up, take ALL the defaults, and bingo bango, a few minutes later they should have a fully functioning openSUSE install. It's only the "corner cases" where someone has some odd hardware that's out of the mainstream or tries to overthink the installer that things go wrong... and guess what, it likely goes wrong regardless of distro or OS you install. I install openSUSE all the time on multiple machines on very varied hardware (laptops, desktops and servers) and the installer (using defaults) rarely fails to give me a working system. I can think of once on some really unusual hardware and user requirements that I had a problem. A new user doesn't have to think about a separate /home.. the installer creates it for him by default. A new user does not need to think about things like "should I make a partition for /tmp and /usr and /var and and and" These are things that experienced users are interested in... a new user often doesn't even know what a partition is :-P A new/inexperienced user will not be trying to rip the guts out of the install by killing splashy and friends. An experienced user.. .sure, why not. but the openSUSE installer cannot possibly hope to cater to every single possible odd out0of the mainstream requirement that someone has... and seriously, taking out splashy and friends is not mainstream.. this is a very special-needs corner case. For advanced users who don't like the GUI and/or the GUI installer... there is the Minimal install... no splashy included. You get CLI, and you can use the text YaSY to add apps including specific GUI components post-install. Yes there are some spaghetti dependencies (such as some very deep reaching and as yet unexplained dependencies for splashy) and at times... dependencies that don't make sense... it happens... contributors are human... they make what appears to be the best choices that make sense to them, and sometimes it doesn't work. Open a bug report and request it changed.

There is no documentation on the DVD iso's explaining anything about things like what "branding" is, why a separate /home is a good idea, what network settings (during install) are (i.e. loopback device), or even how to handle some of the more common problems during install (video cards, etc.).

So... if you know there's a problem here, and you know what exactly the problem is - you've listed several things here - then... the openSUSE doc team is always in need of help. You do not need to be a C++ developer to write a doc. You can find the Doc Team here: http://en.opensuse.org/openSUSE:Documentation_team Maybe you could add content to this doc page here: http://www.novell.com/documentation/opensuse114/book_opensuse_reference/?pag...

And what are we to think when we submit bug reports that don't seem to be investigated during several milestones?  The only response seems to be to call them duplicates but not find a solution until enough duplicates are accumulated.

Loads of bug reports are fixed... all the time. Have you ever worked in software development? I don't mean open source, I mean commercial paid development.... I have, for years, and... well guess what, bugs are handed exactly the same way there as they are here - in fact openSUSE bugs are generally handled better than any other commercial or open source project I've worked on (I'm thinking of OpenOffice in particular which had/has hundreds of bugs open/ignored for 10 years or more)... and good luck submitting a bug to Apple or Microsoft - you want to talk about black hole.. there's one. At least with openSUSE you *actually*do* have a say in where things go. If a bug appears to be ignored maybe there's a reason for it... the maintainer has too many bugs to manage... he/she has forgotten about it (I've done that)... there is no maintainer... it's a low priority because it's an unusual or very uncommon thing that a tiny number of expert users might stumble on in rare cases (so an effort vs gain decision is made... something I've had to do countless times). The openSUSE community here is VERY helpful despite the claims made earlier in this thread. Look at the recent help given to the new user who was asking advice.. there were what.. over 100 messages there with loads of helpful advice - it was explained to this user why he might want to add a few extra partitions outside of the default, and it was explained in clear steps how to do this, people took the time to explain the difference between x86_64 and i586/i686.. the list goes on and on, and that's just one discussion... take a look at the useful info D.Rankin posts - like the mysql/BASH tip today... People who make spurious claims about how crap the community is to them will never believe, no matter how much proof you show them, that the reality is, we're doing pretty good - room for improvement, but overall, this community is alive, helpful and encourages participation at all levels. Hmmm... where'd this soapbox come from? I'll just step down from there, and retreat back in to the background again. C. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Lars, Me too is an (open)suse fan and user since, well, I don't know exactly, but in any case since 1997. Then I bought a Hercules Dynamite 3D/GL card, for which had to *buy* a driver to get it working with Suse. I still have the card... I have seen Suse, later OpenSuse getting better, better and even better. But it still isn't what is more or less my mantra since I'm in IT (that's 1985, student time not counted): a computer should be as easy to use as a vacuum cleaner. Well, it probably will never be... In my posting on this list of 4-11 ("Mixed findings <...>") I have two examples: no sound, which I have solved, but without having the faintest idea how. I won't recap the posting on that, but for a newbie linux user it would most certainly be a reason in its own to refrain from it. Especially since there was no answer to it on this list, too. Second example - in the same post - is video, which still is unsolved. Also on this subject there wasn't any answer on this list. And yes, I have a two monitor setup. I agree which you that will be a minority of the use cases, but I think it's a rather substantial minority. Especially if you are (as an amateur or by profession) in video- of photo editing, a dual monitor setup is a big pré. I'm sure the problems I have will be solved in the end, but again, a newbie linux user must be very determined not to leave when confronted with them. And even more so hearing the disappointing sound of silence on the report of his findings. regards, Jogchum Reitsma -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Lars, Thanks for so quickly replying! Op 09-11-11 22:17, Lars Müller schreef:

Hi Jogchum,

On Wed, Nov 09, 2011 at 08:31:54PM +0100, Jogchum Reitsma wrote:

...

Me too is an (open)suse fan and user since, well, I don't know exactly, but in any case since 1997. Then I bought a Hercules Dynamite 3D/GL card, for which had to *buy* a driver to get it working with Suse. I still have the card... Oh well, I still have such formerly expensive hardware, if IIRC a graphics card es well. Some old Matrox with dual head VGA and no fan. The first sending me an add address get this one for free.

WHich reminds me that I have to bring a system for my colleague Anders on the way. Shame on me.

...

I have seen Suse, later OpenSuse getting better, better and even better. Good to read!

...

But it still isn't what is more or less my mantra since I'm in IT (that's 1985, student time not counted): a computer should be as easy to use as a vacuum cleaner. Well, it probably will never be... That's up to any of us. The big advantage to Microsoft is the way it gets deployed. It's preloaded in - I guess - more than 95% of the systems. That's the first "pro". The second is ask people on the street who is able to help you with Microsoft Windows and who is able to or even willing to make the hands "dirty" with a Linux system?

I have a good friend at university and I gave some hints to install Linux as a second system. Soon after the sysadmin of the institution was replaced and the new one told: If I would have known here is a Linux system running earlier I would not have taken this job. I'm no longer sure if I laughed or cried. :\ My father in law, 73 years old, is also very happy with the 11.4 release I installed there...

...

In my posting on this list of 4-11 ("Mixed findings<...>") I have two examples: no sound, which I have solved, but without having the faintest idea how. I won't recap the posting on that, but for a newbie linux user it would most certainly be a reason in its own to refrain from it. Especially since there was no answer to it on this list, too. There had been may posting on the sound topic after the openSUSE 11.4 release.

On my ever upgraded openSUSE 12.1 RC 2 I currently have it working and had nothing to change while the upgrade from 11.4 with the following packages:

alsa-utils-1.0.24.2-12.1.2 alsa-plugins-pulse-1.0.24-18.1.2 alsa-plugins-pulse-32bit-1.0.24-18.1.2 alsa-devel-1.0.24.1-23.1.2 alsa-plugins-32bit-1.0.24-18.1.2 alsa-oss-32bit-1.0.17-37.1.2 alsa-oss-1.0.17-37.1.2 alsa-plugins-1.0.24-18.1.2 pulseaudio-module-x11-1.1-1.2 pulseaudio-utils-1.1-1.2 pulseaudio-module-bluetooth-1.1-1.2 pulseaudio-esound-compat-1.1-1.2 pulseaudio-module-zeroconf-1.1-1.2 pulseaudio-module-lirc-1.1-1.2 pulseaudio-module-jack-1.1-1.2 pulseaudio-module-gconf-1.1-1.2 pulseaudio-1.1-1.2

Isn't there a "how do I get sound working?" article in the wiki?

http://en.opensuse.org/SDB:Audio_troubleshooting w00t!

And none of you checked this if it still is valid. tstzststs See at the top it was checked to work for 11.2 and 11.3. Come on, make me feel good and happy and try to solve your issue following the article. If it works add oS 11.4 or 12.1 to the "Tested on openSUSE". Get your hand dirty as mine are! :) You definitively have a point there. I must say I didn't have the time yet to look into it in depth. I would most certainly have found the solution somewhere, if I hadn't stumbled upon getting it to work.

So for *me* it's not an unsolvable problem. The point I tried to make is that for an average, plain user, especially as a first-timer, it probably will be a show stopper. Which is a pity, I think, for the OSS-case in general, more specific for Linux, even more specific for OpenSuse. So please see my posting as an - admittedly very tiny - contribution to prohibit that.

...

Second example - in the same post - is video, which still is unsolved. Also on this subject there wasn't any answer on this list. And yes, I have a two monitor setup. I agree which you that will be a minority of the use cases, but I think it's a rather substantial minority. Especially if you are (as an amateur or by profession) in video- of photo editing, a dual monitor setup is a big pré. ATI or Nvidia?

OSS or the closed thing?

With my GeForce 6200 and oS 11.4 I had no luck with the OSS version. While it works with very small and occasional artefacts on 12.1 RC 1 and 2 quite well.

http://en.opensuse.org/SDB:Configuring_graphics_cards is even longer! Must be better therefore. ;)

ATI, OSS. But I think I better file a bug report somewhere in the Xorg/KDE corner. My Geforce 8600 died, but in 11.4 I had got that one working with nouveau.

...

I'm sure the problems I have will be solved in the end, but again, a newbie linux user must be very determined not to leave when confronted with them. And even more so hearing the disappointing sound of silence on the report of his findings. That's why it sometimes even needs more than communication on list. The anual openSUSE Conference is a good event for end users and developers. There you can work in hands on sessions with others and listen to high quality first hand information from developers.

But it's not only such an possible expensive - you usually have to pay for travel and accomodation whiel coffee and some food was sponsored; you see you missed this maybe most important part - and time consuming event where you might meet people which also use Linux. Check if there is something happening local. Expenses wouldn't be a very big point, if held in Germany. Time, and care for our 6-year old, is. Meet with others and flame about these ignorant SUSE guys. I won't do flaming. Constructive criticism is something else... Better sit together, solve the issue and check if you can enhance the wiki. The wike is there for you.

BTW it gets annoying more and more to me as my chanages needs approval - this really sucks; why do we need this overhead for an article about Samba? Why do we need waste man power? Do I understand this? Never mind; I probably won't have to. What would my answer be: file a bug report. ;) See above.

Adé

Lars Thanks, Jogchum

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

Am 09.11.2011 18:09, schrieb Lars Müller:

It's all up to us to make openSUSE a better if not the best community Linux distribution. It's also up to us to make the environment we're working in comfortable and attractive. Only then we'll be able to win and motivate more people to use Linus in general and openSUSE in particular and to contribute to both.

To complain is good but in the majority of cases it doesn't drive things forward. Please use the tools like bugzilla and openFATE⁴ to drive issues forward. And please don't see both tools as trash bin. ;)

Lars

hats off to you. Well and truely spoken. Andreas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2011/11/09 13:16 (GMT-0800) Roger Luedecke composed:

lets see if this issue the OP had is something of a feature request, a bug, or if there is a better way to achieve the end result he wants.

As the OP I think the base issue is the DVD lacks *branding-upstream*, and that *branding-openSUSE* ties X things into things unrelated to runlevel 5/X. I can't remember ever having this degree of trouble eradicating GUI elements from runlevels 1-3 when doing net installs. Don't conflate this to include GFXboot WRT me, as GFXboot makes everything big enough and pleasant enough to use that that it is GUI is not a problem for me. The M$-style obfuscated init process, and the repeated package updating and and disk space it requires, is all I was trying to prevent encountering and resulted in this thread. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/8/2011 3:33 AM, Andreas Jaeger wrote:

On Tuesday, November 08, 2011 01:38:23 Felix Miata wrote:

...

Not quite that bad, but way too many for an RC2.

Many KDE base packages apparently depend on bootsplash, many more than in previous KDE releases, which, along with splashy, I taboo on every install.

Grub failed to finish installing. I booted 11.4 and finished it myself with the Grub shell. Menu.lst had two copies of the default stanza, non-identical, besides a useless HD stanza and two failsafes.

Startx as root failed even after fixing permissions.local and doing 'SuSEconfig --module permissions'. How it failed I couldn't tell. It appeared the default X session was icewm, and it gave some wacko lack of space error, then shut down after I clicked OK, the only thing on the screen to click.

AllowRootLogin=true in kdmrc was apparently ignored (once it could be found squirreled away somewhere in the /usr rats nest instead of logically where config files belong in /etc), so getting into KDE via runlevel 5 was initially impossible, since I create no users on test systems, and even when not test systems I only create users after base installation is complete in order to assign user and group IDs appropriately to match all the other installed distros on the system.

Too many failed deps to remember, most probably based upon taboo of *kde*branding-openSUSE and *splash*.

So, you're doing something outside the normal way. Please fix it yourself. Fixes to packages are welcome but I doubt anybody will help debugging all this,

Typically unhelpful suse answer of the last few years. Requiring those splash programs without some clear and sure way to ensure that they never try to touch the video hardware is broken. The safe mode boot options are not the answer for this either. It's already too late to even select them by the time gfxboot has killed the console or worse. It's like this: if you want to say that it's the users responsibility to fix opensuse bugs and develop opensuse enhancements, then why should the user use opensuse in the first place? Lately we get the worst of both worlds. All the lack of support of a diy distro with none of the flexibility of a diy distro. If we have to do it ourselves, then Arch or slack or linux-from-scratch or gentoo seems to be a much better investment of our time, because, being diy distros, they don't get in the users way and step on the users toes trying to do things automatically but failing at it. Again this is all just lately, the last few years. I know the reason I picked opensuse in the first place was because it was well engineered and more things "just worked" than other distros and up to that point suse had a pretty long and consistent history of being well engineered. But since then it has become much more slapdash. or at least, I certainly encounter more problems on average and have to do more manual work-arounds to things that used to work as advertised. Suse really exemplifies the truism that past performance is no indicator of future performance. You can't decimate the engineering staff and expect the product not to suck before long. You can't allow the product to grow sucky and expect the users not to notice. You can't expect the users to like and continue to use a product that has grown sucky on them. You can't expect the users to become skilled developers and analysts and give skilled time and effort to a project that answers criticisms with responses like yours. Perhaps you're swamped and harried because the upper levels of your organization and your work experience have changed out from under you just as our distribution has on us. If so, your response is understandable if not forgivabel or tolerable. I sympathize, but I do not accept. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2011/11/08 23:23 (GMT-0500) Ken Schneider - openSUSE composed:

You just do not get it! openSuSE is provided with a specified set of packages that need to be from the "official repos" _only_ AND package dependencies need to be adhered to. If the person installing the distro doesn't want to follow these simple guidelines then they are on their own. There is no magic here.

What guidelines? Where is it written that if I want X installed I have to have a GUI running before X is running? I've yet to encounter a GUI init process that's appealing, much less usable. They all either use too little of the available space, or use low contrast, or tiny text (or no text), or most of the above and/or other problems that don't come to mind ATM. I insist on seeing as much as possible of what's going on during init, nice and legible, un-obfuscated by splashes of sickly colors[1]. Is that really too much to ask of any distro?

If anyone doesn't like the way the openSuSE is assembled they are free to create their own distribution.

One shouldn't have to create another distribution or not install X just to escape GUI init. As many choices as openSUSE users have, the omission of this one just isn't right. It smacks of Shuttleworth/Canonical and M$. I don't mind insistence on proprietary theming for proprietary packaging like GFXBoot and YaST, but overriding the upstream theming on essentials like Gimp, *office, KDM and Plasma never have worked for me, and probably never will. Help for such things when necessary of necessity needs to come from either or both upstream and distro communities, so consistency of expectations is a must to avoid confusion between who is may ultimately be responsible for any trouble encountered. In previous openSUSE releases, avoiding GUI init was not a big deal, but apparently it has become one as of 12.1. [1] yellow-greens and brown-greens are the colors of unhealthy vegetation, soiled diapers, and vomit, the epitome of disappeal. The 10.2 (Grub) Tux and 10.0 blue openSUSE themes are the only openSUSE themes that have ever appealed to me. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/9/2011 12:42 AM, Roger Luedecke wrote:

Truth be told we really are a DIY distro. As far as I know few if any people are getting paid to work on openSUSE.

There used to be. Suse before opensuse was by a large consensus the single best engineered distro. No one had anything nearly as good as yast. Many of the other distros sys admin utils, those that even pretended to try to have any at all, were either full of options and dialogs that didn't actually work, or everything actually worked but there was practically nothing in there so it only even tried to handle the single most common case, or they were just valueless text editors to various config files. Yast both offered far more controls in a safe, managed, and user friendly way AND they damned near always actually worked. And they had been consistently better than most for quite some time. A few other distros were pretty good also but didn't last long, ie Caldera. redhat and debian certainly worked, suse just worked better. It's no crime for a distro to require you to handle things yourself. Especially not a linux distro, especially not a free linux distro. The point, or at least my point, is, it's reasonable for long-time users, and new users too really, to object, for several reasons: * For the long-time users, this is a downgrade from past experience. they'd rather be loyal and continue to like their long time preferred OS because it's still the best for all the reasons it used to be the best. * If it's a diy distro, then take the non-working stuff back out of yast. If there's a button somewhere it needs to work and it needs to be fully documented. If you can't make it actually work, or document how you're actually supposed to use it, then get it out of there, it's false advertising and a problem-factory. There has been some "progress" along this line already, ie the removal of the repair system and boot-installed-system installer options. * If it's a diy distro, then stop having yast and other system scripts override user edits in config files. If I'm to be responsible for making menu.lst and other grub files say what I know it needs to say, then the installer needs to dump me into a text editor on those files and then NOT break my hand-edited files with their _wrong_ automatically generated ideas. Similarly post-install yast and kernel updates and such need to stop breaking my hand-edited files. * If it's a diy distro, then there can be no such thing as "doing something unusual and so it's unsupported" since nothing is supported. By definition you should be able to do whatever you want and the system should not actively fight you over it. Whether something works or not should only depend on the foo of the user who tried to do it. sles may be different, maybe it is still solid, but who in their right mind pays money to have their system be even less common, less documented, less exposed to user experience, less likely to be out-of-the-box compatible with any software out there, than opensuse already is compared to redhat and ubuntu? -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2011/11/09 07:52 (GMT+0100) Stefan Seyfried composed:

Felix Miata wrote:

...

What guidelines? Where is it written that if I want X installed I have to have a GUI running before X is running? I've yet to encounter a GUI

You don't have to. You can get perfectly splash free boot without uninstalling gfxboot and bootsplash.

Sure, but the ecological conservatism I practice demands unnecessary stuff not be installed. Until I try, I don't know it won't work, for me, or for others practicing similar philosophies.

The problem is, that by blocking those packages, through the mechanism of package dependencies, you are blocking much more, necessary packages and those make your system fail.

IMO the packagers are setting deps in too many cases where they should be suggests, but until I try tabooing unwanted packages to force "breakage" I can't tell which are which.

Now reducing those package dependencies might be a worthwile goal. But it is a lot of work. And the strange bugs coming from missing packages are hard to fix. I know, because I always update my systems with the "--no-recommends" switch and later find, that I'm actually missing the new features, simply because the package was just recommended and not strictly necessary. But I do not blame the developers or packagers, because I got what I asked for. Especially it is a lot of work to save a few MB of disk space - nothing else. I am not going to help with that.

For Factory, which is where most of my installation and update time and effort go, it's more than a few, since unused/unwanted packages also eat download bandwidth and update time unnecessarily in addition to the "few MB of disk space".

...

init process that's appealing, much less usable. They all either use too little of the available space, or use low contrast, or tiny text (or no text),

Holy crap. Just use "CONSOLE_FONT=ter-v32n.psfu" and I get nice 80x25 on my 1280x800 native screen. Even better readable than "vga=0" ugly scaled fonts.

Which tool facilitates such a specification? How's anyone supposed to know which of those arcane font specifications is suitable for a particular purpose, more to the point, which achieves how many rows & columns at any particular resolution so as to predict a suitable size for a given display size?

...

or most of the above and/or other problems that don't come to mind ATM. I insist on seeing as much as possible of what's going on during init, nice and legible, un-obfuscated by splashes of sickly colors[1]. Is that really too much to ask of any distro?

And why would you need to uninstall bootsplash to achieve that?

That which?

anyway, the dependencies of *splash* are pretty minimal and it is easy to uninstall them. Your problem was probably, that by tabooing them and later wrongly resolving the package dependencies, you missed much more than just the splash and branding packages.

If I would have wanted to do what you did, I would simply first have selected all the -branding-upstream and then deselected the -branding-openSUSE packages and I'm pretty sure no single dependency problem would have popped up.

ISTR that's what I usually do, but apparently it only works with a net install, as the upstream brandings are apparently excluded from the RC2 DVD I used for installation this time in order to save some bandwidth in installing to a bunch of machines in relative succession. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/8/2011 11:23 PM, Ken Schneider - openSUSE wrote:

...

On 11/08/2011 11:10 PM, Brian K. White pecked at the keyboard and wrote:

...

On 11/8/2011 3:33 AM, Andreas Jaeger wrote:

...

On Tuesday, November 08, 2011 01:38:23 Felix Miata wrote:

...

Not quite that bad, but way too many for an RC2.

Many KDE base packages apparently depend on bootsplash, many more

...

...

...

...

in previous KDE releases, which, along with splashy, I taboo on every install.

Grub failed to finish installing. I booted 11.4 and finished it myself with the Grub shell. Menu.lst had two copies of the default stanza, non-identical, besides a useless HD stanza and two failsafes.

Startx as root failed even after fixing permissions.local and doing 'SuSEconfig --module permissions'. How it failed I couldn't tell. It appeared the default X session was icewm, and it gave some wacko lack of space error, then shut down after I clicked OK, the only thing on the screen to click.

AllowRootLogin=true in kdmrc was apparently ignored (once it could be found squirreled away somewhere in the /usr rats nest instead of logically where config files belong in /etc), so getting into KDE via runlevel 5 was initially impossible, since I create no users on test systems, and even when not test systems I only create users after base installation is complete in order to assign user and group IDs appropriately to match all the other installed distros on the system.

Too many failed deps to remember, most probably based upon taboo of *kde*branding-openSUSE and *splash*.

So, you're doing something outside the normal way. Please fix it yourself. Fixes to packages are welcome but I doubt anybody will help debugging all this,

Typically unhelpful suse answer of the last few years.

Requiring those splash programs without some clear and sure way to ensure that they never try to touch the video hardware is broken.

The safe mode boot options are not the answer for this either. It's already too late to even select them by the time gfxboot has killed the console or worse.

It's like this: if you want to say that it's the users responsibility to fix opensuse bugs and develop opensuse enhancements, then why should

...

...

user use opensuse in the first place?

Brian,

You just do not get it! openSuSE is provided with a specified set of packages that need to be from the "official repos" _only_ AND package dependencies need to be adhered to. If the person installing the distro doesn't want to follow these simple guidelines then they are on their own. There is no magic here.

If anyone doesn't like the way the openSuSE is assembled they are free to create their own distribution.

I get all any user needs to get. If the distribution sucks, it sucks. You can't tell a user who pops the cd in, tries to use the system, and encounters all those problems, that it's their fault.

Those branding packages *break some systems*.

I also taboo them because I CAN NOT have grub loading gfxboot and I CAN NOT have the kernel trying to switch into graphical console modes, and I CAN NOT have any xdm-alike trying to start up at all. I can not have these things happen even the very first time so I can't let the installer install whatever and then go in and adjust config files to disable the problem actions. I will not be able to go in and do anything at all the instant any of those things happens the very first time. So I have to prevent them from even being installed in the first place during initial install, that way even if I miss one of the several manual things I have to do during text-only installs, and say, the menu.lst is left with the gfxboot line in it and uncommented, if it's not installed the line becomes harmless since the file isn't actually there and the console doesn't get killed and I can resume the install without having to boot the install media from the network to use it as a repair platform.

When I remove the gfxboot, splashy and bootsplash packages, the branding packages "require" them, so the branding packages end up going too.

It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.

Either that or suse should just stop all pretense of being a suitable OS for servers.

That would change everything and make your attitude correct. If they would say that, then, and only then, you would be able to say "Hey you're mis-using the system so of course it doesn't work. You can't do text-only installs or because this is only a gui system, and you can't do server optimized installs because this is a desktop system." and I'd have to agree.

I would complain but only once and only briefly and for a different reason, because then it would mean I have to toss out my time investment in crafting my opensuse based system and procedures and scripts and documentation for the rest of the company etc, and start working on probably an Arch one. Then I would go and do that and suse's unsuitability for servers would no longer be a problem for me and you would no longer have to hear reports of things that don't work and it would no longer annoy me that you don't care about anything you don't happen to do yourself.

Seriously sometimes it's like trying to order eggs without spam here. So what do you think we can do? Do you consider this a bug, or something more akin to a feature? This issue is more complex than I can easily comprehend, and it may take a thorough bug report or feature request to achieve what you need. Point is, lets start thinking about what we can do... not how a few

On Tuesday, November 08, 2011 09:36:10 PM Brian K. White wrote: than the people who apparently equal everybody are out to make life difficult. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 09 November 2011, Brian K. White wrote:

It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.

Either that or suse should just stop all pretense of being a suitable OS for servers.

I'd really like to see such statement about this to be written down somewhere. Maybe there should be a voting about it but I guess it's hard to get a useful voting if all the ubuntu users would be able to participate. Mostly I'm happy with suse since very long time but if I remember all these gui, branding, *-kit, avahi, ... dependency hell last years I got more and more in doubt about the suitability for servers. Now with systemd it gets even worse. See for example here http://en.opensuse.org/Main_Page "It is aimed towards users and developers working on the desktop or server. It is great for beginners, experienced users and ultra geeks alike, in short, it is perfect for everybody!" IMO the whole statement is not really true. "perfect for everybody" is not true for sure! It should be rewritten without advertising affectations but to represent the real project objective. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 10 November 2011, Lars Müller wrote:

On Thu, Nov 10, 2011 at 12:47:40AM +0100, Rüdiger Meier wrote:

12.1 will still have sysvinit. Unfortunately it will replace sysvinit on upgrades.Bugzilla got informed about this. bnc#725917 Many people like the most recent commenter don't get why this is bad if not the wrong behavior.

Yes, unfortuantely most people don't see that this feature comparison http://0pointer.de/blog/projects/why.html is as funny/stupid as this one http://i.imgur.com/usftZ.png

...

See for example here http://en.opensuse.org/Main_Page "It is aimed towards users and developers working on the desktop or server. It is great for beginners, experienced users and ultra geeks alike, in short, it is perfect for everybody!"

Yeah, that's blurbing and boring to me too. But hey, enhance it! Make it fit better!

...

IMO the whole statement is not really true. "perfect for everybody" is not true for sure! It should be rewritten without advertising affectations but to represent the real project objective.

We as the openSUSE community are waiting for your contribution. Make it sound good while not being boring. Make it sound to invite further people while not excluding all the old users. I'm sure you soon will join the openSUSE maeketing team and then the baby will fligh high. ;)

Hehe, I would more like to see a general mission statement which the marketing team (and packagers) had to respect. My slogan would be like this "If you need a Windows/Ubuntu replacement then opensuse is not for you. Opensuse is a unix like distro for ambitious users, developers and admins - not as conservative as Debian Woody and not as "up-to-date" as Fedora. It's not made for people who have read about Linux in Computer Bild only so far." I'm in doubt it would be accepted without reference to a similar offical mission statement. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 10 November 2011, Lars Müller wrote:

On Thu, Nov 10, 2011 at 02:21:21PM +0100, Ruediger Meier wrote:

...

Yes, unfortuantely most people don't see that this feature comparison http://0pointer.de/blog/projects/why.html is as funny/stupid as this one http://i.imgur.com/usftZ.png

I'm sure Lennart and Key will be proud of this. ;)

Seriously watching both pictures says more than the most other discussions about sysvinit vs. systemd I've seen so far.

...

My slogan would be like this "If you need a Windows/Ubuntu replacement then opensuse is not for you. Opensuse is a unix like distro for ambitious users, developers and admins - not as conservative as Debian Woody and not as "up-to-date" as Fedora. It's not made for people who have read about Linux in Computer Bild only so far."

[...] While reading the first line of your suggestion again I musts state that I'm not really happy with it. I myself never would do what I'm now doing and love to do and I came from the Microsoft world. Came? Well, I'm still in it.

You don't look like the usual windows/ubuntu user which I'd like to address and which I'd like to keep out of my favourite distro.

And the users of Microsoft systems - 98.68% of all deployed systems are using it; maybe even a bit more - is what I consider most attractive.

The Problem is if we make all these 98.68% really happy with opensuse then I will be unhappy whith it and I guess you and many others would be unhappy too. This is because of the same reason why you can't make ComputerBILD readers happy with another newspaper you'd like to read yourself. You would need to make a similar crap newspaper to take over the BILD readers. Moreover and even worse there will be always more people who like BILD style more than "good" style thus you will loose any voting about the fundamental style decision.

- many got frustrated by the quality Microsoft delivered in the past - many are unhappy with the former default web browser - many are unhappy having no word processor and spreadsheet app available by default - feel free to add 100 more good reasons

Yes, and all these reasons are suitable to argue for not repeating the same design decisions like Microsoft did. Using Poettering designed software for the process with PID 1 and father of the whole userspace is IMO a huge mistake.

BTW mission statement sounds a bit like at the beginning of this century. Why do we need such crap anyhow at all?

Because this would be UNIX like. Define some standards and try hard to follow them. So if Discussions about particual things are getting hot then it helps a lot to point to the well defined standards to clear up things finally. This unix way has shown in past that it's the most substantial way.

Since ages the main motivation to use a SUSE based system is written down in /etc/motd :)

Yup fun is the most important thing for me too. Unfortunately there is no ISO standard and not even an RFC about what is fun at all :). cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 10, 2011 at 3:20 PM, Brian K. White wrote:

What we HAVE now is a distro with most of the old limitations and few of the old benefits. Now when something doesn't work it's fix it yourself. When something could work but requires a change to the distro's tools to stop doing something wrong, it's figure out for yourself why it's broken, how to fix it, and then request the few remaining hq guys to please do this fix that you figured out for them, and then they never do it.

That is a bad deal.

Ok, I don't like to flame, but I'll bite the bait. That's OSS everywhere. Big teams = most is fixed by them, you may still have to provide patches. Small teams = most is fixed by taking patches. If suse has too small a team, providing patches *IS* the OSS solution. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/10/2011 6:59 AM, Lars Müller wrote:

...

On Thu, Nov 10, 2011 at 12:47:40AM +0100, Rüdiger Meier wrote:

...

On Wednesday 09 November 2011, Brian K. White wrote:

...

It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.

Thoughtlessly assembled? Sucking community I have to reply. Fix it! This is the opensuse-factory list. It's not leading, this is bleeding edge. You don't have enough blood? Fix it by getting a blood bottle.

...

...

Either that or suse should just stop all pretense of being a suitable OS for servers.

openSUSE is a community project. See my longer recent mail with Message-id:<20111109170951.GE4977@giles.fritz.box>

@Brian: Read this message two or three times please before you reply fast and cause more unproductive noise on this openSUSE driving forward list.

Interesting to see people complaining loud and with high frequency on mailing lists but not being able or willing to feed bugzilla and openFATE.

I am not the one who missed something here.

I asked, multiple times in other such threads:

Why should I?

There are already tons of other diy distro's out there, only they've been diy distro's all their lives and so they're better at it. I chose suse because it was not a diy distro and in fact was the best of the distro's that claimed not to be diy.

If I have to trade in the polished and really good suse ditro of old for the new do-it-yourself distro of today, then why use opensuse as my platform to do all this work on? It is _not_ as flexible a platform for doing it yourself as the others. It still has things in it that staps on your toes and makes it difficult to customize because until recently, you were really not supposed to need to customize it, it just worked, because they had a lot of engineers spending a lot of time _making_ it work, and keeping it working when all the underlying software and hardware keeps changing out from under it.

Take away all that dedicated and skilled staff and it is _impossible_ to maintain the former level of quality.

As I also said before mroe than once, we are getting the worst of both worlds lately. Maybe you don't know what that means or are unfamiliar with the expression.

It means, very often in life you have to choose one option or another, and each option has some advantages and some disadvantages.

In this case, way back when my company was still using 100% SCO Open Server (Even SCO Xenix before that, even Tandy Xenix before that), which also means that's what all our customers used since we are a software firm, I had of course been using linux and freebsd personally for a long time, and when one of the founders of SCO died and the companies culture and started changing and then broke up and the Unix part went to Caldera and all THAT nonsense started up, I had the ammo I needed to convince my partners to shift everything to linux.

There were many linux distros and I was already fully familiar with all of the big ones and many of the small ones.

One strategic decision that has to be made is, use a diy distro, maybe even maintain our own fully tailored and customized spin? Or use a canned distro?

With a diy distro: Dis advantages: You get a reasonable base to start from, the kernel major software will be updated and security patched. But a lot of things will have to be done by us, there will be little or no automagical stuff. If I want to have a samba server with a given share, I'll have to know how to find and edit smb.conf myself (ok bad example, samba has swat, then again, I'll have to know how to start and then log in to swat). If I want to print to a printer, I'll have to pick a spooler system to install, which means knowing enough about the different spoolers to even know which one I want, and then know how to configure it. Ok that's practically always cups today and cups also has a web configurator, but wasn't always the case and getting that cups web interface to actually work is not always easy. It's basically a lot of work to use a diy distro and I'll have to spend a lot of time developing our own configs and scripts and procedures, and keeping them all working as the underlying software changes over time. Also there will never be more than a ver few people in the company who would have the skill to fix problems or make changes to the system. Many tasks that it might be nice to be able to delegate, will have to be done by me or someone like me.

Advantages: But, with a diy distro, I'll at least _be able_ to do all that because by definition it won't conflict with any of the distro's own mechanisms for managing all that stuff. And with a diy distro, I can have a really custom install that's exactly suited to our product.

With a canned distro, Disadvantages: Inflexible. If the supplied tools don't do it, then it's usually difficult to do it yourself because you have to not only figure out how to do the difficult thing itself, you then also have to figure out how to do it within the framework of the distro's tools or fiigure out how to trick them into doing what you want or give up and completely break the distro's tools and other config schemes, or really give up and live without whatever it is you were trying to accomplish. The distro-compatible packaged software is only a small subset of all software out there, and a lot of random software out there may not only need to be self compiled, it will often need to be modified in some way to adapt to the way the distro is laid out.

Advantages: At least with a good one, most of the system integration is handled by fancy intelligent scripts and utilities provided and constantly maintained by the distro. Tricky things like setting up the firewall, setting up the box to be a nat router and dhcp server, installing onto and booting from software raid, detecting and configuring the nic and printers and modems... all that has been made easy and relatively safe by some tool like yast. And, being a canned static target, more 3rd party commercial things will support it, and I definitely need that.

So there is a choice where you have to go one way or the other, and both ways have some advantages, and both ways have some disadvantages.

Worst of both worlds means when some path has some or all of the disadvantages of one way, AND some or all of the disadvantages of the other way, and none of the advantages of either way.

That is what I am saying has happened to opensuse.

I'm FINE with diy distros. You get what you put into them. And in trade for that requirement that you do everything yourself, you are allowed to to things yourself.

What we HAD was a distro where you were not easily allowed to do much yourself, but in trade for those limitations, you didn't have to worry about making the basic system work most of the time. Most hardware was supported, most services had reasonably functional configurator front ends, you didn't have to know what grub even is. People back at HQ spend all day figuring out that if you have a particular chip in your nic, then you need to put a particular option in modules.conf or on the kernel command line in the bootloader, and also disable some checkboxes in some of the network manager screens because your may claim to offer some feature like offloading tcp checksums, but in reality it doesn't work well enough so you have to know not to use it...

What we HAVE now is a distro with most of the old limitations and few of the old benefits. Now when something doesn't work it's fix it yourself. When something could work but requires a change to the distro's tools to stop doing something wrong, it's figure out for yourself why it's broken, how to fix it, and then request the few remaining hq guys to please do this fix that you figured out for them, and then they never do it.

That is a bad deal. I'm quite confused at this point. Is it Felix or Brian that is having the issue with the odd configuration and errors? Looking back at Felix post it looks as though the issue could be resolved by simply selecting a minimal X installation, for which there is a pattern on the DVD install. I would really

On Thursday, November 10, 2011 10:20:40 AM Brian K. White wrote: like to turn this conversation away from abstractions and flames towards a movement of resolution. It seems to me that this could be solved with correcting the install method using patterns, and any other oddities being filed as bugs or feature requests so we can if possible accomodate this leaner setup. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, November 10, 2011 11:57:33 AM Brian K. White wrote:

On 11/10/2011 2:45 PM, Roger Luedecke wrote:

...

I'm quite confused at this point. Is it Felix or Brian that is having the

Felix's original post was no more about any single specific issue than mine have been. They have been presented as examples only.

In both cases, we already manage to find ways to overcome the actual problems. The points is it sucks that we have to, and that we didn't used to have to, and it's an overall worsening pattern and trend not a particular bug, and that "file bugzilla and openfate entries" is no answer and misses the point.

The discussion is in fact about higher level general issues and not about any specific technical issue. Well, my thought is we can keep discussing it or start addressing it with bug reports and feature requests. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/10/2011 4:52 PM, Lars Müller wrote:

With all the available SUSE Linux Enterprise variations I'm sure a partner or reseller is more likly able to satisfy your demanding needs.

There is an entirely different set of fundamental problems with sles which, since it's sles I won't get into here. You are wrong if you think I don't want to pay for a good product. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/10/2011 1:41 PM, David Hall wrote:

On Nov 9, 2011, at 12:36 AM, "Brian K. White" wrote:

...

I get all any user needs to get. If the distribution sucks, it sucks. You can't tell a user who pops the cd in, tries to use the system, and encounters all those problems, that it's their fault.

Those branding packages *break some systems*.

I also taboo them because I CAN NOT have grub loading gfxboot and I CAN NOT have the kernel trying to switch into graphical console modes, and I CAN NOT have any xdm-alike trying to start up at all. I can not have these things happen even the very first time so I can't let the installer install whatever and then go in and adjust config files to disable the problem actions. I will not be able to go in and do anything at all the instant any of those things happens the very first time. So I have to prevent them from even being installed in the first place during initial install, that way even if I miss one of the several manual things I have to do during text-only installs, and say, the menu.lst is left with the gfxboot line in it and uncommented, if it's not installed the line becomes harmless since the file isn't actually there and the console doesn't get killed and I can resume the install without having to boot the install media from the network to use it as a repair pla tform.

When I remove the gfxboot, splashy and bootsplash packages, the branding packages "require" them, so the branding packages end up going too.

It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.

Either that or suse should just stop all pretense of being a suitable OS for servers.

During install, if you choose minimal server install, it seems to do what you want. Or you can choose minimal X and then uncheck gfxboot, splashy, and bootsplash.

I find opensuse to work perfectly for my servers, especially with the ease of pulling in OBS packages that I build specially for my needs.

-David

I install rather a lot of systems, remotely, text-only serial console and ssh. I know what it does and doesn't do. Unless something changed very recently in 12.1 because I haven't touched that yet, when you select the minimal text-only system, it still installs gfxboot, and the kernel is configured to switch to a graphical console mode. I have to fight the installer to prevent it from installing gfxboot, and I have to go around behind yasts's back and edit menu.lst manually, in another ssh session, after yast has finished writing the bootloader, but before allowing yast to exit, because when it exits the installer immediately reboots the system. Or, I have to pxe-boot the system to the installer again, don't run yast this time, use the shell to manually assemble the mdraid array and mount it, or mount the usb thumb drive whatever that box is booting from, manually edit menu.lst, umount and reboot and allow it to boot from the local disks and resume the install 2nd stage. There are multiple dialogs in the bootloader screens in yast that look like they offer a way to do this all from within the installer nicely. There is an input line for the message file which contains the gfxboot file. Ok yay just clear that out, simple. Wrong. Yast just puts it back in there no matter what. Ok there is an advanced option to edit the files directly, including menu.lst. Ok yay just use the advanced option to edit menu.lst directly and remove or comment out the gfxboot line. Wrong. It puts it back. There may be a particular sequence of using the advanced option and then carefully avoiding one of the other screens that might prevent your manual edits from getting overwritten but I haven't found it. After I overcome this install-time problem, it's basically better behaved for the rest of the life of the system, but maybe only because I never use the bootloader screen in yast after that, or maybe because by then I have gfxboot well and truly uninstalled and tabood, so even if the line reappears, it's harmless if the file isn't actually there. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Nov 10, 2011 at 2:21 PM, Brian K. White wrote:

On 11/10/2011 1:41 PM, David Hall wrote:

...

On Nov 9, 2011, at 12:36 AM, "Brian K. White"  wrote:

...

I get all any user needs to get. If the distribution sucks, it sucks. You can't tell a user who pops the cd in, tries to use the system, and encounters all those problems, that it's their fault.

Those branding packages *break some systems*.

I also taboo them because I CAN NOT have grub loading gfxboot and I CAN NOT have the kernel trying to switch into graphical console modes, and I CAN NOT have any xdm-alike trying to start up at all. I can not have these things happen even the very first time so I can't let the installer install whatever and then go in and adjust config files to disable the problem actions. I will not be able to go in and do anything at all the instant any of those things happens the very first time. So I have to prevent them from even being installed in the first place during initial install, that way even if I miss one of the several manual things I have to do during text-only installs, and say, the menu.lst is left with the gfxboot line in it and uncommented, if it's not installed the line becomes harmless since the file isn't actually there and the console doesn't get killed and I can resume the install without having to boot the install media from the network to use it as a repair pla

tform.

...

...

When I remove the gfxboot, splashy and bootsplash packages, the branding packages "require" them, so the branding packages end up going too.

It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.

Either that or suse should just stop all pretense of being a suitable OS for servers.

During install, if you choose minimal server install, it seems to do what you want.  Or you can choose minimal X and then uncheck gfxboot, splashy, and bootsplash.

I find opensuse to work perfectly for my servers, especially with the ease of pulling in OBS packages that I build specially for my needs.

-David

I install rather a lot of systems, remotely, text-only serial console and ssh. I know what it does and doesn't do. Unless something changed very recently in 12.1 because I haven't touched that yet, when you select the minimal text-only system, it still installs gfxboot, and the kernel is configured to switch to a graphical console mode. I have to fight the installer to prevent it from installing gfxboot, and I have to go around behind yasts's back and edit menu.lst manually, in another ssh session, after yast has finished writing the bootloader, but before allowing yast to exit, because when it exits the installer immediately reboots the system. Or, I have to pxe-boot the system to the installer again, don't run yast this time, use the shell to manually assemble the mdraid array and mount it, or mount the usb thumb drive whatever that box is booting from, manually edit menu.lst, umount and reboot and allow it to boot from the local disks and resume the install 2nd stage.

There are multiple dialogs in the bootloader screens in yast that look like they offer a way to do this all from within the installer nicely. There is an input line for the message file which contains the gfxboot file. Ok yay just clear that out, simple. Wrong. Yast just puts it back in there no matter what.

Maybe there is something that acts differently in remote installation, but I just downloaded the opensuse 12.1 RC2 (Build 25) DVD, ran it in virtualbox, chose "Minimal Server Selection (Text Mode)", and it did not install gfxboot, bootsplash, or splashy. If you find something different happens when installing remotely, then it should be investigated. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/10/2011 4:21 PM, David Hall wrote:

On Thu, Nov 10, 2011 at 2:21 PM, Brian K. White wrote:

...

On 11/10/2011 1:41 PM, David Hall wrote:

...

On Nov 9, 2011, at 12:36 AM, "Brian K. White" wrote:

...

I get all any user needs to get. If the distribution sucks, it sucks. You can't tell a user who pops the cd in, tries to use the system, and encounters all those problems, that it's their fault.

Those branding packages *break some systems*.

I also taboo them because I CAN NOT have grub loading gfxboot and I CAN NOT have the kernel trying to switch into graphical console modes, and I CAN NOT have any xdm-alike trying to start up at all. I can not have these things happen even the very first time so I can't let the installer install whatever and then go in and adjust config files to disable the problem actions. I will not be able to go in and do anything at all the instant any of those things happens the very first time. So I have to prevent them from even being installed in the first place during initial install, that way even if I miss one of the several manual things I have to do during text-only installs, and say, the menu.lst is left with the gfxboot line in it and uncommented, if it's not installed the line becomes harmless since the file isn't actually there and the console doesn't get killed and I can resume the install without having to boot the install media from the network to use it as a repair pla

tform.

...

...

When I remove the gfxboot, splashy and bootsplash packages, the branding packages "require" them, so the branding packages end up going too.

It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.

Either that or suse should just stop all pretense of being a suitable OS for servers.

During install, if you choose minimal server install, it seems to do what you want. Or you can choose minimal X and then uncheck gfxboot, splashy, and bootsplash.

I find opensuse to work perfectly for my servers, especially with the ease of pulling in OBS packages that I build specially for my needs.

-David

I install rather a lot of systems, remotely, text-only serial console and ssh. I know what it does and doesn't do. Unless something changed very recently in 12.1 because I haven't touched that yet, when you select the minimal text-only system, it still installs gfxboot, and the kernel is configured to switch to a graphical console mode. I have to fight the installer to prevent it from installing gfxboot, and I have to go around behind yasts's back and edit menu.lst manually, in another ssh session, after yast has finished writing the bootloader, but before allowing yast to exit, because when it exits the installer immediately reboots the system. Or, I have to pxe-boot the system to the installer again, don't run yast this time, use the shell to manually assemble the mdraid array and mount it, or mount the usb thumb drive whatever that box is booting from, manually edit menu.lst, umount and reboot and allow it to boot from the local disks and resume the install 2nd stage.

There are multiple dialogs in the bootloader screens in yast that look like they offer a way to do this all from within the installer nicely. There is an input line for the message file which contains the gfxboot file. Ok yay just clear that out, simple. Wrong. Yast just puts it back in there no matter what.

Maybe there is something that acts differently in remote installation, but I just downloaded the opensuse 12.1 RC2 (Build 25) DVD, ran it in virtualbox, chose "Minimal Server Selection (Text Mode)", and it did not install gfxboot, bootsplash, or splashy. If you find something different happens when installing remotely, then it should be investigated.

Then it would seem complaining about it finally yielded a result! :) It's only been a problem since ?? ever? 10.0 at least at a guess. I recently looked back as far as 9.1 to check every version to see when the text-only system option appeared, and which versions said "minimal" and or "server" in the wording of either the name or the description of the option. I only had media as far back as 9.1 and it was there in some form in every version from then to now, but I didn't actually install them and don't know how far back this gfxboot and bootsplash and graphical console behavior goes. I wasn't doing remote serial console installs until 10.3 or so. This is really just one item though. Next item, kernel by default tries to switch video modes for the console. Sometimes this actually crashes boxes. I had to discover for myself, somehow, by clairevoience or magic, the reason the box was crashing was not because there was anything wrong with the box, it was because the kernel was by default trying to use a buggy video driver. I had to discover the kernel command line option i915something-or-other=disable or i915.modeset=false or some such. I don't remember if the simpler "nomodeset" worked or not on that one. It's fine to try to provide a nice gui, or at least high resolution text, experience and all that. Surely for most it is better to have a system that looks modern. So, I don't necessarily expect these things to be all turned off by default since really that only serves a minority. I completely agree with that. I do want a better install option to do it though, and I do want those text-mode options that are offered to be tested and to work. I also want the minimal install to be a lot more minimal. For further examples of this: When logging in on a serial console, something in bashrc keeps setting the LINES and COLUMNS to 80x24. It overrides them at every new command prompt even if I manually set them to whatever my terminal really has. It manages to screw up some apps, even if I manually set them and export them and readonly them. Some parent of the actual interactive shell still has them set and I can only change the final interactive shell and it's children. This is annoying but not necessarily so bad until the next thing: Some buttons & tabs in Yast do not appear anywhere on the screen unless the lines & columns are at least 80x25. It makes some screens non-functional. This stilllll wouldn't be sooooo bad if it weren't for the fact that some of these screens are in the network setup, so you may not have the option of ssh-ing in to use a network terminal instead. Roadblock! (hm, you know it just occurred to me I never tried "ssh localhost" to see if that would work) Usually I myself don't get all the way roadblocked like that because I usually use a machine for which the installer has a working nic driver and so installing via ssh works and the ssh session has no such problem. But when I see that it just tells me that this stuff is not actually tested. Except by me. Which isn't enough. It also implies it isn't even wanted, except by me, which isn't enough. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org