On Thursday, November 10, 2011 11:21:31 AM Brian K. White wrote:
On 11/10/2011 1:41 PM, David Hall wrote:
On Nov 9, 2011, at 12:36 AM, "Brian K. White"
wrote: I get all any user needs to get. If the distribution sucks, it sucks. You can't tell a user who pops the cd in, tries to use the system, and encounters all those problems, that it's their fault.
Those branding packages *break some systems*.
I also taboo them because I CAN NOT have grub loading gfxboot and I CAN NOT have the kernel trying to switch into graphical console modes, and I CAN NOT have any xdm-alike trying to start up at all. I can not have these things happen even the very first time so I can't let the installer install whatever and then go in and adjust config files to disable the problem actions. I will not be able to go in and do anything at all the instant any of those things happens the very first time. So I have to prevent them from even being installed in the first place during initial install, that way even if I miss one of the several manual things I have to do during text-only installs, and say, the menu.lst is left with the gfxboot line in it and uncommented, if it's not installed the line becomes harmless since the file isn't actually there and the console doesn't get killed and I can resume the install without having to boot the install media from the network to use it as a repair pla
tform.
When I remove the gfxboot, splashy and bootsplash packages, the branding packages "require" them, so the branding packages end up going too.
It not our fault for needing to prevent these things, it's the distros fault for being so thoughtlessly assembled that we have to go through such contortions just to get installed.
Either that or suse should just stop all pretense of being a suitable OS for servers.
During install, if you choose minimal server install, it seems to do what you want. Or you can choose minimal X and then uncheck gfxboot, splashy, and bootsplash.
I find opensuse to work perfectly for my servers, especially with the ease of pulling in OBS packages that I build specially for my needs.
-David
I install rather a lot of systems, remotely, text-only serial console and ssh. I know what it does and doesn't do. Unless something changed very recently in 12.1 because I haven't touched that yet, when you select the minimal text-only system, it still installs gfxboot, and the kernel is configured to switch to a graphical console mode. I have to fight the installer to prevent it from installing gfxboot, and I have to go around behind yasts's back and edit menu.lst manually, in another ssh session, after yast has finished writing the bootloader, but before allowing yast to exit, because when it exits the installer immediately reboots the system. Or, I have to pxe-boot the system to the installer again, don't run yast this time, use the shell to manually assemble the mdraid array and mount it, or mount the usb thumb drive whatever that box is booting from, manually edit menu.lst, umount and reboot and allow it to boot from the local disks and resume the install 2nd stage. That is a pain. Would bug fixes resolve this, or would some feature tweaks be necessary you think?
There are multiple dialogs in the bootloader screens in yast that look like they offer a way to do this all from within the installer nicely. There is an input line for the message file which contains the gfxboot file. Ok yay just clear that out, simple. Wrong. Yast just puts it back in there no matter what. That sounds like a fileable bug.
Ok there is an advanced option to edit the files directly, including menu.lst. Ok yay just use the advanced option to edit menu.lst directly and remove or comment out the gfxboot line. Wrong. It puts it back. Yet another fileable bug.
There may be a particular sequence of using the advanced option and then carefully avoiding one of the other screens that might prevent your manual edits from getting overwritten but I haven't found it.
After I overcome this install-time problem, it's basically better behaved for the rest of the life of the system, but maybe only because I never use the bootloader screen in yast after that, or maybe because by then I have gfxboot well and truly uninstalled and tabood, so even if the line reappears, it's harmless if the file isn't actually there. These are nice specific examples we could work on. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org