[CentOS] CentOS7 KDE - post-boot splash screen
Hello List Members, I decided to install C7 KDE on a workstation for a friend of mine. Works great, but the post-boot KDE splash screen (light blue and has 3 or more up ^ arrows that move from the lower center upwards) is a bit of a frustration for that person. I've determined that one can press the Escape key and move from that bluish splash to the login screen. (And at one point rolling the wheel on the mouse worked too, but didn't consistently cause the transition from splash to login screen.) At this point I think it's more ideal to just disable the splash screen and instead have the system go straight to the login screen (where user names are listed). Can that be done? Here's to hoping a KDE user or two on this list knows a solution. ;-) Thanks! -- ---~~.~~--- Mike // SilverTip257 // ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Grub legacy on Centos 7
On Sun, Aug 16, 2015 at 3:18 PM, Sachin Gupta wrote: > Hello Everyone, > > We have centos6 server. And we are planning to upgrade it to Centos7.And > GRUB 2 needs a new bios grub partition. BIOS boot partition is only necessary on GPT partitioned disks. For MBR partitioned disks, the GRUB 2 core.img goes into the MBR gap, the same as before. On rare occasion when the 1st partition starts at LBA 63 the core.img can't fit into the gap. The supported work around is repartitioning such that 1st partition starts at LBA 2048. The less supported and recommended work around is to use grub2-install with -f >Creating a new partition is too > much risky. It really isn't. You can use gparted to resize/move the /boot partition/volume safely and fast. And if it blows up just reformat it it in the installer which isn't a bad idea to do anyway. There's no need to keep an old CentOS 6 /boot partition around anyway. >I am wondering if it is possible to replace Grub2 with Grub > legacy on Centos7 machine? Yeah just yum erase grub2 and then force the installation of the CentOS 6 grub package; then run grub-install. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Grub legacy on Centos 7
On 8/16/2015 2:18 PM, Sachin Gupta wrote: We have centos6 server. And we are planning to upgrade it to Centos7.And GRUB 2 needs a new bios grub partition. Creating a new partition is too much risky. I am wondering if it is possible to replace Grub2 with Grub legacy on Centos7 machine? I would build the CentOS 7 machine on new hardware, bring it up in parallel, then cut your applications over to it, and redeploy the old hardware as something else. -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Grub legacy on Centos 7
Hello Everyone, We have centos6 server. And we are planning to upgrade it to Centos7.And GRUB 2 needs a new bios grub partition. Creating a new partition is too much risky. I am wondering if it is possible to replace Grub2 with Grub legacy on Centos7 machine? Thanks!! Sachin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Clunky Xorg with latest 6.7 upgrade?
On Fri, 2015-08-14 at 07:51 -0400, Bill Maltby (C4B) wrote: > > Ksnapshot region selection still lagging and jerky. > > So it would be easy to think some of this A.M.'s updates had a > beneficial effect in one regard, CPU, usage, but not in the clunky > behavior of region selection with Ksnapshot (could be a mouse driver > issue introduced with the 6.7 update?). > > But drawing any conclusion would be premature until I've run a normal > day and see if FF keeps increasing in CPU usage like it normally does, > the java applets, once I've several running, do the same, etc., and see > how Xorg CPU usage and region selection with Ksnapshot behave. Xorg CPU usage did increase, as before, under certain conditions of my test, and held up very high at times when I would not have expected that (like when the things that may have caused it are left idle with no activity for hours on end). Ksnapshot region selection had only minor, if any, improvement. This is subjective, so hard to be certain. > > I'll wrap up this thread this evening and thanks for your help Gordon! > > Bill To spare the list, most of whom likely have little interest, http://pastebin.com/6Gtf99fh contains the gory details of my attempt to find causation. Undertaking it over the weekend when certain possible causes weren't available was not optimal but I don't want to take too much away from my real-life needs to overcome deficiencies introduced by new ... "features". But I would like my 6-core AMD Linux home-built box to perform better than, or at least as well as, my *old* (2009?) 2-core HP AMD Windows 7 (now Windows 10) box. Yeah, it has more memory, 12GB vs. 8GB, and only runs a single user, but that's not enough to make much difference because it runs a really hoggish *huge* Java app all day while my Linux box just runs some spreadsheets and browser activities. Never thought I'd see the day when an *IX box couldn't keep up with that other stuff. One possible good may come from it - a possible clue to where to look next to fix the telinit 3/5 X screw up referenced in the big report posted in the CentOS mantis system back in ... Dec? Since RH doesn't have it I assume the same thing that caused run-level change to stop working correctly when X is active will cause it to not get fixed. On to the topic du jour ... First, a couple minor corrections. I erroneously provided CPU info from one of my other boxes in the OP. Actual CPU is $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1035T Processor stepping: 0 cpu MHz : 800.000 cache size : 512 KB ... cpu cores : 6 ... I also said "openoffice" when it's actually "libreoffice". My preliminary conclusion is there's something in java and/or libreoffice that begins causing load on the X server once activity begins. The full effects of the java applet in FF could not be determined during the attempt to duplicate due to the lack of a data feed Saturday and Sunday. There's apparently something somewhere that holds the X server load high even when the causative items are just sitting idle for extended periods. The Ksnapshot region selection is still clunky (tested again after this latest closing of the all spreadsheets and libreoffice) with noticeable lag to cursor movement and jerky progression of the window borders, as compared to CentOS pre-6.7 update. I doubt I have enough expertise to do anything more that could be worthwhile, but hope that maybe someone who has the interest and expertise might stumble upon, or pursue, a solution. Bill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] persistent change of max_stack_depth
On Aug 16, 2015 11:20, Leon Fauster wrote: > > Am 15.08.2015 um 23:38 schrieb Thomas Eriksson > : > > > > On Aug 15, 2015 13:23, Mark Milhollan wrote: > >> > >> On Fri, 14 Aug 2015, Thomas Eriksson wrote: > >> > >>> If it's centos 6 stick 'ulimit -s' in the init script > >> > >> I suggest putting it in the sysconfig file instead, if such exists. > >> > >> > > > > Sure, but how many init scripts provide for adding an extra command > > via sysconfig files? Most of them only allows for adding some predefined > > options to main service start command. > > > while processing the init script the sysconfig files are sourced and > completely > parsed as they where part of the init script. So, everything will > interpreted. > > -- > LF > Yes, you are absolutely correct, my bad. Thomas ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] persistent change of max_stack_depth
Am 15.08.2015 um 23:38 schrieb Thomas Eriksson : > > On Aug 15, 2015 13:23, Mark Milhollan wrote: >> >> On Fri, 14 Aug 2015, Thomas Eriksson wrote: >> >>> If it's centos 6 stick 'ulimit -s' in the init script >> >> I suggest putting it in the sysconfig file instead, if such exists. >> >> > > Sure, but how many init scripts provide for adding an extra command > via sysconfig files? Most of them only allows for adding some predefined > options to main service start command. while processing the init script the sysconfig files are sourced and completely parsed as they where part of the init script. So, everything will interpreted. -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
