Description of problem: If I shutdown my F16 installation, the computer won't power off. Version-Release number of selected component (if applicable): Fedora 16rc4 How reproducible: Always. Steps to Reproduce: Shutdown Fedora 16. Actual results: - If system is in runlevel 5: The Fedora logo is shown during shutdown and stay there forever. If I hit [ESC], there are no messages shown - just a black screen. - If system is in runlevel 3: The Fedora logo is shown and if I hit [ESC], I see the message "System halted". But in both cases, the computer won't power off. Reboot works fine. Expected results: Computer should shutdown and power off. Additional info: F16rc4 with no updates installed (because there were none available). F15 turned the power off after shutdown. My hardware-profile: http://www.smolts.org/client/show/pub_92160530-4300-4a42-b54c-e69aef4190e0 # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.1.0-7.fc16.i686.PAE root=UUID=246dfcfe-a2c1-4ee2-99e3-ff59c45f6c6c ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=de_DE.UTF-8 KEYTABLE=de-latin1-nodeadkeys
Meanwhile I can say that the system shutdown in runlevel 5. But it need a long time until the power is turned of (3-7 mins).
I have the same symptoms, with a tiny difference: my machine does not shut down ever (left it 12 hours...) Two interesting facts - The LiveCD system could shut down with no problem - The last thing printed out by the LiveCD system (if I hit ESC at shutdown) is "stopping /dev/md126" and md127; I have a RAID10 raid set using Intel firmware raid, ISW, managed by MDADM. This message is not printed out by the installed system, but the raid set comes up with clean metadata (phew!). I use a /boot in a extended partition and root on an LVM partition. My hardware profile is on http://www.smolts.org/client/show/pub_39c6283a-9e95-45ad-86d2-d09cc6686b14 $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.1.0-7.Core2_SMP_RAID10Fix.fc16.x86_64 root=/dev/mapper/vg_BigVol10-LogVol00 ro rd.md.uuid=9236fca1:517dcb00:e5dd63cf:902aa8a3 rd.dm=0 rd.md.uuid=ad81c652:fa726287:5123faf7:fd1c0785 quiet SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=uk rd.luks=0 rd.lvm.lv=vg_BigVol10/LogVol00 LANG=en_US.UTF-8 (The funny name of the kernel reflects a single patch I added to drivers/md/raid10, and I had this problem with the installed kernel :( .) Best Regards Jens
I am experiencing the same issue as Jens Tingleff, my machine does not shutdown or reboot ever. Like Jens LiveCD shuts down correctly. I am using intel bios-raid managed by mdadm, the last I see before I manually power off is below. Sending SIGTERM to remaining processes... Sending SIGKILL to remaining processes... Unmounting file systems. Unmounted /sys/fs/fuse/Connections Unmounted /dev/hugepages Unmounted /sys/kernel/security Unmounted /sys/kernel/debug Unmounted /dev/mqueue Then the machine will sit there as long as I leave it, have tested over night. At least though after forcing power off the raid set starts up clean. (improvement on fedora 15) - PC hasn't shut down correctly since fedora 14, but on 15 it broke the RAID set each time too. $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.1.1-1.fc16.x86_64 root=/dev/mapper/vg_wil48pc-lv_root ro quiet rhgb I'm happy to provide any logs requested to get this rolling. Any assistance would be appreciated, this problem has been troubling me for some time now. Regards, Nick
Same Problem here. I have the feeling, that somehow the system does not manage to shut down the raid properly, and hangs there. 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02) >cat /proc/mdstat Personalities : [raid1] md127 : active raid1 sda[1] sdb[0] 244137984 blocks super external:/md0/0 [2/2] [UU] md0 : inactive sdb[1](S) sda[0](S) 5282 blocks super external:imsm Serge
Inspired by the splendid http://www.fedoraforum.org/forum/showthread.php?t=271918 I created a script in directory /lib/systemd/system-shutdown/ containing #!/bin/sh mount / -orw,remount dmesg > /dmesg.shutdown mount / -oro,remount (script called dmesg_on_shutdown)and booted with kernel options systemd.log_level=debug and systemd.log_target=kms Sadly, this did not get the script executed :( I then booted with the same options and did sleep 10; /lib/systemd/system-shutdown/dmesg_on_shutdown & sync halt This did get my script executed (yay!) - result attached Best Regards Jens
Created attachment 534569 [details] Output from "dmesg" at or around shutdown after booting with systemd.log_level=debug and systemd.log_target=kmsg kernel options
Oh, and the last message on the console when shutting down is unmounted /dev/hugepages Best Regards Jens
Thanks Jens, I had previously tried that script but could not make it run. With your sleep 10 advice I have created the file also, see attached. Also like Serge I am using 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller If it helps: $ cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [raid0] md124 : active raid0 sdd[1] sde[0] 2930272256 blocks super external:/md126/0 128k chunks md126 : inactive sdd[1](S) sde[0](S) 4648 blocks super external:imsm md125 : active raid5 sda[2] sdb[1] sdc[0] 976768000 blocks super external:/md127/0 level 5, 64k chunk, algorithm 0 [3/3] [UUU] md127 : inactive sdc[2](S) sda[1](S) sdb[0](S) 7356 blocks super external:imsm
Created attachment 534613 [details] Output from "dmesg" at or around shutdown after booting with systemd.log_level=debug and systemd.log_target=kmsg kernel options
Same issue. Fixed appending "power_off=1" to GRUB_CMDLINE_LINUX in /etc/default/grub.
Same issue, appending power_off does not change it. Never shuts down. Also using same RAID controller. Dell precision m6500.
I don't have a raid controller or soft-raid. But the power off comes after some minutes. I don't have it, that the computer stays on endlessly.
I also had no success powering off after booting with power_off=1. This line of thinking lead me to try boot options around acpi and apm, turning them on and off in different combinations. My searches regarding the power_off=1 revealed ubuntu having similar issues. Regardless of my searches and trials I have had no success. Has anyone else come across anything useful regarding this issue? Or know of anything else that could be worth trying?
You are running systemd. You can't use the `halt' command to power off the machine, you should use the `poweroff' command (or `init 0' or `halt -p'). Have a look on HALT(8). Bye
using poweroff or the gnome 3 shutdown command on a computer with an Intel RAID controller hangs indefinitely. (My max wait was 2 hours before giving up.) Last messages seen are Unmounted /dev/hugepages Unmounted /sys/kernel/security Then it sits there. I have had the disks come up uncleanly, so it doesn't appear to be completely harmless. Not sure if there is a period that you can wait to make it always harmless, but I have shut down after that message and ended up with the raid setup unclean on restart afterwards. Have had one time where fsck had to do some cleanup as well. System was very stable with Fedora 15 until a disk failure required a rebuild, which I used to upgrade to Fedora 16. Ticket is monitored, and am willing to test any bug fixes identified for this issue. As noted by others, Live CD shuts down cleanly.
3.1.4-1 has this problem aswell, dell 330 using intel raid (raid1), hangs on unmounting "/dev/hugepages." a patch/fix would be pretty nice..
Created attachment 548173 [details] System messages Same problem here, plus my system clock gets back in time: Mar 9 23:52:49 pegaso kernel: [ 138.969065] UDF-fs: Partition marked readonly; forcing readonly mount Mar 9 23:52:49 pegaso kernel: [ 139.035232] UDF-fs INFO UDF: Mounting volume 'UDF Volume', timestamp 2010/11/21 03:42 (1ed4) smolt: http://www.smolts.org/client/show/pub_7d4ed8c6-6538-4180-a68a-26dafc0b2375
In mi case only the kernel 3.1.4-1.fc16.x86_64 runs fine; 3.1.5-2.fc16.x86_64 and 3.1.5-6.fc16.x86_64 fail.
kernel 3.1.4-1.fc16.x86_64 still waits some time before is turns off (4min) but does not corrupt my filesystem clock.
Today kernel 3.1.4-1.fc16.x86_64 also when shutting down corrupts the system of my laptop; my desktop with f16 works fine.
With the latest updates this issue has been resolved in my laptop; it would be interesting if any of the other reporters still having problems. Thanks.
(In reply to comment #21) > With the latest updates this issue has been resolved in my laptop; it would be > interesting if any of the other reporters still having problems. > If you boot the older kernel, does the problem come back? -c
Unfortunately after latest updates issue remains on my PC. Happy to provide further information or log files if requested. No new symptoms, last thing I see on power off or reboot is: Sending SIGTERM to remaining processes... Sending SIGKILL to remaining processes... Unmounting file systems. Unmounted /sys/fs/fuse/Connections Unmounted /dev/hugepages Unmounted /sys/kernel/security Unmounted /sys/kernel/debug Unmounted /dev/mqueue Then computer will wait indefinitely.
User provided information
(In reply to comment #22) > (In reply to comment #21) > > With the latest updates this issue has been resolved in my laptop; it would be > > interesting if any of the other reporters still having problems. > > > > If you boot the older kernel, does the problem come back? > > -c Well, when trying to probe your recommendation I wake up my laptop and tried to reboot, but then it took like 10 minutes to reboot; it seems the problem is related to the system suspension process.
,,, or the system update process, that was the other thing I did.
I'm not 100% sure, but the long hanging moment on shutdown only seems to be there, when I shutdown/reboot from runlevel 5. When I shutdown from KDE, the GUI shutdown and I see the Fedora boot-/shutdown-screen. When I hit [ESC], I only see a black screen for many minutes. And then, after a long time, for 2 seconds I see the output of the shutdown scripts and then the computer turns off or reboot. And I guess everytime I was in runlevel 1-3, the shutdown comes immediately. Maybe it's a problem with leaving the graphical part of fedora.
This is still happening with 3.1.7-1 for me. Shutting down from init 3 does not appear to make a difference (there was certainly no instant shutdown). A long wait was not enough (waited some hours).
Today I have rebooted from kernel-3.2.2-1.fc16.x86_64 to kernel-3.2.3-2.fc16.x86_64. The problem is still there and the raid disk got degraded. Please, maintainers, pay some more attention to this bug
this problem persists with kernel-3.2.6-3
Appears to persist in Fedora17 Alpha 2
Trouble here too, Dell Dimension 3100 (dual-core Pentium 4, Intel 915GV with BIOS RAID 1). It's not possible to shutdown cleanly, /var/log/messages shows that the RAID array needs to be recovered at restart; fortunately it is able to do this, at least so far. I attempted to suspend the system as a workaround, but after recovering from suspend, the integrated graphics memory is corrupted (menus and window titles show broken and corrupted characters). I"m running kernel-3.1.9-1.fc16.x86_64; booting a later kernel disables my network interfaces, which is the next issue on my to-do list. I'm not sure what other information would be helpful, but this issue is easily repeatable.
I tried using the "special storage devices" option during install using the fedora16 DVD. One two occasions, I got a good install, but no clean shutdon after the install (the installer shuts down cleanly of I install using the "basic storage devices"). In one instance, the raid array was clean, in the other it wasn't.
Oooh - look at this! https://bugzilla.redhat.com/show_bug.cgi?id=752593
There is a known issue with Intel BIOS (IMSM) RAID which should be fixed in Fedora 17 and patches should get backported to F16 at some point. If anyone has this shutdown hang problem using IMSM RAID where it hangs just before unmounting /, it is likely that BZ#752593 is the issue. If anyone has the problem without IMSM RAID it is likely a different bug and we should separate handling of the two bugs.
I'm fairly sure this is the same as 752593. Or at least most of the people reporting here are hitting that issue. I'm going to dupe. If anyone is hitting long shutdown hangs with the latest F16 kernel (3.2.7 or newer) and they aren't using IMSM RAID, please open a new bug. *** This bug has been marked as a duplicate of bug 752593 ***