Re: From where does fsck failure prompt root passwd come?
On Thu, Feb 2, 2012 at 5:19 PM, Yasha Karant ykar...@csusb.edu wrote: 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. Yes, it was presented by you. You are the *only one* who has associated this problem with grub's internal passwords, tied to your deductions about a memory of how this used to work. But that's a different password storage and handling entirely. It has to be separate for a whole stack of security and maintenance reasons: one cracked or corrupted OS image should not provide init=/bin/sh and other access to all the other operating systems that may be accessible from grub. The login being requested when fsck failed. is the normal root password out of /etc/passwd, /etc/shadow, or other network based authentication mechanisms. And since your disk is demonstrably corrupt at this point due to that power failure, the state of /etc/shadow (the likely repository) is indeterminate, as is the state of the normal login utilities for /bin/sh and /bin/login. The problem with the login screen is easy to test. Just add a line to /etc/fstab, something like this: /dev/sdf1 /mnt/test ext4 defaults 0 2 Then reboot. Grub will perform some sleight of hand to gain access to the / partition and gain access to the OS startup tools, /etc/fstab will be parsed, fsck will fail (as it did for your / partition), and grub will give init the -b option to summon the /sbin/sulogin program. The init and sulogin handling is documented in the sulogin man page. Then you can verify that it was *not* grub, or a software bug, but rather your corrupted disk causing the mishandled password entry problems you encountered (which is my theory).
Re: CUPS doesn't offer Ledger as a paper size
On Thu, Feb 2, 2012 at 2:47 PM, James M Pulver jmp...@cornell.edu 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. Set an alternative printer configuration with the different page size in CUPS. This is what I used to do to get double-sided printing for Samba users.
RE: CUPS doesn't offer Ledger as a paper size
So now I think I've managed to get the PPD edited so Tabloid prints from Linux CUPS clients. However, the PPD update doesn't seem to get copied to the Windows side via cupsaddsmbd ... the Windows users still don't get a Tabloid (or really many of the PPD page size options) in their GUI. I can work around it via selecting A3 as a paper size, that is close enough, but does have a larger boarder than the actual Tabloid setting... Any ideas? -- James Pulver LEPP Computer Group Cornell University -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Mark Stodola Sent: Thursday, February 02, 2012 3:21 PM To: scientific-linux-us...@fnal.gov Subject: 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] Keyboard issue with SL6.2RC1
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? Cheers Bill Maidment IT Consultant to Elgas Ltd Phone: 02 4294 3649 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. Pat -- Pat Riehecky Scientific Linux Developer
Re: [SCIENTIFIC-LINUX-USERS] Keyboard issue with SL6.2RC1
On Fri, Feb 3, 2012 at 7:58 AM, Pat Riehecky riehe...@fnal.gov 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
SL debuginfo packages?
Hi, guys - my SL 6.1 repo files do not seem to have a reference to the SL debuginfo repository. I looked at the SL FTP server and I see the debuginfo files here: http://ftp1.scientificlinux.org/linux/scientific/6.1/archive/debuginfo/ Is that the right stuff? Is there any particular reason why there is no repo file for them? P.S. I am looking at a crash of mdadm and gdb mdadm tells me to run debuginfo-install mdadm-3.2.1-1.el6.x86_64 which in turn enables the epel-debuginfo repo, but then bails out because there is no sl-debuginfo repo and it cannot find the glibc debuginfo package. I hope I am on the right track here. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] SL debuginfo packages?
On 02/03/2012 11:43 AM, Konstantin Olchanski wrote: Hi, guys - my SL 6.1 repo files do not seem to have a reference to the SL debuginfo repository. I looked at the SL FTP server and I see the debuginfo files here: http://ftp1.scientificlinux.org/linux/scientific/6.1/archive/debuginfo/ Is that the right stuff? Is there any particular reason why there is no repo file for them? P.S. I am looking at a crash of mdadm and gdb mdadm tells me to run debuginfo-install mdadm-3.2.1-1.el6.x86_64 which in turn enables the epel-debuginfo repo, but then bails out because there is no sl-debuginfo repo and it cannot find the glibc debuginfo package. I hope I am on the right track here. The debuginfo repo is in contained in yum-conf-sl-other. Pat -- Pat Riehecky Scientific Linux Developer
Re: From where does fsck failure prompt root passwd come?
On 02/03/2012 08:46 AM, Konstantin Olchanski wrote: On Thu, Feb 2, 2012 at 5:19 PM, Yasha Karantykar...@csusb.edu wrote: https://bugzilla.redhat.com/show_bug.cgi?id=636628 That bug report is no good as it is filed against Fedora. If you want to see the same bug fixed in RHEL/SL, you better file a bug against RHEL (with reference to the fedora bug). In the RHEL world, no bug report - no problem - no fix. P.S. And that's my personal experience. system-config-date has been busted since SL6.0. Original bug was reported in Fedora, *fixed* in Fedora for years, then shows up again in RHEL6. So I file a bug against RHEL6.0. First it is downgraded to low priority, (RHEL6.1 is out), then it is bumped into high priority (RHEL6.2 is about to go out), now the fix is scheduled for RHEL6.3. If you think it is too cumbersone and too difficult and too slow, please go ahead and roll out your own YaLinux or whatever. P.P.S. The quoted bug report includes a workaround for the problem (RTFBR!), so I vote to delete this whole email thread out of existance - problem is known, is reported through proper channels and there is a workaround. There is nothing to discuss other than whining about bugs not being fixed quickly enough or diverge into unrelated topics such as bios and grub password protections. I vote to keep the thread. Your statement that the bug report is only in Fedora and that no one else has experienced this issue with EL 6 is not correct, and I quote from a previous post I made to this thread: From: https://bugzilla.redhat.com/show_bug.cgi?id=636628 Geeky 2011-06-04 09:02:40 EDT Also present in RHEL6.1 ! paid, licensed, commercial support End quote. If necessary, to satisfy the poster, I suppose that the report can also be filed against RHEL 6.1, although I personally do not have such RH paid, licensed, commercial support. (Is that needed for posting against a licensed-for-fee binary product?) Thus, the entire set of TUV compliant distributions probably have this feature, including RHEL 6.1 and SL 6.1 In private communication off list, it has been pointed out to me that: I suspect the big difference is the use of upstart in 6.x where just plain old init was used before. Upstart may either be just using mode that are there or setting some different one than before. End quote. The mode to which the correspondent refers are TTY control and interpretation modes (bits) set in the software, and possibly not even reflected into the hardware via the driver. Yasha Karant
Re: From where does fsck failure prompt root passwd come?
On Fri, Feb 3, 2012 at 10:29 AM, Yasha Karant ykar...@csusb.edu wrote: https://bugzilla.redhat.com/show_bug.cgi?id=636628 Geeky 2011-06-04 09:02:40 EDT Also present in RHEL6.1 ! paid, licensed, commercial support End quote. If necessary, to satisfy the poster, I suppose that the report can also be filed against RHEL 6.1, although I personally do not have such RH paid, licensed, commercial support. (Is that needed for posting against a licensed-for-fee binary product?) What should have been done was to clone the Fedora bug as a RHEL bug. It is easy in bugzilla; just click on the Clone This Bug link and follow the procedure. Having said that, it looks like the bug for this issue already exists for RHEL-6 and being worked on (Bug 702814). However, like in many other cases, it is not publicly accessible, so we cannot follow the progress. The only thing visible to the general public is their knowledgebase: https://access.redhat.com/kb/docs/DOC-49493 Akemi
upstart
I have been looking into the issue of upstart. From: http://upstart.ubuntu.com/ Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. and is therein listed as: Known Users Ubuntu 6.10 and later Fedora 9 and later Debian (as an option) Nokia's Maemo platform Palm's WebOS Google's Chromium OS Google's Chrome OS Copyright © 2010 Canonical Ltd. Upstart is a trademark of Canonical Ltd. which date indicates that the above list may be obsolete, and probably is obsolete in that upstart appears to be incorporated into EL 6 . From the upstart FAQ: What are the example jobs? The example jobs are based on the /etc/inittab file found in Ubuntu, and thus also Debian. They run the same scripts as the old System-V init packages on the same events, using the System-V compatibility tools to generate runlevel events. Why don't the example jobs work on my distribution? Because every distribution has used System-V init differently, every distribution's /etc/inittab file (on which the example jobs are based) is different. You'll need to examine this file from your distribution, compare it against the one found in Ubuntu or Debian, and modify the example jobs appropriately. End quotes. I apologize for my lack of free time to dig up the details on upstart in SL 6, but if anyone is familiar with upstart as used in SL 6, I would appreciate links to the appropriate documentation, any EL changes from the Debian/Ubuntu distribution source, and related upstart material (a state transition chart would be nice given that upstart is event driven). Replies on upstart off list are invited. I note that openSUSE has included upstart as of version 11.3 Milestone 4, but not as default (http://en.wikipedia.org/wiki/Upstart). A colleague and I did a comparison of the boot on an openSUSE machine versus a SL 6.1 machine -- otherwise essentially identical hardware platforms with very similar application and systems environments -- and noted a difference. As openSUSE evidently does not default to upstart, this may explain at least one difference in behavior -- he took mostly defaults from openSUSE during the installation phase. Yasha Karant
Busted SL6.1 mdadm array monitoring
FYI, unless you have a freshly installed SL6.1 machine, it is likely that you will not receive email from mdadm when your array fails. This is because mdadm is not runing. It looks like it always crashes on startup unless all md arrays have metadata version 1.0 or later - there is a version number listed in /proc/mdstat - if there is an array without version number, mdstat will crash. This was found and fixed in Fedora. For more details, see https://bugzilla.redhat.com/show_bug.cgi?id=787276 P.S. Aparently this problem is fixed in RHEL/SL6.2: cd /triumfcs/mirror/SL/6.2/x86_64/os/Packages rpm -vh --upgrade mdadm-3.2.2-9.el6.x86_64.rpm service mdmonitor restart no mdadm crash got many emails from mdadm mdadm still running. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: upstart
On 3 February 2012 19:08, Yasha Karant ykar...@csusb.edu wrote: I have been looking into the issue of upstart. From: http://upstart.ubuntu.com/ Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. and is therein listed as: Known Users Ubuntu 6.10 and later Fedora 9 and later Debian (as an option) Nokia's Maemo platform Palm's WebOS Google's Chromium OS Google's Chrome OS Copyright © 2010 Canonical Ltd. Upstart is a trademark of Canonical Ltd. which date indicates that the above list may be obsolete, and probably is obsolete in that upstart appears to be incorporated into EL 6 . From the upstart FAQ: What are the example jobs? The example jobs are based on the /etc/inittab file found in Ubuntu, and thus also Debian. They run the same scripts as the old System-V init packages on the same events, using the System-V compatibility tools to generate runlevel events. Why don't the example jobs work on my distribution? Because every distribution has used System-V init differently, every distribution's /etc/inittab file (on which the example jobs are based) is different. You'll need to examine this file from your distribution, compare it against the one found in Ubuntu or Debian, and modify the example jobs appropriately. End quotes. I apologize for my lack of free time to dig up the details on upstart in SL 6, but if anyone is familiar with upstart as used in SL 6, I would appreciate links to the appropriate documentation, any EL changes from the Debian/Ubuntu distribution source, and related upstart material (a state transition chart would be nice given that upstart is event driven). Replies on upstart off list are invited. I note that openSUSE has included upstart as of version 11.3 Milestone 4, but not as default (http://en.wikipedia.org/wiki/Upstart). A colleague and I did a comparison of the boot on an openSUSE machine versus a SL 6.1 machine -- otherwise essentially identical hardware platforms with very similar application and systems environments -- and noted a difference. As openSUSE evidently does not default to upstart, this may explain at least one difference in behavior -- he took mostly defaults from openSUSE during the installation phase. Yasha Karant Yasha, Please, please use the Scientific Linux fora for this sort of discussion. Comments about other non-EL distros are really not relevant to this mailing list. I leave it to you to look up the URL and register. Alan.
Re: upstart
On Feb 3, 2012, at 8:08 PM, Yasha Karant wrote: have been looking into the issue of upstart. From: http://upstart.ubuntu.com/ Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. and is therein listed as: Known Users Ubuntu 6.10 and later Fedora 9 and later This is wrong. Fedora 15 and up uses systemd. http://www.freedesktop.org/wiki/Software/systemd with compatibly for SysV stuff present. Fedora is pushing hard to convert everything to systemd for Fedora17 and they did for 16 as well. One can assume form that RHEL7 will land with systemd. Steve. Debian (as an option) Nokia's Maemo platform Palm's WebOS Google's Chromium OS Google's Chrome OS
Re: upstart
On Fri, Feb 3, 2012 at 2:08 PM, Yasha Karant ykar...@csusb.edu wrote: I have been looking into the issue of upstart. From: http://upstart.ubuntu.com/ Copyright © 2010 Canonical Ltd. Upstart is a trademark of Canonical Ltd. which date indicates that the above list may be obsolete, and probably is obsolete in that upstart appears to be incorporated into EL 6 . From the upstart FAQ: What are the example jobs? The example jobs are based on the /etc/inittab file found in Ubuntu, and thus also Debian. They run the same scripts as the old System-V init packages on the same events, using the System-V compatibility tools to generate runlevel events. Why don't the example jobs work on my distribution? Because every distribution has used System-V init differently, every distribution's /etc/inittab file (on which the example jobs are based) is different. You'll need to examine this file from your distribution, compare it against the one found in Ubuntu or Debian, and modify the example jobs appropriately. I apologize for my lack of free time to dig up the details on upstart in SL 6, but if anyone is familiar with upstart as used in SL 6, I would appreciate links to the appropriate documentation, any EL changes from the Debian/Ubuntu distribution source, and related upstart material (a state transition chart would be nice given that upstart is event driven). I'm not too sure how copyright works but since there's a 13 December 2011 Upstart 1.4 Released! on that page, it's more up to dat than you seem to think. 1) What are you trying to do? 2) SInce upstart runs in hybrid mode on SL6 (and even on latest Ubuntu alpha), you can write a sysvinit script for whatever custom daemon you want to launch and upstart'll call it.
Re: serious bug in boot sequence when fsck is required
On Wed, Feb 1, 2012 at 9:04 PM, jdow j...@earthlink.net wrote: On 2012/02/01 15:38, Tom H wrote: On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcianka...@gmail.com wrote: On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karantykar...@csusb.edu wrote: Back to my primary point: the bug in accepting the root password upon a failed fsck during boot is from TUV and documented (please see a previous post nominally in this thread). Is there any fix? I do not care if the fix breaks TUV bug-for-bug compatibility -- is there a fix to which routine(s) are causing the problem? This is, in fact, an option to configure in grub in the older LILO boot loader. Run the command info grub-md5-crypt for more information. 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. I've just re-read the whole thread. You're right; it started out about a bug entering the root password in single-user mode after filesystem corruption. A solution was pointed to http://listserv.fnal.gov/scripts/wa.exe?A2=ind1202L=scientific-linux-usersT=0P=243 but Yasha somehow decided that it would turn off the password prompt for single-user mode when all it does is turn off plymouth and allow someone in his situation (according to the Fedora bug) to enter the root password.
Re: From where does fsck failure prompt root passwd come?
On Fri, Feb 3, 2012 at 11:46 AM, Konstantin Olchanski olcha...@triumf.ca wrote: On Thu, Feb 2, 2012 at 5:19 PM, Yasha Karant ykar...@csusb.edu wrote: https://bugzilla.redhat.com/show_bug.cgi?id=636628 That bug report is no good as it is filed against Fedora. If you want to see the same bug fixed in RHEL/SL, you better file a bug against RHEL (with reference to the fedora bug). In the RHEL world, no bug report - no problem - no fix. +1
RE: [SCIENTIFIC-LINUX-USERS] Keyboard issue with SL6.2RC1
-Original message- From: Akemi Yagi amy...@gmail.com Sent: Sat 04-02-2012 03:04 Subject:Re: [SCIENTIFIC-LINUX-USERS] Keyboard issue with SL6.2RC1 To: Pat Riehecky riehe...@fnal.gov; CC: Bill Maidment b...@maidment.vu; SCIENTIFIC-LINUX-USERS@listserv.fnal.gov; On Fri, Feb 3, 2012 at 7:58 AM, Pat Riehecky riehe...@fnal.gov 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
Re: Bug report: Page allocation failure with virtio-net in kvm guest on 2.6.32-220.4.1
To verify whether this is a hardware or configuration problem on my side, do SL 6.2 guests on SL 6.2 hosts work reliably without virtio-net hiccups for other people? Even when they are stressed with a bit of network traffic? (~100 GB/hour) Any reports are highly appreciated. Original Message Subject: Bug report: Page allocation failure with virtio-net in kvm guest on 2.6.32-220.4.1 Date: Thu, 02 Feb 2012 16:21:38 +0100 From: Benjamin Reiter, Aginion IT-Consulting b.rei...@aginion.de To: scientific-linux-us...@fnal.gov 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: IRQ [81123daf] ? __alloc_pages_nodemask+0x77f/0x940 Feb 2 13:04:02 host656 kernel: [81158a1a] ? alloc_pages_current+0xaa/0x110 Feb 2 13:04:02 host656 kernel: [a0108d22] ? try_fill_recv+0x262/0x280 [virtio_net] Feb 2 13:04:02 host656 kernel: [8142df18] ? netif_receive_skb+0x58/0x60 Feb 2 13:04:02 host656 kernel: [a01091fd] ? virtnet_poll+0x42d/0x8d0 [virtio_net] Feb 2 13:04:02 host656 kernel: [814307c3] ? net_rx_action+0x103/0x2f0 Feb 2 13:04:02 host656 kernel: [81072001] ? __do_softirq+0xc1/0x1d0 Feb 2 13:04:02 host656 kernel: [8100c24c] ? call_softirq+0x1c/0x30 Feb 2 13:04:02 host656 kernel: EOI [8100de85] ? do_softirq+0x65/0xa0 Feb 2 13:04:02 host656 kernel: [81071f0a] ? local_bh_enable+0x9a/0xb0 Feb 2 13:04:02 host656 kernel: [8147a8e7] ? tcp_rcv_established+0x107/0x800 Feb 2 13:04:02 host656 kernel: [81482c13] ? tcp_v4_do_rcv+0x2e3/0x430 Feb 2 13:04:02 host656 kernel: [8147ead6] ? tcp_write_xmit+0x1f6/0x9e0 Feb 2 13:04:02 host656 kernel: [8141cc75] ? release_sock+0x65/0xe0 Feb 2 13:04:02 host656 kernel: [8146fb4c] ? tcp_sendmsg+0x73c/0xa10 Feb 2 13:04:02 host656 kernel: [81419a0a] ? sock_sendmsg+0x11a/0x150 Feb 2 13:04:02 host656 kernel: [81038488] ? pvclock_clocksource_read+0x58/0xd0 Feb 2 13:04:02 host656 kernel: [81090a90] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [81061c95] ? enqueue_entity+0x125/0x420 Feb 2 13:04:02 host656 kernel: [81419a81] ? kernel_sendmsg+0x41/0x60 Feb 2 13:04:02 host656 kernel: [a018ab6e] ? xs_send_kvec+0x8e/0xa0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018acf3] ? xs_sendpages+0x173/0x220 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018aedd] ? xs_tcp_send_request+0x5d/0x160 [sunrpc] Feb 2 13:04:02 host656 kernel: [a0188e63] ? xprt_transmit+0x83/0x2e0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a0185c48] ? call_transmit+0x1d8/0x2c0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018e23e] ? __rpc_execute+0x5e/0x2a0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018e4d0] ? rpc_async_schedule+0x0/0x20 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018e4e5] ? rpc_async_schedule+0x15/0x20 [sunrpc] Feb 2 13:04:02 host656 kernel: [8108b150] ? worker_thread+0x170/0x2a0 Feb 2 13:04:02 host656 kernel: [81090a90] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [8108afe0] ? worker_thread+0x0/0x2a0 Feb 2 13:04:02 host656 kernel: [81090726] ? kthread+0x96/0xa0 Feb 2 13:04:02 host656 kernel: [8100c14a] ? child_rip+0xa/0x20 Feb 2 13:04:02 host656 kernel: [81090690] ? kthread+0x0/0xa0 Feb 2 13:04:02 host656 kernel: [8100c140] ? child_rip+0x0/0x20 ... VM is started with: qemu 2347 61.7 3.7 537704 281556 ? Sl 13:09 67:29 /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name kvm_host656.net31 -uuid 97eae23f-bb13-58da-b4bc-258c6bf275a2 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm_host656.net31.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/dev/disk/by-path/ip-10.224.2.20:3260-iscsi-iqn.1986-03.com.sun:02:e9e63ad1-3f29-4d5c-9da9-b10e44a1520f.vmstore12.net31-lun-1,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6a:c7:d8,bus=pci.0,addr=0x3 -chardev
XFCE - panel 2 (lower panel) keeps on disappearing
Hello, i'm not sure what i changed ( as far as i remember - nothing), but since about 3 days ago, the lower panel ( panel 2) started dissappearing from the screen upon startup. In order to get it back i had to un-check Show and hide panel in panel preferences. that would make it appear . Subsequent setting of the Show and hide panel flag will make it hide - as expected. It's quite annoying, but i'm not sure where to look. thank you Andrew
Re: Bug report: Page allocation failure with virtio-net in kvm guest on 2.6.32-220.4.1
Dne 4.2.2012 3:34, Benjamin Reiter, Aginion IT-Consulting napsal(a): To verify whether this is a hardware or configuration problem on my side, do SL 6.2 guests on SL 6.2 hosts work reliably without virtio-net hiccups for other people? Even when they are stressed with a bit of network traffic? (~100 GB/hour) Any reports are highly appreciated. Original Message Subject: Bug report: Page allocation failure with virtio-net in kvm guest on 2.6.32-220.4.1 Date: Thu, 02 Feb 2012 16:21:38 +0100 From: Benjamin Reiter, Aginion IT-Consulting b.reiter-jxsx9qjxn1celga04la...@public.gmane.org To: scientific-linux-users-13hema8v...@public.gmane.org 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:IRQ [81123daf] ? __alloc_pages_nodemask+0x77f/0x940 Feb 2 13:04:02 host656 kernel: [81158a1a] ? alloc_pages_current+0xaa/0x110 Feb 2 13:04:02 host656 kernel: [a0108d22] ? try_fill_recv+0x262/0x280 [virtio_net] Feb 2 13:04:02 host656 kernel: [8142df18] ? netif_receive_skb+0x58/0x60 Feb 2 13:04:02 host656 kernel: [a01091fd] ? virtnet_poll+0x42d/0x8d0 [virtio_net] Feb 2 13:04:02 host656 kernel: [814307c3] ? net_rx_action+0x103/0x2f0 Feb 2 13:04:02 host656 kernel: [81072001] ? __do_softirq+0xc1/0x1d0 Feb 2 13:04:02 host656 kernel: [8100c24c] ? call_softirq+0x1c/0x30 Feb 2 13:04:02 host656 kernel:EOI [8100de85] ? do_softirq+0x65/0xa0 Feb 2 13:04:02 host656 kernel: [81071f0a] ? local_bh_enable+0x9a/0xb0 Feb 2 13:04:02 host656 kernel: [8147a8e7] ? tcp_rcv_established+0x107/0x800 Feb 2 13:04:02 host656 kernel: [81482c13] ? tcp_v4_do_rcv+0x2e3/0x430 Feb 2 13:04:02 host656 kernel: [8147ead6] ? tcp_write_xmit+0x1f6/0x9e0 Feb 2 13:04:02 host656 kernel: [8141cc75] ? release_sock+0x65/0xe0 Feb 2 13:04:02 host656 kernel: [8146fb4c] ? tcp_sendmsg+0x73c/0xa10 Feb 2 13:04:02 host656 kernel: [81419a0a] ? sock_sendmsg+0x11a/0x150 Feb 2 13:04:02 host656 kernel: [81038488] ? pvclock_clocksource_read+0x58/0xd0 Feb 2 13:04:02 host656 kernel: [81090a90] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [81061c95] ? enqueue_entity+0x125/0x420 Feb 2 13:04:02 host656 kernel: [81419a81] ? kernel_sendmsg+0x41/0x60 Feb 2 13:04:02 host656 kernel: [a018ab6e] ? xs_send_kvec+0x8e/0xa0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018acf3] ? xs_sendpages+0x173/0x220 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018aedd] ? xs_tcp_send_request+0x5d/0x160 [sunrpc] Feb 2 13:04:02 host656 kernel: [a0188e63] ? xprt_transmit+0x83/0x2e0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a0185c48] ? call_transmit+0x1d8/0x2c0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018e23e] ? __rpc_execute+0x5e/0x2a0 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018e4d0] ? rpc_async_schedule+0x0/0x20 [sunrpc] Feb 2 13:04:02 host656 kernel: [a018e4e5] ? rpc_async_schedule+0x15/0x20 [sunrpc] Feb 2 13:04:02 host656 kernel: [8108b150] ? worker_thread+0x170/0x2a0 Feb 2 13:04:02 host656 kernel: [81090a90] ? autoremove_wake_function+0x0/0x40 Feb 2 13:04:02 host656 kernel: [8108afe0] ? worker_thread+0x0/0x2a0 Feb 2 13:04:02 host656 kernel: [81090726] ? kthread+0x96/0xa0 Feb 2 13:04:02 host656 kernel: [8100c14a] ? child_rip+0xa/0x20 Feb 2 13:04:02 host656 kernel: [81090690] ? kthread+0x0/0xa0 Feb 2 13:04:02 host656 kernel: [8100c140] ? child_rip+0x0/0x20 ... VM is started with: qemu 2347 61.7 3.7 537704 281556 ? Sl 13:09 67:29 /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name kvm_host656.net31 -uuid 97eae23f-bb13-58da-b4bc-258c6bf275a2 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm_host656.net31.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/dev/disk/by-path/ip-10.224.2.20:3260-iscsi-iqn.1986-03.com.sun:02:e9e63ad1-3f29-4d5c-9da9-b10e44a1520f.vmstore12.net31-lun-1,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0
Re: serious bug in boot sequence when fsck is required
On 02/03/2012 02:43 PM, Tom H wrote: On Wed, Feb 1, 2012 at 9:04 PM, jdowj...@earthlink.net wrote: On 2012/02/01 15:38, Tom H wrote: On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcianka...@gmail.com wrote: On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karantykar...@csusb.eduwrote: Back to my primary point: the bug in accepting the root password upon a failed fsck during boot is from TUV and documented (please see a previous post nominally in this thread). Is there any fix? I do not care if the fix breaks TUV bug-for-bug compatibility -- is there a fix to which routine(s) are causing the problem? This is, in fact, an option to configure in grub in the older LILO boot loader. Run the command info grub-md5-crypt for more information. 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. I've just re-read the whole thread. You're right; it started out about a bug entering the root password in single-user mode after filesystem corruption. A solution was pointed to http://listserv.fnal.gov/scripts/wa.exe?A2=ind1202L=scientific-linux-usersT=0P=243 but Yasha somehow decided that it would turn off the password prompt for single-user mode when all it does is turn off plymouth and allow someone in his situation (according to the Fedora bug) to enter the root password. Please excuse my obvious misunderstanding, but the URL that was mentioned and that you repeat contains the statement: With rd_NO_PLYMOUTH I don't get a prompt for the password for the root filesystem encryption, but that's a minor matter relative to the problem itself. End quote. Not having a prompt for the password is what is stated. Thus, I assumed that under a call to fsck during boot with an abnormal exit from fsck, the default behavior of rd_NO_PLYMOUTH would be to allow root access without a password during boot. Admittedly, a boot root password under these circumstances is little protection to a determined attacker who has physical access -- but it will deter the casual hacker. By analogy, it is rather like a deadbolt lock on a wood frame and wood door without metal armor, a reinforced wall and door frame: a determined attacker simply kicks in the door, but a casual thief finding the door locked and unwilling to break a window leaves. I have not done the experiment as if it fails, I do not want to have to go through the rescue DVD approach again unless I must. Has anyone done the experiment with SL 6x and verified that rd_NO_PLYMOUTH allows for a successful request of a legitimate root password? Yasha Karant
Re: serious bug in boot sequence when fsck is required
On Fri, Feb 03, 2012 at 11:22:39PM -0800, Yasha Karant wrote: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1202L=scientific-linux-usersT=0P=243 [With rd_NO_PLYMOUTH ... no ... prompt for the password for the root filesystem encryption ...] Not having a prompt for the password is what is stated. Dear Yasha, you need to read what you quote. password for xxx filesystem encryption is not the same as login password. But regardless of that, I recommend that you start trying things to find out what *actually* happens rather than trying to guess what other people writings mean or how software ought to and should work. I have not done the experiment as if it fails, I do not want to have to go through the rescue DVD approach again unless I must. Running experiments is what test machines are for. And if you never run experiments you will never learn what *actually* happens and will be doomed forever to confusion and ignorance. And get used to run the rescue DVD. If you stay in the sysadmin business, you will run it many many many more times. It's the computer equivalent of fixing flat tires or washing bird poop off the windshield. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
