On Thu, 29 Jun 2017 03:33:05 -0000 "William Mattison" <mattison.computer@xxxxxxxxx> wrote: > Good evening, > > I believe Stan is correct. I built this system 4+ years ago. At > that time, it was my understanding that to get a windows-7 and Fedora > dual-boot system, I had to install windows-7 first. I think that at > that time, windows-7 did not support UEFI. Though I did not > explicitly make it so, the windows-7 install made this a non-UEFI > (old BIOS?) system. My sense is that that in turn forced the Fedora > install to use the old BIOS. I don't recall having any choice in > that. My sense is that for me to now try to convert this home system > to UEFI would mean a total re-install of both Fedora and windows-7. > (Am I correct?) Remembering how much trouble I had with this 4+ > years ago, and being a home user, not a sys-admin, I fear such a > conversion would take days, and wouldn't really gain me anything. I agree. I don't know the procedure to switch over, though EFI requires a larger reserved area at the start of the hard drive, so you would at least have to change the layout of your drive. I think that EFI is more secure if you are using a mobile device, but for a home user of a desktop it probably provides little benefit. > Questions: When doing my windows patches and scans today, windows > automatically downloaded and installed a new device driver for the > new hard drive. Do I need to do that in Fedora? Did Fedora > automatically do that already? How do I check? I think Tim has the right of it in his answer. Every time you update your kernel in Fedora, you update your drivers with any changes that have been made to them. It's possible that the vendor has proprietary enhancements in the windows driver specific to the drive. Those might or might not be in the linux driver, depending on whether they have been reverse engineered. They won't affect standard SATA functionality, they will probably be for windows specific reporting for performance statistics via vendor supplied windows software. > I saw no indication of vmlinuz crashes in the "journalctl -b" > output. I also haven't seen any more vmlinuz crash messages. I'll > keep watching. I'll be doing the weekly "dnf upgrade" tomorrow; > maybe that will fix any problems that do exist. > > What log file shows me all attempts to sign in to this system > regardless whether they're local or remote, and regardless whether > they were successful or not? And where is that log file? Do a journalctl -r and then search for the phrase LOGIN ON /LOGIN ON The journal files are all under /var/log/journal, but they are not human readable. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx