RE: MATE on SL 7
Hi Guys I installed (yum groupinstall mate-desktop) on SL 7.2 and I can select MATE using the icon next to the "Sign In" button on the password entry screen. It seems to remember what your last selection was, too. Cheers Bill -Original message- > From:S. Tindall > Sent: Saturday 9th April 2016 10:15 > To: SL Users > Subject: Re: MATE on SL 7 > > On 04/06/2016 05:30 PM, Yasha Karant wrote: > > It appears that the software package GUI installer, gpk-application, > > does not have what is needed for an install of MATE > > under SL. (One evidently does not need MATE for SL 6 as Gnome 2 is part > > of the stock SL 6 distribution). During the base install of SL 7, > > I always install both whatever Gnome and KDE GUIs are supplied; thus the > > comment below about X windows is not relevant for my use. > > I do this on servers as well as workstations so that graphical machine > > "workload" display and analysis tools are available in addition to the > > scrolling text tools. (Sometimes a visualisation provides insight that > > a table or text does not.) > ... > > One workaround under SL7.2 is to switch your display manager from gdm to > lightdm, which will allow you to select MATE at login (upper right > corner). I think lightdm comes with the MATE desktop group. Otherwise, > look in epel. > > # uname -r > 3.10.0-327.13.1.el7.x86_64 > > # rpm -q system-switch-displaymanager lightdm > > system-switch-displaymanager-1.3-4.el7.nux.noarch > lightdm-1.10.5-6.el7.x86_64 > > # system-switch-displaymanager > Please specify one of either GDM, KDM, XDM, WDM or LIGHTDM. > > # system-switch-displaymanager LIGHTDM > Created symlink from /etc/systemd/system/display-manager.service to > /usr/lib/systemd/system/lightdm.service. > Your default graphical display manager has successfully been switched. > > # reboot > > Alternately, you can systemctl disable gdm, systemctl enable lightdm and > reboot. > > Your Mileage May Vary. > > BTW, a while back, MATE was installed locally on a SL7.1 system and it > continues to launch MATE under SL7.2 without any problems. Go figure. > > Steve > >
named-chroot issue - AGAIN
Hi guys Another named update and still the named-chroot.service file has not been fixed. It is really annoying to have to manually fix it every time, just to get DNS working after an update. Why is the -t /var/named/chroot option included in the ExecStart but not in the ExecStartPre ExecStartPre=/bin/bash -c 'if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi' ExecStart=/usr/sbin/named -u named -t /var/named/chroot $OPTIONS Surely named-checkconf should be run with the same named.conf file as named !!! This was reported back in November 2015 https://bugzilla.redhat.com/show_bug.cgi?id=1278082 This should have been fixed by now. How hard is a one line change to fix ??? Cheers Bill Maidment
RE: named-chroot issue - AGAIN
Hi again Seeing as I started all this with my original post. Perhaps I'd better close off by saying a couple of things. 1. It appears that the very process (ensuring no regression errors creep back in) that is stopping this problem being fixed in a reasonable time-scale, is the very same process that failed to stop this particular regression error. Some sort of twisted catch-22 logic there! 2. I put in an easy to monitor workaround, by setting DISABLE_ZONE_CHECKING="yes" in /etc/sysconfig/named. I can always run a manual named-chkconfig if I need to and now I won't get caught out on the next update. Cheers and thanks for all the valuable insights. Bill -Original message- > From:Steven Haigh > Sent: Saturday 19th March 2016 8:43 > To: scientific-linux-us...@fnal.gov > Subject: Re: named-chroot issue - AGAIN > > On 19/03/2016 1:31 AM, Tom H wrote: > > On Thu, Mar 17, 2016 at 11:17 PM, David Sommerseth > > wrote: > >> On 17/03/16 13:23, Tom H wrote: > >>> On Thu, Mar 17, 2016 at 12:53 PM, David Sommerseth > >>> wrote: > > Not going to argue that this could have been done better, I agree with > you > here. On the other hand, maybe *that* is one reason it takes time to get > this > issue resolved too? That Red Hat QE is working on improving the > situation, > adding needed regression tests and so on for this use case. I know I'm > speculating now, but I also know that these guys really do their best to > avoid > painful experiences for users and customers. Unfortunately, they do > mistakes > - as we all do from time to time. > >>> > >>> Given the > >>> https://git.centos.org/blobdiff/rpms!bind.git/d56ed2d3a2736a07a09c268f3b2607cca8f1b6ca/SOURCES!named-chroot.service > >>> commit, there's probably a lot of hype in RH's QA marketing claims. > >>> I'm not implying that there's no QA at all but, in this case, if there > >>> was any, it sucked. > >> > >> The people working on CentOS are not the same people working on RHEL, > >> even if they're working in the same company. And RHEL is still the > >> upstream source of CentOS. > >> > >> So if CentOS decides to fix this on their own, they need to keep track > >> of this until it's fixed in RHEL and then remove their own fix. Of > >> course SL could do that as well, but that can be a maintenance burden. > >> > >> That's the downside of being a downstream distro. > > > > Just because it's on git.centos.org doesn't mean that this is a CentOS > > change. It's an import from RH. CentOS doesn't diverge from RHEL with > > downstream patches. And, AFAIK, SL uses pristine RH sources and not > > those modified by CentOS. > > Correct - that was my point. This is part of a change that RH pushed > internally and to CentOS. The origin is RedHat - and the change shows > the source of the bug - RedHat :) > > -- > Steven Haigh > > Email: net...@crc.id.au > Web: https://www.crc.id.au > Phone: (03) 9001 6090 - 0412 935 897 > >
RE: Problem with setting permissions in /etc/fstab [RESOLVED]
Apparently, the /usr/lib/tmpfiles.d/ directory is a "blessing" from systemd. Permanent changes should be done by creating the changed file in /etc/tmpfiles.d/ We live and learn! -Original message- > From:Bill Maidment > Sent: Thursday 11th February 2016 15:49 > To: Bill Maidment ; Nico Kadel-Garcia > Cc: scientific-linux-us...@fnal.gov > Subject: RE: Problem with setting permissions in /etc/fstab [RESOLVED] > > Oops copied wrong line, try > z /var/spool/MD-Quarantine 0750 defang defang - - > > > -Original message- > > From:Bill Maidment > > Sent: Thursday 11th February 2016 15:46 > > To: Bill Maidment ; Nico Kadel-Garcia > > Cc: scientific-linux-us...@fnal.gov > > Subject: RE: Problem with setting permissions in /etc/fstab [RESOLVED] > > > > Nico > > The issue has been resolved. > > I discovered a file /usr/lib/tmpfiles.d/mimedefang.conf which contained the > > following line (among others): > > z /var/spool/MD-Quarantine 0750 defang defang - - > > > > This is obvious used in a chmod call. > > Altering 0750 to 0770 got me back in business. > > > > Cheers > > Bill > > > > -Original message- > > > From:Bill Maidment > > > Sent: Tuesday 9th February 2016 15:21 > > > To: Nico Kadel-Garcia > > > Cc: scientific-linux-us...@fnal.gov > > > Subject: RE: Problem with setting permissions in /etc/fstab > > > > > > Nico > > > Thanks for your suggestions. > > > I know it is not a typo as I did copy and paste into the second machine > > > /etc/fstab and it worked. > > > I note that /etc/mtab contains > > > /dev/shm /var/spool/MIMEDefang tmpfs > > > rw,relatime,size=262144k,mode=770,uid=991,gid=990 0 0 > > > so it looks like the mount is working OK. > > > > > > I believe your other suggestion might well be the cause and I am trying > > > to locate which service is causing the issue. > > > /etc/passwd has > > > defang:x:991:990:MIMEDefang User:/var/spool/MIMEDefang:/sbin/nologin > > > May be this is causing something to go wrong. > > > > > > Still searching..... > > > > > > Cheers > > > Bill > > > > > > -Original message- > > > > From:Nico Kadel-Garcia > > > > Sent: Monday 8th February 2016 23:41 > > > > To: Bill Maidment > > > > Cc: scientific-linux-us...@fnal.gov > > > > Subject: Re: Problem with setting permissions in /etc/fstab > > > > > > > > On Mon, Feb 8, 2016 at 1:26 AM, Bill Maidment wrote: > > > > > An update. > > > > > I have put the same /etc/fstab entry in another SL7.2 machine and it > > > > > sets the permissions correctly on boot. > > > > > > > > > > On the problem machine I have tried setting the permissions on the > > > > > directory to 0770 before rebooting, but something is setting it to > > > > > 0750 on boot. > > > > > A manual mount works fine with: > > > > > mount -t tmpfs -o size=256m,mode=0770,uid=defang,gid=defang /dev/shm > > > > > /var/spool/MIMEDefang > > > > > > > > > > So what can be upsetting the /etc/fstab mount? > > > > > > > > > > I'm stumped! > > > > > > > > > > Cheers > > > > > Bill > > > > > > > > Do you have a typo in /etc/fstab, perhaps? Or some other management > > > > process, such as chef, puppet, cfentine, etc. that make might be > > > > resetting directory permissions. > > > > > > > > > > > > > > > >
RE: Problem with setting permissions in /etc/fstab [RESOLVED]
Oops copied wrong line, try z /var/spool/MD-Quarantine 0750 defang defang - - -Original message- > From:Bill Maidment > Sent: Thursday 11th February 2016 15:46 > To: Bill Maidment ; Nico Kadel-Garcia > Cc: scientific-linux-us...@fnal.gov > Subject: RE: Problem with setting permissions in /etc/fstab [RESOLVED] > > Nico > The issue has been resolved. > I discovered a file /usr/lib/tmpfiles.d/mimedefang.conf which contained the > following line (among others): > z /var/spool/MD-Quarantine 0750 defang defang - - > > This is obvious used in a chmod call. > Altering 0750 to 0770 got me back in business. > > Cheers > Bill > > -Original message- > > From:Bill Maidment > > Sent: Tuesday 9th February 2016 15:21 > > To: Nico Kadel-Garcia > > Cc: scientific-linux-us...@fnal.gov > > Subject: RE: Problem with setting permissions in /etc/fstab > > > > Nico > > Thanks for your suggestions. > > I know it is not a typo as I did copy and paste into the second machine > > /etc/fstab and it worked. > > I note that /etc/mtab contains > > /dev/shm /var/spool/MIMEDefang tmpfs > > rw,relatime,size=262144k,mode=770,uid=991,gid=990 0 0 > > so it looks like the mount is working OK. > > > > I believe your other suggestion might well be the cause and I am trying to > > locate which service is causing the issue. > > /etc/passwd has > > defang:x:991:990:MIMEDefang User:/var/spool/MIMEDefang:/sbin/nologin > > May be this is causing something to go wrong. > > > > Still searching. > > > > Cheers > > Bill > > > > -Original message- > > > From:Nico Kadel-Garcia > > > Sent: Monday 8th February 2016 23:41 > > > To: Bill Maidment > > > Cc: scientific-linux-us...@fnal.gov > > > Subject: Re: Problem with setting permissions in /etc/fstab > > > > > > On Mon, Feb 8, 2016 at 1:26 AM, Bill Maidment wrote: > > > > An update. > > > > I have put the same /etc/fstab entry in another SL7.2 machine and it > > > > sets the permissions correctly on boot. > > > > > > > > On the problem machine I have tried setting the permissions on the > > > > directory to 0770 before rebooting, but something is setting it to 0750 > > > > on boot. > > > > A manual mount works fine with: > > > > mount -t tmpfs -o size=256m,mode=0770,uid=defang,gid=defang /dev/shm > > > > /var/spool/MIMEDefang > > > > > > > > So what can be upsetting the /etc/fstab mount? > > > > > > > > I'm stumped! > > > > > > > > Cheers > > > > Bill > > > > > > Do you have a typo in /etc/fstab, perhaps? Or some other management > > > process, such as chef, puppet, cfentine, etc. that make might be > > > resetting directory permissions. > > > > > > > > > >
RE: Problem with setting permissions in /etc/fstab [RESOLVED]
Nico The issue has been resolved. I discovered a file /usr/lib/tmpfiles.d/mimedefang.conf which contained the following line (among others): z /var/spool/MD-Quarantine 0750 defang defang - - This is obvious used in a chmod call. Altering 0750 to 0770 got me back in business. Cheers Bill -Original message- > From:Bill Maidment > Sent: Tuesday 9th February 2016 15:21 > To: Nico Kadel-Garcia > Cc: scientific-linux-us...@fnal.gov > Subject: RE: Problem with setting permissions in /etc/fstab > > Nico > Thanks for your suggestions. > I know it is not a typo as I did copy and paste into the second machine > /etc/fstab and it worked. > I note that /etc/mtab contains > /dev/shm /var/spool/MIMEDefang tmpfs > rw,relatime,size=262144k,mode=770,uid=991,gid=990 0 0 > so it looks like the mount is working OK. > > I believe your other suggestion might well be the cause and I am trying to > locate which service is causing the issue. > /etc/passwd has > defang:x:991:990:MIMEDefang User:/var/spool/MIMEDefang:/sbin/nologin > May be this is causing something to go wrong. > > Still searching. > > Cheers > Bill > > -Original message----- > > From:Nico Kadel-Garcia > > Sent: Monday 8th February 2016 23:41 > > To: Bill Maidment > > Cc: scientific-linux-us...@fnal.gov > > Subject: Re: Problem with setting permissions in /etc/fstab > > > > On Mon, Feb 8, 2016 at 1:26 AM, Bill Maidment wrote: > > > An update. > > > I have put the same /etc/fstab entry in another SL7.2 machine and it sets > > > the permissions correctly on boot. > > > > > > On the problem machine I have tried setting the permissions on the > > > directory to 0770 before rebooting, but something is setting it to 0750 > > > on boot. > > > A manual mount works fine with: > > > mount -t tmpfs -o size=256m,mode=0770,uid=defang,gid=defang /dev/shm > > > /var/spool/MIMEDefang > > > > > > So what can be upsetting the /etc/fstab mount? > > > > > > I'm stumped! > > > > > > Cheers > > > Bill > > > > Do you have a typo in /etc/fstab, perhaps? Or some other management > > process, such as chef, puppet, cfentine, etc. that make might be > > resetting directory permissions. > > > > > >
RE: SL 7.2 not booting on HP Microserver N36L
Sorry. I spoke too soon. I still have a machine that fails to boot without this extra parameter. Using kernel-3.10.0-327.4.5 -Original message- > From:Bill Maidment > Sent: Thursday 11th February 2016 9:35 > To: Nico Kadel-Garcia ; Eero Volotinen > > Cc: o...@ieee.org; scientific-linux-us...@fnal.gov > > Subject: RE: SL 7.2 not booting on HP Microserver N36L > > Yes. It's fixed for me in latest kernel > > > -Original message- > > From:Nico Kadel-Garcia > > Sent: Thursday 11th February 2016 1:04 > > To: Eero Volotinen > > Cc: o...@ieee.org; scientific-linux-us...@fnal.gov > > > > Subject: Re: SL 7.2 not booting on HP Microserver N36L > > > > On Wed, Feb 10, 2016 at 4:12 AM, Eero Volotinen > > wrote: > > > Try this kernel parameter on boot for workaround: > > > initcall_blacklist=clocksource_done_booting > > > > > > -- > > > Eero > > > > I ran into a very similar issue myself yesterday trying to install 7.2 > > on a server. I'll try that one myself. > > > > Is it fixed in the latest update kernels? Any idea? > > > > > >
RE: SL 7.2 not booting on HP Microserver N36L
Yes. It's fixed for me in latest kernel -Original message- > From:Nico Kadel-Garcia > Sent: Thursday 11th February 2016 1:04 > To: Eero Volotinen > Cc: o...@ieee.org; scientific-linux-us...@fnal.gov > > Subject: Re: SL 7.2 not booting on HP Microserver N36L > > On Wed, Feb 10, 2016 at 4:12 AM, Eero Volotinen wrote: > > Try this kernel parameter on boot for workaround: > > initcall_blacklist=clocksource_done_booting > > > > -- > > Eero > > I ran into a very similar issue myself yesterday trying to install 7.2 > on a server. I'll try that one myself. > > Is it fixed in the latest update kernels? Any idea? > >
RE: Problem with setting permissions in /etc/fstab
Nico Thanks for your suggestions. I know it is not a typo as I did copy and paste into the second machine /etc/fstab and it worked. I note that /etc/mtab contains /dev/shm /var/spool/MIMEDefang tmpfs rw,relatime,size=262144k,mode=770,uid=991,gid=990 0 0 so it looks like the mount is working OK. I believe your other suggestion might well be the cause and I am trying to locate which service is causing the issue. /etc/passwd has defang:x:991:990:MIMEDefang User:/var/spool/MIMEDefang:/sbin/nologin May be this is causing something to go wrong. Still searching. Cheers Bill -Original message- > From:Nico Kadel-Garcia > Sent: Monday 8th February 2016 23:41 > To: Bill Maidment > Cc: scientific-linux-us...@fnal.gov > Subject: Re: Problem with setting permissions in /etc/fstab > > On Mon, Feb 8, 2016 at 1:26 AM, Bill Maidment wrote: > > An update. > > I have put the same /etc/fstab entry in another SL7.2 machine and it sets > > the permissions correctly on boot. > > > > On the problem machine I have tried setting the permissions on the > > directory to 0770 before rebooting, but something is setting it to 0750 on > > boot. > > A manual mount works fine with: > > mount -t tmpfs -o size=256m,mode=0770,uid=defang,gid=defang /dev/shm > > /var/spool/MIMEDefang > > > > So what can be upsetting the /etc/fstab mount? > > > > I'm stumped! > > > > Cheers > > Bill > > Do you have a typo in /etc/fstab, perhaps? Or some other management > process, such as chef, puppet, cfentine, etc. that make might be > resetting directory permissions. > >
RE: Problem with setting permissions in /etc/fstab
An update. I have put the same /etc/fstab entry in another SL7.2 machine and it sets the permissions correctly on boot. On the problem machine I have tried setting the permissions on the directory to 0770 before rebooting, but something is setting it to 0750 on boot. A manual mount works fine with: mount -t tmpfs -o size=256m,mode=0770,uid=defang,gid=defang /dev/shm /var/spool/MIMEDefang So what can be upsetting the /etc/fstab mount? I'm stumped! Cheers Bill -Original message- > From:Bill Maidment > Sent: Sunday 7th February 2016 17:49 > To: scientific-linux-us...@fnal.gov > Subject: Problem with setting permissions in /etc/fstab > > Hi > After the recent rounds of updates in SL7 I have found that the mode > parameter in /etc/fstab doesn't seem to be working: > I Have this line in /etc/fstab > > none /var/spool/MIMEDefang tmpfs > mode=0770,size=256M,uid=defang,gid=defang 0 0 > > but the directory is set up on reboot with 0750 > I have to manually issue chmod 0770 to get clamd working. > > Has anyone else come across this issue, or is there an obvious solution that > I have overlooked? > > Cheers > Bill Maidment > >
Problem with setting permissions in /etc/fstab
Hi After the recent rounds of updates in SL7 I have found that the mode parameter in /etc/fstab doesn't seem to be working: I Have this line in /etc/fstab none/var/spool/MIMEDefang tmpfs mode=0770,size=256M,uid=defang,gid=defang 0 0 but the directory is set up on reboot with 0750 I have to manually issue chmod 0770 to get clamd working. Has anyone else come across this issue, or is there an obvious solution that I have overlooked? Cheers Bill Maidment
RE: Upgrading SL 7.1 to SL 7.2 - auto update switched back on
That should have been /etc/yum/yum-cron.conf -Original message- > From:Bill Maidment > Sent: Saturday 6th February 2016 16:21 > To: scientific-linux-us...@fnal.gov > Subject: Upgrading SL 7.1 to SL 7.2 - auto update switched back on > > Be aware > The upgrade overwrites /etc/yum/yum.conf (putting the old file in > /etc/yum/yum.conf.saved). > All for the sake of a few changed comment lines. > > Cheers > Bill Maidment > >
Upgrading SL 7.1 to SL 7.2 - auto update switched back on
Be aware The upgrade overwrites /etc/yum/yum.conf (putting the old file in /etc/yum/yum.conf.saved). All for the sake of a few changed comment lines. Cheers Bill Maidment
RE: Problem with GnuCash after recent Scientific Linux 7.1 updates
Hi James I installed gnucash (I had to install geoclue2-2.1.10-2.el7.x86_64.rpm first) and I get the same error on SL 7.1 However, when I install gnucash on SL 7.2RC everything works OK. It seems that EPEL is ahead of SL7. BUT next week it should all be sorted out ;-) Cheers Bill -Original message- > From:James M. Pulver > Sent: Sunday 31st January 2016 1:35 > To: scientific-linux-us...@fnal.gov > Subject: Problem with GnuCash after recent Scientific Linux 7.1 updates > > Every time I try and start it, I get > gnucash: symbol lookup error: /usr/lib64/libwebkitgtk-1.0.so.0: undefined > symbol: _gst_tag_list_type > > The GnuCash IRC helped me to figure out that it seems to be an issue with > some dependencies not being filled for the package that provides that file? > > > Any ideas how to resolve this? I've installed gnucash from EPEL-Testing now > to get the latest version, but had this same problem with the version I had > used successfully before from Nux. > > -- > James Pulver
RE: [SCIENTIFIC-LINUX-USERS] Wireshark broken os SL6x
Hi Pat That fixed it. Thanks. Regards Bill Maidment -Original message- > From:Pat Riehecky > Sent: Saturday 25th October 2014 3:10 > To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: Re: [SCIENTIFIC-LINUX-USERS] Wireshark broken os SL6x > > I've just pushed the 6.6 gtk (and its dependencies) into the sl-testing > repo. > > Does > > yum --enablerepo=sl-testing update gtk2 > > resolve your issue? > > Pat > > On 10/24/2014 03:36 AM, Bill Maidment wrote: > > It looks like we need a new version of gtk2 > > Current version is gtk2-2.20.1-4.el6.x86_64 > > gtk2-2.24 is required for gtk_combo_box_text_new_with_entry > > > > > > Regards > > Bill Maidment > > > > -Original message- > >> From:Bill Maidment > >> Sent: Friday 24th October 2014 18:01 > >> To: scientific-linux-us...@fnal.gov > >> Subject: Wireshark broken os SL6x > >> > >> After the latest yum update, wireshark fails with: > >> wireshark: symbol lookup error: wireshark: undefined symbol: > >> gtk_combo_box_text_new_with_entry > >> wireshark-1.8.10-8.el6_6.x86_64 > >> > >> Regards > >> Bill Maidment > >> Landline: +61 2 4472 9374 > >> Mobile: +61 418 682 993 > >> Web: www.maidment.me > >> > >> > > > -- > Pat Riehecky > > Scientific Linux developer > http://www.scientificlinux.org/ > >
RE: SL7rc2 grub2 setting wrong kernel version as default after a kernel update
Thanks again Akemi. When I looked at the bugzilla there was a new fix (for /usr/share/grub/grub-mkconfig_lib) suggested today that worked for me. Regards Bill Maidment -Original message- > From:Akemi Yagi > Sent: Thursday 9th October 2014 23:51 > To: Users, Scientific Linux (SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV) > > Subject: Re: SL7rc2 grub2 setting wrong kernel version as default after a > kernel update > > On Thu, Oct 9, 2014 at 3:20 AM, Bill Maidment wrote: > > After a yum update the latest kernel is set as the second entry rather than > > the first entry in the boot menu. > > This seems to be because it sorts the kernel name using a simple > > alpha-numeric test rather than a more intelligent version number test > > What you are seeing is a known bug as detailed in this upstream bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=1124074 > > Akemi > >
RE: SL7rc2 grub2 setting wrong kernel version as default after a kernel update
Hmmm. Maybe adding /etc/grub,d/11_windows7 and running grub2-mkconfig -o /boot/grub2/grub.cfg upset the default. Should I have run grub2-set-default ? Regards Bill Maidment -Original message- > From:Bill Maidment > Sent: Thursday 9th October 2014 21:23 > To: Users, Scientific Linux (SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV) > > Subject: SL7rc2 grub2 setting wrong kernel version as default after a kernel > update > > After a yum update the latest kernel is set as the second entry rather than > the first entry in the boot menu. > This seems to be because it sorts the kernel name using a simple > alpha-numeric test rather than a more intelligent version number test > > Regards > Bill Maidment > Landline: 02 4472 9374 > Mobile: 0418 682 993 > Web: www.maidment.me > >
SL7rc2 grub2 setting wrong kernel version as default after a kernel update
After a yum update the latest kernel is set as the second entry rather than the first entry in the boot menu. This seems to be because it sorts the kernel name using a simple alpha-numeric test rather than a more intelligent version number test Regards Bill Maidment Landline: 02 4472 9374 Mobile: 0418 682 993 Web: www.maidment.me
RE: SL7rc Dual Boot Issues
Thanks Akemi.
That's exactly what I needed to make it permanent.
Regards
Bill Maidment
-Original message-
> From:Akemi Yagi
> Sent: Wednesday 8th October 2014 11:59
> To: Bill Maidment
> Cc: Users, Scientific Linux (SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV)
>
> Subject: Re: SL7rc Dual Boot Issues
>
> On Mon, Oct 6, 2014 at 6:38 PM, Bill Maidment wrote:
> > Looking at the Disk utility, it turns out that the install had set up the
> > disks correctly, in spite of what the install menu showed.
> > I added the following to /etc/grub2/grub.cfg just after the 10-linux
> > section:
> >
> > menuentry "Windows 7 Professional SP1" {
> > insmod ntfs
> > set root=(hd1,2)
> > chainloader +1 }
> >
> > And all is working OK, except now I have a laptop fan running all the time
> > at full speed.
>
> Did you mean the /boot/grub2/grub.cfg file? If so, your edit will be
> wiped clean when grub2-mkconfig is run next time (kernel update etc).
>
> To modify grub.cfg, you'd need to create a file in /etc/grub.d/ (for
> example, 11_Windows7):
>
> #! /bin/bash
> echo "Adding Windows7"
> cat << EOF
> menuentry "Windows7" {
> set root=hd0(1,2)
> chainloader +1
> }
> EOF
>
> Make the file executable and then run:
>
> grub2-mkconfig -o /boot/grub2/grub.cfg
>
> Akemi
>
>
RE: SL7rc Dual Boot Issues
Looking at the Disk utility, it turns out that the install had set up the disks
correctly, in spite of what the install menu showed.
I added the following to /etc/grub2/grub.cfg just after the 10-linux section:
menuentry "Windows 7 Professional SP1" {
insmod ntfs
set root=(hd1,2)
chainloader +1 }
And all is working OK, except now I have a laptop fan running all the time at
full speed.
Regards
Bill Maidment
-Original message-
> From:Bill Maidment
> Sent: Tuesday 7th October 2014 10:29
> To: Users, Scientific Linux (SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV)
>
> Subject: SL7rc Dual Boot Issues
>
> I have been using dual boot SL6.5 and Windows 7 successfully on my laptop.
> The disk setup is:
> HD0 - /dev/sda - Seagate - SL6.5
> HD1 - /dev/sdb - Toshiba - Windows 7
> HD2 - /dev/sdc - MSATA - cache for Windows 7
>
> I replaced the Seagate drive with a spare Seagate and when I tried installing
> SL7rc2 the installer recognised only the Seagate disk as /dev/sdb - no
> mention of sda or sdc.
> The installation went OK and SL7 booted and ran OK, But I can't access the
> Windows disk.
>
> I looked at the grub2 configuration and realised that I was completely out of
> my depth. How could the simplicity of the old grub be so bastardised
> Swapping back to the original Seagate drive gave me back my original setup
> with no damage done.
>
> Can anyone point me in the right direction to get these drives correctly
> recognised in the SL7 installer and grub2?
>
> Regards
> Bill Maidment
>
>
SL7rc Dual Boot Issues
I have been using dual boot SL6.5 and Windows 7 successfully on my laptop. The disk setup is: HD0 - /dev/sda - Seagate - SL6.5 HD1 - /dev/sdb - Toshiba - Windows 7 HD2 - /dev/sdc - MSATA - cache for Windows 7 I replaced the Seagate drive with a spare Seagate and when I tried installing SL7rc2 the installer recognised only the Seagate disk as /dev/sdb - no mention of sda or sdc. The installation went OK and SL7 booted and ran OK, But I can't access the Windows disk. I looked at the grub2 configuration and realised that I was completely out of my depth. How could the simplicity of the old grub be so bastardised Swapping back to the original Seagate drive gave me back my original setup with no damage done. Can anyone point me in the right direction to get these drives correctly recognised in the SL7 installer and grub2? Regards Bill Maidment
FW: 7rolling rsync not fully populated
-Original message- > From:Bill Maidment > Sent: Saturday 27th September 2014 11:34 > To: scientific-linux-de...@fnal.gov > Subject: 7rolling rsync not fully populated > > Hi Pat > Thanks for the hard work. You guys have been busy!!! > > It appears that the rsync server does not have all the changes yet in > 7rolling. In particulatr: > -rw-r--r-- 1 root root 6702497792 Sep 17 03:30 > SL-7-x86_64-Everything-Dual-Layer-DVD.iso > -rw-r--r-- 1 root root 413138944 Sep 17 03:30 SL-7-x86_64-netinst.iso > are still the old isos > > At what point is 7rolling moved to 7x or 7 ? I seem to remeber an earlier > email stating this would be at RC time. > > Regards > Bill Maidment
RE: Installation of SL7 as a guest vm using virt-manager broken?
I've just installed a VM with 6GB RAM and 4 CPU with no problems. Post install setup seems to take a long time (9 minutes) or am I just impatient? I'm still getting the redhat EULA message (see attached). When I look at the EULA it refers to RHEL6 !!! -Original message- > From:Bill Maidment > Sent: Saturday 26th July 2014 19:31 > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: RE: Installation of SL7 as a guest vm using virt-manager broken? > > I've just tried SL7Beta1 and I get a freeze up with 100% CPU using 1 CPU and > 1GB RAM. > Tried with 2 CPU and 1GB RAM still froze. > Tried with 2 CPU and 2GB RAM and got an anaconda error as attached. > > > -Original message- > > From:Bill Maidment > > Sent: Saturday 26th July 2014 18:59 > > To: Peter Boy ; > > SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > > Subject: RE: Installation of SL7 as a guest vm using virt-manager broken? > > > > When I installed SL7alpha1 using pxe on SL6.5 host I got a similar problem > > with 1GB RAM and 1 CPU on the guest. Ever since I have used 2GB and 2 CPU > > with no problems. > > I've not tried SL7Beta1 yet. > > Cheers > > > > > > -Original message- > > > From:Peter Boy > > > Sent: Saturday 26th July 2014 18:35 > > > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > > > Subject: Installation of SL7 as a guest vm using virt-manager broken? > > > > > > Yesterday (25 July) I tried to install SL7 as a guest vm on a 6.5 host > > > system (install over network from the os subdirectory using an official > > > mirror). I could proceed up to the message „creating domain …“ (and the > > > new domain was added to the domain list in virt-manager). The vnc window > > > opened, a message alike „connecting ….“ appeared and than the window got > > > black and empty. Virt-manager indicated some activity for the domain, but > > > after several seconds all activities ceased, nothing happened anymore. > > > When I moved the mouse pointer over that black window, the pointer > > > disappeared (for the first seconds I could move the mouse pointer over > > > that black window). > > > > > > I repeated the very same procedure with 6.5 and everything installed just > > > fine. So I hope I didn’t made a silly mistake. > > > > > > Could anybody successfully install SL 7 as a guest VM? > > > > > > > > > > > > > > > > > > — > > > Dr. Peter Boy > > > Universität Bremen > > > Mary-Somerville-Str. 5 > > > 28359 Bremen > > > Germany > > > > > > p...@zes.uni-bremen.de > > > www.zes.uni-bremen.de > > > > > > > > > > > > Are you looking for a web content management system for scientific > > > research organizations? > > > Have a look at http://www.scientificcms.org > > > > > > > > > >
RE: Installation of SL7 as a guest vm using virt-manager broken?
I've just tried SL7Beta1 and I get a freeze up with 100% CPU using 1 CPU and 1GB RAM. Tried with 2 CPU and 1GB RAM still froze. Tried with 2 CPU and 2GB RAM and got an anaconda error as attached. -Original message- > From:Bill Maidment > Sent: Saturday 26th July 2014 18:59 > To: Peter Boy ; > SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: RE: Installation of SL7 as a guest vm using virt-manager broken? > > When I installed SL7alpha1 using pxe on SL6.5 host I got a similar problem > with 1GB RAM and 1 CPU on the guest. Ever since I have used 2GB and 2 CPU > with no problems. > I've not tried SL7Beta1 yet. > Cheers > > > -Original message- > > From:Peter Boy > > Sent: Saturday 26th July 2014 18:35 > > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > > Subject: Installation of SL7 as a guest vm using virt-manager broken? > > > > Yesterday (25 July) I tried to install SL7 as a guest vm on a 6.5 host > > system (install over network from the os subdirectory using an official > > mirror). I could proceed up to the message „creating domain …“ (and the new > > domain was added to the domain list in virt-manager). The vnc window > > opened, a message alike „connecting ….“ appeared and than the window got > > black and empty. Virt-manager indicated some activity for the domain, but > > after several seconds all activities ceased, nothing happened anymore. When > > I moved the mouse pointer over that black window, the pointer disappeared > > (for the first seconds I could move the mouse pointer over that black > > window). > > > > I repeated the very same procedure with 6.5 and everything installed just > > fine. So I hope I didn’t made a silly mistake. > > > > Could anybody successfully install SL 7 as a guest VM? > > > > > > > > > > > > — > > Dr. Peter Boy > > Universität Bremen > > Mary-Somerville-Str. 5 > > 28359 Bremen > > Germany > > > > p...@zes.uni-bremen.de > > www.zes.uni-bremen.de > > > > > > > > Are you looking for a web content management system for scientific research > > organizations? > > Have a look at http://www.scientificcms.org > > > > > >
RE: Installation of SL7 as a guest vm using virt-manager broken?
When I installed SL7alpha1 using pxe on SL6.5 host I got a similar problem with 1GB RAM and 1 CPU on the guest. Ever since I have used 2GB and 2 CPU with no problems. I've not tried SL7Beta1 yet. Cheers -Original message- > From:Peter Boy > Sent: Saturday 26th July 2014 18:35 > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: Installation of SL7 as a guest vm using virt-manager broken? > > Yesterday (25 July) I tried to install SL7 as a guest vm on a 6.5 host system > (install over network from the os subdirectory using an official mirror). I > could proceed up to the message „creating domain …“ (and the new domain was > added to the domain list in virt-manager). The vnc window opened, a message > alike „connecting ….“ appeared and than the window got black and empty. > Virt-manager indicated some activity for the domain, but after several > seconds all activities ceased, nothing happened anymore. When I moved the > mouse pointer over that black window, the pointer disappeared (for the first > seconds I could move the mouse pointer over that black window). > > I repeated the very same procedure with 6.5 and everything installed just > fine. So I hope I didn’t made a silly mistake. > > Could anybody successfully install SL 7 as a guest VM? > > > > > > — > Dr. Peter Boy > Universität Bremen > Mary-Somerville-Str. 5 > 28359 Bremen > Germany > > p...@zes.uni-bremen.de > www.zes.uni-bremen.de > > > > Are you looking for a web content management system for scientific research > organizations? > Have a look at http://www.scientificcms.org > >
RE: SL7 Alpha USB install issue - solved
Solved. http://www.cyberciti.biz/faq/linux-create-a-bootable-usb-pen/ showed me the principles. -Original message- > From:Bill Maidment > Sent: Tuesday 8th July 2014 21:40 > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: SL7 Alpha USB install issue > > I created a USB install drive (16GB) using: > livecd-iso-to-disk --format --reset-mbr SL-7-x86_64-DVD.iso /dev/sdd > It boots OK, But it only does a network install. What am I doing wrong? > > Regards > Bill Maidment > >
SL7 Alpha USB install issue
I created a USB install drive (16GB) using: livecd-iso-to-disk --format --reset-mbr SL-7-x86_64-DVD.iso /dev/sdd It boots OK, But it only does a network install. What am I doing wrong? Regards Bill Maidment
RE: Scientific Linux 7 ALPHA
Yes. It is reproducible. The major difference between the RHEL7rc install and the SL7alpha install is that RHEL7rc was bare-metal and SL7alpha was a KVM guest under SL6.5 host. -Original message- > From:Bill Maidment > Sent: Tuesday 8th July 2014 10:51 > To: Pat Riehecky ; > SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; > scientific-linux-de...@listserv.fnal.gov > Subject: RE: Scientific Linux 7 ALPHA > > I think this may be an SL issue as python-ethtool installed OK with RHEL7rc. > I'll try a fresh install of SL7alpha to see if it is reproducible. > > > -Original message- > > From:Pat Riehecky > > Sent: Tuesday 8th July 2014 1:36 > > To: Bill Maidment ; > > SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; > > scientific-linux-de...@listserv.fnal.gov > > Subject: Re: Scientific Linux 7 ALPHA > > > > That's not right... > > > > Looks like we need an upstream bug for that. > > > > Pat > > > > On 07/04/2014 10:35 PM, Bill Maidment wrote: > > > The actual error was caused by python-ethtool not being installed, so > > > firstboot crashed. > > > > > > > > > -Original message- > > >> From:Bill Maidment > > >> Sent: Saturday 5th July 2014 11:13 > > >> To: Pat Riehecky ; > > >> SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > > >> Subject: RE: Scientific Linux 7 ALPHA > > >> > > >> Pat > > >> I'm getting the following error report at logon: > > >> > > >> Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 > > >> ABRT has detected 1 problem(s). For more info run: abrt-cli list --since > > >> 1404480973 > > >> > > >> [root@sl7 ~]# abrt-cli list --since 1404480973 > > >> id 2dcb3b8c827f788139fffe4995e64f615530216e > > >> Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 > > >> count: 8 > > >> executable: /usr/sbin/firstboot > > >> package: firstboot-19.9-1.el7 > > >> time: Sat 05 Jul 2014 02:28:51 EST > > >> uid: 0 > > >> Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for > > >> creating a case in Red Hat Customer Portal > > >> > > >> The Autoreporting feature is disabled. Please consider enabling it by > > >> issuing > > >> 'abrt-auto-reporting enabled' as a user with root privileges > > >> [root@sl7 ~]# > > >> > > >> Is this a TUV reference/script to be removed? > > >> > > >> Cheers > > >> Bill > > >> > > >> -Original message- > > >>> From:Pat Riehecky > > >>> Sent: Friday 4th July 2014 7:23 > > >>> To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > > >>> Subject: Scientific Linux 7 ALPHA > > >>> > > >>> Users interested in Scientific Linux 7 ALPHA can review: > > >>> > > >>> http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-linux-devel&T=0&X=30246605F08F0DC7ED&P=74 > > >>> > > >>> -- > > >>> Pat Riehecky > > >>> > > >>> Scientific Linux developer > > >>> http://www.scientificlinux.org/ > > >>> > > >>> > > >> > > > > > > -- > > Pat Riehecky > > > > Scientific Linux developer > > http://www.scientificlinux.org/ > > > > > >
RE: Scientific Linux 7 ALPHA
I think this may be an SL issue as python-ethtool installed OK with RHEL7rc. I'll try a fresh install of SL7alpha to see if it is reproducible. -Original message- > From:Pat Riehecky > Sent: Tuesday 8th July 2014 1:36 > To: Bill Maidment ; > SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; > scientific-linux-de...@listserv.fnal.gov > Subject: Re: Scientific Linux 7 ALPHA > > That's not right... > > Looks like we need an upstream bug for that. > > Pat > > On 07/04/2014 10:35 PM, Bill Maidment wrote: > > The actual error was caused by python-ethtool not being installed, so > > firstboot crashed. > > > > > > -Original message- > >> From:Bill Maidment > >> Sent: Saturday 5th July 2014 11:13 > >> To: Pat Riehecky ; > >> SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > >> Subject: RE: Scientific Linux 7 ALPHA > >> > >> Pat > >> I'm getting the following error report at logon: > >> > >> Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 > >> ABRT has detected 1 problem(s). For more info run: abrt-cli list --since > >> 1404480973 > >> > >> [root@sl7 ~]# abrt-cli list --since 1404480973 > >> id 2dcb3b8c827f788139fffe4995e64f615530216e > >> Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 > >> count: 8 > >> executable: /usr/sbin/firstboot > >> package: firstboot-19.9-1.el7 > >> time: Sat 05 Jul 2014 02:28:51 EST > >> uid: 0 > >> Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for > >> creating a case in Red Hat Customer Portal > >> > >> The Autoreporting feature is disabled. Please consider enabling it by > >> issuing > >> 'abrt-auto-reporting enabled' as a user with root privileges > >> [root@sl7 ~]# > >> > >> Is this a TUV reference/script to be removed? > >> > >> Cheers > >> Bill > >> > >> -Original message- > >>> From:Pat Riehecky > >>> Sent: Friday 4th July 2014 7:23 > >>> To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > >>> Subject: Scientific Linux 7 ALPHA > >>> > >>> Users interested in Scientific Linux 7 ALPHA can review: > >>> > >>> http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-linux-devel&T=0&X=30246605F08F0DC7ED&P=74 > >>> > >>> -- > >>> Pat Riehecky > >>> > >>> Scientific Linux developer > >>> http://www.scientificlinux.org/ > >>> > >>> > >> > > > -- > Pat Riehecky > > Scientific Linux developer > http://www.scientificlinux.org/ > >
RE: Scientific Linux 7 ALPHA
The actual error was caused by python-ethtool not being installed, so firstboot crashed. -Original message- > From:Bill Maidment > Sent: Saturday 5th July 2014 11:13 > To: Pat Riehecky ; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: RE: Scientific Linux 7 ALPHA > > Pat > I'm getting the following error report at logon: > > Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 > ABRT has detected 1 problem(s). For more info run: abrt-cli list --since > 1404480973 > > [root@sl7 ~]# abrt-cli list --since 1404480973 > id 2dcb3b8c827f788139fffe4995e64f615530216e > Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 > count: 8 > executable: /usr/sbin/firstboot > package:firstboot-19.9-1.el7 > time: Sat 05 Jul 2014 02:28:51 EST > uid:0 > Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for > creating a case in Red Hat Customer Portal > > The Autoreporting feature is disabled. Please consider enabling it by issuing > 'abrt-auto-reporting enabled' as a user with root privileges > [root@sl7 ~]# > > Is this a TUV reference/script to be removed? > > Cheers > Bill > > -Original message- > > From:Pat Riehecky > > Sent: Friday 4th July 2014 7:23 > > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > > Subject: Scientific Linux 7 ALPHA > > > > Users interested in Scientific Linux 7 ALPHA can review: > > > > http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-linux-devel&T=0&X=30246605F08F0DC7ED&P=74 > > > > -- > > Pat Riehecky > > > > Scientific Linux developer > > http://www.scientificlinux.org/ > > > > > >
RE: Scientific Linux 7 ALPHA
Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package:firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid:0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- > From:Pat Riehecky > Sent: Friday 4th July 2014 7:23 > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: Scientific Linux 7 ALPHA > > Users interested in Scientific Linux 7 ALPHA can review: > > http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-linux-devel&T=0&X=30246605F08F0DC7ED&P=74 > > -- > Pat Riehecky > > Scientific Linux developer > http://www.scientificlinux.org/ > >
RE: Scientific Linux 7 ALPHA
Pat That's amazing work by you guys. So much for all the conspiracy theories ;-) Cheers Bill -Original message- > From:Pat Riehecky > Sent: Friday 4th July 2014 7:23 > To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: Scientific Linux 7 ALPHA > > Users interested in Scientific Linux 7 ALPHA can review: > > http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-linux-devel&T=0&X=30246605F08F0DC7ED&P=74 > > -- > Pat Riehecky > > Scientific Linux developer > http://www.scientificlinux.org/ > >
RE: [SCIENTIFIC-LINUX-USERS] Scientific Linux 6.5 is officially released for i686/x86_64
Pat It seems that the ipv4 rsync://mirrors.servercentral.net/fedora-epel/6/x86_6 was down. It is now working OK. Thanks for following up. Cheers Bill -Original message- > From:Pat Riehecky > Sent: Tuesday 4th February 2014 2:23 > To: Bill Maidment ; > SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV > Subject: Re: [SCIENTIFIC-LINUX-USERS] Scientific Linux 6.5 is officially > released for i686/x86_64 > > On 01/31/2014 07:06 PM, Bill Maidment wrote: > > After upgrading to SL 6.5 x86_64 I noticed that my rsync of EPEL no longer > > works: > > > > [root@giggs ~]# rsync -tulvr --partial --delete --exclude debug --exclude > > repoview --bwlimit=600 > > rsync://mirrors.servercentral.net/fedora-epel/6/x86_64 > > /vol2/scientific/epel/6/ > > rsync: failed to connect to mirrors.servercentral.net: Address family not > > supported by protocol (97) > > rsync error: error in socket IO (code 10) at clientserver.c(124) > > [receiver=3.0.6] > > [root@giggs ~]# > > > > Is this an issue with SL, or is it just a coincidence that the EPEL mirror > > server has an issue? > > > > Cheers > > Bill > Is this still an issue? > > -- > Pat Riehecky > > Scientific Linux developer > http://www.scientificlinux.org/ > >
RE: kvm xp and in place reinstalls
-Original message- > From:Todd And Margo Chester > Sent: Wednesday 29th May 2013 9:50 > To: Scientific Linux Users > Subject: kvm xp and in place reinstalls > > Hi All, > > SL 6.4 x64 > > Do any of you run XP in KVM? Have you noticed that you have > to do occasional "in place reinstalls" of XP to correct a severe > case of the slows? > > I have two XP VM (and others). I just got through having to > in place both of them (again). > > If you have had the same problem, do yo come up with a > way to prevent it recurring? > > Many thanks, > -T > > Hi I've noticed this behaviour and on Win 7 too. A reboot seems to make it slightly better, but up to now I have assumed it's a Windows issue.
RE: recent kernel and root raid1
Try updating dracut. I have dracut-004-284.el6_3.1.noarch Regards Bill Maidment Maidment Enterprises Pty Ltd -Original message- > From:Robert Blair mailto:r...@anl.gov> > > Sent: Sunday 11th November 2012 1:11 > To: Scientific Linux <mailto:scientific-linux-us...@fnal.gov> > > Subject: recent kernel and root raid1 > > I have a system that failed to boot after the most recent kernel update. > It took a while, but I eventually traced it to the initramfs not having > raid1 included. I had to manually do a "mkinitrd --preload raid1" for > the new kernel to get the system back up. Oddly, the previous kernel's > ram image was also similarly broken (and the time stamp indicated that > it had been updated at about the same time as the new one) so I couldn't > even revert to it but had to boot from a usb drive to do the repair. > Has something changed in the post install or in mkinitrd that would > explain this? Am I the only one who has had this problem (am I the only > one using a raid 1 root disk with no volume management)? > > For the record the system is SL 6.3 x86_64, the mkinitrd comes from > dracut-004-283.el6.noarch and the kernels in question are > vmlinuz-2.6.32-279.11.1.el6.x86_64 > vmlinuz-2.6.32-279.14.1.el6.x86_64 > > Oddly I see that dracut is "a new, event-driven initramfs infrastructure > based around udev". How does that work on a system with a raid 1 root > drive? In my case the boot fails because the root file system > (identified by a UUID on /dev/md0) can't be found. It seems like udev > is not going to be very functional until mkinitrd has already been used > and the update of the previous kernel is likely related to how this is > being done. Maybe someone has some insight into this? > > Thanks, > Bob Blair > >
RE: wine 1.4 is out
-Original message- From: Nico Kadel-Garcia Sent: Thu 15-03-2012 11:32 Subject:Re: wine 1.4 is out To: Bill Maidment ; CC: Scientific Linux Users ; Todd And Margo Chester ; > On Wed, Mar 14, 2012 at 3:26 AM, Bill Maidment wrote: > > After a complete re-install it's all working fine. > I think there was a serious corruption on my hard disks. > > Cheers > > > > Then I strongly urge you to replace them. Even the best disk monitors usually > fail to detect disk failure before it occurs. (There was a fasciinating white > paper from Google about ths, look up "google white paper disk failure". > > Done. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: wine 1.4 is out
-Original message- From: Todd And Margo Chester Sent: Sun 11-03-2012 17:10 Subject:wine 1.4 is out To: Scientific Linux Users ; > Hi All, > > I don't know if anyone else has noticed this, but > Wine 1.4 RPMs are out > > First, you have to manually download and install, > care of pbone: > openal-soft-1.12.854-1.el6.i686.rpm > openal-soft-1.12.854-1.el6.x86_64.rpm > from ATRPMS > > Then as root (#) > # yum --enablerepo=epel-testing upgrade wine > > -T > > After a complete re-install it's all working fine. I think there was a serious corruption on my hard disks. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: [SCIENTIFIC-LINUX-USERS] wine 1.4 is out
-Original message- From: Pat Riehecky Sent: Wed 14-03-2012 00:39 Subject:Re: [SCIENTIFIC-LINUX-USERS] wine 1.4 is out To: Bill Maidment ; CC: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; > On 03/12/2012 08:02 PM, Bill Maidment wrote: > > -Original message- > > On the distribution server the i686 package is a hard link within the > x86_64 tree. > > $ ls -li 6.2/i386/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > 6.2/x86_64/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > 1501786955 -rw-r--r--. 2 root root 137720 Dec 13 08:56 > 6.2/i386/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > 1501786955 -rw-r--r--. 2 root root 137720 Dec 13 08:56 > 6.2/x86_64/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > > > You may want to remove and re-add the SL signing key. It seems > something is wonky with your rpm gpg keyring. There are instructions on > this within the rpm man page. > > Pat Thanks Pat. I've deleted and reimported the gpg keys, but something very scary has happened to this machine. I can run yum, but rpm -qv yum says it's not installed!!!! I think it's time for a complete baremetal reinstall. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
[SCIENTIFIC-LINUX-USERS] wine 1.4 is out
-Original message- From: Pat Riehecky Sent: Tue 13-03-2012 00:33 Subject:Re: [SCIENTIFIC-LINUX-USERS] wine 1.4 is out To: Bill Maidment ; CC: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; > On 03/11/2012 07:38 PM, Bill Maidment wrote: > > -Original message- > > From: Bill Maidment > > Sent: Mon 12-03-2012 11:18 > > Subject:RE: wine 1.4 is out > > To: Scientific Linux Users; Todd > And Margo Chester; > >> -Original message- > >> From: Todd And Margo Chester > >> Sent: Mon 12-03-2012 07:04 > >> Subject: Re: wine 1.4 is out > >> To:Scientific Linux > >> Users; > >>> On 03/10/2012 10:46 PM, Bill Maidment wrote: > >>>> -Original message- > >>>> From:Todd And Margo Chester > >>>> Sent:Sun 11-03-2012 17:10 > >>>> Subject: wine 1.4 is out > >>>> To: Scientific Linux > >>>> Users; > >>>>> Hi All, > >>>>> > >>>>> I don't know if anyone else has noticed this, but > >>>>> Wine 1.4 RPMs are out > >>>>> > >>>>> First, you have to manually download and install, > >>>>> care of pbone: > >>>>> openal-soft-1.12.854-1.el6.i686.rpm > >>>>> openal-soft-1.12.854-1.el6.x86_64.rpm > >>>>> from ATRPMS > >>>>> > >>>>> Then as root (#) > >>>>> # yum --enablerepo=epel-testing upgrade wine > >>>>> > >>>>> -T > >>>>> > >>>>> > >>>> Thanks for that. I haven't installed wine yet, so I did yum > >>> --enablerepo=epel-testing install wine and I got this error: > >>>> Installing: > >>>> wine x86_641.4-1.el6 epel-testing > >>> 37 k > >>>> Installing for dependencies: > >>>>alsa-plugins-pulseaudio i686 1.0.21-3.el6 sl > >>> 33 k > >>>>cyrus-sasl-lib i686 2.1.23-13.el6 sl > >>> 134 k > >>>> > >>>> error: rpmts_HdrFromFdno: Header V4 DSA/SHA1 Signature, key ID 192a7d7d: > BAD > >>>> Problem opening package cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > >>>> > >>>> Is there an issue with the cyrus-sasl-lib or have I got something wrong? > >>>> > >>>> Cheers > >>>> Bill Maidment > >>>> IT Consultant to Elgas Ltd > >>>> Phone: 02 4294 3649 > >>>> > >>> Hi Bill, > >>> > >>> Here is what my cyrus-sasl-lib looks like: > >>> > >>> $ rpm -qa \*cyrus-sasl-lib\* > >>> cyrus-sasl-lib-2.1.23-13.el6.x86_64 > >>> cyrus-sasl-lib-2.1.23-13.el6.i686 > >>> > >>> Maybe take a trip over to pbone.net, redownload then manually, > >>> and reinstall them. > >>> > >>> -T > >>> > >>> > >> Thanks. I'll try that, but that still means the signature on SL repo is > >> incorrect! > >> > >> Cheers > >> Bill Maidment > >> IT Consultant to Elgas Ltd > >> Phone: 02 4294 3649 > >> > >> > > Well I tried that and now I find the DB4.1686 dependancy has the same > signature problem. > > Maybe all the 32 bit packages on sl.repo have the wrong signatures. > > I noticed that the RPM-GPG-KEYS on my machine changed on Jan 27. > > > > > > Cheers > > Bill Maidment > > IT Consultant to Elgas Ltd > > Phone: 02 4294 3649 > > The signature on that rpm looks good to me. > > $ rpm -K -v 6.2/i386/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > 6.2/i386/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm: > Header V4 DSA/SHA1 Signature, key ID 192a7d7d: OK > Header SHA1 digest: OK (5eeb959ea3c2532993f9cc6f9cdb1c533e9c3f5d) > MD5 digest: OK (ed84b4a91843079c47b8513edbe444c1) > V4 DSA/SHA1 Signature, key ID 192a7d7d: OK > $ rpmdev-checksig 6.2/i386/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > 6.2/i386/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm: DSA/SHA1 - > 192a7d7d - > > > > Pat > > -- > Pat Riehecky > Scientific Linux Developer > > What about the i686 package on the x86_64 repository? rpm -K -v /misc/yum/6.2/x86_64/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm /misc/yum/6.2/x86_64/os/Packages/cyrus-sasl-lib-2.1.23-13.el6.i686.rpm: Header V4 DSA/SHA1 Signature, key ID 192a7d7d: BAD Header SHA1 digest: BAD MD5 digest: BAD V4 DSA/SHA1 Signature, key ID 192a7d7d: BAD [root@ferguson ~]# Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: wine 1.4 is out
-Original message- From: Bill Maidment Sent: Mon 12-03-2012 11:18 Subject:RE: wine 1.4 is out To: Scientific Linux Users ; Todd And Margo Chester ; > -Original message- > From: Todd And Margo Chester > Sent: Mon 12-03-2012 07:04 > Subject: Re: wine 1.4 is out > To: Scientific Linux Users ; > > On 03/10/2012 10:46 PM, Bill Maidment wrote: > > > -Original message- > > > From: Todd And Margo Chester > > > Sent: Sun 11-03-2012 17:10 > > > Subject: wine 1.4 is out > > > To: Scientific Linux > > > Users; > > >> Hi All, > > >> > > >> I don't know if anyone else has noticed this, but > > >> Wine 1.4 RPMs are out > > >> > > >> First, you have to manually download and install, > > >> care of pbone: > > >>openal-soft-1.12.854-1.el6.i686.rpm > > >>openal-soft-1.12.854-1.el6.x86_64.rpm > > >> from ATRPMS > > >> > > >> Then as root (#) > > >> # yum --enablerepo=epel-testing upgrade wine > > >> > > >> -T > > >> > > >> > > > > > > Thanks for that. I haven't installed wine yet, so I did yum > > --enablerepo=epel-testing install wine and I got this error: > > > Installing: > > > winex86_641.4-1.el6 epel-testing > > > > > 37 k > > > Installing for dependencies: > > > alsa-plugins-pulseaudio i686 1.0.21-3.el6 sl > > > > > 33 k > > > cyrus-sasl-lib i686 2.1.23-13.el6 sl > > > > > 134 k > > > > > > error: rpmts_HdrFromFdno: Header V4 DSA/SHA1 Signature, key ID 192a7d7d: > > > BAD > > > Problem opening package cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > > > > > > Is there an issue with the cyrus-sasl-lib or have I got something wrong? > > > > > > Cheers > > > Bill Maidment > > > IT Consultant to Elgas Ltd > > > Phone: 02 4294 3649 > > > > > > > Hi Bill, > > > > Here is what my cyrus-sasl-lib looks like: > > > > $ rpm -qa \*cyrus-sasl-lib\* > > cyrus-sasl-lib-2.1.23-13.el6.x86_64 > > cyrus-sasl-lib-2.1.23-13.el6.i686 > > > > Maybe take a trip over to pbone.net, redownload then manually, > > and reinstall them. > > > > -T > > > > > > Thanks. I'll try that, but that still means the signature on SL repo is > incorrect! > > Cheers > Bill Maidment > IT Consultant to Elgas Ltd > Phone: 02 4294 3649 > > Well I tried that and now I find the DB4.1686 dependancy has the same signature problem. Maybe all the 32 bit packages on sl.repo have the wrong signatures. I noticed that the RPM-GPG-KEYS on my machine changed on Jan 27. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: wine 1.4 is out
-Original message- From: Todd And Margo Chester Sent: Mon 12-03-2012 07:04 Subject:Re: wine 1.4 is out To: Scientific Linux Users ; > On 03/10/2012 10:46 PM, Bill Maidment wrote: > > -Original message- > > From: Todd And Margo Chester > > Sent: Sun 11-03-2012 17:10 > > Subject:wine 1.4 is out > > To: Scientific Linux Users; > >> Hi All, > >> > >> I don't know if anyone else has noticed this, but > >> Wine 1.4 RPMs are out > >> > >> First, you have to manually download and install, > >> care of pbone: > >>openal-soft-1.12.854-1.el6.i686.rpm > >>openal-soft-1.12.854-1.el6.x86_64.rpm > >> from ATRPMS > >> > >> Then as root (#) > >> # yum --enablerepo=epel-testing upgrade wine > >> > >> -T > >> > >> > > > > Thanks for that. I haven't installed wine yet, so I did yum > --enablerepo=epel-testing install wine and I got this error: > > Installing: > > winex86_641.4-1.el6 epel-testing > 37 k > > Installing for dependencies: > > alsa-plugins-pulseaudio i686 1.0.21-3.el6 sl > 33 k > > cyrus-sasl-lib i686 2.1.23-13.el6 sl > 134 k > > .... > > error: rpmts_HdrFromFdno: Header V4 DSA/SHA1 Signature, key ID 192a7d7d: BAD > > Problem opening package cyrus-sasl-lib-2.1.23-13.el6.i686.rpm > > > > Is there an issue with the cyrus-sasl-lib or have I got something wrong? > > > > Cheers > > Bill Maidment > > IT Consultant to Elgas Ltd > > Phone: 02 4294 3649 > > > > Hi Bill, > > Here is what my cyrus-sasl-lib looks like: > > $ rpm -qa \*cyrus-sasl-lib\* > cyrus-sasl-lib-2.1.23-13.el6.x86_64 > cyrus-sasl-lib-2.1.23-13.el6.i686 > > Maybe take a trip over to pbone.net, redownload then manually, > and reinstall them. > > -T > > Thanks. I'll try that, but that still means the signature on SL repo is incorrect! Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: Degraded array issues with SL 6.1 and SL 6.2
-Original message- From: Nico Kadel-Garcia Sent: Thu 23-02-2012 10:42 Subject:Re: Degraded array issues with SL 6.1 and SL 6.2 To: Bill Maidment ; CC: SL Users ; Tom H ; > On Wed, Feb 22, 2012 at 4:38 PM, Bill Maidment wrote: > > In (1) above, are they replying that you can't "--fail", "--remove", > > and then "--add" the same disk or that you can't "--fail" and > > "--remove" a disk, replace it, and then can't "--add" it because it's > > got the same "X"/"XY" in "sdX"/"sdaXY" as the previous, failed disk? > > > > > > Now I've had my coffee fix I have got back my sanity. > I have used the following sequence of commands to remove and re-add a disk to > a > running RAID1 array: > mdadm /dev/md3 -f /dev/sdc1 > mdadm /dev/md3 -r /dev/sdc1 > mdadm --zero-superblock /dev/sdc1 > mdadm /dev/md3 -a /dev/sdc1 > > It works as expected. I just found the original error message a bit confusing > when it referred to making the disk a "spare". It would seem that earlier > versions of the kernel did that automatically. > > > > Interesting! I have mixed feeling about RAID, especially for simple RAID1 > setups. I'd rather use the second drive as an rsnapshot based backup drive, > usueally in read-only mode. That allows me to recover files that I've > accidentally screwed up or deleted in the recent past, which occurs far more > often than drive failures. And it puts different wear and tear on the hard > drive: there's nothing like having all the drives in a RAID set start failing > at almost the same time, before drive replacement can occur. This has > happened > to me before and is actually pretty well described in a Google white paper at > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.goo > gle.com/en/us/archive/disk_failures.pdf > <http://static.googleusercontent.com/external_content/untrusted_dlcp/research.go > ogle.com/en/us/archive/disk_failures.pdf> . > > However, in this case, I'd tend to agreee with the idea that a RAID1 pair > should not be automatically re-activated on reboot. If one drive starts > failing, it should be kept offline until replaced, and trying to outguess > this > process at boot time without intervention seems fraught. > Yes. I agree with your sentiments generally. We had an issue that required we change the hard drives before they actually failed. The firmware on several of our 500GB Seagate drives (firmware SN05) was faulty and liable to cause the drive to fail if the machine was rebooted. We took these drives out of the arrays and re-flashed the firmware to SN06 and then added the drives back into the arrays. We needed to go this way because of the dramatic shortage of server grade hard drives (and consequent price increase) in recent months. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: Degraded array issues with SL 6.1 and SL 6.2
-Original message- From: Tom H Sent: Thu 23-02-2012 01:12 Subject:Re: Degraded array issues with SL 6.1 and SL 6.2 To: SL Users ; > On Wed, Feb 22, 2012 at 7:58 AM, Bill Maidment wrote: > > -Original message- > > From: Bill Maidment > > Sent: Mon 20-02-2012 17:43 > > Subject: Degraded array issues with SL 6.1 and SL 6.2 > > To: scientific-linux-us...@fnal.gov ; > >> I have had some issues with the last two kernel releases. When a degraded > array > >> event occurs, I am unable to add a new disk back in to the array. This has > been > >> reported on Centos 6.1/6.2 and also RHEL 6.2 (see Bug 772926 - dracut > >> unable > to > >> boot from a degraded raid1 array). I have found that I need to revert to > kernel > >> 2.6.32-131.21.1.el6.x86_64 in order to be able to add the new drive. > > > > The response from RH is as follows: > > 1) If you try to re-add a disk to a running raid1 after having failed it, > > mdadm correctly rejects it as it has no way of knowing which of the disks > > are authoritative. It clearly tells you that in the error message you > > pasted into the bug. > > > > 2) You reported a Scientific Linux bug against Red Hat Enterprise Linux. > > Red Hat does not support Scientific Linux, please report bugs against > > Scientific Linux to the people behind Scientific Linux. > > > > My response is: > > 1) a) It used to work it out. b) No it does not clearly spell it out. c) > > Why > was it not a problem in earlier kernels? > > 2) Is this an SL bug? I think not! > > Bug 772926 doesn't have anything about SL. Are you referring to another bug? > > In (1) above, are they replying that you can't "--fail", "--remove", > and then "--add" the same disk or that you can't "--fail" and > "--remove" a disk, replace it, and then can't "--add" it because it's > got the same "X"/"XY" in "sdX"/"sdaXY" as the previous, failed disk? > > Now I've had my coffee fix I have got back my sanity. I have used the following sequence of commands to remove and re-add a disk to a running RAID1 array: mdadm /dev/md3 -f /dev/sdc1 mdadm /dev/md3 -r /dev/sdc1 mdadm --zero-superblock /dev/sdc1 mdadm /dev/md3 -a /dev/sdc1 It works as expected. I just found the original error message a bit confusing when it referred to making the disk a "spare". It would seem that earlier versions of the kernel did that automatically. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: Degraded array issues with SL 6.1 and SL 6.2
-Original message- From: Bill Maidment Sent: Mon 20-02-2012 17:43 Subject:Degraded array issues with SL 6.1 and SL 6.2 To: scientific-linux-us...@fnal.gov ; > Hi, just a heads up. > I have had some issues with the last two kernel releases. When a degraded > array > event occurs, I am unable to add a new disk back in to the array. This has > been > reported on Centos 6.1/6.2 and also RHEL 6.2 (see Bug 772926 - dracut unable > to > boot from a degraded raid1 array). I have found that I need to revert to > kernel > 2.6.32-131.21.1.el6.x86_64 in order to be able to add the new drive. > > Cheers > Bill Maidment > IT Consultant to Elgas Ltd > Phone: 02 4294 3649 The response from RH is as follows: 1) If you try to re-add a disk to a running raid1 after having failed it, mdadm correctly rejects it as it has no way of knowing which of the disks are authoritative. It clearly tells you that in the error message you pasted into the bug. 2) You reported a Scientific Linux bug against Red Hat Enterprise Linux. Red Hat does not support Scientific Linux, please report bugs against Scientific Linux to the people behind Scientific Linux. My response is: 1) a) It used to work it out. b) No it does not clearly spell it out. c) Why was it not a problem in earlier kernels? 2) Is this an SL bug? I think not! Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: Boot screen says 6.1
-Original message- From: Todd And Margo Chester Sent: Tue 21-02-2012 15:14 Subject:Re: Boot screen says 6.1 To: Scientific Linux Users ; > On 02/20/2012 06:05 PM, Steven Haigh wrote: > > On 21/02/2012 12:42 PM, Akemi Yagi wrote: > >> On Mon, Feb 20, 2012 at 4:41 PM, Todd And Margo Chester > >> wrote: > >>> Hi All, > >>> > >>> Updates to 6.2 a few days ago. > >>> > >>> Interesting, when I boot up, the splash screen says I am > >>> running "Scientific Linux 6.1". > >> > >> I can confirm this on my system. :-( > > > > It will probably still say this until a kernel update is done. The > > splash stuff is loaded from the boot portions of the kernel and is not > > updated automatically. > > > > Don't stress about it - it'll fix itself on the next kernel update. > > > > Hi Steven, > > That is good news. I was hoping it was not yet another thing that went > wrong with the upgrade. (I just fixed my stinkin' sound and have > still to fix my video driver.) > > I am surprised that the kernel did not change as well. > > Thanks you for the help, > -T > > Boot into a previous kernel and then do yum reinstall kernel This will rebuild initramfs and fix it. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
Degraded array issues with SL 6.1 and SL 6.2
Hi, just a heads up. I have had some issues with the last two kernel releases. When a degraded array event occurs, I am unable to add a new disk back in to the array. This has been reported on Centos 6.1/6.2 and also RHEL 6.2 (see Bug 772926 - dracut unable to boot from a degraded raid1 array). I have found that I need to revert to kernel 2.6.32-131.21.1.el6.x86_64 in order to be able to add the new drive. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: [SCIENTIFIC-LINUX-USERS] Keyboard issue with SL6.2RC1
-Original message- From: Akemi Yagi Sent: Sat 04-02-2012 03:04 Subject:Re: [SCIENTIFIC-LINUX-USERS] Keyboard issue with SL6.2RC1 To: Pat Riehecky ; CC: Bill Maidment ; SCIENTIFIC-LINUX-USERS@listserv.fnal.gov; > On Fri, Feb 3, 2012 at 7:58 AM, Pat Riehecky wrote: > > On 02/02/2012 11:33 PM, Bill Maidment wrote: > >> > >> Hi > >> I've just installed SL6.2RC1 as a KVM guest on a SL6.1 host. Yum updates > >> done on both. > >> When I start a terminal I find that the Ctrl keys are ignored, e.g. doing > >> Ctrl-C just gives a lower case c. > >> Is this an issue for anyone installing SL6.2RC1 as a host, or is it > >> something to do with qemu-kvm on SL6.1? > > > I've got a 6.1 workstation here and just did a quick test on this. I can't > > seem to replicate it. My 6.2 VMs all respond as expected to CTRL+C. > > > > Curious. > > Works here as well on a SL 6.2RC1 KVM guest. > > Is the Ctrl key the only one that's not working? > > Akemi > > It only appears to be the two Ctrl keys that are ignored, when I use the virt-manager console. If I ssh into the guest the Ctrl keys work OK (same physical keyboard). Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
Keyboard issue with SL6.2RC1
Hi I've just installed SL6.2RC1 as a KVM guest on a SL6.1 host. Yum updates done on both. When I start a terminal I find that the Ctrl keys are ignored, e.g. doing Ctrl-C just gives a lower case c. Is this an issue for anyone installing SL6.2RC1 as a host, or is it something to do with qemu-kvm on SL6.1? Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: qemu-kvm-0.12.1.2 issue
-Original message- From: Bill Maidment Sent: Tue 17-01-2012 10:51 Subject:qemu-kvm-0.12.1.2 issue To: scientific-linux-us...@fnal.gov; > Hey guys > After upgrading my SL 6.1 with qemu-kvm-0.12.1.2, one of my guest servers > keeps > shutting down every few hours. > The message in the host log is as follows: > qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/hw/usb.c:345: > usb_packet_complete: Assertion `p->owner != ((void *)0)' failed. > > Does anyone know what this means? > > I have done a yum downgrade for now. Hopefully the guest will stay up now. > > Cheers > Bill Maidment > IT Consultant to Elgas Ltd > Phone: 02 4294 3649 Well the guest has stayed up for over 24 hours, so I guess qemu-kvm-0.12.1.2 is the cause. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
qemu-kvm-0.12.1.2 issue
Hey guys After upgrading my SL 6.1 with qemu-kvm-0.12.1.2, one of my guest servers keeps shutting down every few hours. The message in the host log is as follows: qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/hw/usb.c:345: usb_packet_complete: Assertion `p->owner != ((void *)0)' failed. Does anyone know what this means? I have done a yum downgrade for now. Hopefully the guest will stay up now. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: kernel panic with 2.6.32-220.2.1
-Original message- From: zxq9 Sent: Fri 13-01-2012 15:00 Subject:Re: kernel panic with 2.6.32-220.2.1 To: scientific-linux-us...@fnal.gov; > On 01/13/2012 08:48 AM, Bill Maidment wrote: > > Good Morning all from Australia > > I have a problem when upgrading to the newest 64bit kernel. After it runs > > for > a couple of minutes I get a kernel panic (see below). The previous > kernel-2.6.32-131.21.1 reported the nouveau scaling lines but does not kernel > panic. > > Has anyone else seen anything like this? Could this indicate a hardware > > error? > > Any help would be appreciated. > > > > Jan 13 10:20:39 charlton kernel: [drm] nouveau :05:00.0: No native > > mode, > forcing panel scaling > > Jan 13 10:20:49 charlton kernel: [drm] nouveau :05:00.0: No native > > mode, > forcing panel scaling > > Jan 13 10:20:49 charlton kernel: [drm:drm_crtc_helper_set_config] *ERROR* > failed to set mode on [CRTC:5] > > Jan 13 10:20:50 charlton kernel: irq 18: nobody cared (try booting with the > "irqpoll" option) > > Jan 13 10:20:50 charlton kernel: Pid: 0, comm: swapper Tainted: GW > 2.6.32-220.2.1.el6.x86_64 #1 > > Jan 13 10:20:50 charlton kernel: Call Trace: > > Jan 13 10:20:50 charlton kernel: [] ? > __report_bad_irq+0x2b/0xa0 > > Jan 13 10:20:50 charlton kernel: [] ? > note_interrupt+0x18c/0x1d0 > > Jan 13 10:20:50 charlton kernel: [] ? > handle_fasteoi_irq+0xcd/0xf0 > > Jan 13 10:20:50 charlton kernel: [] ? handle_irq+0x49/0xa0 > > Jan 13 10:20:50 charlton kernel: [] ? do_IRQ+0x6c/0xf0 > > Jan 13 10:20:50 charlton kernel: [] ? > > ret_from_intr+0x0/0x11 > > Jan 13 10:20:50 charlton kernel: [] ? > native_safe_halt+0xb/0x10 > > Jan 13 10:20:50 charlton kernel: [] ? > > default_idle+0x4d/0xb0 > > Jan 13 10:20:50 charlton kernel: [] ? c1e_idle+0x9d/0x120 > > Jan 13 10:20:50 charlton kernel: [] ? cpu_idle+0xb6/0x110 > > Jan 13 10:20:50 charlton kernel: [] ? > start_secondary+0x202/0x245 > > Jan 13 10:20:50 charlton kernel: handlers: > > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > > Jan 13 10:20:50 charlton kernel: [] > (nouveau_irq_handler+0x0/0x140 [nouveau]) > > Jan 13 10:20:50 charlton kernel: Disabling IRQ #18 > > It looks like nouveau is on fire. > > Assuming you in fact have an nVidia chipset... > > Can you boot to runlevel 3? > > If so you've got two primary routes: Learning about the display option > details and try passing some boot parameter magic to nouveau -- these > days there is no xorg.conf file by default, and everything is > autodetected each boot, so you can get specific in boot options or by > writing an xorg.conf of your own (but this has become a deep body of > knowledge recently, so that can suck if you're new to it) > > ...or... > > You can run off and get the nVidia proprietary driver pack and compile > it. If you have already done this, then nouveau needs to be explicitely > blacklisted to prevent these sort of hairballs making your kernel cough. > > I am already running in runlevel 3 with a NV50 type nVidia card and no proprietary driver. I think the boot parameter magic drm_kms_helper.poll=0 has at least stopped the kernel panic, so I'll investigate that further. Thanks for the info. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
RE: kernel panic with 2.6.32-220.2.1
-Original message- From: Bill Maidment Sent: Fri 13-01-2012 10:48 Subject:kernel panic with 2.6.32-220.2.1 To: scientific-linux-us...@fnal.gov; > Good Morning all from Australia > I have a problem when upgrading to the newest 64bit kernel. After it runs for > a > couple of minutes I get a kernel panic (see below). The previous > kernel-2.6.32-131.21.1 reported the nouveau scaling lines but does not kernel > panic. > Has anyone else seen anything like this? Could this indicate a hardware error? > Any help would be appreciated. > > Jan 13 10:20:39 charlton kernel: [drm] nouveau :05:00.0: No native mode, > forcing panel scaling > Jan 13 10:20:49 charlton kernel: [drm] nouveau :05:00.0: No native mode, > forcing panel scaling > Jan 13 10:20:49 charlton kernel: [drm:drm_crtc_helper_set_config] *ERROR* > failed to set mode on [CRTC:5] > Jan 13 10:20:50 charlton kernel: irq 18: nobody cared (try booting with the > "irqpoll" option) > Jan 13 10:20:50 charlton kernel: Pid: 0, comm: swapper Tainted: GW > 2.6.32-220.2.1.el6.x86_64 #1 > Jan 13 10:20:50 charlton kernel: Call Trace: > Jan 13 10:20:50 charlton kernel: [] ? > __report_bad_irq+0x2b/0xa0 > Jan 13 10:20:50 charlton kernel: [] ? > note_interrupt+0x18c/0x1d0 > Jan 13 10:20:50 charlton kernel: [] ? > handle_fasteoi_irq+0xcd/0xf0 > Jan 13 10:20:50 charlton kernel: [] ? handle_irq+0x49/0xa0 > Jan 13 10:20:50 charlton kernel: [] ? do_IRQ+0x6c/0xf0 > Jan 13 10:20:50 charlton kernel: [] ? ret_from_intr+0x0/0x11 > Jan 13 10:20:50 charlton kernel: [] ? > native_safe_halt+0xb/0x10 > Jan 13 10:20:50 charlton kernel: [] ? default_idle+0x4d/0xb0 > Jan 13 10:20:50 charlton kernel: [] ? c1e_idle+0x9d/0x120 > Jan 13 10:20:50 charlton kernel: [] ? cpu_idle+0xb6/0x110 > Jan 13 10:20:50 charlton kernel: [] ? > start_secondary+0x202/0x245 > Jan 13 10:20:50 charlton kernel: handlers: > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) > Jan 13 10:20:50 charlton kernel: [] > (nouveau_irq_handler+0x0/0x140 [nouveau]) > Jan 13 10:20:50 charlton kernel: Disabling IRQ #18 > > > Cheers > Bill Maidment > IT Consultant to Elgas Ltd > Phone: 02 4294 3649 > > I suppressed the nouveau scaling lines with boot parameter drm_kms_helper.poll=0 but now I get a warning message: [ cut here ] WARNING: at kernel/sched.c:5914 thread_return+0x232/0x79d() (Not tainted) Hardware name: System Product Name Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl auth_rpcgss exportfs autofs4 sunrpc cpufreq_ondemand powernow_k8 freq_table mperf bridge stp llc ipv6 dm_mirror dm_region_hash dm_log vhost_net macvtap macvlan tun kvm_amd kvm asus_atk0110 r8169 8139too 8139cp mii microcode k10temp edac_core edac_mce_amd shpchp sg snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i2c_piix4 xhci_hcd ext4 mbcache jbd2 raid1 sd_mod crc_t10dif sr_mod cdrom pata_atiixp ahci ata_generic pata_acpi pata_jmicron usb_storage nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core mxm_wmi wmi video output dm_mod [last unloaded: scsi_wait_scan] Pid: 2375, comm: qemu-kvm Not tainted 2.6.32-220.2.1.el6.x86_64 #1 Call Trace: [] ? warn_slowpath_common+0x87/0xc0 [] ? warn_slowpath_null+0x1a/0x20 [] ? thread_return+0x232/0x79d [] ? __hrtimer_start_range_ns+0x1a3/0x460 [] ? lock_hrtimer_base+0x31/0x60 [] ? schedule_hrtimeout_range+0xc8/0x160 [] ? hrtimer_wakeup+0x0/0x30 [] ? hrtimer_start_range_ns+0x14/0x20 [] ? poll_schedule_timeout+0x39/0x60 [] ? do_select+0x578/0x6b0 [] ? __pollwait+0x0/0xf0 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? pollwake+0x0/0x60 [] ? core_sys_select+0x18a/0x2c0 [] ? __hrtimer_start_range_ns+0x1a3/0x460 [] ? autoremove_wake_function+0x0/0x40 [] ? read_tsc+0x9/0x20 [] ? ktime_get_ts+0xa9/0xe0 [] ? read_tsc+0x9/0x20 [] ? ktime_get_ts+0xa9/0xe0 [] ? sys_select+0x47/0x110 [] ? system_call_fastpath+0x16/0x1b ---[ end trace c440723fb9745c91 ]--- Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
kernel panic with 2.6.32-220.2.1
Good Morning all from Australia I have a problem when upgrading to the newest 64bit kernel. After it runs for a couple of minutes I get a kernel panic (see below). The previous kernel-2.6.32-131.21.1 reported the nouveau scaling lines but does not kernel panic. Has anyone else seen anything like this? Could this indicate a hardware error? Any help would be appreciated. Jan 13 10:20:39 charlton kernel: [drm] nouveau :05:00.0: No native mode, forcing panel scaling Jan 13 10:20:49 charlton kernel: [drm] nouveau :05:00.0: No native mode, forcing panel scaling Jan 13 10:20:49 charlton kernel: [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:5] Jan 13 10:20:50 charlton kernel: irq 18: nobody cared (try booting with the "irqpoll" option) Jan 13 10:20:50 charlton kernel: Pid: 0, comm: swapper Tainted: GW 2.6.32-220.2.1.el6.x86_64 #1 Jan 13 10:20:50 charlton kernel: Call Trace: Jan 13 10:20:50 charlton kernel: [] ? __report_bad_irq+0x2b/0xa0 Jan 13 10:20:50 charlton kernel: [] ? note_interrupt+0x18c/0x1d0 Jan 13 10:20:50 charlton kernel: [] ? handle_fasteoi_irq+0xcd/0xf0 Jan 13 10:20:50 charlton kernel: [] ? handle_irq+0x49/0xa0 Jan 13 10:20:50 charlton kernel: [] ? do_IRQ+0x6c/0xf0 Jan 13 10:20:50 charlton kernel: [] ? ret_from_intr+0x0/0x11 Jan 13 10:20:50 charlton kernel: [] ? native_safe_halt+0xb/0x10 Jan 13 10:20:50 charlton kernel: [] ? default_idle+0x4d/0xb0 Jan 13 10:20:50 charlton kernel: [] ? c1e_idle+0x9d/0x120 Jan 13 10:20:50 charlton kernel: [] ? cpu_idle+0xb6/0x110 Jan 13 10:20:50 charlton kernel: [] ? start_secondary+0x202/0x245 Jan 13 10:20:50 charlton kernel: handlers: Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) Jan 13 10:20:50 charlton kernel: [] (usb_hcd_irq+0x0/0x90) Jan 13 10:20:50 charlton kernel: [] (nouveau_irq_handler+0x0/0x140 [nouveau]) Jan 13 10:20:50 charlton kernel: Disabling IRQ #18 Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
service named is unable to restart
Hi again
I have been having some issues with named (bind-9.7.3-2.el6_1.P3.3.x86_64)
where after a while it fails to resolve some domains and when I try to do
service named restart I get a message that says:
Stopping named: .umount: /var/named/chroot/var/named: device is
busy.
I have to do a kill -9 to stop named before I can start it again.
I have searched high and low in logs and google to find the cause of this; even
disabling openvpn and dnssec, but I still can't solve it. lsof doesn't seem to
reveal the culprit.
This occurs with a variety of named.conf settings, but the simplest is with
just these two lines added to the standard config
forwarders { 192.168.2.4; 192.168.2.18; };
forward only;
Has anyone else experienced this or knows how to resolve this?
Cheers
Bill Maidment
IT Consultant to Elgas Ltd
Phone: 02 4294 3649
RE: NetworkManager-0.8.1-15.el6 problem
-Original message- From: Bill Maidment Sent: Fri 09-12-2011 22:00 Subject:NetworkManager-0.8.1-15.el6 problem To: scientific-linux-us...@fnal.gov; > Hi guys > When I upgraded my laptop to NetworkManager-0.8.1-15.el6 I can no longer > access > my wireless network card. > I am using a Dell Inspiron XPS M1730 with an Intel 4965AGN wireless card. > Does anyone know how to fix this issue? > yum downgrade NetworkManager* has got me going again, but that is only a > temporary fix. > > Cheers > Bill Maidment > IT Consultant to Elgas Ltd > Phone: 02 4294 3649 > > I just noticed that this version is a fastbugs update, so there may not be kernel updates to match yet. I've switched off the fastbugs repo to avoid further issues. Sorry for the noise. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
NetworkManager-0.8.1-15.el6 problem
Hi guys When I upgraded my laptop to NetworkManager-0.8.1-15.el6 I can no longer access my wireless network card. I am using a Dell Inspiron XPS M1730 with an Intel 4965AGN wireless card. Does anyone know how to fix this issue? yum downgrade NetworkManager* has got me going again, but that is only a temporary fix. Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649
