Many thanks, for your kind comments. After sending my query to the list, I have made a copy of my installation into another partition, and redid the installation. As it stands, I have /dev/sda1 with 12.2 without YOU, and /dev/sda2 with YOU. The console is working okay as usual, and I can log on as root, or another user account in kde or gnome. I did try to look into dual-booting in the hope of starting up sda2, but have to admit falling behind on Opensuse. Under 12.1 and 11.x, there is a simple script /boot/grub/menu.lst, that I can manually add in a second boot entry. But this file is no longer present, so cannot reboot the YOU applied version to try out your suggestions, sorry... I have however got a copy of the Xorg.0.log, that I have attached here. In comparison from the non-YOU patched version, I can see the patched version is trying to use the module sis [ 1984.582] (II) LoadModule: "sis" [ 1984.582] (II) Loading /usr/lib64/xorg/modules/drivers/sis_drv.so [ 1984.583] (II) Module sis: vendor="X.Org Foundation" [ 1984.583] compiled for 1.12.3, module version = 0.10.4 [ 1984.583] Module class: X.Org Video Driver [ 1984.583] ABI class: X.Org Video Driver, version 12.0 [ 1984.583] (II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620, SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, SIS315H, SIS315PRO/E, SIS550, SIS650/M650/651/740, SIS330(Xabre), SIS660/[M]661[F|M]X/[M]670/[M]741[GX]/[M]760[GX]/[M]761[GX]/[M]770[GX], SIS340 [ 1984.583] (II) SIS: driver for XGI chipsets: Volari Z7 (XG20), Volari V3XT/V5/V8/Duo (XG40) [ 1984.583] (--) using VT number 8 [ 1984.615] (WW) Falling back to old probe method for sis [ 1984.615] (EE) No devices detected. [ 1984.615] Fatal server error: [ 1984.615] no screens found [ 1984.615] Whereas the non-YOU patched version is using vesa and fbdev modules: [ 550.244] (II) LoadModule: "vesa" [ 550.244] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 550.244] (II) Module vesa: vendor="X.Org Foundation" [ 550.244] compiled for 1.12.3, module version = 2.3.1 [ 550.244] Module class: X.Org Video Driver [ 550.244] ABI class: X.Org Video Driver, version 12.0 [ 550.244] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server, Ivybridge Server (GT2) [ 550.244] (II) FBDEV: driver for framebuffer: fbdev [ 550.244] (II) VESA: driver for VESA chipsets: vesa [ 550.244] (++) using VT number 7 [ 550.246] (WW) Falling back to old probe method for fbdev [ 550.246] (II) Loading sub module "fbdevhw" [ 550.246] (II) LoadModule: "fbdevhw" [ 550.246] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so [ 550.246] (II) Module fbdevhw: vendor="X.Org Foundation" [ 550.246] compiled for 1.12.3, module version = 0.0.2 [ 550.246] ABI class: X.Org Video Driver, version 12.0 [ 550.246] (WW) Falling back to old probe method for vesa [ 550.246] drmOpenDevice: node name is /dev/dri/card0 [ 550.246] drmOpenDevice: open result is 9, (OK) [ 550.246] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 [ 550.246] drmOpenDevice: node name is /dev/dri/card0 [ 550.246] drmOpenDevice: open result is 9, (OK) [ 550.246] drmOpenByBusid: drmOpenMinor returns 9 Why it got changed, not sure. But it will be useful to know how to reconfigure this. Many thanks. Kind regards, Peter -----Original Message----- From: Felix Miata [mailto:mrmazda@earthlink.net] Sent: 04 February 2013 11:16 To: opensuse@opensuse.org Subject: Re: [opensuse] Opensuse 12.2 - console screen blank after YOU On 2013-02-04 09:57 (GMT) peter.chiu@stfc.ac.uk composed:

I have mounted OpenSuse 12.2 on a DELL Optiplx 960 from scratch.

After the installation, all seems to be working fine.

I then applied YOU to update all components, and rebooted. The system starts up to the point that says starting up ramdisk, the console screen then goes blank (black).

I can log on over the network afterwards.

The Xorg.log says: x server for display 0 cannot be started - session disabled.

No screen is specified.

Looks like the console start up screen is somehow corrupted.

There is no /etc/X11/xorg.conf, but a set of /etc/X11/xorg.conf.d/ files. A new scheme that I am not familiar with now.

Those files are nothing but xorg.conf separated into separate sections. Some are optional, and if you look inside them you'll see the video related ones are nothing but comments. They're useful to uncomment if one needs to override automagic configuration, e.g. to force a specific non-native resolution, enable panning, or to force DPI. You might want to try renaming the directory temporarily before a boot to see if it changes your problem.

Does anyone have any idea what happens?

No, but I'm going to guess it's Plymouth related. None of my older Optiplexes have done this. Try adding noplymouth & splash=verbose to the cmdline, and remove quiet, before booting to see if there are any clues in the startup messages. Does booting using the failsafe stanza help at all? The failsafe stanza adds nomodeset, which prevents use of the Intel driver, so it's only a workaround for diagnostic purposes. Without doing failsafe boot, can you show us Xorg.0.log via susepaste.org, and output from 'lspci | grep VGA' and 'cat /proc/cmdline'? If using a DVI cable, can you try switching to a VGA cable, or vice versa, just to see if it changes anything? Check http://en.opensuse.org/SDB:Configuring_graphics_cards to see if anything looks helpful. Also try from cmdline 'zypper ref; zypper up' to see if maybe you got a mix of older and fresh updates that are incompatible in some way and missed by YOU. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org -- Scanned by iCritical.

Anton Aylward wrote:

"Console" meaning what, exactly? To me, being an old UNIX hack from long before GUI, a console is the text mode terminal device hanging of a RS-232 port. What is it to you? Do you mean the text-mode "console" on tt1 that applies whether you are in "runlevel" 1, 3 or 5 or the GUI mode login running under Xorg and XMD/KDM/GDM that only applies if you are running in 'runlevel 5" (or "systemctl default.target" being 'graphical.target' rather than merely 'multi-user.target')

Why am I making an issue of this? The term 'console' does have a specific meaning and that meaning is distinct from the GUI.

See console(4) pam_console(8) and of course consoletype(1) whic will when run as 'consoletype fg' tell you if you are at the console or not.

There's another important difference that Lynn (forget last name) brought up -- There's "Text mode" (booting in a BIOS supported VGA text mode) where scrolling is done in hardward, vs. what you get in most grub+initrd setups = a framebuffer, a sofware window that displays text, that is scrolled by software routines that scrolls significantly more slowly than the VGA text mode (VGA text mode usually scrolls by too fast to catch details -- but can let you see anomalies if you are used to watching a bootup, and can let you see the last thing on the screen before something hung...)... the framebuffer, scrolling the bootup process can slow down the boot process insignificantly and is still usually too blurry to read). I wasn't able to get any bootup display booting from grub+initrd -- I couldn't figure out how to make it boot in a VGA text mode and it refused to display a bootup log on my VGA-compat, on-board display card (MGA200 on board -- only enough memory to display 1024x768 in 32bit or 1280x1024 in 16bit color (on a 1920x1200 flat panel that came w/system -- it's meant to be a text console, not a GUI). I was only able to keep VGA text mode boot by using lilo. Of course initrd ignores all those settings and tries to do it's own thing, which meant I got no output UNTIL I saw a login prompt (in runlevel 3). Not very comforting -- didn't know if it was booting up or was hung... Forced me back to lilo and no initrd, ever since -- which is proving to be a major problem now with recent ill-thought-out changes that serve no purpose. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Linda Walsh said the following on 02/05/2013 04:39 PM:

...

I wasn't able to get any bootup display booting from grub+initrd -- I couldn't figure out how to make it boot in a VGA text mode and it refused to display a bootup log on my VGA-compat, on-board display card (MGA200 on board -- only enough memory to display 1024x768 in 32bit or 1280x1024 in 16bit color (on a 1920x1200 flat panel that came w/system -- it's meant to be a text console, not a GUI).

I was only able to keep VGA text mode boot by using lilo.

Of course initrd ignores all those settings and tries to do it's own thing, which meant I got no output UNTIL I saw a login prompt (in runlevel 3).

Not very comforting -- didn't know if it was booting up or was hung...

Forced me back to lilo and no initrd, ever since -- which is proving to be a major problem now with recent ill-thought-out changes that serve no purpose.

Quite different from my experience though the ages: lilo, grub, grub2, initrd ...

The only time I don't see the boot process display is if I choose a setting on the boot (lilo,grub,grub2) menu that explicitly hides it by using a splash screen and boots 'quiet"ly

Linda, you've often posted about how you have a strange and anomalous system. Perhaps this explains some of it ...

Well.. which part of it? As I'm back to this problem now I have no display on my server, yet it is up and running. I turned off the 'fbset' service, as that changed my standard 43 line full screen VGA to about a 25 line 1/3-height (upper 1/3rd of screen) display... that was obviously, by the slower smooth scroll a framebuffer. With fbset service turned off, it seems something in the new

And no, I don't think the the changes we've seen are "ill-thought-out changes that serve no purpose".

---- Yet when asked for reasons WHY -- NO ONE can come up with an answer. If you have one, let's hear it. At some point it was said that /usr had to be on the same partition as /root -- why? Because of systemd. Why did systemd need that? Well -- it didn't. It's just that there was a decision to move all of /bin to /usr/bin, and make /bin into a bunch of symlinks to /usr/bin. Um... and why? I ran a script that took all the symlinks in /bin, replaced them with their /usr/bin counterparts and put the symlinks in /usr/bin. I also made sure the libraries used by the boot utils were in /lib64 -- the only one I had to do manually was libblkid -- appears to be a new link for 'mount'? It had been put in /usr/lib64, which meant that mount -- which still lived in /bin, couldn't access it. Ok, so instead of spending a bunch of time moving things from /bin to /usr/bin, why not just move libblkid to /lib64? So far, that's the only thing that was in /usr/lib64 that was needed for boot (and it MAY have been in /lib64...dunno).

Perhaps they are not as well integrated into openSuse as they are into, say, Fedora, but they are well thought out if you look into the work that has been done with them. They may not suit you and your context, we can accept that, but since so many other people find they work and work well in other contexts that is no reason to insult

Insult? Saying something an idea is ill-thought out is hardly an insult. I can't say an idea is 'bad' without it being an "insult"? If I don't agree, I'm insulting? Um... excuse me! the people who worked hard on them. I'm glad to be

able to boot from LVM and get rid of that pesky, fixed size 'boot' partition.

lilo can already boot from lvm, but that's neither here nor there... You could have had your cake and I could have had mine too -- BOTH could have their way -- and neither HAD to step on the other's toes to get to where you want to go. The choice to destroy the past, is the part that was ill thought out. I dunno -- call me naive, but copying binaries from /bin->/usr/bin and putting symlinks in /bin seems pointless -- unless you are *purposefully* screwing over people who don't have /usr/bin mounted. If you do it the other way around -- it's ALMOST guaranteed NOT to screw anyone over -- since historically, /bin has always been mounted at the time of, or before /usr/bin. Now how can you claim that is not, at least, "ill thought out" -- and that's giving the benefit of the doubt of malice, but writing this -- I don't see any other point other than malice to do it that way. That is LIKELY why no one has been willing to give me the reason why it is being done -- because it ISN'T being user friendly and it's beign done deliberately to screw up people's systems who don't comply. I already asked -- and NO ONE ANSWER, does /usr/bin also include /usr/SHARE?... So far, the answer has been YES!...the "SHARE" partition has to be on the root partition too.. I *like* the fast and parallelized boot of systemd ---- It is SLOWER, it just seems faster because it flashes the screen more...it's a Microsoft design policy -- which is where systemd's design has come from. ==============off soap box=================== So how can I keep systemd from messing with my screen and keep it in text mode? I don't boot to a graphical console because the system has a crap video card builtin to it and to try to run a GUI on a server that sits in a closet is a waste of memory. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 02/06/2013 01:48 AM:

Anton Aylward wrote:

...

And no, I don't think the the changes we've seen are "ill-thought-out changes that serve no purpose".

---- Yet when asked for reasons WHY -- NO ONE can come up with an answer. If you have one, let's hear it.

Perhaps if you can deal with specifics rather than generalizations, and perhaps if you want me to do your googling for you... But I suspect this is RELIGION. I'm not a <strike>doctor</strike> True Believer, I'm an engineer. "It Works for me" and works well.

...

Perhaps they are not as well integrated into openSuse as they are into, say, Fedora, but they are well thought out if you look into the work that has been done with them. They may not suit you and your context, we can accept that, but since so many other people find they work and work well in other contexts that is no reason to insult

---

Insult? Saying something an idea is ill-thought out is hardly an insult. I can't say an idea is 'bad' without it being an "insult"? If I don't agree, I'm insulting? Um... excuse me!

There are people who devoted a great deal of time effort, though and experimentation to matters such as systemd. Saying it was 'ill-thought out" is saying that they had inferior though processes. I would see that as insulting. There's a lot of things that are well thought out but constrained in the implementation because of other constraints such as economics and ability to manufacture. Automotive engineering has a lot of the former (we could build really great cars but they would cost 100 times as much) and aeronautics the latter - we often simply don't have materials to do the job. But this is software. neither of those apply. If you can think it through you can build it and we do and we have.

the people who worked hard on them. I'm glad to be

...

able to boot from LVM and get rid of that pesky, fixed size 'boot' partition.

---

lilo can already boot from lvm, but that's neither here nor there... You could have had your cake and I could have had mine too -- BOTH could have their way -- and neither HAD to step on the other's toes to get to where you want to go.

Ah, religion at work again. That you CAN doesn't mean you should or have to. That you choose to ... As far as I'm concerned, I can just stuck in the installation DVD and forget about details like partitioning - that's the beauty of LVM, deferred decisions. I don't have to do any customising of the boot process. Joe Sixpack can do it with the minimum of lock-in and the minimum of knowledge about Linux internals. I recently, as I mentioned here, did an install of 12.2 using BtrFS. it was a start-it-up-and-walk-away install. Whatever defaults... You seem to be asking for two things. The first is that we are not to be given choices. The second is that the result of that lack of choice is to stick with the old way of doing things. I've also mentioned her that I use Fedora. Its supposed to be Redhat's 'experimental' platform (perhaps in the way that openSuse is a 'experimental' platform for SLED/SLES). Yet I find it stably integrates all these leading edge innovations. I'm told this is because it has a much larger user base and developer base than openSuse, but there's a bit of WTF in there since this is all open source; the openSuse developers can study the Fedora source. My point here is that I have choices and I choose to exercise them; the whole point of Linux and FOSS is that there is no 'state religion' as with Microsoft.

The choice to destroy the past, is the part that was ill thought out.

As you point out by insisting on LILO, the past is not destroyed. I still have all the openSuse installation CDs back to 7.something. I may have earlier ones in a box somewhere...

I dunno -- call me naive, but copying binaries from /bin->/usr/bin and putting symlinks in /bin seems pointless -- unless you are *purposefully* screwing over people who don't have /usr/bin mounted. If you do it the other way around -- it's ALMOST guaranteed NOT to screw anyone over -- since historically, /bin has always been mounted at the time of, or before /usr/bin.

Now how can you claim that is not, at least, "ill thought out" -- and that's giving the benefit of the doubt of malice, but writing this -- I don't see any other point other than malice to do it that way.

You are picking on 'just one thing'. The integration of "/" and "/usr" was driven by many other ENGINEERING factors. Prime among them was systemd. As Felix says # why have you not installed # sysvinit-init to dispense with it if you think systemd is your problem?

I already asked -- and NO ONE ANSWER, does /usr/bin also include /usr/SHARE?...

Don't be silly! /usr/share is under /usr not /usr/bin!

So far, the answer has been YES!...the "SHARE" partition has to be on the root partition too..

You can say that all you want and it doesn't make it so. I've told you before and I'll tell you again. I'm running an LVM system where I created a new LV that had "/" and "/usr" copied into it, the /etc/fstab edited to accommodate that an that only, and a new entry in /boot/grub2/grub.cfg to boot using that. The fstab has entries for /usr/share /usr/share/icons /usr/lib/perl /usr/lib/ruby I also have partitions for /home/anton /home/anton/Documents /home/anton/Music /home/anton/Video so I can mount them on any machine on the LAN :-) Oh, and I have no problems with such 'roving shares'. Am I alone in having a /usr/share partition? Not in the least. I recall this being discussed in the 1980s on USENET. It seems many sites, SUN among them, really did share /usr/share so as to avoid duplicating installing it on every node. Since I've managed, just recently, to put 12.2 on an old 10G drive I hand-mangled it to use the NFS version of /usr/share :-) Please stop spreading the nonsense that this s not possible, that /usr/share has to be on the root partition.

I *like* the fast and parallelized boot of systemd ---- It is SLOWER, it just seems faster because it flashes the screen more...it's a Microsoft design policy -- which is where systemd's design has come from.

Considering the large number of people that have done comparative timing studies and that systemd has tools to let you see where the boot process is spending its time so you can do something about that, I'm not sure where you get the idea that a parallelized boot system is slower than the old serialised sysv-init. That on some systems the paths followed means the GUI login comes up while other non GUI services (in my case the email system .. fetchmail depends on postfix and by my decision on dovecot) are still starting isn't an issue. The whole point of the say systemd is set up, unless you've set it up incorrectly, is that the dependency tree says that the DM and login screen are not dependent on anything that is still starting up. For example fetchmail needs networking and DNS. I'm not going to comment on your "Microsoft" observation other than to say that it seems like religion. At one time IBM was spoken of in the same anathematic tones by users of DEC/UNIX.

So how can I keep systemd from messing with my screen and keep it in text mode?

As Felix says: # You really think systemd has anything to do with framebuffer trouble when # you're using a video card so old it has a dedicated section in the # framebuffer HOWTO? [1] If you are using 12.1, why have you not installed # sysvinit-init to dispense with it if you think systemd is your problem? If you are blaming systemd for the fact that you are using "a crap video card" then its clear that you are striking out irrationally because you don't understand the role of systemd. -- I have no faith, very little hope, and as much charity as I can afford. Thomas H. Huxley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 02/06/2013 04:30 PM:

In this case, since the root of this idea stems from the much reviled Microsoft (the designer admits to the the config files being almost an exact carry over from the many ".ini" files of Win98/XP (Win7 is more XML based or other higher-level language based -- not to mention registry).

Case in point -- has been the move away from a central local for config files in /etc/sysconfig, and a proliferation of config files spread out in per-package locations. This was already shown to be a bad idea by MS for system management -- but it is a phase they went through 10 years ago. Seems like we are getting their 10-20 year old ideas...

You're showing you're ignorance of history here. What you are terming Microsoft's .ini files pre-dated Microsoft. That format of config file was used long before in UNIX. But the old UNIX-era didn't have a special name for that format. Sometimes they were "rc" (maybe a dot, maybe not) files. sometimes ".conf", sometime ".cfg", sometimes ".config". Yes you can complain about the inconsistency, but it never seemed to present any problems to the people using them. I am upset that you seem to think that just because an idea comes out of Microsoft or that Microsoft employees published something that is to be reviled. There are many fine minds who have and are working at Microsoft. Not everyone there is like Ballmer! I remember seeing this kind of prejudicial view of IBM in the last century by people who worked with UNIX and VMS, and who failed to realise that IBM was one of the leading drivers of IT research, though they made little use of the genius they funded. Microsoft has followed in these footsteps. I'd also point out that people from Microsoft are major contributors to Linux. I'm sure if I go though my storage I can find the old V7 and BSD source tapes from long ago, though I have nothing to read them on, but surely they are on-line somewhere. You might try looking up the old B-News of 1980 vintage or something of that ilk. As to the per-package location issue, no that's nothing to do with systemd. Many developers have fallen into that. I'd bring to your attention KDM, whose config file lives in /usr/share/. If anything the systemd approach has enforced a migration to have more under /etc/. Try running rpm -q -l $(rpm -q -a | grep kdm) on a system that uses KDM as the login manager. You'll see that various config files live under /usr share. Oh, and then there's the build system! The config files for each package live with the package not with /etc. It would be awkward to have it otherwise! If you're complaining that config files for systemd live in /lib/systemd, then I'm sorry, I'm not buying that. That's where the library lives. Its like the library of PAM files lives in /lib/security. That you have a library of something doesn't mean all the items in the library are active. What is active is under /etc/systemd. Linking is easier than copying. All in all while I support having config under /etc I'm not in favour of obsessive regimentation. Nor anarchy. But the UNIX/Linux culture is not one of obsessive regimentation. Nor would it be possible under anarchy. But so much of FOSS has grow up around convention and a few simple ideas. One I saw on the frontispiece of one of my engineering textbooks. It was a quotation, freely translated, from the Roman poet Horace and I think it sums up FOSS and Linux very well: If you have a better idea, Brother, Propose it Freely. Otherwise make use of mine. Some of us are old enough to remember when many of the things you are advocating, Linda, weren't around. Some of us remember the resistance to the sysv-init approach which in its time was just as radical a 'rationalization' of the previous ad-hoc collection of scripts. -- "Democracy" is a system that allows those who are directly affected by decisions to exert some influence on the decision makers, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 02/07/2013 03:02 AM:

...

...

You're showing you're ignorance of history here.

---

No... you are -- unix rc files were never structured after MS .ini files. From the systemd manpages:

The syntax is inspired by XDG Desktop Entry Specification[1] .desktop files, which are in turn inspired by Microsoft Windows .ini files.

Why do you think Windows .ini files were the start of thing? Windows and MS-DOS did not spring from the brow of Bill Gates like Athena did after Hephaestus cleaved Zeus's forehead with an ax. MS-DOS was purchased from Tim Patterson who had developed it as 386 clone of - COUGH COUGH - CP/M. You think not? Look at the correspondence in the system calls. And where do you think the model for CP/M comes from? Look to DEC, PDP-8 DOS such. I seem to recall that Willie Crowther's "Colossal Cave" for the PDP-8 saved settings in a .ini file, what was that, a 1977 version of Adventure? I'm told, though don't know of my own experience, that Interleaf LISP used .ini files, though I don't know their format. Your quotation doesn't go back far enough. What do you think Microsoft's .ini files were inspired by ? You go on to say

There's a difference between personal .rc files and system rc files.

See [3]

System rc files are usually kept under /etc/<...>

As I've commented, the operative bit there is "usually". Some programmers have not held to that convention and have later been brought into line.

Been that way for as long as I've been around unix...

Two things: 1. Maybe you haven't looked at examples - such as the KDM example I have 2. The change from K&R's V7 to UNIX Systems Group's SYSIII brought in many oddities that persisted even though SVR4[1]. SCO had a developer's book and some of the programs I purchased though that were very off in the way handled configuration! As Felix points out, even with the rationalization of FHS[2], openSuse don't conform. We have to remember that these standards are not set in stone, that they evolve as we rationalise and innovate. Even FSH admits the use of /etc/has evolved: <quote>In early versions of the UNIX Implementation Document from Bell labs, /etc is referred to as the etcetera directory,[24] as this directory historically held everything that did not belong elsewhere </quote> That's very generic! [1] I once had the job of running a source code diff between V7 and SYSIII and later SYSIII and early SYSV. Much of the SYSIII code was of very poor quality compared to the K&R releases. [2] You'll note that http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard makes great use of the phrasing "some..". Not all versions of Linux conform to all of FHS and it was worse in the past. [3] Note that https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/3/ht... says "The /etc/ directory is reserved for configuration files that are local to the machine". It says nothing about config files relevant to dealings with other machines (is that what /usr/etc is for?) such as cluster management, and does not include an exception for per user config files. There are other contradictions implicit in the way that page is written, for example /usr/local/etc is local to the machine! -- It is therefore not unreasonable to suppose that some portion of the neglect of science in England, may be attributed to the system of education we pursue. -- Charles Babbage -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-06 18:31 (GMT-0500) Anton Aylward composed:

I use KDE and KDM. As I've pointed out the config file for KDM lives on /usr share.

In Fedora, it's FHS-conforming /etc/kde/kdm/kdmrc. Mageia symlinks one of several in its /var/lib rat's nest into /etc/kde/config/kdm/kdmrc. In my openSUSE systems I symlink the one buried in /opt or the /usr/share rat's nest to /etc/kde[4]/config/kdm/kdmrc. Sure is nice not for global config files to be so scattered about. :-( -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Linda Walsh said the following on 02/06/2013 04:30 PM:

...

...

...

...

...

I already asked -- and NO ONE ANSWER, does /usr/bin also include /usr/SHARE?... Don't be silly! /usr/share is under /usr not /usr/bin!

---

That wasn't being silly, the initial plan called for /bin, /sbin and the lib directories -- not share.

...

...

...

...

So far, the answer has been YES!...the "SHARE" partition has to be on the root partition too.. You can say that all you want and it doesn't make it so.

---

It's ALREADY the case:

(from my boot log):

In the specific I'll leave that to someone familiar with virtualbox, but as a general observation ... I wonder why a virtual machine is being started as part of - as you claim - the boot sequence. Or perhaps what you mean by boot and what I mean are different. Where in the 'boot" sequence are the udev rules being run and why?

Here is the relevant section of the boot log: [ 9.344087] Adding 8393924k swap on /dev/sdc5. Priority:-1 extents:1 across:8393924k [ 10.088578] bio: create slab <bio-1> at 1 [ 12.626295] XFS (sdc6): Mounting Filesystem [ 12.716268] XFS (sdc6): Ending clean mount [ 12.733438] XFS (sdc2): Mounting Filesystem [ 12.808932] XFS (sdc2): Ending clean mount [ 12.817038] XFS (sdc3): Mounting Filesystem [ 12.900139] XFS (sdc3): Ending clean mount [ 12.912268] XFS (dm-3): Mounting Filesystem [ 13.055804] XFS (dm-3): Ending clean mount [ 13.060619] XFS (dm-8): unknown mount option [noallocsize]. [ 13.067897] XFS (dm-9): Mounting Filesystem [ 13.202846] XFS (dm-9): Ending clean mount [ 13.273282] XFS (dm-0): Mounting Filesystem [ 13.682765] XFS (dm-0): Ending clean mount [ 13.698900] XFS (dm-7): Mounting Filesystem [ 13.913011] XFS (dm-7): Ending clean mount [ 13.918891] XFS (dm-1): Mounting Filesystem [ 14.102282] XFS (dm-1): Ending clean mount [ 14.127728] XFS (dm-6): Mounting Filesystem [ 14.313585] XFS (dm-6): Ending clean mount [ 14.977599] zip (1191) used greatest stack depth: 3792 bytes left Kernel logging (ksyslog) stopped. Kernel log daemon terminating. Boot logging started on /dev/tty1(/dev/console) at Thu Feb 7 07:20:18 2013 <notice -- Feb 7 07:20:18.779735000> service boot.sysctl start <notice -- Feb 7 07:20:18.787557000> service boot.udev start Applying sysctl settings* Applying /lib/sysctl.d/-sysctl.conf- ... net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.promote_secondaries = 1 net.ipv4.conf.all.promote_secondaries = 1 fs.inotify.max_user_watches = 65536 kernel.sysrq = 176 dev.cdrom.autoclose = 0 * Applying /etc/sysctl.conf ... net.ipv4.tcp_reordering = 16 net.ipv4.conf.all.rp_filter = 1 fs.inotify.max_user_watches = 2048000 net.ipv4.conf.default.promote_secondaries = 1 net.ipv4.conf.all.promote_secondaries = 1 net.ipv4.tcp_fack = 0 net.ipv4.tcp_dsack = 0 net.ipv4.tcp_dma_copybreak = 262144 net.ipv4.icmp_echo_ignore_broadcasts = 0 net.ipv4.tcp_allowed_congestion_control = htcp reno highspeed scalable lp net.ipv4.tcp_congestion_control = highspeed net.ipv4.tcp_base_mss = 1400 net.ipv4.tcp_low_latency = 1 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_adv_win_scale = 4 net.ipv4.tcp_abc = 2 net.ipv4.tcp_mem = 16777216 33554432 67108864 net.ipv4.tcp_rmem = 8388608 16777216 33554432 net.ipv4.tcp_wmem = 8388608 16777216 33554432 net.ipv4.udp_mem = 2097152 8388608 16777216 net.ipv4.udp_rmem_min = 262144 net.ipv4.udp_wmem_min = 262144 net.core.rmem_default = 4194304 net.core.wmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 33554432 net.core.optmem_max = 4194304 net.core.somaxconn = 8192 net.core.netdev_max_backlog = 3000000 net.ipv4.conf.eth0.proxy_arp = 1 net.ipv4.conf.eth1.proxy_arp = 1 net.ipv4.ip_forward = 0 done Starting udevd: done Loading drivers, configuring devices: <notice -- Feb 7 07:20:18.879116000> service boot.sysctl done udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 udevd[187]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:7 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:10 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:13 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:16 udevd[187]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/98-usbprog.rules:19 udevd[398]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 768 09': No such file or directory udevd[399]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 256 09': No such file or directory udevd[400]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 896 09': No such file or directory udevd[401]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 0 09': No such file or directory udevd[402]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 640 09': No such file or directory udevd[403]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 128 09': No such file or directory udevd[404]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 512 09': No such file or directory udevd[405]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 384 09': No such file or directory udevd[447]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 769 00': No such file or directory udevd[453]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 1 09': No such file or directory udevd[492]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 3 00': No such file or directory udevd[493]: failed to execute '/usr/share/virtualbox/VBoxCreateUSBNode.sh' '/usr/share/virtualbox/VBoxCreateUSBNode.sh 189 2 00': No such file or directory done <notice -- Feb 7 07:20:20.485336000> service boot.udev done <notice -- Feb 7 07:20:20.485918000> service boot.loadmodules start <notice -- Feb 7 07:20:20.490571000> service boot.rootfsck start Loading required kernel modules done <notice -- Feb 7 07:20:20.528910000> service boot.loadmodules done Activating swap-devices in /etc/fstab... doneroot file system (/) is NOT being checked. <notice -- Feb 7 07:20:20.584001000> service boot.rootfsck done <notice -- Feb 7 07:20:20.584564000> service boot.cgroup start <notice -- Feb 7 07:20:20.593750000> service boot.clock start mounting cgroup file systems... cpuset debug cpu cpuacct devices freezer blkio net_priodone <notice -- Feb 7 07:20:20.730505000> service boot.cgroup done Set System Time to the current Hardware Clockdone <notice -- Feb 7 15:20:20.807209000> service boot.clock done <notice -- Feb 7 15:20:20.813274000> service boot.device-mapper start <notice -- Feb 7 15:20:20.818572000> service boot.localnet start Activating device mapper...done <notice -- Feb 7 15:20:20.829806000> service boot.device-mapper done<notice -- Feb 7 15:20:20.829982000> service boot.lvm start Using boot-specified hostname 'Ishtar' Setting up hostname 'Ishtar'done Setting up NIS domainname 'sc.tlinx.org'/etc/init.d/boot.localnet: line 52: domainname: command not found done Setting up loopback interface done Waiting for udev to settle... Scanning for LVM volume groups... <notice -- Feb 7 15:20:20.950604000> service boot.localnet done Reading all physical volumes. This may take a while... Found volume group "Media" using metadata type lvm2 Found volume group "Backups" using metadata type lvm2 Found volume group "Home+Space" using metadata type lvm2 Activating LVM volume groups... 1 logical volume(s) in volume group "Media" now active 1 logical volume(s) in volume group "Backups" now active 20 logical volume(s) in volume group "Home+Space" now active done <notice -- Feb 7 15:20:23.635159000> service boot.lvm done <notice -- Feb 7 15:20:23.640442000> service boot.localfs start /etc/init.d/boot.localfs: line 23: /usr/sbin/iptables: No such file or directory Cannot open font file lat1-08.psfu.gz /etc/init.d/boot.localfs: line 26: /bin/unicode-start: No such file or directory /etc/init.d/boot.localfs: line 27: /usr/sbin/modprobe: No such file or directory Checking file systems... fsck from util-linux 2.20.1 donedone Mounting local file systems... /dev/sdc6 on /usr type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k) /dev/sdc2 on /var type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k) /dev/sdc3 on /boot type xfs (rw,noatime,nodiratime,swalloc,largeio,allocsize=1m) /var/rtmp on /tmp type none (rw,bind) /dev/mapper/Home+Space-Home on /home type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k,inode64,nobarrier,allocsize=128k) mount: wrong fs type, bad option, bad superblock on /dev/mapper/Home+Space-Share, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so /dev/mapper/Home+Space-Home.diff on /home.diff type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k,nobarrier) /dev/mapper/Media-Media on /Media type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k,allocsize=256m) /dev/mapper/Home+Space-Squid_Cache on /var/cache/squid type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k,nobarrier) /dev/mapper/Backups-Backups on /backups type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k,inode64,allocsize=128m) /dev/mapper/Home+Space-Media_Back on /backups/Media type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k,allocsize=128m) /home/share on /usr/share type none (rw,bind) /Media on /Media type none (rw,bind) failed <notice -- Feb 7 15:20:25.649659000> service boot.localfs done <notice -- Feb 7 15:20:25.650201000> service boot.cleanup start <notice -- Feb 7 15:20:25.659384000> service boot.klog start <notice -- Feb 7 15:20:25.665855000> service boot.swap start <notice -- Feb 7 15:20:25.670955000> service setserial start Activating remaining swap-devices in /etc/fstab... done <notice -- Feb 7 15:20:25.723604000> service boot.swap done<notice -- Feb 7 15:20:25.723786000> service boot.ldconfig start Configuring serial ports... /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A Configured serial ports done <notice -- Feb 7 15:20:25.758864000> service setserial done <notice -- Feb 7 15:20:25.775004000> service boot.isapnp start <notice -- Feb 7 15:20:25.783173000> service boot.ldconfig done <notice -- Feb 7 15:20:25.786718000> service boot.isapnp done <notice -- Feb 7 15:20:25.983887000> service boot.cleanup done <notice -- Feb 7 15:20:25.984082000> service boot.sysstat start <notice -- Feb 7 15:20:26.454701000> killproc: kill(165,29) adding: boot-130207.1520 (deflated 79%) test of /var/log/boot.msg.zip OK doneRunning sadc done <notice -- Feb 7 15:20:26.456098000> service boot.klog done /etc/init.d/boot.sysstat: line 55: /bin/unicode-start: No such file or directory FATAL: Module bond0 not found. <notice -- Feb 7 15:20:26.496935000> service boot.sysstat done System Boot Control: The system has been set up System Boot Control: Running /etc/init.d/boot.local /etc/init.d/boot.local: line 25: /bin/unicode-start: No such file or directory FATAL: Module bond0 not found. failed INIT: Entering runlevel: 3 -------------------------------- Notice that all the partitions were said to be mounted while klogd was still running. Then I see boot logging starting "boot.udev"... For some reason it tries to setup the network before the disks are mounted...?? Fortunately that "FATAL bond0 is bogus -- as it's compiled into the kernel..."... it sorta looks like all the boot scripts are being run w/o dependencies... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh said the following on 02/06/2013 04:30 PM:

You are not reading what I am saying in whole.

Please don't reply to BOTH the list and to me personally. Its redundant. -- A little inaccuracy can save tons of explanation. -- Saki -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata wrote:

On 2013-02-06 13:30 (GMT-0800) Linda Walsh composed:

...

...

# why have you not installed # sysvinit-init to dispense with it if you think systemd is your problem?

...

I had it installed. Twice I've been "upgraded" to systemd.

# zypper in sysvinit-init # zypper al sysvinit-init

Then no more "upgrading" to systemd-init.

Systemd is much more mature in 12.2, so if and when you upgrade to it, you might want to allow it to do init. IIRC I've got about a 5:1 ratio of 12.1 installs with sysvinit-init to those with systemd-init, but somewhere between diametrically opposite and 50:50 with 12.2. Sysvinit-init is scheduled for removal in 12.3.

zypper in sysvinit-init Loading repository data... Reading installed packages... 'sysvinit-init' is already installed. There is an update candidate for 'sysvinit-init', but it comes from repository with lower priority. Use 'zypper install sysvinit-init-2.88+-82.2.x86_64' to install this candidate. --- It is asking me if I want to update to the one from factory... I would guess not? ;-) Note -- My biggest issue with systemd is the fact that to force it's usage, people are moving binaries from /bin and /sbin -> /usr/bin and /usr/sbin. If that was stopped/reversed/fixed, then it becomes something that is just newer and more complex and trade-offs could be measured, but as long as I have to write scripts and recompile packages to put binaries back on the root partition then systemd is off the table. As near as I can tell -- there is no reason other than malice to do this. All of my problems are disappearing as I migrate binaries from /usr back to /. The whole issue would go away if the equivalent of "boot.localfs" could be made a pre-req before starting the network, or DNS, or the desktop. I had previous boots trying to load drivers for virtual machines (WHICH I don't have enabled!!!) BEFORE the local FS was loaded. WHY can't the local FS be loaded before all the rest of the scripts run? What are people saying "you can't run a local mount-script" before you start systemd. Why is that? BTW -- my screen blank probs went away when I compiled-out that driver. now it comes up in the BIOS set VGA mode and stays there. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-05 13:39 (GMT-0800) Linda Walsh composed:

I wasn't able to get any bootup display booting from grub+initrd -- I couldn't figure out how to make it boot in a VGA text mode and it refused to display a bootup log on my VGA-compat, on-board display card (MGA200 on board -- only enough memory to display 1024x768 in 32bit or 1280x1024 in 16bit color (on a 1920x1200 flat panel that came w/system -- it's meant to be a text console, not a GUI).

I was only able to keep VGA text mode boot by using lilo.

Of course initrd ignores all those settings and tries to do it's own thing, which meant I got no output UNTIL I saw a login prompt (in runlevel 3).

Not very comforting -- didn't know if it was booting up or was hung...

Forced me back to lilo and no initrd, ever since -- which is proving to be a major problem now with recent ill-thought-out changes that serve no purpose.

That must be one seriously wonderful old antique server. Doesn't it have a slot you could put a less antique video card in? Did you ever investigate doing a VBIOS upgrade? I used to have Matrox cards that had the same limited compatibility with VESA and framebuffer as older Matrox cards. They were AGP G400s. I solved the problem with VBIOS upgrades, making them as framebuffer compatible as anything else I've ever used. Now since KMS, they still need vga= to produce a text boot mode compatible with my needs, and I still need to use xorg.conf to get X the way I want, but I've never needed anything but Grub to feed the kernel an appropriate cmdline to get desired boot message and tty results, which excludes quiet, and includes "vga=###" "splash=verbose" "3" among others. I've only ever used whatever initrd config the distro choose to install. Whatever an initrd or not could have to do with boot and tty text I cannot imagine. Even with *buntu's Grub 1.98, vga=791 in spite of Grub's warning message gives me the same framebuffer boot message and tty text on G400 as pre-KMS kernels did, and as video=1024x768 does now with KMS kernels on video chips supported by KMS. My first ever Linux installs all used Lilo. Once I discovered Grub, Lilo's been dead to me, and I fervently hope it stays that way. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-06 14:13 (GMT-0800) Linda Walsh composed:

Felix Miata wrote:

...

That must be one seriously wonderful old antique server. Doesn't it have a slot you could put a less antique video card in? Did you ever investigate doing a VBIOS upgrade?

I don't think it is possible -- it's onboard -- though I could be wrong.

The card: 0a:03.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller]) Subsystem: Dell PowerEdge T610 MGA G200eW WPCM450

When I used the word "antique", I was assuming the G200 you have is equivalent to those with which I'm familiar. I found one upstairs with chip labeled G200a. Its copyright stencil is 1998. Dell or Matrox a decade or so later must have either resurrected the ancient chip and modernized it and its BIOS along with adding a new suffix, or reused the base model name with an entirely different chip. I'm guessing the upgrade. ...

Kernel driver in use: mgag200

...

I used to have Matrox cards that had the same limited compatibility with VESA and framebuffer as older Matrox cards. They were AGP G400s.

There is no x64-PCI-E nor AGP slot. There are PCI-E-x4 slots available (2 I think, and maybe (not sure if space allows a 64-bit PCI-X slot.

On a server not needing X, I'm unable to imagine how video speed could be an issue. Anything that fits in any slot you have and is supported by KMS should provide as much speed and function as anyone could use for BIOS or framebuffer text.

...

solved the problem with VBIOS upgrades, making them as framebuffer compatible as anything else I've ever used.

The card **IS** framebuffer compat (in 1280x768x32 OR 1280x1024x16 on a 1920x1200 included monitor (!).

!?!?!?!

lilo feeds it the appropriate VGA command line. I see the kernel boot until it hits "init"... then it flips into framebuff mode .. trying for: 128x48... which was about what it was... on a 1200 high screen, I said about 1/3, 384/1200 => .32, close for eyeballin' it. Um... I've see better... at 1024 wide, the closest it can do is maybe ... hmmm...I dunno. 640x480? -- 1280x768 won't fit.. neither will 1280x1024...

If it's not too much trouble to fit a gfxcard in a slot, I'd give it a try.

...

Even with *buntu's Grub 1.98, vga=791

I'm using vga = 0x30A -- I did a vga = ask and 0x30a was the best of the bunch...

As I can imagine. Using 0x30A on a G400 here I hit https://bugzilla.novell.com/show_bug.cgi?id=259577 which is marked fixed but isn't. To get 0x30A's full 132x43 to stick all the way through the init process and on the vttys requires replacing CONSOLE_FONT="lat9w-16.psfu" with CONSOLE_FONT="lat9w-08.psfu" in /etc/sysconfig/console. Just to figure out what to put in that bug required what ended up being 20 months with kernel devs in https://bugzilla.kernel.org/show_bug.cgi?id=7513 filed the year before. Some of what's in the kernel bug may be of use to you if you want to futz with framebuffer and/or BIOS modes on MGA any more.

I don't WANT to use a frame-buffer -- it's less readable and slower.

How can you tell BIOS modes are any faster or slower? Here all the BIOS modes on MGA and Intel seem slower than the framebuffer modes. To me all the smaller framebuffer fonts are superior to whatever psfu fonts openSUSE replaces the smaller BIOS fonts with. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/07/2013 02:55 AM, Linda Walsh pecked at the keyboard and wrote:

Felix Miata wrote:

...

...

...

I used to have Matrox cards that had the same limited compatibility with VESA and framebuffer as older Matrox cards. They were AGP G400s.

...

There is no x64-PCI-E nor AGP slot. There are PCI-E-x4 slots available (2 I think, and maybe (not sure if space allows a 64-bit PCI-X slot.

...

If it's not too much trouble to fit a gfxcard in a slot, I'd give it a try.

---

AFAIK, they don't make PCI-E-x4 slot cards and i've never seen a PCI-X card either (It's slower than a PCI-E-x4 slow in terms of bandwidth!

I used a standard pci graphics card in a pci-x slot with no noticeable problems. You could at least try it. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-11 10:12 (GMT-0800) Linda Walsh composed:

Ken Schneider - openSUSE wrote:

...

Linda Walsh pecked at the keyboard and wrote:

...

...

Felix Miata wrote:

I used a standard pci graphics card in a pci-x slot with no noticeable problems. You could at least try it.

Why am I doing this BTW? -- I'd rather stay with text mode -- it's a server. I don't sit in front of it and do work.

Because you complained that framebuffer text video on your server ttys is slower than BIOS text video, which is backwards from my experience any time comparing similar rowsXcolumns modes.

I know nothing about PCI video cards

My current card is a Nvidia 690 w/3G of memory, so while it might be useful to have a desktop available on it, but then it would never be a fraction of what the 690 is, so might not be worth it....

Seems like no one knew how to keep systemd from switching mods into frame buffer it it could (the driver for this card just got some limited support for frame buffer stuff in 3.7, but it's pretty low level...

Most console text users have no complaints about console framebuffer text speed. The only time framebuffer text hasn't been faster than my eyes can follow has been while the CPU is running above 99% for reasons other than what I'm doing on a vtty. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-11 12:41 (GMT-0800) Linda Walsh composed:

The main complaint was there was no way to shut off it's flipping into frame buffer mode.

By doing so, it flipped into a mode that the card could only support a 1/3 height set of ~25 lines at the top of the screen. Nothing I did would cause it to go back.

At this point I'd really like to know how to turn off the flip into FB mode, vs. disabling support for my chipset in a special kernel build.

What's your current /proc/cmdline content? stty -a output? Is all viewable area currently in use on the vttys?

The speed is the least of the worries. Most users wouldn't know the difference between hw-assisted scrolling and framebuffer text that is done with memmove's -- a bit at a time to make it scroll smoothly -- but is harder to read on an LCD -- maybe the persistence effect.

I can see the text and make out words as they zip by on a text boot but not on a framebuffer boot.

Also there is no loss of screen picture as it flips from one mode to the other in the middle of the boot when it stays in text mode (in the few times it came up in 1/3rd tall framebuff mode).

The modes I'm aware of are standard BIOS modes, extended BIOS modes that may or may not conform to VESA standards, and framefuffer modes, so it may be that we have context and/or terminology differences in this thread. So, I'm going to stop using the word "framebuffer". I've seen two general cases where an initial mode worked as expected initially, followed by a mode switch that caused row count and/or viewable area on a vtty to become fouled: 1-Old Intel chips with no VESA support, but with proprietary text VBIOS extension modes, IIRC 132x25, 132x43, 132x50 & 132x60. 2-Matrox chips manufactured last century (Millenium, G200, G400, G450), which originally had poor or no VESA support, but improved VESA with later available VBIOS upgrades. With both, using most distros I've ever used, except for *buntus, booting with such cmdline parameters as vga=0x121 or vga=0x30A supported by BIOS, but partially or none by VESA, causes behavior you described, changing from a competent mode to an apparently incompetent one, with improper row and/or column count to fit the font used to the available screen space. I found two solutions to this that work at least for both the i810 and the Matrox G400. For the latter when using openSUSE and most distros I've used, vga=0x30A on cmdline only works as a normal mortal would expect if one of two things are done: 1: change the 16 CONSOLE_FONT in /etc/sysconfig/console to an 8, or 2: disable user-space console font setting such as described in https://bugzilla.kernel.org/show_bug.cgi?id=7513#c7 Either of these methods I would expect to be valid solutions for your desire to maintain the mode and fonts used on boot and on init initially all the way through init and on all vtty logins. For me on G400 currently with vga=0x30A on cmdline and the standard configuration of the two above items, stty -a shows 21 rows, and only about 55-60% of the available screen height used. Switching CONSOLE_FONT from the default 16 to an 8 changes stty -a output to 43 rows using about 80% of the screen height. All size 9 or 10 fonts I tried did worse. Upthread you asked why the suggestion to try a PCI video card. I answered, but failed to include mention that this discussion is all about behavior with gfxchips that KMS does not support. With a PCI video card featuring an ATI or NVidia chip, or a few others less common, KMS should be able to produce a framebuffer mode (via video= on cmdline, not vga=) to please you, something that may truly be impossible as long as you're using Matrox and neither kernel developers nor Matrox provide KMS support for Matrox gfxchips in maintained kernels. This all assumes also use of Lilo or Grub Legacy. Grub2 may produce different complications with its deprecation of vga= and introduction of gfxpayload as its replacement. AFAICT, systemd has nothing to do with any of this. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-04 19:42 (GMT) peter.chiu@stfc.ac.uk composed:

After sending my query to the list, I have made a copy of my installation into another partition, and redid the installation.

As it stands, I have /dev/sda1 with 12.2 without YOU, and /dev/sda2 with YOU. The console is working okay as usual, and I can log on as root, or another user account in kde or gnome.

I did try to look into dual-booting in the hope of starting up sda2, but have to admit falling behind on Opensuse. Under 12.1 and 11.x, there is a simple script /boot/grub/menu.lst, that I can manually add in a second boot entry.

Normally a new installation will find an old installation and include it in the new boot menu, but I don't think this works when the new installation is openSUSE using Grub2 and the old one uses Grub Legacy. What you could do is replace Grub2 with Grub Legacy on the new installation to automate the inclusion of the prior installation in the boot menu.

But this file is no longer present, so cannot reboot the YOU applied version to try out your suggestions, sorry...

If /boot/grub/menu.lst does not exist you should see /boot/grub2/grub.cfg to perform the same function. Note that if you modify it manually, your changes will disappear when a grub update is performed for a new kernel installation. Be careful making modifications, as Grub2 syntax is quite different from Grub Legacy syntax.

I have however got a copy of the Xorg.0.log, that I have attached here. In comparison from the non-YOU patched version, I can see the patched version is trying to use the module sis

[ 1984.582] (II) LoadModule: "sis" [ 1984.582] (II) Loading /usr/lib64/xorg/modules/drivers/sis_drv.so [ 1984.583] (II) Module sis: vendor="X.Org Foundation" [ 1984.583] compiled for 1.12.3, module version = 0.10.4 [ 1984.583] Module class: X.Org Video Driver [ 1984.583] ABI class: X.Org Video Driver, version 12.0 [ 1984.583] (II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620, SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, SIS315H, SIS315PRO/E, SIS550, SIS650/M650/651/740, SIS330(Xabre), SIS660/[M]661[F|M]X/[M]670/[M]741[GX]/[M]760[GX]/[M]761[GX]/[M]770[GX], SIS340 [ 1984.583] (II) SIS: driver for XGI chipsets: Volari Z7 (XG20), Volari V3XT/V5/V8/Duo (XG40)

SiS is a weakly supported gfxchip due to it uncommon appearance generally, and particularly among Linux users when the time is most important, during distro development testing. Only a month ago right here there was a very long thread where SiS seemed to be the root of the user's problem. You might want to give it a read and see if there's any help to be found in it: http://lists.opensuse.org/opensuse/2013-01/msg00073.html -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Mon, 04 Feb 2013 22:38:08 -0500 Felix Miata <mrmazda@earthlink.net> пишет:

Normally a new installation will find an old installation and include it in the new boot menu, but I don't think this works when the new installation is openSUSE using Grub2 and the old one uses Grub Legacy.

grub2 is using os-prober to detect existing installations and os-prober does support grub legacy menu.lst. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org