Re: can't boot F19 system
On 03/20/2014 08:04 PM, Chris Murphy wrote: On Mar 20, 2014, at 6:11 PM, pgaltieri . pgalti...@gmail.com mailto:pgalti...@gmail.com wrote: When I run fsck on the disk it comes back clean. Try fsck.ext4 -f dev It's possible the journal is clean but the file system is not. So how does Linux decide if a drive can be safely removed versus unmounted? If it's unmounted it's safe to remove. If it's mounted, it's not safe to remove. If you're mainly using mate, I'd think that it has a way to automount volumes, and therefore when you reboot it'll unmount them cleanly first. I don't know that it needs to be in fstab. Chris Murphy Chris, my question referred to the menu option. In one case the menu option says Safely Remove Drive in the other case the menu option says Unmount. In the case of Safely Remove when I select it the system unmounts then remounts the filesystem. In the case of Unmount the system unmounts the filesystem, but does not remount it. Paolo -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 19, 2014, at 9:08 PM, pgaltieri . pgalti...@gmail.com wrote: On Wed, Mar 19, 2014 at 11:12 AM, Chris Murphy li...@colorremedies.com wrote: What do you get for smartctl -x /dev/sda Here's the link https://www.amazon.com/clouddrive/share?s=K76mJvZKSG0mr5pSoDGM7k No obvious problems there. I'm suspicious about the many device ready not ready transitions in the phy event counter. So I unplugged the hub after making sure no drives were mounted and rebooted. Guess what? I'm now back to the emergency mode prompt. If I boot off an older kernel I again get the emergency mode prompt. What was working fine earlier no longer works. Here's the shutdown log https://www.amazon.com/clouddrive/share?s=-h_XGxyZT-ws_rNy16Jr0g This system has been running Linux since December and I've never had as much trouble with it as I have had these last few days. Argh! 1. [ 18.334181] systemd[1]: boot-efi.mount mount process exited, code=exited status=0 [ 18.334187] systemd[1]: boot-efi.mount changed mounting - mounted OK so you re-enabled the mounting of /boot/efi and no longer get unknown filesystem type 'vfat' apparently. 2. Like I said before this device has major file system problems. Because it's in your fstab, and fails to mount, you are dropped to emergency shell. *Any* volume in fstab that fails to mount at boot time causes the system to behave this way. Use nofail mount option otherwise. [ 19.400333] systemd[1]: Child 382 died (code=exited, status=1/FAILURE) [ 19.400335] systemd[1]: Child 382 belongs to media-NEWDATA2.mount [ 19.400340] systemd[1]: media-NEWDATA2.mount mount process exited, code=exited status=1 [ 19.401392] systemd[1]: media-NEWDATA2.mount changed mounting - failed 3. What is this watchdog? [ 54.033972] systemd[1]: Shutting down. [ 54.050617] systemd[1]: Hardware watchdog 'iTCO_wdt', version 0 [ 54.052299] systemd[1]: Set hardware watchdog to 10min. [ 54.054024] watchdog watchdog0: watchdog did not stop! Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On 03/19/2014 11:22 PM, Chris Murphy wrote: Like I said before this device has major file system problems. Because it's in your fstab, and fails to mount, you are dropped to emergency shell.*Any* volume in fstab that fails to mount at boot time causes the system to behave this way. Use nofail mount option otherwise. You might also want to change the mount options to noauto user, so that it doesn't get mounted at boot and doesn't require the root password to mount/unmount it. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Wed, Mar 19, 2014 at 11:22 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 19, 2014, at 9:08 PM, pgaltieri . pgalti...@gmail.com wrote: On Wed, Mar 19, 2014 at 11:12 AM, Chris Murphy li...@colorremedies.com wrote: What do you get for smartctl -x /dev/sda Here's the link https://www.amazon.com/clouddrive/share?s=K76mJvZKSG0mr5pSoDGM7k No obvious problems there. I'm suspicious about the many device ready not ready transitions in the phy event counter. So I unplugged the hub after making sure no drives were mounted and rebooted. Guess what? I'm now back to the emergency mode prompt. If I boot off an older kernel I again get the emergency mode prompt. What was working fine earlier no longer works. Here's the shutdown log https://www.amazon.com/clouddrive/share?s=-h_XGxyZT-ws_rNy16Jr0g This system has been running Linux since December and I've never had as much trouble with it as I have had these last few days. Argh! 1. [ 18.334181] systemd[1]: boot-efi.mount mount process exited, code=exited status=0 [ 18.334187] systemd[1]: boot-efi.mount changed mounting - mounted OK so you re-enabled the mounting of /boot/efi and no longer get unknown filesystem type 'vfat' apparently. The latest kernel loads the fat and vfat modules. 2. Like I said before this device has major file system problems. Because it's in your fstab, and fails to mount, you are dropped to emergency shell. *Any* volume in fstab that fails to mount at boot time causes the system to behave this way. Use nofail mount option otherwise. When I run fsck on the disk it comes back clean. I think the problem may have been the entry in fstab. The entry is: labeL=NEWDATA2 /media/NEWDATA2 ext4 defaults,nodev.noexec,nosuid,. it should be: LABEL=NEWDATA2 /media/NEWDATA2 ext4 defaults,nodev.noexec,nosuid,. [ 19.400333] systemd[1]: Child 382 died (code=exited, status=1/FAILURE) [ 19.400335] systemd[1]: Child 382 belongs to media-NEWDATA2.mount [ 19.400340] systemd[1]: media-NEWDATA2.mount mount process exited, code=exited status=1 [ 19.401392] systemd[1]: media-NEWDATA2.mount changed mounting - failed I fixed the fstab entry and mounted it, I get: EXT4-fs (sdb1) mounted filesystem with ordered data mode. Opts (null) When I do umount /media/NEWDATA2 I get systemd[1]: Unit media-NEWDATA2.mount entered failed state. It does unmount the disk 3. What is this watchdog? [ 54.033972] systemd[1]: Shutting down. [ 54.050617] systemd[1]: Hardware watchdog 'iTCO_wdt', version 0 [ 54.052299] systemd[1]: Set hardware watchdog to 10min. [ 54.054024] watchdog watchdog0: watchdog did not stop! I have no idea. But I'm starting to suspect hardware issues with the usb ports. If I plug my usb 3.0 hub in two of the usb ports the system only sees one of the 4 drives plugged into the hub. If I plug it into a third usb port then it sees all 4 drives. Then there's the issue with the usb mouse constantly disconnecting and reconnecting. The system dual boots windows 8.1 and Linux, though by default it boots to Linux. When I try the same experiment with the usb hub under Windows I see the same behaviour. So I booted the system without any drives attached and the system came up fine. I plugged the usb hub in with 4 drives and all 4 drives were mounted. What's strange, and this does not happen on any other F19 system I have, when I right click on any of the drive icons on the desktop and select Safely Remove Drive the system unmounts the drive and then immediately remounts it. And 3 of these drives are not in /etc/fstab. Here's the relevant lines from /var/log/messages Mar 20 16:52:28 peglaptopnew udisksd[3362]: Cleaning up mount point /run/media/pgaltieri/OLDSYSBACKUPS2 (device 8:65 is not mounted) == I don't understand this message Mar 20 16:52:28 peglaptopnew ntfs-3g[5276]: Unmounting /dev/sde1 (OLDSYSBACKUPS2) Mar 20 16:52:28 peglaptopnew udisksd[3362]: Unmounted /dev/sde1 on behalf of uid 1000 Mar 20 16:52:29 peglaptopnew kernel: [ 659.569779] sd 14:0:0:0: [sde] Synchronizing SCSI cache Mar 20 16:52:29 peglaptopnew kernel: [ 659.573672] usb 3-2.1.2: USB disconnect, device number 14 Mar 20 16:52:29 peglaptopnew systemd-udevd[6431]: inotify_add_watch(7, /dev/sde1, 10) failed: No such file or directory Mar 20 16:52:29 peglaptopnew kernel: [ 659.893887] usb 3-2.1.2: new SuperSpeed USB device number 15 using xhci_hcd Mar 20 16:52:29 peglaptopnew kernel: [ 659.906021] usb 3-2.1.2: New USB device found, idVendor=0bc2, idProduct=2312 Mar 20 16:52:29 peglaptopnew kernel: [ 659.906028] usb 3-2.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mar 20 16:52:29 peglaptopnew kernel: [ 659.906032] usb 3-2.1.2: Product: Expansion Mar 20 16:52:29 peglaptopnew kernel: [ 659.906035] usb 3-2.1.2: Manufacturer: Seagate Mar 20 16:52:29 peglaptopnew kernel: [ 659.906038] usb 3-2.1.2: SerialNumber: NA47TGJ2 Mar 20
Re: can't boot F19 system
On Mar 20, 2014, at 6:11 PM, pgaltieri . pgalti...@gmail.com wrote: When I run fsck on the disk it comes back clean. Try fsck.ext4 -f dev It's possible the journal is clean but the file system is not. So how does Linux decide if a drive can be safely removed versus unmounted? If it's unmounted it's safe to remove. If it's mounted, it's not safe to remove. If you're mainly using mate, I'd think that it has a way to automount volumes, and therefore when you reboot it'll unmount them cleanly first. I don't know that it needs to be in fstab. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 18, 2014, at 6:19 PM, pgaltieri . pgalti...@gmail.com wrote: When I looked at the grub.cfg the enforcing=0 was there. In you previous email this URL contains a log with a command line that doesn't include enforcing=0. https://www.amazon.com/clouddrive/share?s=4LDATpk0T3IoK1jb-pKshY rpm -q selinux-policy selinux-policy-3.12.1-74.18.fc19.noarch selinux-policy-3.12.1-74.19.fc19 is stable as of four days ago. There's a newer kernel stable also. I ran shutdown from the Mate login panel and again the system did not powerdown. Here's the shutdown log from doing a shutdown from mate. https://www.amazon.com/clouddrive/share?s=Tfn2AX3zTZAn01Ljxcsc0c OK keep these additions to boot params, with one addition: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0 systemd.unit=rescue.target echo 1 /proc/sys/kernel/sysrq echo s /proc/sysrq-trigger echo u /proc/sysrq-trigger echo o /proc/sysrq-trigger Does that power down the laptop? If not, it's probably a kernel bug. I'd go back to an old kernel that you know worked and test that. And then file a bug against the kernel noting the last kernel it works with and the first one it doesn't. Note the computer make/model, and firmware version, and the fact it's UEFI. If it does power it off, then test the same boot parameter but use the poweroff command instead of the sysrq trigger. The laptop firmware is for sure up to date? Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Tue, Mar 18, 2014 at 11:06 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 18, 2014, at 6:19 PM, pgaltieri . pgalti...@gmail.com wrote: When I looked at the grub.cfg the enforcing=0 was there. In you previous email this URL contains a log with a command line that doesn't include enforcing=0. https://www.amazon.com/clouddrive/share?s=4LDATpk0T3IoK1jb-pKshY rpm -q selinux-policy selinux-policy-3.12.1-74.18.fc19.noarch selinux-policy-3.12.1-74.19.fc19 is stable as of four days ago. There's a newer kernel stable also. I ran shutdown from the Mate login panel and again the system did not powerdown. Here's the shutdown log from doing a shutdown from mate. https://www.amazon.com/clouddrive/share?s=Tfn2AX3zTZAn01Ljxcsc0c OK keep these additions to boot params, with one addition: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0 systemd.unit=rescue.target echo 1 /proc/sys/kernel/sysrq echo s /proc/sysrq-trigger echo u /proc/sysrq-trigger echo o /proc/sysrq-trigger Does that power down the laptop? If not, it's probably a kernel bug. I'd go back to an old kernel that you know worked and test that. And then file a bug against the kernel noting the last kernel it works with and the first one it doesn't. Note the computer make/model, and firmware version, and the fact it's UEFI. If it does power it off, then test the same boot parameter but use the poweroff command instead of the sysrq trigger. The above series of commands do not power off the system, it resets it. Same with the poweroff command. What's strange is I was running 3.13.5-103 kernel without issues until I turned the power off by hitting the switch. I tried 2 earlier kernels, 3.12.11-201 and 3.13.5-101. Both of these worked, i.e. the system went straight to the graphical login and a shutdown resulted in the system powering off. What's interesting is that I tried the 3.13.5-101 kernel a couple of days ago and it went straight to rescue mode as well. I also checked and all modules got loaded so it looks like I can boot the older kernel and try to do an update and see if the most recent kernel exhibits the same problem. A couple of other issues. First when I boot the kernel with the above recommended options it looks like I get 2 shells. What I see is the following: Welcome to emergency mode! After logging in, type journalctl -xb to view Welcome to rescue mode! Type systemctl default or ^D to enter default mode. system logs, .. After I provide my password I get the expected prompt, when I hit return I get another password prompt, another return gives me the command prompt again. I can't type any commands in. If I do Ctrl-Alt-Delete, and wait a while, then I manage to have only one password prompt. The other issue is that when I plug my USB stick in the kernel detects it, since I see the messages on the console, however, it doesn't create a device node and running fdisk -l does not show the device. I'm going to remove the systemd.unit=rescue.target parameter The laptop firmware is for sure up to date? The system was purchased in December of 2013, but I have not checked for an update. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 19, 2014, at 11:24 AM, pgaltieri . pgalti...@gmail.com wrote: The above series of commands do not power off the system, it resets it. Same with the poweroff command. What's strange is I was running 3.13.5-103 kernel without issues until I turned the power off by hitting the switch. I tried 2 earlier kernels, 3.12.11-201 and 3.13.5-101. Both of these worked, i.e. the system went straight to the graphical login and a shutdown resulted in the system powering off. What's interesting is that I tried the 3.13.5-101 kernel a couple of days ago and it went straight to rescue mode as well. I also checked and all modules got loaded so it looks like I can boot the older kernel and try to do an update and see if the most recent kernel exhibits the same problem. Well the fact you're getting different results with different kernels implies there is a kernel bug or regression. But then the fact you're also getting different results with a particular kernel version also, implies some kind of on-disk corruption. So if previously working kernels are now not working, while older ones do work, then just reinstall them. What do you get for smartctl -x /dev/sda But I have no patience for corruption. I personally don't just do reinstalls for that, because corruption is like mice. Where there's one, there's more and I go for complete extermination by reverting to the basics: manufacturer hardware test [1], memtest 86+[2], backup then obliterate the drive contents with ATA secure erase [3], reinstall, smartctl -t long /dev/ test followed by smartctl -x, then restore user data and apps. Good opportunity to upgrade to Fedora 20. :-) [1] For UEFI systems, this can be built-into the firmware, or reside on the EFI System partition so you should inspect your ESP to see if it's there somewhere so you can back it up for future use. Doing a 'tree /boot/efi' is useful for this. Or it may be a separate download. [2] You want one of the first two, use dd to write to a USB stick. http://www.memtest.org/#downiso [3] Applies to SSDs and HDDs alike. http://mackonsti.wordpress.com/2011/11/22/ssd-secure-erase-ata-command/ A couple of other issues. First when I boot the kernel with the above recommended options it looks like I get 2 shells. What I see is the following: Welcome to emergency mode! After logging in, type journalctl -xb to view Welcome to rescue mode! Type systemctl default or ^D to enter default mode. system logs, …... Hmm. Well I'm dense and reversed rescue and emergency targets. single = 1 = rescue.target emergency.target is like runlevel 0.5, it's more minimal. I'm not sure what's going on in your case because whether I use boot param single, 1, rescue.target, or emergency.target I don't see both emergency mode and rescue mode on the same boot. After I provide my password I get the expected prompt, when I hit return I get another password prompt, another return gives me the command prompt again. I can't type any commands in. If I do Ctrl-Alt-Delete, and wait a while, then I manage to have only one password prompt. The other issue is that when I plug my USB stick in the kernel detects it, since I see the messages on the console, however, it doesn't create a device node and running fdisk -l does not show the device. I'm going to remove the systemd.unit=rescue.target parameter It should work since it's the same thing as single user mode. The system was purchased in December of 2013, but I have not checked for an update. I would. My main laptop is an Apple Macbook Pro and it had a firmware update out of the gate upon arrival the very month of its assembly (and about 4 more after that mostly all Thunderbolt related). It's not a given that the new firmware is better. But that's usually the case when experiencing weird problems like being unable to power off the computer. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Wed, Mar 19, 2014 at 11:12 AM, Chris Murphy li...@colorremedies.comwrote: On Mar 19, 2014, at 11:24 AM, pgaltieri . pgalti...@gmail.com wrote: The above series of commands do not power off the system, it resets it. Same with the poweroff command. What's strange is I was running 3.13.5-103 kernel without issues until I turned the power off by hitting the switch. I tried 2 earlier kernels, 3.12.11-201 and 3.13.5-101. Both of these worked, i.e. the system went straight to the graphical login and a shutdown resulted in the system powering off. What's interesting is that I tried the 3.13.5-101 kernel a couple of days ago and it went straight to rescue mode as well. I also checked and all modules got loaded so it looks like I can boot the older kernel and try to do an update and see if the most recent kernel exhibits the same problem. Well the fact you're getting different results with different kernels implies there is a kernel bug or regression. But then the fact you're also getting different results with a particular kernel version also, implies some kind of on-disk corruption. So if previously working kernels are now not working, while older ones do work, then just reinstall them. What do you get for smartctl -x /dev/sda Here's the link https://www.amazon.com/clouddrive/share?s=K76mJvZKSG0mr5pSoDGM7k But I have no patience for corruption. I personally don't just do reinstalls for that, because corruption is like mice. Where there's one, there's more and I go for complete extermination by reverting to the basics: manufacturer hardware test [1], memtest 86+[2], backup then obliterate the drive contents with ATA secure erase [3], reinstall, smartctl -t long /dev/ test followed by smartctl -x, then restore user data and apps. Good opportunity to upgrade to Fedora 20. :-) I'll wait a bit, I'm not that adventurous :-) [1] For UEFI systems, this can be built-into the firmware, or reside on the EFI System partition so you should inspect your ESP to see if it's there somewhere so you can back it up for future use. Doing a 'tree /boot/efi' is useful for this. Or it may be a separate download. [2] You want one of the first two, use dd to write to a USB stick. http://www.memtest.org/#downiso [3] Applies to SSDs and HDDs alike. http://mackonsti.wordpress.com/2011/11/22/ssd-secure-erase-ata-command/ The system was purchased in December of 2013, but I have not checked for an update. I would. My main laptop is an Apple Macbook Pro and it had a firmware update out of the gate upon arrival the very month of its assembly (and about 4 more after that mostly all Thunderbolt related). It's not a given that the new firmware is better. But that's usually the case when experiencing weird problems like being unable to power off the computer. There was a BIOS update which I installed. The system booted fine after the update, but now I'm back to emergency mode, and I have no idea what I did :-( This is now starting to get very frustrating. After booting of an old kernel I ran yum -y update and updated to the latest kernel and selinux packages plus other stuff. I rebooted and the system lo and behold booted up to the graphical login, there was no emergency mode login prompt :-) This was running fine for a while. I plugged in my external USB 3.0 hub, which worked fine with 3.13.5 prior to me screwing things up :-) and nothing happened, it did not see any drives. I unplugged the drives and then plugged them in one by one and it saw one but not the other 3. So I unplugged the hub after making sure no drives were mounted and rebooted. Guess what? I'm now back to the emergency mode prompt. If I boot off an older kernel I again get the emergency mode prompt. What was working fine earlier no longer works. Here's the shutdown log https://www.amazon.com/clouddrive/share?s=-h_XGxyZT-ws_rNy16Jr0g This system has been running Linux since December and I've never had as much trouble with it as I have had these last few days. Argh! Paolo Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 11:15 PM, pgaltieri . pgalti...@gmail.com wrote: complained about dirty bit being set and that backup version didn't match current version. And if you run it a second time with: # fsck.msdos -av /dev/sda1 I'd like to see the result of a boot with boot parameters rhgb quiet removed, and systemd.log_level=debug added. And then use this: journalctl -xb -o short-monotonic /mnt/usb/journal-debug.txt Here's the link https://www.amazon.com/clouddrive/share?s=femLQ67TRQkjI3mhQQKx1c It did not mount my external USB hard drive, but after loading the vfat module it did mount my USB stick. Please unplug everything from this laptop, except power. You need to get the basic setup working reliably first. No external hard drives. No mouse. Nothing, except power. Skip creating a replacement journal for now, I'll probably see most of it with the shutdown-log.txt I mention later. OK stop doing that. echo 1 /proc/sys/kernel/sysrq echo r /proc/sysrq-trigger echo e /proc/sysrq-trigger echo i /proc/sysrq-trigger Got to this point and system reset. That doesn't seem right at all. Do you have some kind of watchdog like process running that causes a reboot if something fails? That's what this sounds like to me, because i is just a SIGKILL for everything except systemd. So it should not reboot. Read this under the section Shutdown Completes Eventually http://freedesktop.org/wiki/Software/systemd/Debugging/ Follow the instructions exactly. For this you can directly edit grub.cfg if you want, rather than editing it in grub's edit mode which can't do copy-paste obviously. Create the debug.sh (remember to make it executable or it won't work). Reboot so the boot params take effect, and then do a poweroff. That whole poweroff sequence should record a lot of debug information and write it all out to /shutdown-log.txt which you can then post. With debug turned on I keep seeing messages like the following USB disconnect, device number 15 new low-speed USB device number 16 using xhci_hcd The number 15 and 16 keep incrementing about 5 seconds apart. This device is my USB optical mouse Please disconnect the mouse for this troubleshooting so that we're only dealing with the basic system for now. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Tue, Mar 18, 2014 at 10:07 AM, Chris Murphy li...@colorremedies.comwrote: On Mar 17, 2014, at 11:15 PM, pgaltieri . pgalti...@gmail.com wrote: complained about dirty bit being set and that backup version didn't match current version. And if you run it a second time with: # fsck.msdos -av /dev/sda1 I'd like to see the result of a boot with boot parameters rhgb quiet removed, and systemd.log_level=debug added. And then use this: journalctl -xb -o short-monotonic /mnt/usb/journal-debug.txt Here's the link https://www.amazon.com/clouddrive/share?s=femLQ67TRQkjI3mhQQKx1c It did not mount my external USB hard drive, but after loading the vfat module it did mount my USB stick. Please unplug everything from this laptop, except power. You need to get the basic setup working reliably first. No external hard drives. No mouse. Nothing, except power. Skip creating a replacement journal for now, I'll probably see most of it with the shutdown-log.txt I mention later. OK stop doing that. echo 1 /proc/sys/kernel/sysrq echo r /proc/sysrq-trigger echo e /proc/sysrq-trigger echo i /proc/sysrq-trigger Got to this point and system reset. That doesn't seem right at all. Do you have some kind of watchdog like process running that causes a reboot if something fails? That's what this sounds like to me, because i is just a SIGKILL for everything except systemd. So it should not reboot. Read this under the section Shutdown Completes Eventually http://freedesktop.org/wiki/Software/systemd/Debugging/ Follow the instructions exactly. For this you can directly edit grub.cfg if you want, rather than editing it in grub's edit mode which can't do copy-paste obviously. Create the debug.sh (remember to make it executable or it won't work). Reboot so the boot params take effect, and then do a poweroff. That whole poweroff sequence should record a lot of debug information and write it all out to /shutdown-log.txt which you can then post. With debug turned on I keep seeing messages like the following USB disconnect, device number 15 new low-speed USB device number 16 using xhci_hcd The number 15 and 16 keep incrementing about 5 seconds apart. This device is my USB optical mouse Please disconnect the mouse for this troubleshooting so that we're only dealing with the basic system for now. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org Now I'm completely and utterly confused :-) I put in the debug.sh script in place and edited the grub.cfg to add in the systemd debug lines including the enforcing=0. Here's the link to the output file https://www.amazon.com/clouddrive/share?s=txDEjSfhRRspXGR4KioIa8 I tried the poweroff and it worked. I rebooted tried it again and it worked. I rebooted again and tried the echo 1 /proc/sys/kernel/sysrq echo r /proc/sysrq-trigger echo i /proc/sysrq-trigger echo s /proc/sysrq-trigger echo u /proc/sysrq-trigger echo b /proc/sysrq-trigger Just to see what would happen. It started to do a SElinux relable and got about 20% before it rebooted. Now the reason I'm utterly confused is that it got to graphical mode :-(. I typed Ctrl-Alt-F3 to get to a virtual console and entered poweroff and this time the system did not power off, it reset and now I'm back in rescue mode. Here's the link to the shutdown-log.txt file for this event. https://www.amazon.com/clouddrive/share?s=4LDATpk0T3IoK1jb-pKshY When I was in the virtual console I ran ifconfig and it did not see any network interfaces, it only showed the loopback interface. Paolo -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 18, 2014, at 12:53 PM, pgaltieri . pgalti...@gmail.com wrote: Please unplug everything from this laptop, except power. You need to get the basic setup working reliably first. No external hard drives. No mouse. Nothing, except power. You haven't done this like I asked. [0.860472] scsi 0:0:0:0: Direct-Access ATA WDC WD10JPVX-75J 01.0 PQ: 0 ANSI: 5 [0.861762] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [2.901151] scsi 5:0:0:0: Direct-Access SanDisk Cruzer 2.01 PQ: 0 ANSI: 6 [2.909355] sd 5:0:0:0: [sdb] 31266816 512-byte logical blocks: (16.0 GB/14.9 GiB) [3.012954] scsi 6:0:0:0: Direct-Access Seagate Backup+ BL 0409 PQ: 0 ANSI: 6 [3.014683] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks: (1.00 TB/931 GiB) [ 703.081242] systemd[1]: Timed out waiting for device ST1000LM024_HN-M101MBB. Your logs indicate problems with sdc. That needs to be disconnected, and comment out its fstab entry if there is one. And ideally don't have the SanDisk connecting during boot or reboot/poweroff, only on-demand when you need to save out a log file. Thanks. I tried the poweroff and it worked. I rebooted tried it again and it worked. I rebooted again and tried the So I think you either have a race condition that is mitigated by one or more of the debug boot parameters; or maybe more likely you've got an selinux issue that's alleviated by enforcing=0. For now, keep enforcing=0 as a boot parameter. and this time the system did not power off, it reset and now I'm back in rescue mode. Here's the link to the shutdown-log.txt file for this event. https://www.amazon.com/clouddrive/share?s=4LDATpk0T3IoK1jb-pKshY Yeah you forgot to include enforcing=0 in this boot, so I think you might have an SELinux issue, possibly the result of the interrupted labeling. *sigh* LOTS of problems with sdc that even the kernel doesn't like. Remove this device and troubleshoot that separately. [ 634.006871] EXT4-fs error (device sdc1): ext4_find_entry:1309: inode #2: comm sagan: reading directory lblock 0 [ 754.896528] EXT4-fs error (device sdc1): __ext4_get_inode_loc:3909: inode #2: block 1057: comm broctl: unable to read itable block [ 760.478899] quiet_error: 24 callbacks suppressed [ 760.478905] Buffer I/O error on device sdc1, logical block 121667584 [ 760.478907] lost page write due to I/O error on sdc1 [ 760.478910] JBD2: Error -5 detected when updating journal superblock for sdc1-8. [ 760.478937] Aborting journal on device sdc1-8. [ 760.478940] Buffer I/O error on device sdc1, logical block 121667584 [ 760.478941] lost page write due to I/O error on sdc1 [ 760.478943] JBD2: Error -5 detected when updating journal superblock for sdc1-8. [ 1053.600851] EXT4-fs error (device sdc1): ext4_journal_check_start:56: Detected aborted journal [ 1053.600858] EXT4-fs (sdc1): Remounting filesystem read-only [ 1365.490135] EXT4-fs error (device sdc1): ext4_put_super:791: Couldn't clean up the journal [ 1365.491999] [ cut here ] [ 1365.492897] WARNING: CPU: 2 PID: 3751 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0() [ 1365.493824] sysfs group 81cb05c0 not found for kobject 'target6:0:0' [ 1365.494823] Modules linked in: vfat fat usb_storage i915 i2c_algo_bit drm_kms_helper drm i2c_core video [ 1365.495802] CPU: 2 PID: 3751 Comm: umount Not tainted 3.13.5-103.fc19.x86_64 #1 [ 1365.496750] Hardware name: Dell Inc. Inspiron 7537/0F5R3Y, BIOS A05 10/31/2013 [ 1365.497700] 0009 8802089b9b70 81680604 8802089b9bb8 [ 1365.498649] 8802089b9ba8 8106d35d 81cb05c0 [ 1365.499599] 8800afd47c38 8802315ce188 8800afc7f100 8802089b9c08 [ 1365.500546] Call Trace: [ 1365.501510] [81680604] dump_stack+0x45/0x56 [ 1365.502432] [8106d35d] warn_slowpath_common+0x7d/0xa0 [ 1365.503352] [8106d3cc] warn_slowpath_fmt+0x4c/0x50 [ 1365.504236] [8123004e] ? sysfs_get_dirent_ns+0x4e/0x70 [ 1365.505101] [81231316] sysfs_remove_group+0xc6/0xd0 [ 1365.505920] [8141cb63] dpm_sysfs_remove+0x43/0x50 [ 1365.506730] [814128b5] device_del+0x45/0x1c0 [ 1365.507549] [8143cb77] scsi_target_reap_usercontext+0x27/0x40 [ 1365.508349] [81086147] execute_in_process_context+0x67/0x70 [ 1365.509177] [8143dff4] scsi_target_reap+0xc4/0xf0 [ 1365.509991] [8143ffc6] scsi_device_dev_release_usercontext+0xe6/0x120 [ 1365.510783] [81086147] execute_in_process_context+0x67/0x70 [ 1365.511592] [8143fedc] scsi_device_dev_release+0x1c/0x20 [ 1365.512458] [81411f02] device_release+0x32/0xa0 [ 1365.513320] [813156b7] kobject_cleanup+0x77/0x1b0 [ 1365.514154] [81315570] kobject_put+0x30/0x60 [ 1365.515035] [814121f7] put_device+0x17/0x20 [ 1365.515865] [814326db]
Re: can't boot F19 system
On Tue, Mar 18, 2014 at 3:01 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 18, 2014, at 12:53 PM, pgaltieri . pgalti...@gmail.com wrote: Please unplug everything from this laptop, except power. You need to get the basic setup working reliably first. No external hard drives. No mouse. Nothing, except power. You haven't done this like I asked. [0.860472] scsi 0:0:0:0: Direct-Access ATA WDC WD10JPVX-75J 01.0 PQ: 0 ANSI: 5 [0.861762] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [2.901151] scsi 5:0:0:0: Direct-Access SanDisk Cruzer 2.01 PQ: 0 ANSI: 6 [2.909355] sd 5:0:0:0: [sdb] 31266816 512-byte logical blocks: (16.0 GB/14.9 GiB) [3.012954] scsi 6:0:0:0: Direct-Access Seagate Backup+ BL 0409 PQ: 0 ANSI: 6 [3.014683] sd 6:0:0:0: [sdc] 1953525167 512-byte logical blocks: (1.00 TB/931 GiB) [ 703.081242] systemd[1]: Timed out waiting for device ST1000LM024_HN-M101MBB. Your logs indicate problems with sdc. That needs to be disconnected, and comment out its fstab entry if there is one. And ideally don't have the SanDisk connecting during boot or reboot/poweroff, only on-demand when you need to save out a log file. Thanks. I tried the poweroff and it worked. I rebooted tried it again and it worked. I rebooted again and tried the So I think you either have a race condition that is mitigated by one or more of the debug boot parameters; or maybe more likely you've got an selinux issue that's alleviated by enforcing=0. For now, keep enforcing=0 as a boot parameter. and this time the system did not power off, it reset and now I'm back in rescue mode. Here's the link to the shutdown-log.txt file for this event. https://www.amazon.com/clouddrive/share?s=4LDATpk0T3IoK1jb-pKshY Yeah you forgot to include enforcing=0 in this boot, so I think you might have an SELinux issue, possibly the result of the interrupted labeling. *sigh* LOTS of problems with sdc that even the kernel doesn't like. Remove this device and troubleshoot that separately. [ 634.006871] EXT4-fs error (device sdc1): ext4_find_entry:1309: inode #2: comm sagan: reading directory lblock 0 [ 754.896528] EXT4-fs error (device sdc1): __ext4_get_inode_loc:3909: inode #2: block 1057: comm broctl: unable to read itable block [ 760.478899] quiet_error: 24 callbacks suppressed [ 760.478905] Buffer I/O error on device sdc1, logical block 121667584 [ 760.478907] lost page write due to I/O error on sdc1 [ 760.478910] JBD2: Error -5 detected when updating journal superblock for sdc1-8. [ 760.478937] Aborting journal on device sdc1-8. [ 760.478940] Buffer I/O error on device sdc1, logical block 121667584 [ 760.478941] lost page write due to I/O error on sdc1 [ 760.478943] JBD2: Error -5 detected when updating journal superblock for sdc1-8. [ 1053.600851] EXT4-fs error (device sdc1): ext4_journal_check_start:56: Detected aborted journal [ 1053.600858] EXT4-fs (sdc1): Remounting filesystem read-only [ 1365.490135] EXT4-fs error (device sdc1): ext4_put_super:791: Couldn't clean up the journal [ 1365.491999] [ cut here ] [ 1365.492897] WARNING: CPU: 2 PID: 3751 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0() [ 1365.493824] sysfs group 81cb05c0 not found for kobject 'target6:0:0' [ 1365.494823] Modules linked in: vfat fat usb_storage i915 i2c_algo_bit drm_kms_helper drm i2c_core video [ 1365.495802] CPU: 2 PID: 3751 Comm: umount Not tainted 3.13.5-103.fc19.x86_64 #1 [ 1365.496750] Hardware name: Dell Inc. Inspiron 7537/0F5R3Y, BIOS A05 10/31/2013 [ 1365.497700] 0009 8802089b9b70 81680604 8802089b9bb8 [ 1365.498649] 8802089b9ba8 8106d35d 81cb05c0 [ 1365.499599] 8800afd47c38 8802315ce188 8800afc7f100 8802089b9c08 [ 1365.500546] Call Trace: [ 1365.501510] [81680604] dump_stack+0x45/0x56 [ 1365.502432] [8106d35d] warn_slowpath_common+0x7d/0xa0 [ 1365.503352] [8106d3cc] warn_slowpath_fmt+0x4c/0x50 [ 1365.504236] [8123004e] ? sysfs_get_dirent_ns+0x4e/0x70 [ 1365.505101] [81231316] sysfs_remove_group+0xc6/0xd0 [ 1365.505920] [8141cb63] dpm_sysfs_remove+0x43/0x50 [ 1365.506730] [814128b5] device_del+0x45/0x1c0 [ 1365.507549] [8143cb77] scsi_target_reap_usercontext+0x27/0x40 [ 1365.508349] [81086147] execute_in_process_context+0x67/0x70 [ 1365.509177] [8143dff4] scsi_target_reap+0xc4/0xf0 [ 1365.509991] [8143ffc6] scsi_device_dev_release_usercontext+0xe6/0x120 [ 1365.510783] [81086147] execute_in_process_context+0x67/0x70 [ 1365.511592] [8143fedc] scsi_device_dev_release+0x1c/0x20 [ 1365.512458] [81411f02] device_release+0x32/0xa0 [ 1365.513320] [813156b7] kobject_cleanup+0x77/0x1b0 [ 1365.514154] [81315570]
Re: can't boot F19 system
This didn't work. I still get the access denied error. The /boot/efi/EFI/fedora directory contains a file gcdx64.efi and grubx64.efi They are both the same size. The first is dated July 2 2013 the other is dated today. I tried renaming grubx64.efi to gcdx64.efi but it also failed. Paolo On Sun, Mar 16, 2014 at 10:47 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 16, 2014, at 11:19 PM, pgaltieri . pgalti...@gmail.com wrote: Well I tried to re-install grub per the link in a previous email. I booted from DVD, went into rescue mode and did the chroot. I ran /sbin/grub2-install /dev/sda and on rebooting I get: Secure Boot Image failed to verify with ACCESS DENIED Press any key to continue So now what? Anyway to recover from this? Well the autopsy is that the advice to re-install grub wasn't appropriate for UEFI computers, and actually makes the problem worse on UEFI computers with Secure Boot enabled. By using grub2-install, a custom grubx64.efi (core.img) was created and replaced the signed one making what was actually a booting system, not bootable. To replace the signed one, you need to boot the DVD with the rescue a system option found in the troubleshooting menu. Accept the default options in the menus. cp /run/install/repo/EFI/BOOT/grubx64.efi /mnt/sysimage/boot/efi/EFI/fedora/ chroot /mnt/sysimage grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg exit reboot See the other email I posted for what information you need to supply to fix your original problem. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 10:47 AM, pgaltieri . pgalti...@gmail.com wrote: This didn't work. I still get the access denied error. The /boot/efi/EFI/fedora directory contains a file gcdx64.efi and grubx64.efi They are both the same size. The first is dated July 2 2013 the other is dated today. I tried renaming grubx64.efi to gcdx64.efi but it also failed. I think I understand what's going on. The grub2-install command added a new NVRAM entry pointing to grubx64.efi. While you now have the correctly signed grubx64.efi file, the NVRAM entry pointing to it is incorrect, because grubx64.efi is signed with the Fedora key which isn't present in your firmware (normal). The NVRAM entry should either be deleted, or replaced to point to shim.efi which is signed with a Microsoft key, which is in your firmware. Either way then shim.efi will properly execute grubx64.efi. From the rescue environment (not chrooted), what do you get for efibootmgr -v cat /mnt/sysimage/var/log/anaconda/anaconda.program.log | grep efibootmgr Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
Here's the output
BootCurrent: 0015
Timeout: 0 seconds
BootOrder:
,0001,0016,0013,0014,0015,0012,0010,0011,0019,001A,001B,0017,0018
Boot* fedora
HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\fedora\grubx64.efi)
Boot0001* Windows Boot Manager
HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...5....
Boot0010 Setup
Boot0011 Boot Menu
Boot0012* Removable Drive
030a2400d23878bc820f604d8316c068ee79d25b20699b27e1a34f488e97534d40523c1d
Boot0013* Hard Drive
030a2400d23878bc820f604d8316c068ee79d25bf5b01cc8ce8e9841b3a8fb94b6dfefee
Boot0014* USB Storage Device
030a2400d23878bc820f604d8316c068ee79d25b6895f49a99882e4bb0da03ec784d2828
Boot0015* CD/DVD/CD-RW Drive
030a2400d23878bc820f604d8316c068ee79d25b3750dce1249e1748876bee5d3f25ebfb
Boot0016* Network
030a2400d23878bc820f604d8316c068ee79d25b6567de8ee595634d842b325e6a43510b
Boot0017* Onboard NIC
030a2400d23878bc820f604d8316c068ee79d25b1b7f7356e3475744a9a6ed8e91832083
Boot0018* Onboard NIC
030a2400d23878bc820f604d8316c068ee79d25bb4a054dda1fa7043abf832c5a88367a6
Boot0019 Diagnostics
Boot001A Peripheral Device setting (OPROM setting)
Boot001B Change boot mode setting
On Mon, Mar 17, 2014 at 12:11 PM, Chris Murphy li...@colorremedies.comwrote:
On Mar 17, 2014, at 10:47 AM, pgaltieri . pgalti...@gmail.com wrote:
This didn't work. I still get the access denied error. The
/boot/efi/EFI/fedora directory contains a file
gcdx64.efi
and
grubx64.efi
They are both the same size. The first is dated July 2 2013 the other
is dated today. I tried renaming grubx64.efi to gcdx64.efi but it also
failed.
I think I understand what's going on. The grub2-install command added a
new NVRAM entry pointing to grubx64.efi. While you now have the correctly
signed grubx64.efi file, the NVRAM entry pointing to it is incorrect,
because grubx64.efi is signed with the Fedora key which isn't present in
your firmware (normal). The NVRAM entry should either be deleted, or
replaced to point to shim.efi which is signed with a Microsoft key, which
is in your firmware. Either way then shim.efi will properly execute
grubx64.efi.
From the rescue environment (not chrooted), what do you get for
efibootmgr -v
cat /mnt/sysimage/var/log/anaconda/anaconda.program.log | grep efibootmgr
Chris Murphy
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 1:37 PM, pgaltieri . pgalti...@gmail.com wrote: Here's the output BootCurrent: 0015 Timeout: 0 seconds BootOrder: ,0001,0016,0013,0014,0015,0012,0010,0011,0019,001A,001B,0017,0018 Boot* fedora HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\fedora\grubx64.efi) OK so that's the wrong entry, we'll need to remove it. Missing the 2nd requested command. Please bottom post if possible. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mon, Mar 17, 2014 at 12:56 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 17, 2014, at 1:37 PM, pgaltieri . pgalti...@gmail.com wrote: Here's the output BootCurrent: 0015 Timeout: 0 seconds BootOrder: ,0001,0016,0013,0014,0015,0012,0010,0011,0019,001A,001B,0017,0018 Boot* fedora HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\fedora\grubx64.efi) OK so that's the wrong entry, we'll need to remove it. Missing the 2nd requested command. Please bottom post if possible. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org Chris, sorry about the second command. Here's the output: 17:43:20,191 INFO program: Running... efibootmgr 17:43:20,519 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi Paolo -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 2:13 PM, pgaltieri . pgalti...@gmail.com wrote: On Mon, Mar 17, 2014 at 12:56 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 1:37 PM, pgaltieri . pgalti...@gmail.com wrote: Here's the output BootCurrent: 0015 Timeout: 0 seconds BootOrder: ,0001,0016,0013,0014,0015,0012,0010,0011,0019,001A,001B,0017,0018 Boot* fedora HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\fedora\grubx64.efi) Chris, sorry about the second command. Here's the output: 17:43:20,191 INFO program: Running... efibootmgr 17:43:20,519 INFO program: Running… efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi OK try this from the rescue DVD, chroot /mnt/sysimage efibootmgr -b -B efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi exit reboot That should first delete the bogus entry, and then add the prior one that points to shim.efi, and then you should be able to boot. And then get on with the real problem which is being dropped at emergency.target. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mon, Mar 17, 2014 at 2:02 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 17, 2014, at 2:13 PM, pgaltieri . pgalti...@gmail.com wrote: On Mon, Mar 17, 2014 at 12:56 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 1:37 PM, pgaltieri . pgalti...@gmail.com wrote: Here's the output BootCurrent: 0015 Timeout: 0 seconds BootOrder: ,0001,0016,0013,0014,0015,0012,0010,0011,0019,001A,001B,0017,0018 Boot* fedora HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\fedora\grubx64.efi) Chris, sorry about the second command. Here's the output: 17:43:20,191 INFO program: Running... efibootmgr 17:43:20,519 INFO program: Running… efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi OK try this from the rescue DVD, chroot /mnt/sysimage efibootmgr -b -B efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi exit reboot That should first delete the bogus entry, and then add the prior one that points to shim.efi, and then you should be able to boot. And then get on with the real problem which is being dropped at emergency.target. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org Chris, that worked. Thank you very much. Now I can go back to your previous email and see if I can get it to boot to multi user. Thanks, Paolo -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mon, Mar 17, 2014 at 2:17 PM, pgaltieri . pgalti...@gmail.com wrote: On Mon, Mar 17, 2014 at 2:02 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 17, 2014, at 2:13 PM, pgaltieri . pgalti...@gmail.com wrote: On Mon, Mar 17, 2014 at 12:56 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 1:37 PM, pgaltieri . pgalti...@gmail.com wrote: Here's the output BootCurrent: 0015 Timeout: 0 seconds BootOrder: ,0001,0016,0013,0014,0015,0012,0010,0011,0019,001A,001B,0017,0018 Boot* fedora HD(1,800,fa000,a37591b8-de99-44c3-9eb8-e7de6f28d62d)File(\EFI\fedora\grubx64.efi) Chris, sorry about the second command. Here's the output: 17:43:20,191 INFO program: Running... efibootmgr 17:43:20,519 INFO program: Running… efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi OK try this from the rescue DVD, chroot /mnt/sysimage efibootmgr -b -B efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi exit reboot That should first delete the bogus entry, and then add the prior one that points to shim.efi, and then you should be able to boot. And then get on with the real problem which is being dropped at emergency.target. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org Chris, that worked. Thank you very much. Now I can go back to your previous email and see if I can get it to boot to multi user. Thanks, Paolo Chris, here is the output for journal -b https://www.amazon.com/clouddrive/share?s=yuVEpW13SV0n_TIJKaokLs Paolo -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
Chris, here is the output for journal -b https://www.amazon.com/clouddrive/share?s=yuVEpW13SV0n_TIJKaokLs Mar 17 14:14:57 peglaptopnew systemd[1]: Mounting /boot/efi... Mar 17 14:14:57 peglaptopnew mount[460]: mount: unknown filesystem type 'vfat' Mar 17 14:14:57 peglaptopnew systemd[1]: boot-efi.mount mount process exited, code=exited status=32 Mar 17 14:14:57 peglaptopnew systemd[1]: Failed to mount /boot/efi. This is weird. Unknown file system type vfat? That kernel module should be available by this point in the boot process. I'm going to guess that at the emergency.target shell prompt you can type exit and it will continue to boot to graphical.target. The boot failure is just an attempt to get your attention that a locally required volume isn't mounting. I'm rather opposed to the idea of persistently mounted /boot/efi, but that's currently what we do and it should work. What do you get for: mount /boot/efi lsmod | grep vfat cat /etc/fstab blkid Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mon, Mar 17, 2014 at 4:31 PM, Chris Murphy li...@colorremedies.comwrote: Chris, here is the output for journal -b https://www.amazon.com/clouddrive/share?s=yuVEpW13SV0n_TIJKaokLs Mar 17 14:14:57 peglaptopnew systemd[1]: Mounting /boot/efi... Mar 17 14:14:57 peglaptopnew mount[460]: mount: unknown filesystem type 'vfat' Mar 17 14:14:57 peglaptopnew systemd[1]: boot-efi.mount mount process exited, code=exited status=32 Mar 17 14:14:57 peglaptopnew systemd[1]: Failed to mount /boot/efi. This is weird. Unknown file system type vfat? That kernel module should be available by this point in the boot process. I'm going to guess that at the emergency.target shell prompt you can type exit and it will continue to boot to graphical.target. The boot failure is just an attempt to get your attention that a locally required volume isn't mounting. I'm rather opposed to the idea of persistently mounted /boot/efi, but that's currently what we do and it should work. What do you get for: mount /boot/efi lsmod | grep vfat cat /etc/fstab blkid Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org Chris, here's the info you requested. mount /boot/efi mount: unknown filesystem type 'vfat' lsmod | grep vfat returns nothing, no vfat module present. cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Dec 8 17:19:59 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/fedora-root / ext4defaults1 1 UUID=1fac12c9-bd58-4f5f-9ae3-7b9bb55cfd85 /boot ext4 defaults1 2 UUID=A005-B31B /boot/efi vfat umask=0077,shortname=winnt 0 0 /dev/mapper/fedora-home /home ext4defaults1 2 /dev/mapper/fedora-swap swapswapdefaults0 0 LABEL=NEWDATA2/media/NEWDATA2ext4 defaults,nodev,noexec,nosuid,async,noatime1 2 blkid /dev/sda1: LABEL=ESP UUID=A005-B31B TYPE=vfat PARTLABEL=EFI System Partition PARTUUID=a37591b8-de99-44c3-9eb8-e7de6f28d62d /dev/sda2: LABEL=DIAGS UUID=9E58-3CE0 TYPE=vfat PARTLABEL=Basic data partition PARTUUID=90f009cd-547f-4829-bd4c-014ef1c2b4f0 /dev/sda3: UUID=1fac12c9-bd58-4f5f-9ae3-7b9bb55cfd85 TYPE=ext4 PARTUUID=9e47e650-33ca-4514-9185-f12a4d9fe3b2 /dev/sda4: LABEL=WINRETOOLS UUID=4CFE599AFE597D60 TYPE=ntfs PARTLABEL=Basic data partition PARTUUID=5aafa934-c73a-417d-b9b3-fa51a506c936 /dev/sda5: LABEL=PEGLTOPWIN8 UUID=4A7CD0AC7CD093D3 TYPE=ntfs PARTLABEL=Basic data partition PARTUUID=41a07db4-1103-4ffb-969a-67ea87aa477f /dev/sda6: UUID=E69CF1879CF15293 TYPE=ntfs PARTUUID=cc82e82f-56da-40c7-b6b4-9d79e0709e99 /dev/sda7: UUID=8066EE7366EE697C TYPE=ntfs PARTUUID=3d8e9278-4fb3-4ca8-a57d-15f329642338 /dev/sda8: LABEL=PBR Image UUID=8E764C71764C5BD9 TYPE=ntfs PARTLABEL=Microsoft recovery partition PARTUUID=f5a7ccda-2b8a-45d9-bf2d-a60149646835 /dev/sda9: UUID=UXaRXx-XoYJ-KiZC-4Q3B-A1VR-BxUD-HmgG5q TYPE=LVM2_member PARTUUID=f29aa601-9fa5-4f02-98f9-ec85da1df97d /dev/sr0: UUID=2013-06-27-14-02-10-00 LABEL=Fedora 19 x86_64 TYPE=iso9660 PTTYPE=dos /dev/mapper/fedora-swap: UUID=f38c5443-bd86-41a5-b32c-3d572bac25de TYPE=swap /dev/mapper/fedora-root: UUID=f19bf96d-13b6-44ca-95d6-4491e8c75a16 TYPE=ext4 /dev/mapper/fedora-home: UUID=e2dd9fa7-c6a6-47dc-92d4-da5e8395639e TYPE=ext4 /dev/sdb1: LABEL=NEWDATA2 UUID=72c38495-62e8-49ce-bc94-7bd4447c39fa TYPE=ext4 Note that NEWDATA2 is an external USB drive I've been using to copy files between the non working system and another Fedora 19 system where I'm reading my email. It's formatted as ext4 and so gets mounted. I tried a USB stick, but it wont mount since it too is formatted as vfat. No matter what I do the system never boots past emergency mode. It never gets to graphical mode. If I look at /usr/lib/modules on the non working system I get: 3.12.11-201.fc19.x86_64/ 3.12.9-201.fc19.x86_64/ 3.13.5-101.fc19.x86_64/ 3.13.5-103.fc19.x86_64/ uname -a shows Linux peglaptopnew 3.13.5-103.fc19.x86_64 #1 SMP Mon Mar 3 18:46:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux and both vfat.ko and fat.ko are present in 3.13.5-103.fc19.x86_64/kernel/fs/fat If I run insmod /usr/lib/modules/3.13.5-103.fc19.x86_64/kernel/fs/fat/fat.ko insmod /usr/lib/modules/3.13.5-103.fc19.x86_64/kernel/fs/fat/vfat.ko Then do lsmod | grep vfat it now shows both fat and vfat modules loaded I then did an exit from emergency mode, but it again dropped into emergency mode lsmod shows: Module Size Used by vfat 17411 1 fat60923 1 vfat
Re: can't boot F19 system
On Mar 17, 2014, at 6:12 PM, pgaltieri . pgalti...@gmail.com wrote: If I look at /usr/lib/modules on the non working system I get: 3.12.11-201.fc19.x86_64/ 3.12.9-201.fc19.x86_64/ 3.13.5-101.fc19.x86_64/ 3.13.5-103.fc19.x86_64/ uname -a shows Linux peglaptopnew 3.13.5-103.fc19.x86_64 #1 SMP Mon Mar 3 18:46:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux and both vfat.ko and fat.ko are present in 3.13.5-103.fc19.x86_64/kernel/fs/fat If I run insmod /usr/lib/modules/3.13.5-103.fc19.x86_64/kernel/fs/fat/fat.ko insmod /usr/lib/modules/3.13.5-103.fc19.x86_64/kernel/fs/fat/vfat.ko Then do lsmod | grep vfat it now shows both fat and vfat modules loaded I then did an exit from emergency mode, but it again dropped into emergency mode So after insmod, see if mount /boot/efi works. And if it does then exit. And then, figure out why vfat.ko isn't loading. That I don't understand. I don't think it needs to be in the initramfs. But maybe once /boot/efi is mounted, it's worth doing dracut -f to rebuild the initramfs, and then reboot. If that doesn't fix it, I'm curious whether the grub menu kernel options work. I'd try them in reverse order. I have had this problem once before, it was the identical error but in my case was only with the rescue kernel option which is actually a rescue initramfs. The problem was that vfat.ko isn't built into the non-host initramfs and the rescue kernel /lib/modules directory had since been deleted so there wasn't a vfat.ko available. Sorta makes the rescue option not much of a rescue but whatever - your situation is the opposite, you have vfat.ko it's just not loading for some reason. What about cat /etc/modprobe.d/blacklist.conf Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 7:57 PM, Chris Murphy li...@colorremedies.com wrote: But maybe once /boot/efi is mounted, it's worth doing dracut -f to rebuild the initramfs, and then reboot. It's not worth it. I just used lsinitrd on my working system and neither fat.ko or vfat.ko are in the initramfs. So somehow on your system either vfat.ko or fat.ko (or both) are being blacklisted. If that doesn't fix it, I'm curious whether the grub menu kernel options work. I'd try them in reverse order. Still interested with which kernel this does work. What about cat /etc/modprobe.d/blacklist.conf Better is grep -i fat /usr/lib/modprobe.d/* Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 8:15 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 7:57 PM, Chris Murphy li...@colorremedies.com wrote: But maybe once /boot/efi is mounted, it's worth doing dracut -f to rebuild the initramfs, and then reboot. It's not worth it. I just used lsinitrd on my working system and neither fat.ko or vfat.ko are in the initramfs. So somehow on your system either vfat.ko or fat.ko (or both) are being blacklisted. If that doesn't fix it, I'm curious whether the grub menu kernel options work. I'd try them in reverse order. Still interested with which kernel this does work. What about cat /etc/modprobe.d/blacklist.conf Better is grep -i fat /usr/lib/modprobe.d/* And while you're at it also fpaste the grub.cfg. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 8:24 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 8:15 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 7:57 PM, Chris Murphy li...@colorremedies.com wrote: But maybe once /boot/efi is mounted, it's worth doing dracut -f to rebuild the initramfs, and then reboot. It's not worth it. I just used lsinitrd on my working system and neither fat.ko or vfat.ko are in the initramfs. So somehow on your system either vfat.ko or fat.ko (or both) are being blacklisted. If that doesn't fix it, I'm curious whether the grub menu kernel options work. I'd try them in reverse order. Still interested with which kernel this does work. What about cat /etc/modprobe.d/blacklist.conf Better is grep -i fat /usr/lib/modprobe.d/* And while you're at it also fpaste the grub.cfg. And while you're at it, reboot with the busted kernel option, and at the emergency shell: modprobe vfat ## note any messages for that command and then also dmesg ## note the last entries that seem relevant Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mon, Mar 17, 2014 at 7:28 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 17, 2014, at 8:24 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 8:15 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 17, 2014, at 7:57 PM, Chris Murphy li...@colorremedies.com wrote: But maybe once /boot/efi is mounted, it's worth doing dracut -f to rebuild the initramfs, and then reboot. It's not worth it. I just used lsinitrd on my working system and neither fat.ko or vfat.ko are in the initramfs. So somehow on your system either vfat.ko or fat.ko (or both) are being blacklisted. If that doesn't fix it, I'm curious whether the grub menu kernel options work. I'd try them in reverse order. Still interested with which kernel this does work. What about cat /etc/modprobe.d/blacklist.conf Better is grep -i fat /usr/lib/modprobe.d/* And while you're at it also fpaste the grub.cfg. And while you're at it, reboot with the busted kernel option, and at the emergency shell: modprobe vfat ## note any messages for that command and then also dmesg ## note the last entries that seem relevant Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org modprobe vfat returns with no messages at all. The vfat module is not loaded. There is no file /etc/modprobe.d/blacklist.conf Here's a link to dmesg output https://www.amazon.com/clouddrive/share?s=xbSlzWw9RXoqK8H9HAVgIw Here's a link to grub.cfg https://www.amazon.com/clouddrive/share?s=M-h6hV1bQcEinfQSrTkMsc The kernel that is causing my issues is the same kernel I've been running for a while, 3.13.5-103.fc19.x86_64. Here's the steps that lead to my current problem: 1) log out and run shutdown from button on top right of login screen (I'm running mate desktop) 2) System indicates it's powering off, however, system does not turn off it restarts and boots back to login screen 3) Try shutdown again - same result 4) Get frustrated :-) 5) Hit power button to turn off system. 6) Power system on, goes to emergency mode. And no matter what I do it never gets passed emergency mode. What I find interesting is that both the root and home filesystems are mounted. So I was able to back up stuff. I am running LVM, I don't know if this is part of the problem. I tried booting off an older kernel 3.12.11-201.fc19.x86_64 and it also put me in emergency mode, but when I did an lsmod the vfat module was loaded and there where a total of 69 modules loaded. If I exit from the emegency mode prompt the process starts all over, the circle fills up, turns into the Fedora f, pauses for a while and then puts me back info emergency mode. Paolo -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 17, 2014, at 9:53 PM, pgaltieri . pgalti...@gmail.com wrote: modprobe vfat returns with no messages at all. The vfat module is not loaded. Seems important to find out why the kernel isn't loading fat.ko+vfat.ko. Emergency shell you can run: fsck.msdos -a /dev/sda1 See where that gets you, and report back. There is no automatic FAT fsck at startup, which maybe is a bug since we're always mounting /boot/efi read-write. I'd like to see the result of a boot with boot parameters rhgb quiet removed, and systemd.log_level=debug added. And then use this: journalctl -xb -o short-monotonic /mnt/usb/journal-debug.txt And post that somewhere. I'd like to see the full debug info from systemd. Maybe it's trying to mount /boot/efi before /sysroot? Hard to imagine that. Here's a link to grub.cfg https://www.amazon.com/clouddrive/share?s=M-h6hV1bQcEinfQSrTkMsc That's normal. 2) System indicates it's powering off, however, system does not turn off it restarts and boots back to login screen What happens if you logout your user, change to a shell, login as root, and issue: poweroff If that consistently works, and doing it with Mate's UI does not, then file a bug against Mate. If poweroff doesn't work either… 3) Try shutdown again - same result 4) Get frustrated :-) 5) Hit power button to turn off system. OK stop doing that. echo 1 /proc/sys/kernel/sysrq echo r /proc/sysrq-trigger echo e /proc/sysrq-trigger echo i /proc/sysrq-trigger echo s /proc/sysrq-trigger echo u /proc/sysrq-trigger echo o /proc/sysrq-trigger If that reboots instead of powers off, then it's probably a kernel bug and you should file a bug against the kernel. I'd check to make sure your UEFI firmware is up to date first. If it does power off, but the poweroff command does not, then your problem might be a systemd bug. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mon, Mar 17, 2014 at 9:37 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 17, 2014, at 9:53 PM, pgaltieri . pgalti...@gmail.com wrote: modprobe vfat returns with no messages at all. The vfat module is not loaded. Seems important to find out why the kernel isn't loading fat.ko+vfat.ko. Emergency shell you can run: fsck.msdos -a /dev/sda1 See where that gets you, and report back. There is no automatic FAT fsck at startup, which maybe is a bug since we're always mounting /boot/efi read-write. complained about dirty bit being set and that backup version didn't match current version. I'd like to see the result of a boot with boot parameters rhgb quiet removed, and systemd.log_level=debug added. And then use this: journalctl -xb -o short-monotonic /mnt/usb/journal-debug.txt Here's the link https://www.amazon.com/clouddrive/share?s=femLQ67TRQkjI3mhQQKx1c It did not mount my external USB hard drive, but after loading the vfat module it did mount my USB stick. And post that somewhere. I'd like to see the full debug info from systemd. Maybe it's trying to mount /boot/efi before /sysroot? Hard to imagine that. Here's a link to grub.cfg https://www.amazon.com/clouddrive/share?s=M-h6hV1bQcEinfQSrTkMsc That's normal. 2) System indicates it's powering off, however, system does not turn off it restarts and boots back to login screen What happens if you logout your user, change to a shell, login as root, and issue: poweroff ran poweroff at emergency mode prompt and system reset, did not power off. If that consistently works, and doing it with Mate's UI does not, then file a bug against Mate. If poweroff doesn't work either… 3) Try shutdown again - same result 4) Get frustrated :-) 5) Hit power button to turn off system. OK stop doing that. echo 1 /proc/sys/kernel/sysrq echo r /proc/sysrq-trigger echo e /proc/sysrq-trigger echo i /proc/sysrq-trigger Got to this point and system reset. echo s /proc/sysrq-trigger echo u /proc/sysrq-trigger echo o /proc/sysrq-trigger If that reboots instead of powers off, then it's probably a kernel bug and you should file a bug against the kernel. I'd check to make sure your UEFI firmware is up to date first. If it does power off, but the poweroff command does not, then your problem might be a systemd bug. With debug turned on I keep seeing messages like the following USB disconnect, device number 15 new low-speed USB device number 16 using xhci_hcd The number 15 and 16 keep incrementing about 5 seconds apart. This device is my USB optical mouse Paolo Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On 03/16/2014 02:05 PM, pgaltieri . wrote: Today I needed to power off one of my F19 systems. So I logged out and selected shutdown from the top right button. Instead of powering off as I expected, and was told it was going to do from the message that appeared on the screen, much to my amazement it didn't. Instead it restarted and went back to the login screen. This happened again when I tried it. So in desperation I hit the power switch. Well now the system wont boot. Instead it always goes to emergency mode. I booted off a F19 DVD, went into troubleshooting and ran fsck on all the file systems. They all came back clean - no errors, and yet I can't get it to boot. I have hit the power switch to power off a system in the past because it was so hung up I couldn't do anything else. Every time the system has recovered, but not this time. Anybody know what I need to do to get back to a working system? This particular system is a Dell Inspiron 15 laptop. Any assistance is appreciated. maybe try to reinstall grub?? https://ask.fedoraproject.org/en/question/31318/recovering-fedora-19-boot-reinstalling-grub/ or http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-rescuemode-boot.html or maybe mkconfig: https://ask.fedoraproject.org/en/question/9997/updating-grub/ -- Paul Cartwright Registered Linux User #367800 and new counter #561587 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 16, 2014, at 12:05 PM, pgaltieri . pgalti...@gmail.com wrote: Today I needed to power off one of my F19 systems. So I logged out and selected shutdown from the top right button. Instead of powering off as I expected, and was told it was going to do from the message that appeared on the screen, much to my amazement it didn't. Instead it restarted and went back to the login screen. This happened again when I tried it. So in desperation I hit the power switch. http://www.jovicailic.org/2013/05/linux-gets-frozen-what-do-you-do/ Well now the system wont boot. Instead it always goes to emergency mode. GRUB menu entry, edit the kernel boot param to delete rghb and quiet. Add systemd.log_level=debug systemd.log_target=console F10 to boot with those temporary changes. Then either: a. mount a USB stick and use journalctl -b /mnt/usb/journal.txt and then post that txt file somewhere. b. Take a cell phone photo of the screen and post it somewhere. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
Well I tried to re-install grub per the link in a previous email. I booted from DVD, went into rescue mode and did the chroot. I ran /sbin/grub2-install /dev/sda and on rebooting I get: Secure Boot Image failed to verify with ACCESS DENIED Press any key to continue So now what? Anyway to recover from this? Paolo On Sun, Mar 16, 2014 at 6:18 PM, pgaltieri . pgalti...@gmail.com wrote: The file is only 100K bytes, it's probably easier to attach the file to this email than try to figure out where to put it so people can get it. Paolo On Sun, Mar 16, 2014 at 5:09 PM, Chris Murphy li...@colorremedies.comwrote: On Mar 16, 2014, at 12:05 PM, pgaltieri . pgalti...@gmail.com wrote: Today I needed to power off one of my F19 systems. So I logged out and selected shutdown from the top right button. Instead of powering off as I expected, and was told it was going to do from the message that appeared on the screen, much to my amazement it didn't. Instead it restarted and went back to the login screen. This happened again when I tried it. So in desperation I hit the power switch. http://www.jovicailic.org/2013/05/linux-gets-frozen-what-do-you-do/ Well now the system wont boot. Instead it always goes to emergency mode. GRUB menu entry, edit the kernel boot param to delete rghb and quiet. Add systemd.log_level=debug systemd.log_target=console F10 to boot with those temporary changes. Then either: a. mount a USB stick and use journalctl -b /mnt/usb/journal.txt and then post that txt file somewhere. b. Take a cell phone photo of the screen and post it somewhere. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: can't boot F19 system
On Mar 16, 2014, at 11:19 PM, pgaltieri . pgalti...@gmail.com wrote: Well I tried to re-install grub per the link in a previous email. I booted from DVD, went into rescue mode and did the chroot. I ran /sbin/grub2-install /dev/sda and on rebooting I get: Secure Boot Image failed to verify with ACCESS DENIED Press any key to continue So now what? Anyway to recover from this? Well the autopsy is that the advice to re-install grub wasn't appropriate for UEFI computers, and actually makes the problem worse on UEFI computers with Secure Boot enabled. By using grub2-install, a custom grubx64.efi (core.img) was created and replaced the signed one making what was actually a booting system, not bootable. To replace the signed one, you need to boot the DVD with the rescue a system option found in the troubleshooting menu. Accept the default options in the menus. cp /run/install/repo/EFI/BOOT/grubx64.efi /mnt/sysimage/boot/efi/EFI/fedora/ chroot /mnt/sysimage grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg exit reboot See the other email I posted for what information you need to supply to fix your original problem. Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
