[opensuse] Opensuse 12.2 - console screen blank after YOU
Hi, 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. Does anyone have any idea what happens? Peter -- Scanned by iCritical. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
peter.chiu@stfc.ac.uk said the following on 02/04/2013 04:57 AM:
Hi,
I have mounted OpenSuse 12.2 on a DELL Optiplx 960 from scratch.
? "mounted" ?
After the installation, all seems to be working fine.
By "all" do you mean that after the installation but before the update you have the video login, could login, get a GUI with icons and menu?
Looks like the console start up screen is somehow corrupted.
Please, do you mean the GUI (hot-key F7) or the text-mode console (hot-key F1) or do you mean the 'console' in the sense of the text-mode boot sequence? If all you see is the splash screen you may want to edit that boot kernel command line and remove the "splash" ... When you see the boot screen press the 'Esc" button to get into edit mode. When you boot without the splash screen you will see the details of the boot sequence go by. Too fast?
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.
A new scheme we've had a for a few years :-) xorg got smarts and can self configure in many straight forward cases so you don't need (and don't want!) xorg.conf. You can specify individual parts, like a featured mouse or a synaptic tablet or a specific attribute of your display (maybe you have many physical screens side by side or rotated to 'page mode') and specify JUST THAT.
Does anyone have any idea what happens?
We'd have to see your logs for that! The oblivious place to start is - as always with xorg - /var/log/Xorg.0.log. Are there "EE" lines there? You may have to back-trace to the kernel/boot and make sure the kernel has he module for the particular graphics card you are using. That may need fixing in /etc/modules* But not knowing your kernel, your card, the log files the output of 'lsmod' and other things, no we don't have any idea what happened. Or rather we have many, many ideas what might have happened but can't tell which are valid without those details. -- There are two ways to slide easily through life: to believe everything or to doubt everything; both ways save us from thinking. -- Alfred Korzybski -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.
peter.chiu@stfc.ac.uk said the following on 02/04/2013 02:42 PM:
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.
"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.
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...
The "menu.lst" is from the original grub that was the default with older versions of openSuse. It looks like you took or defaulted to installing grub2. Look under /boot/grub2 for grub.cfg You're not supposed to had edit this :-) See /etc/grub2/ for the files that go to generate it if you want your changes to be persistent. Oh, and google for how-tos on grub2 for that all.
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
Why it got changed, not sure.
Why it got changed .. probably because your hardware is 'sis'. That's what xorg saw. It would be useful if you gave us the output of "lspci | grep VGA" and "lsmod | grep sis" You might also want to google for an read some of the more recent docco on the X server. I would strongly suggest that while debugging you do not run the system in "runlevel 5" but rather "runlevel 3" and use 'startx'. If all else fails you can use the "-configure" option of X to see what it thinks it should be using - wrong obviously, but it gives you soemting to work with. DO NOT USE A xorg.conf FILE ON A LIVE SYSTEM. The 'sis' system I have had to tweek have a minimalist change in the /etc/X11/xorg.conf.d/ files as needed. What did I do? I set the frequency of my screen in 50-monitor.conf That doesn't seem to be your problem. You can look through the archives for why I needed to do that. I set the characteristics of my touch-pad in 50-synaptics.conf That deons't seem to be your problem either. My *F*E*E*L*I*N*G* is that this is not an xorg problem but a system level problem. Look to see what kernel modules you have loaded.
But it will be useful to know how to reconfigure this.
Go google :-) -- I suspect that, over time, all bureaucratic processes decay into cargo cults unless regularly challenged by a hostile reality. -- Alan Rocker 2001-11-23 -- 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
Felix Miata said the following on 02/04/2013 10:38 PM:
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
Upon investigation of this I found differences in the iterations and capabilities of the SIS video chips installed on a number of motherboard that were notionally the same in that they were the same revision and had the same revision BIOS. I don't know about "uncommon" - it seems to be in a lot of the low-cost hardware that many organization buy in bulk for the basic simple desktop for the <strike>drones</strike> employees. At least that is my observation. Just enough to run XP and Office - its not as if these <strike>drones</strike> employees are meant to be net-warriors, or even _have_ Internet access! But I've got them to work on a one-by-one basis. Some perform better than others. That thread to which Felix refers ... one chip would do no better than 1024x768; another will do 1360x768 but not 1280x1024. Go figure. My choice, when I have it, is to use a proper, supported chip. But sometimes at work you're just another <strike>drone</strike> employee and you use what you're given. I imagine academia is like that as well. The bottom line: Avoid sis, go with Intel, ATI/AMD or Nvidia. Individual cards may be bleeding edge or certain features may not be available but that are not the PITA that sis chips are. So why do some vendors supply mobos with sis chips? Cos they're CHEAP! And that's why some companies buy them by the pallet-load. -- Security engineering is about building systems to remain dependable in the face of malice, error, or mischance. As a discipline, it focuses on the tools, processes, and methods needed to design, implement, and test complete systems, and to adapt existing systems as their environment evolves. Security engineering requires cross-disciplinary expertise, ranging from cryptography and computer security through hardware tamper-resistance and formal methods to a knowledge of economics, applied psychology, organizations and the law. System engineering skills, from business process analysis through software engineering to evaluation and testing, are also important; but they are not sufficient, as they deal only with error and mischance rather than malice. -- Ross Anderson "Security Engineering", 2nd Edition, Introduction http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c01.pdf -- 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
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
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
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 ... And no, I don't think the the changes we've seen are "ill-thought-out changes that serve no purpose". 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 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. I *like* the fast and parallelized boot of systemd and the more rational way it integrates dependencies. I'm looking forward to the time my employer converts everything over since my experiences with them at home and on the machines I can control have been great - video cards aside! Maybe a change in employer will bring that about (or have me working with AIX or SAMBA on HP/UX again). But then I'm glad to have a closet of junk machines that I can experiment with in my spare time. -- More to the point, why would you want to have HTML emails other than to send spam advertising, attempts at hacking your system, having pretty pictures displayed in a software issues mailing list? -- 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
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
On 2013-02-05 22:48 (GMT-0800) Linda Walsh composed:
So how can I keep systemd from messing with my screen and keep it in text mode?
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? Are bootsplash and splashy uninstalled? What's in in /proc/cmdline now? What's listed if you boot with vga=ask on cmdline? [1] http://www.faqs.org/docs/Linux-HOWTO/Framebuffer-HOWTO.html#ss5.4 -- "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
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
You are not reading what I am saying in whole. You are taking sections and rallying against them, but if you read the whole thing, you find you are disagreeing with something I don't believe. Anton Aylward wrote:
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.
I'm a scientist graduated from an engineering background. Works for me isn't always enough -- I want to know how it works as well -- I test, I benchmark, I research.
---- 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.
Ill thought out doesn't mean 'ill thought processes', it means they didn't use their abilities and didn't do "due-diligence". Usually it means insufficient (not inferior) consideration was given as they took someone else's word for it -- that's the *usually* definition in my experience. 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...
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.
Or if you can take current ideas on the subject rather than using 10-20 year old ideas that were rejected for their problems, you can leap-frog ahead. Do you think MS and Apple use each other's 10 year old ideas? They readily pay attention to state-of-the-art.
---- 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 ...
Religion? That's an irrational holding to a belief that something is a certain way. You claimed, irrationally, that the new system gets away from a limited size boot and allows you to boot from LVM. I boot from a RAID5 with XFS -- someting grub hasn't supported directly from disk and still doesn't AFAIK. Whether the earth is flat or round isn't religion (well some people believed it was), but, really, it isn't. But I said, that wasn't important -- since you could have your way of doing things and I could have my way -- BOTH could have our way AT the same time with a better solution.
You seem to be asking for two things. The first is that we are not to be given choices.
---- You misread what I wrote.
The second is that the result of that lack of choice is to stick with the old way of doing things.
You misread what I wrote. I'm saying both could have been provided with less work than has been done to date.
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.
Where do you think these ideas of a "Service Manager" that manages all states of boot and boots from hidden or encrypted partitions comes from? This is Paladium in different socks -- something roundly rejected as bad for consumers -- turning them into passive "users", and removing their capacity to be producers/creaters.
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 am not insisting on Lilo. I am pointing out it solves some of the problems you had without the many changes that are ongoing. The fact that you have historical archives that are both incompatible and can't be easily integrated or work with modern software is moot. You may still have 5.25" floppies or "Dec-tape" for storage. Try using that with any modern machine.
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
Which was later shown to not need such. My latest system (which will work until the next upgrade), boots just fine with systemd (except for it's video corruption) with /usr NOT mounted. The engineering factors were, after further *thought*, were found not to be necessary -- and that's a prime example of the initial decision "ill thought out" -- there was a jump & leap before the engineering factors were examined by Suse experts -- who I suspect are a bit more circumspect (or have been) than fedora engineers (though RedHat has a few high powered employees, so am not "dissing" them or those who work in fedora).
# 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. I've installed packages from 12.2 and factory -- and the trend is toward making these decisions for the user and not using their previous defaults. Example: On my boot disk, I see: (not a complete listing)... Oct 29 2011 disk.b Oct 29 2011 first.b ---- Dec 10 01:04 initrd -> initrd-3.1.10-1.16-desktop Dec 10 01:04 initrd-3.1.10-1.16-desktop Dec 10 01:04 initrd-3.1.9-1.4-vanilla Dec 10 01:04 initrd-3.2.0-Isht-Van Dec 10 01:05 initrd-3.2.21-Ish-Van Dec 10 01:05 initrd-3.2.21-Isht-Van Dec 10 01:05 initrd-3.2.29-Isht-Van Dec 10 01:05 initrd-3.2.5-pk-IshImqXen2 Dec 10 01:06 initrd-3.3.6-Ish+xen Dec 10 01:06 initrd-3.3.6-Ish-Van Dec 10 01:06 initrd-3.4.4-Ish-Vanilla Dec 10 01:06 initrd-3.5.4-Isht-Van Dec 10 01:07 initrd-3.6.0-1-desktop Dec 10 01:07 initrd-3.6.0-Isht-Van Dec 10 01:07 initrd-3.6.2-Isht-Van Dec 10 01:07 initrd-3.6.3-Isht-Van Dec 10 01:08 initrd-3.6.6-Isht-Van Dec 10 01:08 initrd-3.6.7-Isht-Van Dec 10 01:08 initrd-3.6.8-Isht-Van Dec 10 01:00 initrd-vanilla -> initrd-3.1.9-1.4-vanilla --- May 23 2011 inside.bmp May 23 2011 tuxlogo.bmp --- Jun 27 2012 vmlinux-3.1.10-1.16-desktop.gz Jan 27 2012 vmlinux-3.1.9-1.4-vanilla.gz Oct 11 03:27 vmlinux-3.6.0-1-desktop.gz Dec 4 01:20 vmlinuz -> vmlinuz-3.1.10-1.16-desktop Jun 27 2012 vmlinuz-3.1.10-1.16-desktop Jan 27 2012 vmlinuz-3.1.9-1.4-vanilla Sep 23 08:08 vmlinuz-3.2.0-Isht-Van Jun 30 2012 vmlinuz-3.2.21-Ish-Van Sep 1 01:29 vmlinuz-3.2.21-Isht-Van Sep 18 05:41 vmlinuz-3.2.29-Isht-Van Aug 22 22:13 vmlinuz-3.2.5-pk-IshImqXen2 May 31 2012 vmlinuz-3.3.6-Ish+xen Aug 7 2012 vmlinuz-3.3.6-Ish-Van Jun 28 2012 vmlinuz-3.4.4-Ish-Vanilla Oct 4 15:23 vmlinuz-3.5.4-Isht-Van Oct 11 03:13 vmlinuz-3.6.0-1-desktop Oct 4 19:47 vmlinuz-3.6.0-Isht-Van Oct 15 04:27 vmlinuz-3.6.2-Isht-Van Nov 6 17:28 vmlinuz-3.6.3-Isht-Van Nov 19 16:42 vmlinuz-3.6.6-Isht-Van Nov 21 17:09 vmlinuz-3.6.7-Isht-Van Dec 2 03:35 vmlinuz-3.6.8-Isht-Van --- Feb 2 22:16 vmlinuz-3.7.1-Isht-Van Feb 5 22:16 vmlinuz-3.7.6-Isht-Van Dec 10 01:00 vmlinuz-vanilla -> vmlinuz-3.1.9-1.4-vanilla --- Notice, some package I installed on Dec 10, built unusable initrd disks for ALL of my then existing kernels. The ones built since then don't have them. My lilo.conf -- which was unalterered, has lines like: ---------------- image = /boot/vmlinuz-3.7.6-Isht-Van label = 376-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native reboot=bios" root = /dev/sdc1 ... image = /boot/vmlinuz-3.6.8-Isht-Van label = 368-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native" root = /dev/sdc1 image = /boot/vmlinuz-3.6.7-Isht-Van label = 367-Isht-Van append = "root=/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=force pcie_ports=native" root = /dev/sdc1 --- Notice NONE of them specify an initrd to use on boot. There is no way those initrd's could have been used, but the default was to create initrd's for all my kernels.
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):
done
Starting udevd: done
Loading drivers, configuring devices:
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'.
I go for mostly higher level directories:
/ /usr /var /tmp->/var/rtmp, /var/cache/squid
/boot /home /Share /home.diff /Media /backups /backups/Media
---
My exports look completely different:
Audio (/Share/Audio)
backup (/backup/<hostname>)
backups_by_user (/backup/<username>)
Documents (/home/[
Please stop spreading the nonsense that this s not possible, that /usr/share has to be on the root partition.
It's not nonsense -- it's from the system boot log.
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.
I didn't say that. The system that came before systemd used a parallel make type structure. Parallel make is VERY fast. Before recent 12.1 changes, my system came up in as little as 23 seconds (to initial login & ability to serve files/web pages...etc). Now it's usually ~ 90 seconds, though minimally about 50-60, not counting the 2-3 hour sessions to get it to come up at all that happen about every other boot. I think the normal time just before I started installing 12.1 was about 33 seconds. No way 60-90 is faster, let alone the 2-3 hour repair times...which nearly always require a separate rescue disk because systemd's startup processes are designed not to be hand startable.
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.
I've been told on this list, if I want MS Windows, then go to MS. I'm less MS-hostile than most -- if they have a good technology, I look at it and like it.
# You really think systemd has anything to do with framebuffer trouble when # you're using a video card so old
--- 3 years old? It came on the server board.
it has a dedicated section in the # framebuffer HOWTO? [1] **If** you are using 12.1 (and 12.2? 12.3?), why have you not installed # sysvinit-init to dispense with it if you think systemd is your problem?
I have -- twice. It's been upgraded on me -- twice.
If you are blaming systemd for the fact that you are using "a crap video card".
It's designed to be a server. Not a desktop. My desktop has an Nvidia 690 SLI card with 3GB memory -- that wouldn't be supported on linux in any meaningful way either!
then its clear that you are striking out irrationally because you don't understand the role of systemd.
It's clear you don't understand separation of roles and systems. I use the server as a back-end for my desktop. I want the server to do it's thing, and my Windows desktop can do it's thing. After many years I came to this solution -- and Win7 cinched it because Win7 isn't reliable with backups and files. So all my data is on the server. It does everything Windows isn't so good at -- firewall, routing, Mail server, IMAP(dovecot), fast disks, backups, DNS, web proxy, disk space (~30T on the non-root partitions, about half of which is used for backups) w/max speeds ~ 1TB/RW Win7 does the things linux isn't easy to use *or* is not good at -- multimedia (my 2nd screen is my Samsung LCD TV on the wall where I watch videos). My primary screen where I do linux devel and win-desktop app usage (photoshop, a [very] few games) is a 2560x1600 Dell. I can watch videos and do devel at the same time -- the win machine powers both fetching content from the server over what is currently a 300-400MB/s ethernet link (20Gb dedicated for my workstation, 1Gb for rest of house). What part of my HW is 'crap' and exactly where am I "stuck" in the past? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 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. 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... 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...
I don't WANT to use a frame-buffer -- it's less readable and slower.
Lynn on here asked about how to get text mode too and everyone played 'dumb',
like they didn't know she meant HW text scrolling.
--
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/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? I'm not running virtualbox, but those other "will be removed in a future udev version" ones are in /var/log/messages I see it preceded by messages from other sub-systems which tells me that it is the part of 'boot' where scripts are being run. It makes me think that there's something wrong with the dependency rules. I had this problem with spamassassin on my mail server. It was failing every time until I inserted a dependency on postfix. In turn I set a dependency of fetchmail for spamassassin. Methinks that you have something wrong with your rules or scripts to be starting virtualbox too early in the sequence. I use KDE and KDM. As I've pointed out the config file for KDM lives on /usr share. If the problem really was as you claim then I'd be seeing this problem too, just with a different file. But since the graphical login is dependent on my having /usr/share mounted - and yes I have /usr/share ... /dev/vgmain/share /usr/share reiserfs notail,relatime,_xattr 1 2 its not a problem. What is a problem (or was for me) is that "out of the box" spamassassin was not dependent on postfix and fetchmail was not dependent on spamc. The fact that I *CAN* set up dependencies like this is good; the fact that they can be set up incorrectly, which is persistent in your case, emerges from the same. lets be polite and call it a 'teething problems' bug. Insufficient testing. Report it. -- Teachers open the door. You enter by yourself. Chinese Proverb -- 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
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 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
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!
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.
--- Maybe that's why my kernel got this during the last boot: /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... Hmm... iptables in in /sbin, so is modprobe.... guess it needs some symlinks. where did unicode-start go? ... The font is there, it just didn't come up in the right order. ARG!!.. That's why I just want to know why I can't put the mount's in the first step... then it can boot everything else in parallel. 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. -- 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:
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.
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. ...In addition to the generic [Unit] and [Install] sections described here, each unit should have a type-specific section, e.g. [Service] for a service unit. See the respective man pages for more information. ------- There's a difference between personal .rc files and system rc files. System rc files are usually kept under /etc/<...> Been that way for as long as I've been around unix... -- 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
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. -- "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
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
Felix Miata said the following on 02/07/2013 01:35 AM:
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. :-(
+1 Firstly that you're doing that fix manually, subsequently that Fedora is conforming .... The point I was trying to make was that the original developers were not 'conforming' and as you say, neither is openSUSE. I'm sure if we drill down we'll find many examples of individual developers who made various non-conforming choices. I could be pedantic and point out that K&R established a convention that you could grep for things in files since the config was all 'one liners' like in the /etc/passwd, etc/group and old /etc/inetd format, a convention of colon separated values on one lines. The move to "stanzas" - started if I recall by IBM on the early AIX machines/6150 workstations of 1986 vintage - broke that. The X11 config used 'stanzas' as well but instead of reading like C with "{ ...}" format it used CamelWord delimiters. We've subsequently moved to XML, a different view of 'stanzas' that needs a special parser program. I can be picky and point out that X11 used other formats for config files and that KDM's kdmrc uses the "[Stanza Label]" format. When did they start using that? Did they "borrow" it from Microsoft or is it one of those 'simultaneous' inventions because its obvious? Contemporary UNIX/Linux uses all these formats. I can't see them all being abolished in favour of one format or one centralized 'registry' ala Microsoft. I'm not in favour of such a move. Such a move would not be innovative but would be regressive since it would stifle further innovation. Suppose it had happened a decade or so ago; would we have developed XML config files? -- The art of progress is to preserve order amid change and to preserve change amid order. --Alfred North Whitehead -- 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:19 AM:
Notice that all the partitions were said to be mounted while klogd was still running.
You you mean
service boot.klog done
Which is how I view it, in which case the udev rules are in error and should be run later, or
Kernel logging (ksyslog) stopped. Kernel log daemon terminating.
I'm not sure what those mount message preceding those two lines mean but if they are mounts as opposed to some kind of probes, then why are there the fsck-preceded mounts later? I'm not asking that rhetorically. I'm saying those later mounts are the real mounts and I don't know what those earlier messages are. I also don't know why udevd is trying to start virtualbox; I don't run or know much about virtualbox. I do recall that there is a mechanism whereby some udev rules can be deferred until other events occur. Perhaps that's the problem. I'd be interested to know why your system is trying to start virtualbox that early in the boot sequence since its clearly before the LVM is activated. If you /usr/share on on a LVM partition then it sure as hell ain't going to be mounted before the LVM is activated! I don't know what or why those earlier messages are but I see evidence of later activation and mounting of file systems. Misconfiguration of udev or incorrectly configured dependencies does not constitute a complaint that revisions emerging from the use of systemd demands that /usr/share be part of the root FS.
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...
I also note that this occurs much later:
Waiting for udev to settle... Scanning for LVM volume groups...
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
So where does /usr/share live?
service boot.lvm done service boot.localfs start
As I read it, it is her that the mount of the local file systems can begin.
/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
WOW! That last one might account for other problems! I note that these are in "boot.localfs". As far as I can see this is an anachronism. There are few of these around that haven't been replaced by systemd equivalents. But the ones for which there are replacements, you should be using the replacements to ensure consistency and integrity. Take a look at /lib/systemd/system/localfs.service for comparison The pre target explicitly says After=md.service lvm.service dmraid.service Perhaps you should be using that instead. If you are using half old sysv-init and half systemd then I'm not surprised there are anomalies!
Checking file systems... fsck from util-linux 2.20.1 donedone Mounting local file systems...
Only now!
/dev/sdc6 on /usr type xfs (rw,noatime,nodiratime,swalloc,largeio,logbsize=256k)
Is /usr/share on a separate FS or is it here? If its here then its only available now.
/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
I'd be alarmed at seeing that on *my* system!
/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
service boot.localfs done service boot.cleanup start service boot.klog start service boot.swap start service setserial start Activating remaining swap-devices in /etc/fstab... done service boot.swap done 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 service setserial done service boot.isapnp start service boot.ldconfig done service boot.isapnp done service boot.cleanup done service boot.sysstat start killproc: kill(165,29) adding: boot-130207.1520 (deflated 79%) test of /var/log/boot.msg.zip OK doneRunning sadc done Waiting for udev to settle... Scanning for LVM volume groups... 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 service boot.lvm done service boot.localfs start /etc/init.d/boot.localfs: line 23: /usr/sbin/iptables: No such file or
So where is /usr/share mounted?
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
On 2013-02-07 05:27 (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? ;-)
I won't be guessing. If you have Factory enabled on a 12.1 system I'm outa here. If I want a package from an alien repo, I download the package and install locally if it will let me without complaining about incompatible deps. Sysvinit-init except from a 12.1 repo isn't likely to be anything more than a problem creator. Mixing basesystem packages from different release versions can't be good for much other than making trouble. -- "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
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
Ken Schneider - openSUSE wrote:
On 02/07/2013 02:55 AM, 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. 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... -- 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
Felix Miata wrote:
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 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. 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). So can systemd be controlled? So far, everything along the way has been people telling me why Ishould be happy with new, broken functionality that I've been encountering since last summer when I first touch 12.2. I barely manage to fix one thing or my old process around it and some knew incompatibility crops up. -- 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
В Mon, 11 Feb 2013 12:41:02 -0800
Linda Walsh
Felix Miata wrote:
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 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.
Does not "nomodeset vga=text" do it? It -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Andrey Borzenkov -
Anton Aylward -
Felix Miata -
Ken Schneider - openSUSE -
Linda Walsh -
peter.chiu＠stfc.ac.uk