[arch-general] login fails after update
Hello all, I did a complete upgrade following the instructions w.r.t. the /lib symlink, and indeed ended up with pacman -Su saying 'nothing to do' and /lib being a symlink. On rebooting I get the login prompt on tty1..6, but after entering a login nothing happens (no passwd prompt) and after a few seconds the screen is cleared and the login prompt returns. Any ideas ? -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] login fails after update
On 15/07/12 at 08:35P, Fons Adriaensen wrote: Hello all, I did a complete upgrade following the instructions w.r.t. the /lib symlink, and indeed ended up with pacman -Su saying 'nothing to do' and /lib being a symlink. On rebooting I get the login prompt on tty1..6, but after entering a login nothing happens (no passwd prompt) and after a few seconds the screen is cleared and the login prompt returns. Any ideas ? -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) Boot into single user mode and look at /var/log/auth.log. It should tell you what the problem is. -- Dave.
Re: [arch-general] Failed to compile Emacs
After apply this patch, I get: cd /home/favadi/abs/emacs/src/emacs-24.1 automake --gnu -a -c lib/Makefile configure.in:29: error: version mismatch. This is Automake 1.12.2, configure.in:29: but the definition used by this AM_INIT_AUTOMAKE configure.in:29: comes from Automake 1.11.1. You should recreate configure.in:29: aclocal.m4 with aclocal and run automake again. make: *** [/home/favadi/abs/emacs/src/emacs-24.1/lib/Makefile.in] Error 63 config.status: executing gdbinit commands cd /home/favadi/abs/emacs/src/emacs-24.1 automake --gnu -a -c lib/Makefile configure.in:29: error: version mismatch. This is Automake 1.12.2, configure.in:29: but the definition used by this AM_INIT_AUTOMAKE configure.in:29: comes from Automake 1.11.1. You should recreate configure.in:29: aclocal.m4 with aclocal and run automake again. make: *** [/home/favadi/abs/emacs/src/emacs-24.1/lib/Makefile.in] Error 63 == ERROR: A failure occurred in build(). Aborting... How can I solve it? At Sat, 14 Jul 2012 15:12:02 -0500, Leonid Isaev lis...@umail.iu.edu wrote: [1 text/plain; UTF-8 (quoted-printable)] On Sun, 15 Jul 2012 02:21:47 +0700 Diep Pham Van i...@favadi.com wrote: Hello every one, I've tried to compile emacs and fail. You can view the `makepkg -s` ouput here[1]. I think the important part here: ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function) In file included from md5.h:24:0, from md5.c:25: ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function) make[2]: *** [sha1.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [md5.o] Error 1 mv -f .deps/careadlinkat.Tpo .deps/careadlinkat.Po In file included from sha256.h:21:0, from sha256.c:25: ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function) make: *** [lib] Error 2 I do not to know what to do here. Any one can help me with this? [1] https://gist.github.com/3112844 A simple google search yields this: http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-07/msg00240.html... Does it answer your question? -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D [2 signature.asc application/pgp-signature (7bit)]
Re: [arch-general] Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
Am Sun, 15 Jul 2012 00:35:58 -0500 schrieb David C. Rankin drankina...@suddenlinkmail.com: Tom, All, I see the glibc /lib move is out of testing. I updated with --ignore linux,glibc and received an install warning from kmod stating: == Kernel modules are now only read from /usr/lib/modules... My modules are still shown in /lib. Does this mean I cannot reboot safely and expect it to work? Since I wanted to delay install of the new kernel and glibc, should I also have excluded kmod? If you ignore (don't update) linux then the modules are, of course, still in /lib. Maybe you should update your system following the News on the homepage. Heiko
Re: [arch-general] Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
On Sun, Jul 15, 2012 at 12:35:58AM -0500, David C. Rankin wrote: Tom, All, I see the glibc /lib move is out of testing. I updated with --ignore linux,glibc and received an install warning from kmod stating: == Kernel modules are now only read from /usr/lib/modules... My modules are still shown in /lib. Does this mean I cannot reboot safely and expect it to work? Since I wanted to delay install of the new kernel and glibc, should I also have excluded kmod? -- David C. Rankin, J.D.,P.E. it is possible to still have /lib/modules, but have your modules in /usr/lib/modules. Follow issue 2 from the wiki page mentioned in the news. There is a find command to tell you what is in /lib that is not owned. The grep command will tell you what pacman thinks should be in /lib, if you have something that is in there that isn't glibc, either pacman -R it or rebuild it with a fixed pkgbuild that puts them in /usr/lib pgpTbtxPTGZO4.pgp Description: PGP signature
Re: [arch-general] Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/12 08:07, Leonid Isaev wrote: The kernel is not new, but the same with a changed location of the modules. Why would you ever want to mask linux? Those of us who are running Linodes may well all share this issue, because Linode supplies the kernel. But isn't this what kmod is for (I hope, I hope!)? - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAxlHAAoJELT202JKF+xpsvQP+wYdUHNmTldIrPHPzGHCanq3 ufIzaw4GhOuYrIf9TT8/boR07NOOpdEpJUfsbIyYEJaw/dKhTeNaWD115H6q7UCv +MlmPAasg/2y20HOeZIrXeiq4vp53n3Jy8q7u/8lrjL3I/jBpAYSSpRg0IaodEp1 lh5AvIPs4kxegSd+90Pug5MiR23PsCr5vBL4v+vJxsFruN2p71MI0LHeMhy0Jxqc hlNQIoNSklXNkWKkXfVe2ensED3bjtv3R0vjwpzlUvvWKFa3uZqwAwU5XgMCYQ1n 6LjjXfRrpt+apOfKMjJ2rFQw7zU/NUvgGizMG5BpodoSKFjyTa4aNcRBWEs1NS/n r9lMyBzu6JcU/F0fRZAxiV+la6B3G3GUmVIHyESZe6S9PkJWs9XbI98a+KIc5zyJ T3TYK0IblM+9ba2jIOQDFoKaOvB9HTTbZEuSc2lBnNxkHTzb77tgGgyRh4ITm2A4 +uK2M+pwZJhv3fQFd5HFN9JCO2pMfgfYME+MiXvGzqMB5xf37emSa8o0ecSAYe4x iW7Rb+CwO1LPrVJgTWWe6ghrGE5tJDXTzNfm2lZGSF1bWeklgSaJYkvuEEGDtAEW 7+maAPayhb4gpHRBf3r1m0zgMpQREENneiAvCAeKNe7CXlRe9uxjoORBDahbnNlf Johmxsba1RjWczytuYEW =vOw5 -END PGP SIGNATURE-
Re: [arch-general] Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
On 7/15/2012 3:55 PM, C Anthony Risinger wrote: On Sun, Jul 15, 2012 at 2:25 PM, David Benfell benf...@parts-unknown.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/12 08:07, Leonid Isaev wrote: The kernel is not new, but the same with a changed location of the modules. Why would you ever want to mask linux? Those of us who are running Linodes may well all share this issue, because Linode supplies the kernel. But isn't this what kmod is for (I hope, I hope!)? it's pretty easy to run a custom kernel on Linode -- that's what i do with mine at least. ... prob not really an answer in your mind :-) but a possibility. personally i'm curious why it's an issue at all -- if /lib/ is a symlink, why can't modules in /usr/lib/ be found? doesn't kmod follow symlinks? ... all my stuff is working fine, but now i'm compelled to seek the answer. I am having no troubles at all using 3.4.2-linode44 on an i686 instance.
Re: [arch-general] login fails after update
On Sun, Jul 15, 2012 at 10:11:28AM +0100, Dave Morgan wrote: Boot into single user mode and look at /var/log/auth.log. It should tell you what the problem is. Seemed some things were missing, one of them being login Which is *very strange* ... Fortunately I could afford to just dump this system and do a fresh netinstall - all OK now. It was installed something like half a year ago and not used at all before I tried the upgrade. So I really wonder if the late 2011 install image followed by a pacman -Syu still works, as far as I can tell it doesn't, and only a netinstall will. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Re: [arch-general] Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
On 07/15/2012 06:07 AM, Heiko Baums wrote: If you ignore (don't update) linux then the modules are, of course, still in /lib. Maybe you should update your system following the News on the homepage. Heiko Hmm, I did, but I usually put off kernel updates for a week to insure there are not gotchas. I understand now that this update is an all or nothing update. Would have been nice to have that note as part of the announcement. We will get through it, it will just be a bit more fun... -- David C. Rankin, J.D.,P.E.
[arch-general] DeveloperWiki:usrlib - Note - rebuild any needed packages *before* attempting update
All,
After working through the glibc update on several boxes, there should be a
_note_ added to the wiki. You should check the ownership of files in /lib
_before_ attempting any part of the latest update with:
$ find /lib -exec pacman -Qo -- {} +
You will need to rebuild _all_ custom packages _before_ issuing:
# pacman -Syu --ignore glibc
Or you will be left _unable_ to rebuild the packages until you have finished
the update due to the state of your system after pacman -Syu --ignore glibc.
I know most of you know this, but for anyone who simply follows the wiki and
gets to Issue 2: The final pacman -Su still has conflicts in /lib -- it will
be too late at that point. At this point, just complete the update by whatever
means necessary to get the remaining non-glibc owned files out of /lib, complete
the update, then rebuild what you need.
I didn't add the note to the wiki. I can, but don't want to do so until
getting any feedback here.
--
David C. Rankin, J.D.,P.E.
Re: [arch-general] DeveloperWiki:usrlib - Note - rebuild any needed packages *before* attempting update
On Sun, Jul 15, 2012 at 04:20:36PM -0500, David C. Rankin wrote:
All,
After working through the glibc update on several boxes, there should be a
_note_ added to the wiki. You should check the ownership of files in /lib
_before_ attempting any part of the latest update with:
$ find /lib -exec pacman -Qo -- {} +
You will need to rebuild _all_ custom packages _before_ issuing:
# pacman -Syu --ignore glibc
Or you will be left _unable_ to rebuild the packages until you have finished
the update due to the state of your system after pacman -Syu --ignore glibc.
I know most of you know this, but for anyone who simply follows the wiki and
gets to Issue 2: The final pacman -Su still has conflicts in /lib -- it
will
be too late at that point. At this point, just complete the update by whatever
means necessary to get the remaining non-glibc owned files out of /lib,
complete
the update, then rebuild what you need.
I didn't add the note to the wiki. I can, but don't want to do so until
getting any feedback here.
--
David C. Rankin, J.D.,P.E.
Is that not what it says?
It already says These packages need rebuilding so as not to include
the /lib directory. Then the final pacman -Su will successfully
install glibc. I don't see any reason that after reading that it
wouldn't be clear
Re: [arch-general] DeveloperWiki:usrlib - Note - rebuild any needed packages *before* attempting update
On Sun, Jul 15, 2012 at 04:20:36PM -0500, David C. Rankin wrote:
All,
After working through the glibc update on several boxes, there should be a
_note_ added to the wiki. You should check the ownership of files in /lib
_before_ attempting any part of the latest update with:
$ find /lib -exec pacman -Qo -- {} +
You will need to rebuild _all_ custom packages _before_ issuing:
# pacman -Syu --ignore glibc
Or you will be left _unable_ to rebuild the packages until you have finished
the update due to the state of your system after pacman -Syu --ignore glibc.
I know most of you know this, but for anyone who simply follows the wiki and
gets to Issue 2: The final pacman -Su still has conflicts in /lib -- it
will
be too late at that point. At this point, just complete the update by whatever
means necessary to get the remaining non-glibc owned files out of /lib,
complete
the update, then rebuild what you need.
I didn't add the note to the wiki. I can, but don't want to do so until
getting any feedback here.
--
David C. Rankin, J.D.,P.E.
I missed your part about rebuilding before doing pacman -Syu --ignore
glibc, that should be unnecessary as the files will be available in
/usr/lib
Re: [arch-general] DeveloperWiki:usrlib - Note - rebuild any needed packages *before* attempting update
On 07/15/2012 04:52 PM, Daniel Wallace wrote: I missed your part about rebuilding before doing pacman -Syu --ignore glibc, that should be unnecessary as the files will be available in /usr/lib libpam provided the only problem. When the initial pacman -Syu --ignore glibc moved libpam* from /lib to /usr/lib, it left the system unable to build packages that required libpam. I guess the search-path information was hardcoded in the configure.in. I rebuilt the packages that needed rebuilding (hal, shadow (modified), and virtualbox (aur)) on a second box and rsynced the new binaries to the box that was partially updated. After installing the new packages that removed all ownership from /lib (except for glibc), the final 'pacman -Su' completed fine. Progress is always a bit trying, but all in all, Arch did a good job with the move. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] DeveloperWiki:usrlib - Note - rebuild any needed packages *before* attempting update
On 07/15/2012 06:25 PM, Daniel Wallace wrote: On Sun, Jul 15, 2012 at 05:20:03PM -0500, David C. Rankin wrote: On 07/15/2012 04:52 PM, Daniel Wallace wrote: I missed your part about rebuilding before doing pacman -Syu --ignore glibc, that should be unnecessary as the files will be available in /usr/lib libpam provided the only problem. When the initial pacman -Syu --ignore glibc moved libpam* from /lib to /usr/lib, it left the system unable to build packages that required libpam. I guess the search-path information was hardcoded in the configure.in. I rebuilt the packages that needed rebuilding (hal, shadow (modified), and virtualbox (aur)) on a second box and rsynced the new binaries to the box that was partially updated. After installing the new packages that removed all ownership from /lib (except for glibc), the final 'pacman -Su' completed fine. Progress is always a bit trying, but all in all, Arch did a good job with the move. -- David C. Rankin, J.D.,P.E. up to date pam in the repos has all of it's stuff in /usr/lib, you didn't have pam up to date. Also hal has been deprecated for 2 years now, chances are whatever you think you need it for, you don't really need it. if you have hal because you are using [archlinuxfr] repo, you should remove the archlinuxfr repo, hal, and check that you don't have gen-init-cpio installed as that was removed from [archlinuxfr] at the sametime hal was and only a few month ago even though both have been deprecated for a while. There was no where that said to mv stuff from /lib to /usr/lib manually, everything instructed making sure you were entirely up to date, if you are unsure if your mirror is synced recently enough, you can check at http://www.archlinux.org/packages/ Actually he really needs hal --Trinity requires it.
[arch-general] my Arch box randomly becomes irresponsible
Dear Arch users, I have latest Arch installed on my desktop at work. In recent two weeks, the system randomly suspends at night (I call it randomly because it didn't happen every night. And it seems to happen after a random period idle time) when I am off. I can't wake it up in the next morning thru mouse or keyboard. I tried to disable suspension and hibernation by editing /usr/share/polkit-1/actions/org.freedesktop.upower.policy to change from allow_activeyes/allow_active to allow_activeno/allow_active But it doesn't work. While I call it suspend, I am not sure it suspend to RAM or hibernate to disk, because I find the CPU fan and power fan still spin normally. RAM light is also on. So it might be a video driver / setting related issue. For your information, I am using nvidia-302.17-2-x86_64 and have dual monitor set up with nvidia-utils-302.17-1-x86_64 This really bothers me a lot. Any help is appreciated. Thanks! -- Best, Zech
Re: [arch-general] my Arch box randomly becomes irresponsible
2012/7/15 Not To Miss not.to.m...@gmail.com Dear Arch users, I have latest Arch installed on my desktop at work. In recent two weeks, the system randomly suspends at night (I call it randomly because it didn't happen every night. And it seems to happen after a random period idle time) when I am off. I can't wake it up in the next morning thru mouse or keyboard. I tried to disable suspension and hibernation by editing /usr/share/polkit-1/actions/org.freedesktop.upower.policy to change from allow_activeyes/allow_active to allow_activeno/allow_active But it doesn't work. While I call it suspend, I am not sure it suspend to RAM or hibernate to disk, because I find the CPU fan and power fan still spin normally. RAM light is also on. So it might be a video driver / setting related issue. For your information, I am using nvidia-302.17-2-x86_64 and have dual monitor set up with nvidia-utils-302.17-1-x86_64 This really bothers me a lot. Any help is appreciated. Thanks! -- Best, Zech Any hint on /var/log/messages or /var/log/errors?
Re: [arch-general] login fails after update
On 15/07/12 at 08:40pm, Fons Adriaensen wrote: On Sun, Jul 15, 2012 at 10:11:28AM +0100, Dave Morgan wrote: Boot into single user mode and look at /var/log/auth.log. It should tell you what the problem is. Seemed some things were missing, one of them being login Which is *very strange* ... Fortunately I could afford to just dump this system and do a fresh netinstall - all OK now. It was installed something like half a year ago and not used at all before I tried the upgrade. So I really wonder if the late 2011 install image followed by a pacman -Syu still works, as far as I can tell it doesn't, and only a netinstall will. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) The most likely reason for /bin/login being missing is that the upgrade was forced. -- Dave.
Re: [arch-general] my Arch box randomly becomes irresponsible
I didn't remeber I had seen anything relevant in log files. Here is the most recent record in /var/log/messages files (I pressed reset button to reboot at Jul 15 20:37) with -- MARK -- \ message lines skipped: Jul 14 20:36:15 phelps kernel: [111935.191008] PGD 10b42e067 PUD 0 Jul 14 20:36:15 phelps kernel: [111935.191011] Oops: [#1] PREEMPT SMP Jul 14 20:36:15 phelps kernel: [111935.191015] CPU 0 Jul 14 20:36:15 phelps kernel: [111935.191016] Modules linked in: fuse pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O) snd_hda_codec_realtek nvidia(PO) r8169 snd_hd a_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore microcode psmouse i2c_i801 serio_raw intel_agp processor pcspkr iTCO_wdt coretemp mii evdev inte l_gtt iTCO_vendor_support button i2c_core ext4 crc16 jbd2 mbcache raid0 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 md_mod sr_mod cdr om sd_mod usbhid pata_jmicron hid pata_acpi ahci libahci uhci_hcd ata_piix ata_generic ehci_hcd libata scsi_mod usbcore usb_common floppy Jul 14 20:36:15 phelps kernel: [111935.191057] Jul 14 20:36:15 phelps kernel: [111935.191059] Pid: 1373, comm: gnome-shell Tainted: P O 3.4.4-2-ARCH #1 Gigabyte Technology Co., Ltd. P35-DS3R/P35-DS3R Jul 14 20:36:15 phelps kernel: [111935.191063] RIP: 0010:[a06deb9e] [a06deb9e] _nv003990rm+0x4160/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191186] RSP: 0018:88010b6efa88 EFLAGS: 00010246 Jul 14 20:36:15 phelps kernel: [111935.191188] RAX: ffbb RBX: 88011742e008 RCX: 00088004 Jul 14 20:36:15 phelps kernel: [111935.191190] RDX: 88011742e378 RSI: 88011742e008 RDI: 00201875d808 Jul 14 20:36:15 phelps kernel: [111935.191192] RBP: 880118a8dfe0 R08: R09: 880118a8dfec Jul 14 20:36:15 phelps kernel: [111935.191194] R10: R11: 0001 R12: 00088004 Jul 14 20:36:15 phelps kernel: [111935.191196] R13: R14: 88011742e378 R15: Jul 14 20:36:15 phelps kernel: [111935.191199] FS: 7f8f3df8e940() GS:88011fc0() knlGS: Jul 14 20:36:15 phelps kernel: [111935.191201] CS: 0010 DS: ES: CR0: 80050033 Jul 14 20:36:15 phelps kernel: [111935.191203] CR2: 00201875dac0 CR3: 00010b42b000 CR4: 07f0 Jul 14 20:36:15 phelps kernel: [111935.191205] DR0: DR1: DR2: Jul 14 20:36:15 phelps kernel: [111935.191208] DR3: DR6: 0ff0 DR7: 0400 Jul 14 20:36:15 phelps kernel: [111935.191210] Process gnome-shell (pid: 1373, threadinfo 88010b6ee000, task 8801103d7710) Jul 14 20:36:15 phelps kernel: [111935.191212] Stack: Jul 14 20:36:15 phelps kernel: [111935.191213] 88011742e008 88011742e008 00088004 Jul 14 20:36:15 phelps kernel: [111935.191218] c90005144008 a06deaac 88011875f800 88011742e008 Jul 14 20:36:15 phelps kernel: [111935.191222] 880118a8b000 c90005144008 a09067a1 Jul 14 20:36:15 phelps kernel: [111935.191226] Call Trace: Jul 14 20:36:15 phelps kernel: [111935.191347] [a06deaac] ? _nv003990rm+0x406e/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191400] [a09067a1] ? rm_check_pci_config_space+0x499/0xa44 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191450] [a0921930] ? nv_verify_pci_config+0x60/0x80 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191502] [a08fbaab] ? _nv014590rm+0x22/0x27 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191553] [a09080f7] ? _nv014633rm+0x31/0x538 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191675] [a06be7e3] ? _nv009673rm+0xf7/0x134 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191795] [a06df156] ? _nv003990rm+0x4718/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191846] [a0906bdf] ? rm_check_pci_config_space+0x8d7/0xa44 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191915] [a0360736] ? _nv014429rm+0x9/0x21 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191964] [a0921930] ? nv_verify_pci_config+0x60/0x80 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192015] [a08fbaab] ? _nv014590rm+0x22/0x27 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192078] [a031eefa] ? _nv000529rm+0x62/0x98 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192146] [a03639a2] ? _nv016127rm+0x2c/0x67 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192214] [a0362eaa] ? _nv016521rm+0x14aa/0x14fb [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192282] [a0363458] ? _nv016148rm+0x55d/0x58b [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192349] [a0363495] ? _nv001046rm+0xf/0x14 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192416] [a0348b2e] ? _nv000945rm+0x31/0x59 [nvidia] Jul 14
Re: [arch-general] my Arch box randomly becomes irresponsible
2012/7/16 Not To Miss not.to.m...@gmail.com I didn't remeber I had seen anything relevant in log files. Here is the most recent record in /var/log/messages files (I pressed reset button to reboot at Jul 15 20:37) with -- MARK -- \ message lines skipped: Jul 14 20:36:15 phelps kernel: [111935.191008] PGD 10b42e067 PUD 0 Jul 14 20:36:15 phelps kernel: [111935.191011] Oops: [#1] PREEMPT SMP Jul 14 20:36:15 phelps kernel: [111935.191015] CPU 0 Jul 14 20:36:15 phelps kernel: [111935.191016] Modules linked in: fuse pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O) snd_hda_codec_realtek nvidia(PO) r8169 snd_hd a_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore microcode psmouse i2c_i801 serio_raw intel_agp processor pcspkr iTCO_wdt coretemp mii evdev inte l_gtt iTCO_vendor_support button i2c_core ext4 crc16 jbd2 mbcache raid0 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 md_mod sr_mod cdr om sd_mod usbhid pata_jmicron hid pata_acpi ahci libahci uhci_hcd ata_piix ata_generic ehci_hcd libata scsi_mod usbcore usb_common floppy Jul 14 20:36:15 phelps kernel: [111935.191057] Jul 14 20:36:15 phelps kernel: [111935.191059] Pid: 1373, comm: gnome-shell Tainted: P O 3.4.4-2-ARCH #1 Gigabyte Technology Co., Ltd. P35-DS3R/P35-DS3R Jul 14 20:36:15 phelps kernel: [111935.191063] RIP: 0010:[a06deb9e] [a06deb9e] _nv003990rm+0x4160/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191186] RSP: 0018:88010b6efa88 EFLAGS: 00010246 Jul 14 20:36:15 phelps kernel: [111935.191188] RAX: ffbb RBX: 88011742e008 RCX: 00088004 Jul 14 20:36:15 phelps kernel: [111935.191190] RDX: 88011742e378 RSI: 88011742e008 RDI: 00201875d808 Jul 14 20:36:15 phelps kernel: [111935.191192] RBP: 880118a8dfe0 R08: R09: 880118a8dfec Jul 14 20:36:15 phelps kernel: [111935.191194] R10: R11: 0001 R12: 00088004 Jul 14 20:36:15 phelps kernel: [111935.191196] R13: R14: 88011742e378 R15: Jul 14 20:36:15 phelps kernel: [111935.191199] FS: 7f8f3df8e940() GS:88011fc0() knlGS: Jul 14 20:36:15 phelps kernel: [111935.191201] CS: 0010 DS: ES: CR0: 80050033 Jul 14 20:36:15 phelps kernel: [111935.191203] CR2: 00201875dac0 CR3: 00010b42b000 CR4: 07f0 Jul 14 20:36:15 phelps kernel: [111935.191205] DR0: DR1: DR2: Jul 14 20:36:15 phelps kernel: [111935.191208] DR3: DR6: 0ff0 DR7: 0400 Jul 14 20:36:15 phelps kernel: [111935.191210] Process gnome-shell (pid: 1373, threadinfo 88010b6ee000, task 8801103d7710) Jul 14 20:36:15 phelps kernel: [111935.191212] Stack: Jul 14 20:36:15 phelps kernel: [111935.191213] 88011742e008 88011742e008 00088004 Jul 14 20:36:15 phelps kernel: [111935.191218] c90005144008 a06deaac 88011875f800 88011742e008 Jul 14 20:36:15 phelps kernel: [111935.191222] 880118a8b000 c90005144008 a09067a1 Jul 14 20:36:15 phelps kernel: [111935.191226] Call Trace: Jul 14 20:36:15 phelps kernel: [111935.191347] [a06deaac] ? _nv003990rm+0x406e/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191400] [a09067a1] ? rm_check_pci_config_space+0x499/0xa44 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191450] [a0921930] ? nv_verify_pci_config+0x60/0x80 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191502] [a08fbaab] ? _nv014590rm+0x22/0x27 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191553] [a09080f7] ? _nv014633rm+0x31/0x538 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191675] [a06be7e3] ? _nv009673rm+0xf7/0x134 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191795] [a06df156] ? _nv003990rm+0x4718/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191846] [a0906bdf] ? rm_check_pci_config_space+0x8d7/0xa44 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191915] [a0360736] ? _nv014429rm+0x9/0x21 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191964] [a0921930] ? nv_verify_pci_config+0x60/0x80 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192015] [a08fbaab] ? _nv014590rm+0x22/0x27 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192078] [a031eefa] ? _nv000529rm+0x62/0x98 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192146] [a03639a2] ? _nv016127rm+0x2c/0x67 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192214] [a0362eaa] ? _nv016521rm+0x14aa/0x14fb [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192282] [a0363458] ? _nv016148rm+0x55d/0x58b [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192349] [a0363495] ?
Re: [arch-general] my Arch box randomly becomes irresponsible
Thanks. I don't think it is related either. But perhaps I should fix that floppy error anyway Another thing I want to mention is that the screen jitters occasionally and when I lock the screen, only one monitor turns black while the other is still displaying with keyboard disabled but mouse still working. On Sun, Jul 15, 2012 at 11:49 PM, Victor Silva vfbsi...@gmail.com wrote: 2012/7/16 Not To Miss not.to.m...@gmail.com I didn't remeber I had seen anything relevant in log files. Here is the most recent record in /var/log/messages files (I pressed reset button to reboot at Jul 15 20:37) with -- MARK -- \ message lines skipped: Jul 14 20:36:15 phelps kernel: [111935.191008] PGD 10b42e067 PUD 0 Jul 14 20:36:15 phelps kernel: [111935.191011] Oops: [#1] PREEMPT SMP Jul 14 20:36:15 phelps kernel: [111935.191015] CPU 0 Jul 14 20:36:15 phelps kernel: [111935.191016] Modules linked in: fuse pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O) snd_hda_codec_realtek nvidia(PO) r8169 snd_hd a_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore microcode psmouse i2c_i801 serio_raw intel_agp processor pcspkr iTCO_wdt coretemp mii evdev inte l_gtt iTCO_vendor_support button i2c_core ext4 crc16 jbd2 mbcache raid0 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 md_mod sr_mod cdr om sd_mod usbhid pata_jmicron hid pata_acpi ahci libahci uhci_hcd ata_piix ata_generic ehci_hcd libata scsi_mod usbcore usb_common floppy Jul 14 20:36:15 phelps kernel: [111935.191057] Jul 14 20:36:15 phelps kernel: [111935.191059] Pid: 1373, comm: gnome-shell Tainted: P O 3.4.4-2-ARCH #1 Gigabyte Technology Co., Ltd. P35-DS3R/P35-DS3R Jul 14 20:36:15 phelps kernel: [111935.191063] RIP: 0010:[a06deb9e] [a06deb9e] _nv003990rm+0x4160/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191186] RSP: 0018:88010b6efa88 EFLAGS: 00010246 Jul 14 20:36:15 phelps kernel: [111935.191188] RAX: ffbb RBX: 88011742e008 RCX: 00088004 Jul 14 20:36:15 phelps kernel: [111935.191190] RDX: 88011742e378 RSI: 88011742e008 RDI: 00201875d808 Jul 14 20:36:15 phelps kernel: [111935.191192] RBP: 880118a8dfe0 R08: R09: 880118a8dfec Jul 14 20:36:15 phelps kernel: [111935.191194] R10: R11: 0001 R12: 00088004 Jul 14 20:36:15 phelps kernel: [111935.191196] R13: R14: 88011742e378 R15: Jul 14 20:36:15 phelps kernel: [111935.191199] FS: 7f8f3df8e940() GS:88011fc0() knlGS: Jul 14 20:36:15 phelps kernel: [111935.191201] CS: 0010 DS: ES: CR0: 80050033 Jul 14 20:36:15 phelps kernel: [111935.191203] CR2: 00201875dac0 CR3: 00010b42b000 CR4: 07f0 Jul 14 20:36:15 phelps kernel: [111935.191205] DR0: DR1: DR2: Jul 14 20:36:15 phelps kernel: [111935.191208] DR3: DR6: 0ff0 DR7: 0400 Jul 14 20:36:15 phelps kernel: [111935.191210] Process gnome-shell (pid: 1373, threadinfo 88010b6ee000, task 8801103d7710) Jul 14 20:36:15 phelps kernel: [111935.191212] Stack: Jul 14 20:36:15 phelps kernel: [111935.191213] 88011742e008 88011742e008 00088004 Jul 14 20:36:15 phelps kernel: [111935.191218] c90005144008 a06deaac 88011875f800 88011742e008 Jul 14 20:36:15 phelps kernel: [111935.191222] 880118a8b000 c90005144008 a09067a1 Jul 14 20:36:15 phelps kernel: [111935.191226] Call Trace: Jul 14 20:36:15 phelps kernel: [111935.191347] [a06deaac] ? _nv003990rm+0x406e/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191400] [a09067a1] ? rm_check_pci_config_space+0x499/0xa44 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191450] [a0921930] ? nv_verify_pci_config+0x60/0x80 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191502] [a08fbaab] ? _nv014590rm+0x22/0x27 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191553] [a09080f7] ? _nv014633rm+0x31/0x538 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191675] [a06be7e3] ? _nv009673rm+0xf7/0x134 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191795] [a06df156] ? _nv003990rm+0x4718/0xa790 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191846] [a0906bdf] ? rm_check_pci_config_space+0x8d7/0xa44 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191915] [a0360736] ? _nv014429rm+0x9/0x21 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.191964] [a0921930] ? nv_verify_pci_config+0x60/0x80 [nvidia] Jul 14 20:36:15 phelps kernel: [111935.192015] [a08fbaab] ? _nv014590rm+0x22/0x27 [nvidia] Jul 14 20:36:15 phelps
[arch-general] Arch kernel on Linode, was Re: Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/12 18:09, C Anthony Risinger wrote: On Sun, Jul 15, 2012 at 4:14 PM, David Benfell benf...@parts-unknown.org wrote: I'd have to look into using a not-so-custom kernel (presumably from the Arch package). Ten years ago, I used to build kernels routinely. But it's not trivial anymore. nah none of that :-) i detest compiling things. Whew! I mean it used to be fun. And I don't mind much when it's the ./configure-make-make install sequence. But kernel building never was quite that simple and I'd have to say it's become a lot more complicated now. i run the standard Arch kernel, same as any other machine -- you just have to configure your instance to use pv-grub. ... basically, you just need to make a grub-legacy menu.lst file, put it in the normal place on an ext3 partition, and go from there. no real work in the end. I went to the Arch Wiki (or, more precisely, my copy of it, since the original one often fails to answer), went to the Linode wiki (which doesn't talk about Arch Linux), and came up with the following (comments elided) /boot/grub/menu.1st: timeout 5 default 0 color light-blue/black light-cyan/blue title Arch Linux root (hd0) kernel /vmlinuz-linux root=/dev/xvda ro initrd /initramfs-linux.img groot=(hd0) But I missed something because when I went to boot, it still thought it was supposed to boot from (hd0,0). the arch kernel has all the necessary CONFIG_* bits to run unmodified in the Linode XEN environment. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQA531AAoJELT202JKF+xp3e8P/36OaNv+Aa/8pEpuwfPwZ1rY sTjhQaIJM2RF50LMfOLZUqnIz9bae2simjfv2MUi6OgmeDjvDeSKMuDY//HXQlpE mtWlgoQyYFi0SJNnUS/t36wVT5SqKZUDEIfgxqRHy6stbNJd7aaJswkupZitpiT7 z3isrUe3pitGAmLvicpbqmbx2NIDJA6ZBOECdiOQ6FVsvrWrox0bt1p38u5267J0 9hv1AdovkJ74JkmYXZILQHSUNsToW5izzVqXsQXBCM+3OEMuSYfDgb40g/jNT0yV 6oZYnkSIEyKabLrMupEbIYiLFmm1nJ0sMo239C8d2BkyJLdJT1oecc548wvN3Yed K13uKbQGVzjQdoxXWbecBvzSgZAjyFTZ3NZqvF0Rw8ICryc1zAjBkWmIvb/7B9C/ pKnI6BcQaZAZ/SJWaguFiY4xeXgKBx+TUtnshgQTa9UegyYedcp21Uyw/pGrurTF W764dWxqTw/zu9HsBnJ1UEiI03ypaaVfRmSwY+7qZWBpbOD/Orp426/gxq7+zaGs y6X4Pny9fsOw1rmCp80yRvk9MkZSJ09rgHusO6LInCZDki2yyRPBEXYH751hCdF9 3s9COuTf2O8/cQraMX/cEGBWf66ZZkeHc738v26brcuhhQYJmg/Iw+euGvwog1mT TJaLJA83orUL0XRaSZtf =zQgR -END PGP SIGNATURE-
