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: From where does fsck failure prompt root passwd come?
Thank you for the suggestion. I am top-posting my response rather than bottom-posting (I have repeatedly been informed that bottom-posting is required for this list) because you top-posted. As you can read, /sbin/sulogin from a regular shell works, although as it requires su first, it is unclear what sulogin actually accomplishes in this case. To verify that this successful operation was not due to the input coming via a Xwindows Gnome application, I also ran the same sequence from a plain non-GUI terminal screen (ctrl-alt-F4) with the identical success. Obviously, something is different after a fsck failure during boot. As a separate test, I will try single user mode -- but this requires exiting my present work that I simply cannot do at this moment. [ykarant@jb344 ~]$ /sbin/sulogin sulogin: only root can run sulogin. [ykarant@jb344 ~]$ su Password: [root@jb344 ykarant]# /sbin/sulogin Give root password for maintenance (or type Control-D to continue): [root@jb344 ~]# whoami root [root@jb344 ~]# exit exit [root@jb344 ykarant]# exit exit [ykarant@jb344 ~]$ Yasha Karant On 02/02/2012 03:04 PM, Yannick Perret wrote: Yannick Perret a écrit : Hello, the only place I found that have the "Give root password" in /sbin/sulogin. # strings /sbin/sulogin | grep "Give ro" Give root password for maintenance which is part of sysvinit-tools package. 'sulogin' is only called from /etc/rc.sysinit as far as I know (in boot sequence). Did you try to run /sbin/sulogin on a running machine? It will ask you root password, and it could be interresting to check if it can works outside the boot sequence. I mean (I was not clear): it do works on a SL4 / SL5 machine. It could be interresting to see if it does not work for you, in which case it may help to track the reason of this behavior. -- Y. Regards, -- Y. Yasha Karant a écrit : I have been discussing the failure mode that I have observed: also documented in https://bugzilla.redhat.com/show_bug.cgi?id=636628 after fsck fails during a (re)boot Give root password for maintenance (or type Control-D to continue): At this stage, at every second key stroke, it reports "Login incorrect." and repeats the above "Give root password...". as an endless loop. The argument has been presented on this list that it is the root user failure to configure a password into grub.conf or other bootloading or initialization applications/routines configuration or input data files. I have been discussing this issue with a number of experienced systems persons, and none of us accept this argument, especially as without special intervention or configuration, the expected behavior was displayed on EL 4 and 5, as well as several other non-TUV distributions. Expected behavior: whatever root password was encoded into the /etc/shadow file is used by the routine that handles "Give root password for maintenance" is accepted, and not at every second key stroke would it report "Login incorrect." When the system is first installed from physical media such as a bootable DVD (for EL, this is with every major release, e.g., EL 4, EL 5, EL 6, etc.), and a root password is required to be set during installation, this password is put in an encrypted form in the appropriate file in /etc (e.g., /etc/shadow) and wherever else it might be required (e.g., in /boot if the particular implementation were to require this). Moreover, for fsck to run during the boot process, even if /boot is on a separate partition from / (root partition), the fsck executable is on a partition that must have been mounted, and thus /etc/shadow should be available. Hence, the (encrypted) password should be available. The bug is that the password entry routine (as in response to the prompt "Give root password for maintenance") does not accept the full vector of characters for the root password including the Enter keystroke that terminates the vector. As there are correspondents to this list that evidently feel the above arguments to be incorrect, references to the relevant Linux source code sections and design documents (e.g., state machine chart for the sequence that contains "Give root password for maintenance") greatly would be appreciated.
Re: From where does fsck failure prompt root passwd come?
Yannick Perret a écrit : Hello, the only place I found that have the "Give root password" in /sbin/sulogin. # strings /sbin/sulogin | grep "Give ro" Give root password for maintenance which is part of sysvinit-tools package. 'sulogin' is only called from /etc/rc.sysinit as far as I know (in boot sequence). Did you try to run /sbin/sulogin on a running machine? It will ask you root password, and it could be interresting to check if it can works outside the boot sequence. I mean (I was not clear): it do works on a SL4 / SL5 machine. It could be interresting to see if it does not work for you, in which case it may help to track the reason of this behavior. -- Y. Regards, -- Y. Yasha Karant a écrit : I have been discussing the failure mode that I have observed: also documented in https://bugzilla.redhat.com/show_bug.cgi?id=636628 after fsck fails during a (re)boot Give root password for maintenance (or type Control-D to continue): At this stage, at every second key stroke, it reports "Login incorrect." and repeats the above "Give root password...". as an endless loop. The argument has been presented on this list that it is the root user failure to configure a password into grub.conf or other bootloading or initialization applications/routines configuration or input data files. I have been discussing this issue with a number of experienced systems persons, and none of us accept this argument, especially as without special intervention or configuration, the expected behavior was displayed on EL 4 and 5, as well as several other non-TUV distributions. Expected behavior: whatever root password was encoded into the /etc/shadow file is used by the routine that handles "Give root password for maintenance" is accepted, and not at every second key stroke would it report "Login incorrect." When the system is first installed from physical media such as a bootable DVD (for EL, this is with every major release, e.g., EL 4, EL 5, EL 6, etc.), and a root password is required to be set during installation, this password is put in an encrypted form in the appropriate file in /etc (e.g., /etc/shadow) and wherever else it might be required (e.g., in /boot if the particular implementation were to require this). Moreover, for fsck to run during the boot process, even if /boot is on a separate partition from / (root partition), the fsck executable is on a partition that must have been mounted, and thus /etc/shadow should be available. Hence, the (encrypted) password should be available. The bug is that the password entry routine (as in response to the prompt "Give root password for maintenance") does not accept the full vector of characters for the root password including the Enter keystroke that terminates the vector. As there are correspondents to this list that evidently feel the above arguments to be incorrect, references to the relevant Linux source code sections and design documents (e.g., state machine chart for the sequence that contains "Give root password for maintenance") greatly would be appreciated.
Re: From where does fsck failure prompt root passwd come?
Hello, the only place I found that have the "Give root password" in /sbin/sulogin. # strings /sbin/sulogin | grep "Give ro" Give root password for maintenance which is part of sysvinit-tools package. 'sulogin' is only called from /etc/rc.sysinit as far as I know (in boot sequence). Did you try to run /sbin/sulogin on a running machine? It will ask you root password, and it could be interresting to check if it can works outside the boot sequence. Regards, -- Y. Yasha Karant a écrit : I have been discussing the failure mode that I have observed: also documented in https://bugzilla.redhat.com/show_bug.cgi?id=636628 after fsck fails during a (re)boot Give root password for maintenance (or type Control-D to continue): At this stage, at every second key stroke, it reports "Login incorrect." and repeats the above "Give root password...". as an endless loop. The argument has been presented on this list that it is the root user failure to configure a password into grub.conf or other bootloading or initialization applications/routines configuration or input data files. I have been discussing this issue with a number of experienced systems persons, and none of us accept this argument, especially as without special intervention or configuration, the expected behavior was displayed on EL 4 and 5, as well as several other non-TUV distributions. Expected behavior: whatever root password was encoded into the /etc/shadow file is used by the routine that handles "Give root password for maintenance" is accepted, and not at every second key stroke would it report "Login incorrect." When the system is first installed from physical media such as a bootable DVD (for EL, this is with every major release, e.g., EL 4, EL 5, EL 6, etc.), and a root password is required to be set during installation, this password is put in an encrypted form in the appropriate file in /etc (e.g., /etc/shadow) and wherever else it might be required (e.g., in /boot if the particular implementation were to require this). Moreover, for fsck to run during the boot process, even if /boot is on a separate partition from / (root partition), the fsck executable is on a partition that must have been mounted, and thus /etc/shadow should be available. Hence, the (encrypted) password should be available. The bug is that the password entry routine (as in response to the prompt "Give root password for maintenance") does not accept the full vector of characters for the root password including the Enter keystroke that terminates the vector. As there are correspondents to this list that evidently feel the above arguments to be incorrect, references to the relevant Linux source code sections and design documents (e.g., state machine chart for the sequence that contains "Give root password for maintenance") greatly would be appreciated.
From where does fsck failure prompt root passwd come?
I have been discussing the failure mode that I have observed: also documented in https://bugzilla.redhat.com/show_bug.cgi?id=636628 after fsck fails during a (re)boot Give root password for maintenance (or type Control-D to continue): At this stage, at every second key stroke, it reports "Login incorrect." and repeats the above "Give root password...". as an endless loop. The argument has been presented on this list that it is the root user failure to configure a password into grub.conf or other bootloading or initialization applications/routines configuration or input data files. I have been discussing this issue with a number of experienced systems persons, and none of us accept this argument, especially as without special intervention or configuration, the expected behavior was displayed on EL 4 and 5, as well as several other non-TUV distributions. Expected behavior: whatever root password was encoded into the /etc/shadow file is used by the routine that handles "Give root password for maintenance" is accepted, and not at every second key stroke would it report "Login incorrect." When the system is first installed from physical media such as a bootable DVD (for EL, this is with every major release, e.g., EL 4, EL 5, EL 6, etc.), and a root password is required to be set during installation, this password is put in an encrypted form in the appropriate file in /etc (e.g., /etc/shadow) and wherever else it might be required (e.g., in /boot if the particular implementation were to require this). Moreover, for fsck to run during the boot process, even if /boot is on a separate partition from / (root partition), the fsck executable is on a partition that must have been mounted, and thus /etc/shadow should be available. Hence, the (encrypted) password should be available. The bug is that the password entry routine (as in response to the prompt "Give root password for maintenance") does not accept the full vector of characters for the root password including the Enter keystroke that terminates the vector. As there are correspondents to this list that evidently feel the above arguments to be incorrect, references to the relevant Linux source code sections and design documents (e.g., state machine chart for the sequence that contains "Give root password for maintenance") greatly would be appreciated. Yasha Karant
Re: CUPS doesn't offer Ledger as a paper size
James M Pulver wrote: We've got a Brother MFC-j5910 which is working great networked via the brother LPD and CUPS driver, except if you want to print 11x17 / Tabloid. The printer for some reason doesn't support that, and instead supports the less common 17x11 / Ledger format. If I use a program that allows you to set a CUSTOM paper size of 17x11, it prints as expected (well, not really, I have to still change to landscape when it should be portrait for that size configuration)... The issue I have is, on Windows computers using the standard CUPS drivers shared over SAMBA, I can't select a custom paper size (and most users on Linux expect to use Tabloid, not a custom paper size)... Any ideas what I should do here? CUPS is on a SL5 server. -- James Pulver LEPP Computer Group Cornell University You should be able to modify the ppd file in /etc/cups/ppd/. You can add/modify paper dimensions as needed there. I'd start by cloning the Ledger entry, naming it Tabloid (or whatever), then adjusting the dimensions to the orientation you want. Restart cups after editing. -Mark -- Mr. Mark V. Stodola Digital Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Re: [SCIENTIFIC-LINUX-USERS] Netbackup 7.1 BMR and SL6.1 creating boot CD
On 02/02/2012 10:40 AM, James M Pulver wrote: I've got netbackup up and running fine on SL6.1. I'm trying to create the boot CD for my Linux clients (windows worked fine), but get this: Select one of the following options: 1. Create a new Shared Resource Tree. 2. Create a new CD image based Shared Resource Tree. 3. Copy an existing Shared Resource Tree to a new location. 4. Import a Shared Resource Tree. 5. Modify an existing Shared Resource Tree. 6. Delete an existing Shared Resource Tree. 7. List Shared Resource Trees available on this server. 8. Quit. Enter your selection (1-8) [1] : 1 Enter the name of the SRT to create : 64BitSL Enter the description of the new SRT : 64 bit SL6.1 V-128-312 Unsupported Linux release: Scientific Linux release 6.1 (Carbon) Enter the desired RedHat level () : I've entered everything I can find around the web from Red Hat Enterprise Linux Server 6 to 2.6, but it just returns with Enter the desired RedHat level (): ... Any ideas what I should put there? -- James Pulver LEPP Computer Group Cornell University Do you know how it is trying to detect the 'RedHat' level? Some scripts (say redhat-rpm-config found in SL6) look first for 'Red Hat' and then the version. Since we say Scientific Linux, it may be getting caught up on that. Pat -- Pat Riehecky Scientific Linux Developer
CUPS doesn't offer Ledger as a paper size
We've got a Brother MFC-j5910 which is working great networked via the brother LPD and CUPS driver, except if you want to print 11x17 / Tabloid. The printer for some reason doesn't support that, and instead supports the less common 17x11 / Ledger format. If I use a program that allows you to set a CUSTOM paper size of 17x11, it prints as expected (well, not really, I have to still change to landscape when it should be portrait for that size configuration)... The issue I have is, on Windows computers using the standard CUPS drivers shared over SAMBA, I can't select a custom paper size (and most users on Linux expect to use Tabloid, not a custom paper size)... Any ideas what I should do here? CUPS is on a SL5 server. -- James Pulver LEPP Computer Group Cornell University
Re: coreutils for 64 bit
Hi Andrey,
Why would you want a block size in GB? I don't know what the
actual limit for dd itself is, although it does seem to be exactly 2GiB.
regards,
Stephen.
On Thu, 2 Feb 2012, Andrey Y. Shevel wrote:
Hi Stephen,
thank you for your reply.
==
[root@pcfarm-10 ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}.%{ARCH}\n" |
grep coreutils
policycoreutils-1.33.12.x86_64
policycoreutils-newrole-1.33.12.x86_64
coreutils-5.97.x86_64
policycoreutils-gui-1.33.12.x86_64
=
And obviously
[root@pcfarm-10 ~]# arch
x86_64
===
The result is prety same as I shown earlier.
And the same I see at CERN
===
[lxplus427] /afs/cern.ch/user/s/shevel > dd if=/dev/zero of=/tmp/testx64
bs=3GB count=1
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 5.91242 seconds, 363 MB/s
[lxplus427] /afs/cern.ch/user/s/shevel > rpm -q --file /bin/dd
coreutils-5.97-34.el5
[lxplus427] /afs/cern.ch/user/s/shevel > rpm -qa --queryformat
"%{NAME}-%{VERSION}.%{ARCH}\n" | grep coreutil
policycoreutils-1.33.12.x86_64
coreutils-5.97.x86_64
policycoreutils-gui-1.33.12.x86_64
===
As far as I understand the main question is "is there 64 bit dd version which
can operate more then 2GB value for BS in SL anyway?"
Any answer (yes or no) is good to know.
Many thanks,
Andrey
On Wed, 1 Feb 2012, Stephen J. Gowdy wrote:
Date: Wed, 1 Feb 2012 19:10:14 +0100 (CET)
From: Stephen J. Gowdy
To: Andrey Y. Shevel
Cc: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
Subject: Re: coreutils for 64 bit
Exactly if you type "man rpm" it will show you how you get it to print
the arch string (usually i686 or x86_64). Since you seem unabel to read a
man page what you want to type is;
rpm -qa --queryformat "%{NAME}-%{VERSION}.%{ARCH}\n" | grep coreutils
(or miss out the VERSION if you want to see somethign similar to yum)
On Wed, 1 Feb 2012, Andrey Y. Shevel wrote:
Hi Stephen,
thanks for the reply.
I am not sure that I do understand you (sorry for my stupidity).
I have
===
[root@pcfarm-10 ~]# yum list | grep coreutil
Failed to set locale, defaulting to C
coreutils.x86_64 5.97-34.el5 installed
policycoreutils.x86_64 1.33.12-14.8.el5 installed
policycoreutils-gui.x86_64 1.33.12-14.8.el5 installed
policycoreutils-newrole.x86_64 1.33.12-14.8.el5 installed
[root@pcfarm-10 ~]# rpm -q --file /bin/dd
coreutils-5.97-34.el5
=
Presumably all packages are appropriate (they have suffix x86_64) as
shown
by yum.
At the same time rpm does show packages without above suffixes
=
[root@pcfarm-10 ~]# rpm -qa | grep coreutil
policycoreutils-1.33.12-14.8.el5
policycoreutils-newrole-1.33.12-14.8.el5
coreutils-5.97-34.el5
policycoreutils-gui-1.33.12-14.8.el5
=
On Wed, 1 Feb 2012, Stephen J. Gowdy wrote:
> Date: Wed, 1 Feb 2012 11:32:40 +0100 (CET)
> From: Stephen J. Gowdy
> To: Andrey Y Shevel
> Cc: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
> Subject: Re: coreutils for 64 bit
> > It says it only copied 2.1GB. You are runnig a 64bit OS. You
reinstalld > the same coreutils package. You need to change the format of
the package > names from "rpm -qa" if you want to see the architecture
("man rpm" > should help you figure out how).
> > On Wed, 1 Feb 2012, Andrey Y Shevel wrote:
> > > Hi,
> > > > I just paid attention that utility 'dd' uses just 2 GB even I
use > > greater
> > block size (BS). For example
> > > > =
> > [root@pcfarm-10 ~]# dd if=/dev/zero of=/mnt/sdb/TestFile-S1 bs=12GB
> > count=1
> > 0+1 records in
> > 0+1 records out
> > 2147479552 bytes (2.1 GB) copied, 15.8235 seconds, 136 MB/s
> >
> > > > BTW,
> > > > [root@pcfarm-10 ~]# uname -a
> > Linux pcfarm-10.pnpi.spb.ru 2.6.18-274.17.1.el5xen #1 SMP Tue Jan 10
> > 16:41:16 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
> > [root@pcfarm-10 ~]# cat /etc/issue
> > Scientific Linux SL release 5.7 (Boron)
> > Kernel \r on an \m
> > > > > > > > > > I decided to reinstall coreutils:
> > > > [root@pcfarm-10 ~]# yum reinstall coreutils.x86_64
> > Failed to set locale, defaulting to C
> > Loaded plugins: kernel-module
> > Setting up Reinstall Process
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package coreutils.x86_64 0:5.97-34.el5 set to be updated
> > --> Finished Dependency Resolution
> > Beginning Kernel Module Plugin
> > Finished Kernel Module Plugin
> > > > Dependencies Resolved
> > > >
===
> > Package Arch Version
> > Repository
> > Size
> >
===
Netbackup 7.1 BMR and SL6.1 creating boot CD
I've got netbackup up and running fine on SL6.1. I'm trying to create the boot CD for my Linux clients (windows worked fine), but get this: Select one of the following options: 1. Create a new Shared Resource Tree. 2. Create a new CD image based Shared Resource Tree. 3. Copy an existing Shared Resource Tree to a new location. 4. Import a Shared Resource Tree. 5. Modify an existing Shared Resource Tree. 6. Delete an existing Shared Resource Tree. 7. List Shared Resource Trees available on this server. 8. Quit. Enter your selection (1-8) [1] : 1 Enter the name of the SRT to create : 64BitSL Enter the description of the new SRT : 64 bit SL6.1 V-128-312 Unsupported Linux release: Scientific Linux release 6.1 (Carbon) Enter the desired RedHat level () : I've entered everything I can find around the web from Red Hat Enterprise Linux Server 6 to 2.6, but it just returns with Enter the desired RedHat level (): ... Any ideas what I should put there? -- James Pulver LEPP Computer Group Cornell University
Re: coreutils for 64 bit
Hi Stephen,
thank you for your reply.
==
[root@pcfarm-10 ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}.%{ARCH}\n" |
grep coreutils
policycoreutils-1.33.12.x86_64
policycoreutils-newrole-1.33.12.x86_64
coreutils-5.97.x86_64
policycoreutils-gui-1.33.12.x86_64
=
And obviously
[root@pcfarm-10 ~]# arch
x86_64
===
The result is prety same as I shown earlier.
And the same I see at CERN
===
[lxplus427] /afs/cern.ch/user/s/shevel > dd if=/dev/zero of=/tmp/testx64
bs=3GB count=1
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 5.91242 seconds, 363 MB/s
[lxplus427] /afs/cern.ch/user/s/shevel > rpm -q --file /bin/dd
coreutils-5.97-34.el5
[lxplus427] /afs/cern.ch/user/s/shevel > rpm -qa --queryformat
"%{NAME}-%{VERSION}.%{ARCH}\n" | grep coreutil
policycoreutils-1.33.12.x86_64
coreutils-5.97.x86_64
policycoreutils-gui-1.33.12.x86_64
===
As far as I understand the main question is "is there 64 bit dd version
which can operate more then 2GB value for BS in SL anyway?"
Any answer (yes or no) is good to know.
Many thanks,
Andrey
On Wed, 1 Feb 2012, Stephen J. Gowdy wrote:
Date: Wed, 1 Feb 2012 19:10:14 +0100 (CET)
From: Stephen J. Gowdy
To: Andrey Y. Shevel
Cc: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
Subject: Re: coreutils for 64 bit
Exactly if you type "man rpm" it will show you how you get it to print
the arch string (usually i686 or x86_64). Since you seem unabel to read a man
page what you want to type is;
rpm -qa --queryformat "%{NAME}-%{VERSION}.%{ARCH}\n" | grep coreutils
(or miss out the VERSION if you want to see somethign similar to yum)
On Wed, 1 Feb 2012, Andrey Y. Shevel wrote:
Hi Stephen,
thanks for the reply.
I am not sure that I do understand you (sorry for my stupidity).
I have
===
[root@pcfarm-10 ~]# yum list | grep coreutil
Failed to set locale, defaulting to C
coreutils.x86_64 5.97-34.el5 installed
policycoreutils.x86_64 1.33.12-14.8.el5 installed
policycoreutils-gui.x86_64 1.33.12-14.8.el5 installed
policycoreutils-newrole.x86_64 1.33.12-14.8.el5 installed
[root@pcfarm-10 ~]# rpm -q --file /bin/dd
coreutils-5.97-34.el5
=
Presumably all packages are appropriate (they have suffix x86_64) as shown
by yum.
At the same time rpm does show packages without above suffixes
=
[root@pcfarm-10 ~]# rpm -qa | grep coreutil
policycoreutils-1.33.12-14.8.el5
policycoreutils-newrole-1.33.12-14.8.el5
coreutils-5.97-34.el5
policycoreutils-gui-1.33.12-14.8.el5
=
On Wed, 1 Feb 2012, Stephen J. Gowdy wrote:
> Date: Wed, 1 Feb 2012 11:32:40 +0100 (CET)
> From: Stephen J. Gowdy
> To: Andrey Y Shevel
> Cc: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
> Subject: Re: coreutils for 64 bit
>
> It says it only copied 2.1GB. You are runnig a 64bit OS. You reinstalld
> the same coreutils package. You need to change the format of the package
> names from "rpm -qa" if you want to see the architecture ("man rpm"
> should help you figure out how).
>
> On Wed, 1 Feb 2012, Andrey Y Shevel wrote:
>
> > Hi,
> >
> > I just paid attention that utility 'dd' uses just 2 GB even I use
> > greater
> > block size (BS). For example
> >
> > =
> > [root@pcfarm-10 ~]# dd if=/dev/zero of=/mnt/sdb/TestFile-S1 bs=12GB
> > count=1
> > 0+1 records in
> > 0+1 records out
> > 2147479552 bytes (2.1 GB) copied, 15.8235 seconds, 136 MB/s
> >
> >
> > BTW,
> >
> > [root@pcfarm-10 ~]# uname -a
> > Linux pcfarm-10.pnpi.spb.ru 2.6.18-274.17.1.el5xen #1 SMP Tue Jan 10
> > 16:41:16 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
> > [root@pcfarm-10 ~]# cat /etc/issue
> > Scientific Linux SL release 5.7 (Boron)
> > Kernel \r on an \m
> >
> >
> >
> >
> > I decided to reinstall coreutils:
> >
> > [root@pcfarm-10 ~]# yum reinstall coreutils.x86_64
> > Failed to set locale, defaulting to C
> > Loaded plugins: kernel-module
> > Setting up Reinstall Process
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package coreutils.x86_64 0:5.97-34.el5 set to be updated
> > --> Finished Dependency Resolution
> > Beginning Kernel Module Plugin
> > Finished Kernel Module Plugin
> >
> > Dependencies Resolved
> >
> > ===
> > Package Arch Version
> > Repository
> > Size
> >
===
> > Reinstalling:
> > coreutilsx86_645.97-34.el5
> > sl-base
> > 3.6 M
> >
> > Transaction Summary
> >
==
Bug report: Page allocation failure with virtio-net in kvm guest on 2.6.32-220.4.1
Page allocation failure with virtio-net in kvm guest on 2.6.32-220.4.1 Reproducibly after a couple minutes or hours and 100 MB - 30GB of network traffic (NFS) the network interface in the guest goes down. The guest can be shut down from the host via acpi event. This does only happen with the virtio net driver, with e1000 the guest is stable for days. Host and guest run 2.6.32-220.4.1.el6.x86_64 Host runs kvm version 0.12.1.2-2.209.el6_2.4.x86_64 Feb 2 13:04:02 host656 kernel: rpciod/0: page allocation failure. order:0, mode:0x20 Feb 2 13:04:02 host656 kernel: Pid: 1081, comm: rpciod/0 Not tainted 2.6.32-220.4.1.el6.x86_64 #1 Feb 2 13:04:02 host656 kernel: Call Trace: Feb 2 13:04:02 host656 kernel: [] ? __alloc_pages_nodemask+0x77f/0x940 Feb 2 13:04:02 host656 kernel: [] ? alloc_pages_current+0xaa/0x110 Feb 2 13:04:02 host656 kernel: [] ? try_fill_recv+0x262/0x280 [virtio_net] Feb 2 13:04:02 host656 kernel: [] ? netif_receive_skb+0x58/0x60 Feb 2 13:04:02 host656 kernel: [] ? virtnet_poll+0x42d/0x8d0 [virtio_net] Feb 2 13:04:02 host656 kernel: [] ? net_rx_action+0x103/0x2f0 Feb 2 13:04:02 host656 kernel: [] ? __do_softirq+0xc1/0x1d0 Feb 2 13:04:02 host656 kernel: [] ? call_softirq+0x1c/0x30 Feb 2 13:04:02 host656 kernel: [] ? do_softirq+0x65/0xa0 Feb 2 13:04:02 host656 kernel: [] ? local_bh_enable+0x9a/0xb0 Feb 2 13:04:02 host656 kernel: [] ? tcp_rcv_established+0x107/0x800 Feb 2 13:04:02 host656 kernel: [] ? tcp_v4_do_rcv+0x2e3/0x430 Feb 2 13:04:02 host656 kernel: [] ? tcp_write_xmit+0x1f6/0x9e0 Feb 2 13:04:02 host656 kernel: [] ? release_sock+0x65/0xe0 Feb 2 13:04:02 host656 kernel: [] ? tcp_sendmsg+0x73c/0xa10 Feb 2 13:04:02 host656 kernel: [] ? sock_sendmsg+0x11a/0x150 Feb 2 13:04:02 host656 kernel: [] ? pvclock_clocksource_read+0x58/0xd0 Feb 2 13:04:02 host656 kernel: [] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [] ? enqueue_entity+0x125/0x420 Feb 2 13:04:02 host656 kernel: [] ? kernel_sendmsg+0x41/0x60 Feb 2 13:04:02 host656 kernel: [] ? xs_send_kvec+0x8e/0xa0 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? xs_sendpages+0x173/0x220 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? xs_tcp_send_request+0x5d/0x160 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? xprt_transmit+0x83/0x2e0 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? call_transmit+0x1d8/0x2c0 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? __rpc_execute+0x5e/0x2a0 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? rpc_async_schedule+0x0/0x20 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? rpc_async_schedule+0x15/0x20 [sunrpc] Feb 2 13:04:02 host656 kernel: [] ? worker_thread+0x170/0x2a0 Feb 2 13:04:02 host656 kernel: [] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [] ? worker_thread+0x0/0x2a0 Feb 2 13:04:02 host656 kernel: [] ? kthread+0x96/0xa0 Feb 2 13:04:02 host656 kernel: [] ? child_rip+0xa/0x20 Feb 2 13:04:02 host656 kernel: [] ? kthread+0x0/0xa0 Feb 2 13:04:02 host656 kernel: [] ? child_rip+0x0/0x20 Feb 2 13:04:02 host656 kernel: rpciod/0: page allocation failure. order:0, mode:0x20 Feb 2 13:04:02 host656 kernel: Pid: 1081, comm: rpciod/0 Not tainted 2.6.32-220.4.1.el6.x86_64 #1 Feb 2 13:04:02 host656 kernel: Call Trace: Feb 2 13:04:02 host656 kernel: [] ? __alloc_pages_nodemask+0x77f/0x940 Feb 2 13:04:02 host656 kernel: [] ? kmem_getpages+0x62/0x170 Feb 2 13:04:02 host656 kernel: [] ? fallback_alloc+0x1ba/0x270 Feb 2 13:04:02 host656 kernel: [] ? cache_grow+0x2cf/0x320 Feb 2 13:04:02 host656 kernel: [] ? cache_alloc_node+0x99/0x160 Feb 2 13:04:02 host656 kernel: [] ? __alloc_skb+0x7a/0x180 Feb 2 13:04:02 host656 kernel: [] ? kmem_cache_alloc_node_notrace+0x6f/0x130 Feb 2 13:04:02 host656 kernel: [] ? __kmalloc_node+0x7b/0x100 Feb 2 13:04:02 host656 kernel: [] ? __alloc_skb+0x7a/0x180 Feb 2 13:04:02 host656 kernel: [] ? __netdev_alloc_skb+0x36/0x60 Feb 2 13:04:02 host656 kernel: [] ? virtnet_poll+0x1b2/0x8d0 [virtio_net] Feb 2 13:04:02 host656 kernel: [] ? net_rx_action+0x103/0x2f0 Feb 2 13:04:02 host656 kernel: [] ? __do_softirq+0xc1/0x1d0 Feb 2 13:04:02 host656 kernel: [] ? call_softirq+0x1c/0x30 Feb 2 13:04:02 host656 kernel: [] ? do_softirq+0x65/0xa0 Feb 2 13:04:02 host656 kernel: [] ? local_bh_enable+0x9a/0xb0 Feb 2 13:04:02 host656 kernel: [] ? tcp_rcv_established+0x107/0x800 Feb 2 13:04:02 host656 kernel: [] ? tcp_v4_do_rcv+0x2e3/0x430 Feb 2 13:04:02 host656 kernel: [] ? tcp_write_xmit+0x1f6/0x9e0 Feb 2 13:04:02 host656 kernel: [] ? release_sock+0x65/0xe0 Feb 2 13:04:02 host656 kernel: [] ? tcp_sendmsg+0x73c/0xa10 Feb 2 13:04:02 host656 kernel: [] ? sock_sendmsg+0x11a/0x150 Feb 2 13:04:02 host656 kernel: [] ? pvclock_clocksource_read+0x58/0xd0 Feb 2 13:04:02 host656 kernel: [] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [] ? enqueue_entity+0x125/0x420 Feb 2 13:04:02 host656 kernel: [] ? kernel_sendmsg+0x41/0x60 Feb 2 13:04:02 h
Re: serious bug in boot sequence when fsck is required
On Wed, Feb 1, 2012 at 9:04 PM, jdow wrote: > On 2012/02/01 15:38, Tom H wrote: >> >> On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia >> wrote: >>> >>> This is not normally considered a "bug". The software is not doing >>> anything that is not expected or undocumented. It's a *risk*, and some >>> folks might think it's a security flaw. But the burden of storing and >>> managing separate password for deployed systems is not, hirsorically, >>> taken up by default. It would have to be written into the OS instaler >>> to apply on the existing boot loader software. So it's not set by >>> default. >> >> >> It's not a bug; it's a TUV decision. Requiring the root password for >> single user mode can be set through "/etc/sysconfig/init". >> >> As Nico's shown, you can also set a grub password to prevent anyone >> from adding "init=/bin/sh"/"init=/bin/bash" to the "kernel" line >> without that password. > > > It is a bug, IIRC. The original complaint is that it claims it is ready > to accept the root password and something prevents it by causing the > login prompt to recycle with each character typed. That has been declared > a TUV bug. I think somebody mentioned there might be a fix for it that has > not percolated through yet. It'd be worth checking TUV's bugzilla. This is Yasha's original issue, *separate* from password protection for the boot loader. Yasha brought up what he considered a separate "bug", that the init=/bin/sh stunt works by default, and that is what I've been saying "that's not a bug, it's a documented part of how things work, please don't derive software behavior from first principles and then say 'that's a bug' when it doesn't work the way you thing". It's tempting, and I've done it myself, but it leads to confusion. The broken root password handling is a distinct problem. It's clearly a failure, but is probably not a boot loader bug. The system had a corrupted filesystem due to an unmanaged shutdown during a power failure. The state of such a system is unpredictable, and it's unfair to blame the bug on the boot loader when the filesystem may be hosed and demonstrably needs to be fsck'ed. No one can fix that for you from the installed software side, because the state of the data on the disks is unreliable and cannot be trusted to be reliable software. It has to be fixed That's what rescue and recovery media are *for*. I'd be curious if Yasha can *now* reboot into fsck requiring mode. Yasha? Do you feel like testing that? You could use 'tune2fs' to lower the max-mount-counts to, say, 3, and reboot a couple of times to get it do demand an fsck.
