Description of problem: Trying to boot Fedora 19 alpha on a HP Envy 23 fails. Details: 1. Fedora-Live-Desktop-x86_64-19-Alpha-1.iso is booted from USB. Grub starts correctly. 2. Choosing in grub: 2.a "Fedora-Live-Desktop-x86_64-19-A1" -> The blue Fedora Sign appears on the display with an offset. The mouse can still be move but shows that the Window has an offset to the screen. The systems hangs and does not come to the login-window. "CTRL + ALT + F2" gives me the shell.The last line in /var/log/messages is: May 18 13:20:29 localhost setroubleshoot: SELinux is preventing /usr/bin/login from getattr access on the directory /run/systemd/system. For complete messages. run sealert -1 7d408226-3381-4b09-901b-b08063e7ebcb Then the screen and the mouse freeze/hang. The mouse can not be moved anymore. CTRL + ALT + F1/F2 does not work. CTRL + ALT + DELETE does not work. The system has to be powered-off to reboot. 2.b "Fedora-Live-Desktop-x86_64-19-A1" and edit details: in Grub choose "Fedora-Live-Desktop-x86_64-19-A1"and with "e" edit the boot command. Change rgbh to nomodset. The boot command is then: linuxefi /isolinux/vmlinuz0 root=live:LABEL=FEdora-Live_Desktop-x86_64-10-A1 ro rd.live.image quiet nomodeset Press F10 to exit the edit mode and boot. The system starts booting although the displayed window has an offset to the screen. The mouse works but has also this offset. The system advances to "[ok] Started GNOME Display Manager". Then it hangs. The mouse still works. "CTRL + ALT + F2" gives me the shell.The last line in /var/log/messages is: May 18 13:37:23 localhost setroubleshoot: SELinux is preventing /usr/bin/login from getattr access on the directory /run/systemd/system. For complete messages. run sealert -1 08021dc7-061b-4e60-aaf9-7eb5c0b384ea. Then the screen and the mouse freeze/hang. The mouse can not be moved anymore. CTRL + ALT + F1/F2 does not work. CTRL + ALT + DELETE does not work. The system has to be powered-off to reboot. 2.c "Verify and Boot Fedora-Live--Desktop-x86_64-19-A1" The USB-stick is checked and given ok. Then blue Fedora Sign appears on the display with an offset. The mouse can still be move but shows that the Window has an offset to the screen. The systems hangs and does not come to the login-window. Then the system hangs completely. The mouse can not be moved anymore. CTRL + ALT + F1/F2 does not work. CTRL + ALT + DELETE does not work. The system has to be powered-off to reboot. Hardware Details: - HP envy 23 - Video graphics: Radeon HD 7450A - Multi-touch enabled 58.42 cm (23 inch) diagonal widescreen full high-definition LED backlit display - Details on: http://h10025.www1.hp.com/ewfrf/wc/document?docname=c03683196&cc=ad&dlc=en&lc=en&jumpid=reg_r1002_usen_c-001_title_r0001#N1445 Boot Medium: USB-stick with Fedora-Live-Desktop-x86_64-19-Alpha-1.iso of 18.05.2013. The correctness of the USB-stick has been verified by executing the respective grub program and the result is "ok". Version-Release number of selected component (if applicable): Fedora-Live-Desktop-x86_64-19-Alpha-1.iso of 18.05.2013 Additional info: From my interpretation this might even be two bugs. One bug in the installation media that is not able to correctly display the boot-windows (display is frozen, but mouse still moves). And a second bug in xorg that freezes the complete system (mouse can not be moved anymore)
Test with Fedora 19 Mate Beta Live I tried again with Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso (version as of 23.05.13) on HP Envy 23 from: https://dl.fedoraproject.org/pub/alt/stage/19-Beta-RC4/Live/x86_64/ Results: Fedora 19 boots and runs correctly. After ca. 15min the system hangs (keyboard freezes; mouse freezes; ping stops answering) I ran also the following options: 1. Boot with adding "noacpi" as bootparameter in grub 2. Boot with adding "noacpi" as boot parameter in grub and setting power save mode to "endless" 3. Boot with adding "noacpi" as boot parameter in grub and setting power save mode to "endless" and switching of xorg with "service lightdm stop" All 3 attempts lead to a system hand. Interpretation: in Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso the boot problems are fixed. Yet there is still another bug. This bug is not within xorg but in a level below. I am very open to any suggestion what I could do to track down the issue.
One obvious thing would be to leave a terminal running 'journalctl -f' running until the system hangs and see if you can catch any related messages in it.
(In reply to Adam Williamson from comment #2) > One obvious thing would be to leave a terminal running 'journalctl -f' > running until the system hangs and see if you can catch any related messages > in it. Hi Adam, thanks for your suggestion. However running 'journalctl -f' did not capture any message just before the freeze (keyboard freezes; mouse freezes; ping stops answering). I suspect, that the root cause of the freeze is a kernel bug. I would apreciate very much any comment on the issue or any method I could look into. (by the way: I tried installing Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso and the installation routine screwed up my efi-boot systems of all my other Linux operating systems. I am now left in a complete mess).
"I would apreciate very much any comment on the issue or any method I could look into." If you have another system handy, you can enable sshd, ssh in from the other system, and 'tail -f /var/log/messages' and see if you can catch the error that way. I agree, BTW, that what's happening is very likely a kernel crash and we need to capture it somehow. "by the way: I tried installing Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso and the installation routine screwed up my efi-boot systems of all my other Linux operating systems. I am now left in a complete mess" Sad to hear - could you file that separately, with some details? Thanks.
Hi Adam, I have another system ready. Unfortunately the installation routine of Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso does not work correctly, so that I can not install the system. I can only let it run from USB. Booting Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB and changing to su I start the sshd: system sshd start I can ping the system (I have given it a fix IP in my network): ping 192.168.1.53 However I can not login with: ssh 192.168.1.53 since I do not have a user or password on the machine Which password would I have to give in order to login with ssh into the live media?
Set a password for the liveuser or root account with 'passwd', and log in as that account.
(In reply to Adam Williamson from comment #6) > Set a password for the liveuser or root account with 'passwd', and log in as > that account. Here is what I did: Boot Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB and changing to su I start the sshd: service sshd start Then I set the password for root with: passwd From another system I can ping the system (I have given it a fix IP in my network): ping 192.168.1.53 Then from the other system I login into the system: ssh root.1.53 (if this procedure is repeated it might be necessary to delete or change .ssh/known_host on the other system in order to enable the connection) Then from the other system I start the monitoring: tail -f /var/log/messages The system freezes (keyboard freezes; mouse freezes; ping stops answering) in about 10 minuted. The displayed message of 'tail -f /var/log/messages' is: ------------------------------------------------(first attempt) Jun 15 02:33:18 localhost NetworkManager[773]: <info> Activation (eno1) Stage 4 of 5 (IPv6 Configure Timeout) complete. Jun 15 02:33:29 localhost systemd[1]: Starting Stop Read-Ahead Data Collection... Jun 15 02:33:29 localhost systemd[1]: Started Stop Read-Ahead Data Collection. Jun 15 02:33:52 localhost su: (to liveuser) liveuser on none Jun 15 02:38:14 localhost systemd[1]: Starting OpenSSH server daemon... Jun 15 02:38:14 localhost sshd-keygen[1959]: Generating SSH2 RSA host key: [ OK ] Jun 15 02:38:14 localhost sshd-keygen[1959]: Generating SSH1 RSA host key: [ OK ] Jun 15 02:38:14 localhost sshd-keygen[1959]: Generating SSH2 DSA host key: [ OK ] Jun 15 02:38:14 localhost systemd[1]: Started OpenSSH server daemon. Jun 15 02:39:39 localhost systemd-logind[608]: New session 2 of user root. Jun 15 02:47:45 localhost systemd[1]: Starting Cleanup of Temporary Directories... Jun 15 02:47:46 localhost systemd-tmpfiles[2063]: stat(/run/user/1000/gvfs) failed: Permission denied Jun 15 02:47:46 localhost systemd[1]: Started Cleanup of Temporary Directories --------------------------------------------- ------------------------------------------------(second attempt) [root@localhost ~]# tail -f /var/log/messsages tail: cannot open ‘/var/log/messsages’ for reading: No such file or directory [root@localhost ~]# tail -f /var/log/messages Jun 15 01:10:17 localhost NetworkManager[768]: <info> Activation (eno1) Stage 4 of 5 (IPv6 Configure Timeout) complete. Jun 15 01:10:30 localhost systemd[1]: Starting Stop Read-Ahead Data Collection... Jun 15 01:10:30 localhost systemd[1]: Started Stop Read-Ahead Data Collection. Jun 15 01:10:48 localhost su: (to liveuser) liveuser on none Jun 15 01:10:53 localhost systemd[1]: Starting OpenSSH server daemon... Jun 15 01:10:53 localhost sshd-keygen[1933]: Generating SSH2 RSA host key: [ OK ] Jun 15 01:10:53 localhost sshd-keygen[1933]: Generating SSH1 RSA host key: [ OK ] Jun 15 01:10:53 localhost sshd-keygen[1933]: Generating SSH2 DSA host key: [ OK ] Jun 15 01:10:53 localhost systemd[1]: Started OpenSSH server daemon. Jun 15 01:12:27 localhost systemd-logind[618]: New session 2 of user root. Jun 15 01:24:45 localhost systemd[1]: Starting Cleanup of Temporary Directories... Jun 15 01:24:45 localhost systemd-tmpfiles[2038]: stat(/run/user/1000/gvfs) failed: Permission denied Jun 15 01:24:45 localhost systemd[1]: Started Cleanup of Temporary Directories. --------------------------------------------- I have watched the monitoring. The last message has been displayed not in the moment of freezing but perhaps 4-6 minutes before freezing. Also I like to mention that the system went down automatically after 2 minutes after freezing and rebooted. Further informations are - the system run ok with Windows 8. So there does not seem to be a hardware problem - running the HP tools to check hardware e.g. RAM also whos that the hardware is ok I hope that helps (Myself I am still clueless). If I can provide any further information or if I can try anything else please let me know. I would also be interested in an application to completely check the system and the hardware (ubuntu has such an app). Is there a test app for fedora?
Unfortunately, we can't really block releases for this kind of bug if it only seems to affect one system, or a small number of systems: there's just so much hardware out there that it's effectively impossible to commit to something like 'there can't be any hardware we know about where the system just doesn't work', we'd never get a release out. The log messages don't give us much of a hint unfortunately. If you can do it again, can you try running 'journalctl -f' instead of 'tail -f /var/log/messages' ? That might give us a chance at catching more output (sorry I didn't think of it before).
Hi Adam, thanks a lot for your comment. Your helo is very much apreciated. > If you can do it again, can you try running 'journalctl -f' instead of 'tail -f > /var/log/messages' ? That might give us a chance at catching more output In Comment 3 I already debugged the system with 'journalctl -f'. Now I did it again with a remote login from another machine (see comment 7). Then I ran: journalctl -f The system freezes (keyboard freezes; mouse freezes; ping stops answering) in about 20 minuted. The displayed message of 'journalctl -f' is: ------------------------------------------------------------ [root@localhost ~]# journalctl -f -- Logs begin at Sun 2013-06-23 19:41:20 EDT. -- Jun 23 17:42:29 localhost sshd-keygen[1924]: Generating SSH1 RSA host key: [...] Jun 23 17:42:29 localhost sshd-keygen[1924]: Generating SSH2 DSA host key: [...] Jun 23 17:42:29 localhost systemd[1]: Started OpenSSH server daemon. Jun 23 17:42:29 localhost sshd[1946]: Server listening on 0.0.0.0 port 22. Jun 23 17:42:29 localhost sshd[1946]: Server listening on :: port 22. Jun 23 17:42:47 localhost passwd[1948]: pam_unix(passwd:chauthtok): password...t Jun 23 17:43:38 localhost sshd[1951]: Connection closed by 192.168.1.52 [pr...h] Jun 23 17:44:36 localhost sshd[1953]: Accepted password for root from 192.1...h2 Jun 23 17:44:36 localhost systemd-logind[597]: New session 2 of user root. Jun 23 17:44:36 localhost sshd[1953]: pam_unix(sshd:session): session opene...0) Jun 23 17:47:29 localhost su[2031]: (to liveuser) liveuser on none Jun 23 17:47:29 localhost su[2031]: pam_unix(su:session): session opened fo...0) Jun 23 17:56:29 localhost systemd[1]: Starting Cleanup of Temporary Directo..... Jun 23 17:56:29 localhost systemd-tmpfiles[2106]: stat(/run/user/1000/gvfs) f... Jun 23 17:56:29 localhost systemd[1]: Started Cleanup of Temporary Directories. ----------------------------------------------------------------- The result look pretty much like in the other tests. Personally I still do not know/guess what the bug could be. > Unfortunately, we can't really block releases for this kind of bug if it > only seems to affect one system, or a small number of systems I guess we agree that this is a kernel bug. Then it is very likely that it will effect other users as well. As today nearly everybody tests on virtual instead of real hardware, the bugs discoverd with real hardware should be taken even more serious. I would expect Fedora to treat this as a blocker for the moment and at least give me some more help to debug the system. Later - if the bug can be narrowed down to something specific - it might be re-evaluated as non-blocking. But untill more info is available the bug should be treated as blocker because the risk is high.
"I guess we agree that this is a kernel bug." Yes. "Then it is very likely that it will effect other users as well." No. In fact it's *less* likely that kernel bugs will affect large numbers of users than other bugs. Kernel bugs are highly likely to be very hardware-specific: it's quite rare to find a serious kernel bug that is not tied quite tightly to a fairly specific range of hardware. I would expect it will affect anyone who has precisely the hardware configuration involved, but no-one else. "As today nearly everybody tests on virtual instead of real hardware" This is not actually true. I have F19 running full-time on both my primary machines, for instance. Many of our testers are using metal, not VMs (or, rather, both); you can't really test stuff like RAID and UEFI very well in a VM. "I would expect Fedora to treat this as a blocker for the moment and at least give me some more help to debug the system" I'm afraid it's not practical to operate that way; if you look through BZ you'll probably find a hundred bugs fairly similar to this (i.e., 'on this specific system, there's a major problem which doesn't seem to happen on other systems'). We can't treat them all as release blockers. In practice, when there is a bug which affects a significant proportion of hardware, we find that we get several duplicate reports of it in short succession, which makes the fact fairly obvious. That has not happened in this case. I'm afraid I can't help you debug beyond what I've already suggested; I hope the kernel team is able to take a look at this bug soon.
If the time period before the system freezes is pretty consistent, this could be to do with the screen saver kicking in, or it could be something is running the CPU to 100% and it takes that long to overheat? Can you try disabling screen saver / screen lock in MATE preferences, and/or check 'top' or 'htop' and see if something is running the CPU to a high usage (and if you can, install and configure lm_sensors and take a look at the CPU temps). Thanks!
Discussed at 2013-06-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-24/f19final-blocker-review-8.2013-06-24-16.00.log.txt . Rejected as a blocker: no-one present had seen reports of anything similar on any other hardware, and we have no other indications that this is affecting many users. It can be re-proposed if more data becomes available that suggests otherwise.
Could you boot with radeon.modeset=0 and see if it helps. This will disable gpu acceleration.
(In reply to Adam Williamson from comment #11) > If the time period before the system freezes is pretty consistent, this > could be to do with the screen saver kicking in, or it could be something is > running the CPU to 100% and it takes that long to overheat? Can you try > disabling screen saver / screen lock in MATE preferences, and/or check 'top' > or 'htop' and see if something is running the CPU to a high usage (and if > you can, install and configure lm_sensors and take a look at the CPU temps). > Thanks! Here is what I did: I booted Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB disabled the screensaver: system -> preferences -> screensaver: - set 2h for time untill computer is regarded as idle - uncheck "Activate Screensaver when computer is idle" - uncheck "Lock Sceen after Computer is idle" Then I installed all packages of "sensor" and logged in from a remote system (see comment 7). I run "top" and here are the results: ---------------------------------------------- after ca. 10 minutes PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1692 liveuser 20 0 500452 24692 10312 R 99.81 0.305 17:23.15 mate-notificati 2113 root 20 0 119412 1620 1128 R 0.333 0.020 0:00.55 top 1 root 20 0 51348 7560 2404 S 0.000 0.093 0:01.26 systemd 2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.000 0.000 0:00.02 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H -------------------------------------------------------------------- ---------------------------------------------- after ca. 20 minutes PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 606 root 20 0 19188 1188 936 S 0.332 0.015 0:00.07 irqbalance 1202 root 20 0 250016 49688 23120 S 0.332 0.613 0:11.93 X 1 root 20 0 51348 7560 2404 S 0.000 0.093 0:01.27 systemd 2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.000 0.000 0:00.02 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H 7 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/u:0H -------------------------------------------------------------------- ---------------------------------------------- in the moment of freezing (after ca. 45 minutes) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2808 root 20 0 0 0 0 S 0.997 0.000 0:00.04 kworker/u:2 1 root 20 0 51348 7560 2404 S 0.000 0.093 0:01.27 systemd 2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.000 0.000 0:00.03 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H 7 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/u:0H -------------------------------------------------------------------- At the same time I was running sensor rempotely with a little script that I executed uder root: while [ 1 ]; do sensors; sleep 2; done Here are the results: ------------------------------------- after ca. 10 minutes [root@localhost ~]# sensors acpitz-virtual-0 Adapter: Virtual device temp1: +27.8°C (crit = +104.0°C) temp2: +29.8°C (crit = +104.0°C) radeon-pci-0100 Adapter: PCI adapter temp1: +47.0°C coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +55.0°C (high = +93.0°C, crit = +103.0°C) Core 0: +51.0°C (high = +93.0°C, crit = +103.0°C) Core 1: +55.0°C (high = +93.0°C, crit = +103.0°C) Core 2: +48.0°C (high = +93.0°C, crit = +103.0°C) Core 3: +48.0°C (high = +93.0°C, crit = +103.0°C) -------------------------------------------------------------------- ---------------------------------------------- after ca. 20 minutes [root@localhost ~]# sensors acpitz-virtual-0 Adapter: Virtual device temp1: +27.8°C (crit = +104.0°C) temp2: +29.8°C (crit = +104.0°C) radeon-pci-0100 Adapter: PCI adapter temp1: +45.0°C coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +42.0°C (high = +93.0°C, crit = +103.0°C) Core 0: +41.0°C (high = +93.0°C, crit = +103.0°C) Core 1: +40.0°C (high = +93.0°C, crit = +103.0°C) Core 2: +41.0°C (high = +93.0°C, crit = +103.0°C) Core 3: +42.0°C (high = +93.0°C, crit = +103.0°C) -------------------------------------------------------------------- ---------------------------------------------- in the moment of freezing (after ca. 45 minutes) acpitz-virtual-0 Adapter: Virtual device temp1: +27.8°C (crit = +104.0°C) temp2: +29.8°C (crit = +104.0°C) radeon-pci-0100 Adapter: PCI adapter temp1: +45.5°C coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +41.0°C (high = +93.0°C, crit = +103.0°C) Core 0: +41.0°C (high = +93.0°C, crit = +103.0°C) Core 1: +40.0°C (high = +93.0°C, crit = +103.0°C) Core 2: +41.0°C (high = +93.0°C, crit = +103.0°C) Core 3: +41.0°C (high = +93.0°C, crit = +103.0°C) -------------------------------------------------------------------- Here are my conclusions/interpretations: 1. First it is remarkable that it took considerabel longer (ca. 45 min) to freeze than before (ca. 20 min). 2. Moreover it is remarkable that in the first 15 minutes there is a process of liveuser called "mate-notificati" that consumes all the memory. Suddenly this process disappears after ca. 20 minutes. In the moment of freeze no special CPU-consumtion was going on. Could the process "mate-notificati" have something to do with the freeze? 3. Temperature does not seem to play a role. It rises slightly with the CPU-consumtion but is far from critical levels. What do you think? and what could I do to further debug?
(In reply to Jerome Glisse from comment #13) > Could you boot with radeon.modeset=0 and see if it helps. This will disable > gpu acceleration. Here is what I did: I booted Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB and in the grub menu entered with "e" to edit the boot command. I added as last parameter: radeon.modeset=0 The system then hang in the boot process with the following error message: ---------------------------------------------------------- .... [6.393686] [drm:radeon.init] *ERROR* No UMS support in radeon module! .... Starting Terminate Plymouth Boot Screen ... ---------------------------------------------------------- I tried two mode timew with similar results. The error deferred a little bit each time. I hope that information helps. If I can provide anything else please let me know. I appreciate your help very much.
Here is my next try with the Fedora 19 release candidate 1: I tried with Fedora-Live-MATE-Compiz-x86_64-19-1.iso (version as of 23.06.13) on HP Envy 23 from: http://dl.fedoraproject.org/pub/alt/stage/19-RC2/Spins/x86_64/ After booting, to exclude other influences I switched off the screensaver and power management: system -> preferences -> screensaver: - set 2h for time untill computer is regarded as idle - uncheck "Activate Screensaver when computer is idle" - uncheck "Lock Sceen after Computer is idle" system -> preferences -> power management: - set to no power saving mode Moreover I logged into the machine from a remote machine (see comment 7). Results: Fedora 19 boots correctly. After 15min the kernel send a "kernel panic" and some errors to the console. The system then rebooted after 30 secs automatically. This has been kept in the moment of "kernel panic" by "top": ---------------------------------------------------------------------- top - 15:29:27 up 18 min, 4 users, load average: 0.06, 0.03, 0.05 Tasks: 190 total, 1 running, 189 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.1 us, 0.1 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 8108480 total, 1284852 used, 6823628 free, 123080 buffers KiB Swap: 8142844 total, 0 used, 8142844 free, 758256 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1507 liveuser 20 0 591852 21732 12612 S 2.992 0.268 0:00.40 nm-applet 763 root 20 0 238192 41944 19884 S 1.330 0.517 0:06.19 X 1938 root 20 0 119412 1612 1124 S 0.332 0.020 0:01.31 top 1 root 20 0 51364 7532 2388 S 0.000 0.093 0:01.18 systemd 2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.000 0.000 0:00.02 ksoftirqd+ --------------------------------------------------------------------- And this has been kept in the moment of "kernel panic" by "journalctl -f" ------------------------------------------------------------------------ [root@localhost ~]# journalctl -f -- Logs begin at Wed 2013-06-26 15:12:26 EDT. -- Jun 26 15:16:53 localhost userhelper[1953]: pam_unix(liveinst:auth): auth co...] Jun 26 15:16:53 localhost userhelper[1953]: pam_unix(liveinst:auth): convers...d Jun 26 15:16:53 localhost userhelper[1953]: pam_unix(liveinst:auth): auth co...] Jun 26 15:18:16 localhost sshd[1960]: Connection closed by 192.168.1.52 [pr...h] Jun 26 15:18:43 localhost sshd[1962]: Accepted password for root from 192.1...h2 Jun 26 15:18:43 localhost systemd-logind[622]: New session 2 of user root. Jun 26 15:18:43 localhost sshd[1962]: pam_unix(sshd:session): session opene...0) Jun 26 15:19:04 localhost sshd[2005]: Accepted password for root from 192.1...h2 Jun 26 15:19:04 localhost systemd-logind[622]: New session 3 of user root. Jun 26 15:19:04 localhost sshd[2005]: pam_unix(sshd:session): session opene...0) Jun 26 15:26:22 localhost systemd[1]: Starting Cleanup of Temporary Directo..... Jun 26 15:26:22 localhost systemd-tmpfiles[2100]: stat(/run/user/1000/gvfs) f... Jun 26 15:26:22 localhost systemd[1]: Started Cleanup of Temporary Directories. ---------------------------------------------------------------------------- What can I do? What shoud I do now?
At this point I'm kind of at a loss, and I'd have to pass you over to the kernel team - sorry.
Hi guys, thanks for your help so far! On Thursday I discovered that I got a similar freeze under Windows 8. Yet, the standard UEFI hardware check provided by HP did not show any defects. On Firday I installed an advanced hardware check provided by HP and was able to get a freeze repeatetly. I am now waiting for the check and repacement/repair of the hardware by HP. So please do not work on this bug untill I provide further information: I will be back with fedora as soon as I got the hardware back from HP.
Hi everybody, I got the hardware back from the HP support. The support confirmed that there has been a hardware bug in the motherboard of the system. The motherboard has been exchanged. I have now installed Fedora-19-Mate and everything works ok. Hence this has definetly not been a Fedora or Linux bug. This bug can be closed. By the way: The support by HP has been very helpful allthough the bug appeared in Linux and this is offically not supported Thanks for everybody for the support!!! Hopefully the debug strategy helps to at least for other people to trace down their bugs.
*** Bug 948641 has been marked as a duplicate of this bug. ***
Doesn't need commonbugs, if it was a hardware issue.