[opensuse] total system failure update
I was finally able to log into emergency mode today, keyboard could not type in password last night. I ran journalctl and discovered that the kernel is not able to mount any partitions. This is happening on the Samsung 850 EVO (system drive) and the HGST 4T (shared storage drive). On the system drive /home and swap mounts are failing, /home uses the XFS filesystem. On the shared storage drive the NTFS filesystem is used. I ran the manufacturers diagnostic tools from Windows and both drives are reporting no errors. Windows is able to mount the shared storage drive and I have full access to my files on this drive. Any idea what is going on and how to fix it? This system went from working great to total failure from one use to the next. Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 21, 2017 4:55:39 AM PDT, Dave Smith <bushwacker551@gmail.com> wrote:
I was finally able to log into emergency mode today, keyboard could not type in password last night. I ran journalctl and discovered that the kernel is not able to mount any partitions. This is happening on the Samsung 850 EVO (system drive) and the HGST 4T (shared storage drive). On the system drive /home and swap mounts are failing, /home uses the XFS filesystem. On the shared storage drive the NTFS filesystem is used.
I ran the manufacturers diagnostic tools from Windows and both drives are reporting no errors. Windows is able to mount the shared storage drive and I have full access to my files on this drive.
Any idea what is going on and how to fix it? This system went from working great to total failure from one use to the next.
Dave
Do you normally run fstrim on the Linux SSD? How long has it been since that was done? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I do not manually run fstrim. How can I tell if it has been run recently? I am really stumped on this one. I just booted into 4.4.57-18.3 recovery. I wanted to get more info from journalctl. The system fully booted and I am typing this email from Leap 42.2. I did nothing except multiple boot attempts. No idea why it wouldn't boot and now why it will. I would like to figure it out to make sure it does not happen again. On Fri, Apr 21, 2017 at 10:48 AM, John Andersen <jsamyth@gmail.com> wrote:
On April 21, 2017 4:55:39 AM PDT, Dave Smith <bushwacker551@gmail.com> wrote:
I was finally able to log into emergency mode today, keyboard could not type in password last night. I ran journalctl and discovered that the kernel is not able to mount any partitions. This is happening on the Samsung 850 EVO (system drive) and the HGST 4T (shared storage drive). On the system drive /home and swap mounts are failing, /home uses the XFS filesystem. On the shared storage drive the NTFS filesystem is used.
I ran the manufacturers diagnostic tools from Windows and both drives are reporting no errors. Windows is able to mount the shared storage drive and I have full access to my files on this drive.
Any idea what is going on and how to fix it? This system went from working great to total failure from one use to the next.
Dave
Do you normally run fstrim on the Linux SSD? How long has it been since that was done?
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2017 10:20 AM, Dave Smith wrote:
I do not manually run fstrim. How can I tell if it has been run recently? I am really stumped on this one. I just booted into 4.4.57-18.3 recovery. I wanted to get more info from journalctl. The system fully booted and I am typing this email from Leap 42.2. I did nothing except multiple boot attempts. No idea why it wouldn't boot and now why it will. I would like to figure it out to make sure it does not happen again.
man fstrim Run it once manually, no arguments are needed. Then make sure you enable it so it will run on a schedule, which defaults to weekly. systemctl enable fstrim.timer You should remove any -o discard you find in /etc/fstab as this option is recommended against, but I think leap puts it in there by default. Also recommend is -o noatime for ssd drives. Your symptoms suggest either a failing ssd, or more likely one badly in need of a trim operation. Especially after a massive sustem upgrade you would expect to find many pending trims that need to be done, but haven't. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2017 02:55 PM, Carlos E. R. wrote:
On 2017-04-21 19:32, John Andersen wrote:
Also recommend is -o noatime for ssd drives.
Change that to "lazytime" instead, on any type of disk.
Nope. Noatime it is. There is NOTHING that relies on atime anymore in consumer machines. There is simply no reason to maintain it at all. And there are good reasons to turn it off on regular hard drives as well as SSDs. -- After all is said and done, more is said than done.
On 2017-04-22 00:38, John Andersen wrote:
On 04/21/2017 02:55 PM, Carlos E. R. wrote:
On 2017-04-21 19:32, John Andersen wrote:
Also recommend is -o noatime for ssd drives.
Change that to "lazytime" instead, on any type of disk.
Nope. Noatime it is. There is NOTHING that relies on atime anymore in consumer machines. There is simply no reason to maintain it at all. And there are good reasons to turn it off on regular hard drives as well as SSDs.
lazytime is a new option that is reccomended from upstream to use instead. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Dave Smith composed on 2017-04-21 13:20 (UTC-0400):
I am really stumped on this one. I just booted into 4.4.57-18.3 recovery. I wanted to get more info from journalctl. The system fully booted and I am typing this email from Leap 42.2. I did nothing except multiple boot attempts. No idea why it wouldn't boot and now why it will. I would like to figure it out to make sure it does not happen again.
Were any of the boots since right before the first failed boot boots into Windows? If yes, were any of the exits from Windows shutdowns rather than reboots? I don't ever shut Win10 down. I exit Win10 always by rebooting, so that the hocus-pocus it plays when supposedly shutting down won't bollix up booting Linux. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2017 10:40 AM, Felix Miata wrote:
I don't ever shut Win10 down. I exit Win10 always by rebooting, so that the hocus-pocus it plays when supposedly shutting down won't bollix up booting
Red herring. Since it already rebooted in linux, you can assume the grub stuff is still ok. Its possible that what Wols mentioned is the problem, and in this case shutting down windows IS the preferred method because Daves shares at least one mounted NTFS files-ystem. (Although usually this just results in it being Read-Only on the linux side.) -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
The machine can use only one os at a time so anytime I am in Linux, which most of the time Windows is not running. This started when I was in Linux and I had not been in Windows for a couple of weeks. It started out with an extreme lag opening, using, or closing apps. Even changing desktops had about a 30 second lag. I went to a console screen and did an init 6. That was when I could not boot back into Linux. I just ran the fstrim command from su. I did it from / and /home directories. I did not want to use the -all switch as I only want to run it on my Linux ssd. On Fri, Apr 21, 2017 at 1:55 PM, John Andersen <jsamyth@gmail.com> wrote:
On 04/21/2017 10:40 AM, Felix Miata wrote:
I don't ever shut Win10 down. I exit Win10 always by rebooting, so that the hocus-pocus it plays when supposedly shutting down won't bollix up booting
Red herring. Since it already rebooted in linux, you can assume the grub stuff is still ok.
Its possible that what Wols mentioned is the problem, and in this case shutting down windows IS the preferred method because Daves shares at least one mounted NTFS files-ystem. (Although usually this just results in it being Read-Only on the linux side.)
-- After all is said and done, more is said than done.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2017 11:06 AM, Dave Smith wrote:
I did it from / and /home directories. I did not want to use the -all switch as I only want to run it on my Linux ssd.
You should really not try to second guess fstrim. Nor should you run it multiple times. Literally once a week is plenty. Its quite smart, and it will not trim systems it does not know how to handle. Trim sends a command to the drive which handles that task all internally to the hardware. It usually runs "nice" so as not to impose any special burn on the system. Remember to enable the timer as I mentioned in my first reply. Once that is done, it will run once a week, and it will keep a record of when it was last done, so even if you are off line it will run it next time you return. The discard option tries to do this interactively, which Ted Ts'o says is a bad way to do it. (Although better than nothing). -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen composed on 2017-04-21 10:55 (UTC-0700):
Felix Miata wrote:
I don't ever shut Win10 down. I exit Win10 always by rebooting, so that the hocus-pocus it plays when supposedly shutting down won't bollix up booting
Red herring. Since it already rebooted in linux, you can assume the grub stuff is still ok.
What could how Windows gets exited have to do with Grub? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2017 11:27 AM, Felix Miata wrote:
What could how Windows gets exited have to do with Grub?
Google will find for you all the ways this can go wrong. Not only at initial install time, but any time windows gets an update. Complaints are legion. Problems are many and varied and ufei complicates the matter even more. (Although if done correctly it can also be the solution). My time in the office today will be limited, otherwise I could write entire chapters on this subject. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen composed on 2017-04-21 11:38 (UTC-0700):
Felix Miata wrote:
What could how Windows gets exited have to do with Grub?
Google will find for you all the ways this can go wrong.
Not for me it won't, as I won't ask. :-)
Not only at initial install time, An entirely different story. I wrote of normal exit, not installation exit. Tales of Windows re-hikjacking the MBR from a Gnu installer hijacked MBR are legion.
Such is not exclusive to Windows. This apparently happens with regularity on multiboot without windows when a newer MBR Grub hijacks an old MBR Grub as the old installation is later updated.
but any time windows gets an update.
This is news to me, but I suppose that must be a side effect of Grub on MBR, which never occurs here unless I make a bad boo-boo. Only times I can remember non-generic MBR code happening here were eons ago with Corel Linux and Xandros. I think both were Lilo, but Xandros may have been Grub.
Complaints are legion. Problems are many and varied and ufei complicates the matter even more. (Although if done correctly it can also be the solution).
Given all the trouble hijacking the MBR has caused multibooters over many many years, I have to wonder why there has apparently not arisen a non-MBR-hijacking multiboot solution that would put a FOSS bootloader on a native filesystem, and add an entry for the FOSS-BL to boot.ini or do whatever bcdedit.exe does in Windows starting with Vista. On UEFI systems it ought to be easy, since the Vista+ bootloader is a generic (non-Windows-specific) bootloader. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/04/17 09:02, Felix Miata wrote:
Given all the trouble hijacking the MBR has caused multibooters over many many years, I have to wonder why there has apparently not arisen a non-MBR-hijacking multiboot solution that would put a FOSS bootloader on a native filesystem, and add an entry for the FOSS-BL to boot.ini or do whatever bcdedit.exe does in Windows starting with Vista. On UEFI systems it ought to be easy, since the Vista+ bootloader is a generic (non-Windows-specific) bootloader.
OK; without making a fuss about it, I think I have the hijacking problem, or at least a facsimile thereof. Multiboot: Leap 42.1, Leap 42.2 and Tumbleweed. (also Windows 7, but that's not relevant here.) Legacy BIOS/MBR, not UEFI/GPT. Each of the Leaps was a fresh install, with Grub2 in the MBR, an arrangement that had worked well for me over many previous multi installations. But now the Grub2 associated with the Leap 42.1 installation seems to have hijacked the boot processes despite many attempts by me to have the 42.2 Grub2 installation take control. It all works, but not it has done in the past, and not as I had wanted it. Any suggestions (simple ones!) on how to fix this so that "ownership" of the Grub2 multiboot processes is shifted from the Leap 42.1 installation to 42.2? -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-22 01:21, Robin Klitscher wrote:
OK; without making a fuss about it, I think I have the hijacking problem, or at least a facsimile thereof. Multiboot: Leap 42.1, Leap 42.2 and Tumbleweed. (also Windows 7, but that's not relevant here.) Legacy BIOS/MBR, not UEFI/GPT.
Each of the Leaps was a fresh install, with Grub2 in the MBR, an arrangement that had worked well for me over many previous multi installations.
It can not work. It may seem to work. You can only install one grub in the MBR. Only one. The next system you install overwrites the previous one. Not completely, because part of grub resides in the /boot directory of the partition.
It all works, but not it has done in the past, and not as I had wanted it. Any suggestions (simple ones!) on how to fix this so that "ownership" of the Grub2 multiboot processes is shifted from the Leap 42.1 installation to 42.2?
No simple ones. There are some variations, but Grub most be installed in the respective boot partitions of the systems you have. One, or none, can be in the MBR. It also depends on using traditional partitions or GPT. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 22/04/17 11:28, Carlos E. R. wrote:
On 2017-04-22 01:21, Robin Klitscher wrote:
OK; without making a fuss about it, I think I have the hijacking problem, or at least a facsimile thereof. Multiboot: Leap 42.1, Leap 42.2 and Tumbleweed. (also Windows 7, but that's not relevant here.) Legacy BIOS/MBR, not UEFI/GPT.
Each of the Leaps was a fresh install, with Grub2 in the MBR, an arrangement that had worked well for me over many previous multi installations.
It can not work.
It may seem to work.
You can only install one grub in the MBR. Only one. The next system you install overwrites the previous one. Not completely, because part of grub resides in the /boot directory of the partition.
Yes: I know. But the problem here seems to be that a Grub2 installation into the MBR invoked from Leap 42.2 does *not* overwrite the previous one (from Leap 42.1). In all previous openSUSE installations over 20 years I've always installed a new release afresh, and kept the existing one separately as a safety net. In no case until 42.1 and 42.2 has this Grub2 problem surfaced.
It all works, but not it has done in the past, and not as I had wanted it. Any suggestions (simple ones!) on how to fix this so that "ownership" of the Grub2 multiboot processes is shifted from the Leap 42.1 installation to 42.2?
No simple ones.
There are some variations, but Grub most be installed in the respective boot partitions of the systems you have. One, or none, can be in the MBR. It also depends on using traditional partitions or GPT.
As I indicated, traditional not GPT. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/04/17 00:43, Robin Klitscher wrote:
No simple ones.
There are some variations, but Grub most be installed in the respective boot partitions of the systems you have. One, or none, can be in the MBR. It also depends on using traditional partitions or GPT.
As I indicated, traditional not GPT.
And you can also install grub in the PBR (partition boot record). It all gets very confusing. On the laptop I'm typing this on, I have gentoo installed. Gentoo's grub is installed in the MBR. SuSE leap has its grub installed in the PBR, and gentoo passes over to it by default (my gentoo installation is half-complete and broken :-( And both versions of grub will hand over to Window's boot loader, which is installed in Window's PBR. Look at it this way. The "default" boot loader (as it's been referred to elsewhere) isn't "more" o/s agnostic than grub. It just looks at the "active" bit and passes over to the PBR on said active partition. Grub is similar. Give it a linux and it will boot it. Give it a chain partition and it will pass over to the PBR on said partition. And said partition is quite happy to contain Windows, grub, lilo, whatever. So I'm guessing that with previous insstallations, you've managed to put grub in the PBR and either had an active partition for the "default" mbr, or they've spotted and added themselves to the config for a grub in the MBR. This time round, however, you've overwritten the 42.1 grub with the 42.2 grub. Each version of grub remembers where to find its own particular copy of /boot/grub ... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/21/2017 04:21 PM, Robin Klitscher wrote:
OK; without making a fuss about it, I think I have the hijacking problem, or at least a facsimile thereof.
Well you have certainly hijacked the thread. Your problem is sufficiently different that you should start a new thread. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Robin Klitscher composed on 2017-04-22 11:21 (UTC+1200):
On 22/04/17 09:02, Felix Miata wrote:
Given all the trouble hijacking the MBR has caused multibooters over many many years, I have to wonder why there has apparently not arisen a non-MBR-hijacking multiboot solution that would put a FOSS bootloader on a native filesystem, and add an entry for the FOSS-BL to boot.ini or do whatever bcdedit.exe does in Windows starting with Vista. On UEFI systems it ought to be easy, since the Vista+ bootloader is a generic (non-Windows-specific) bootloader.
OK; without making a fuss about it, I think I have the hijacking problem, or at least a facsimile thereof. Multiboot: Leap 42.1, Leap 42.2 and Tumbleweed. (also Windows 7, but that's not relevant here.) Legacy BIOS/MBR, not UEFI/GPT.
Each of the Leaps was a fresh install, with Grub2 in the MBR, an arrangement that had worked well for me over many previous multi installations. But now the Grub2 associated with the Leap 42.1 installation seems to have hijacked the boot processes despite many attempts by me to have the 42.2 Grub2 installation take control.
It all works, but not it has done in the past, and not as I had wanted it. Any suggestions (simple ones!) on how to fix this so that "ownership" of the Grub2 multiboot processes is shifted from the Leap 42.1 installation to 42.2?
Without Grub on any MBR and with intent never to have Grub on any MBR I can't test this, but what I think could have happened: 1-your 42.1 went first, and for whatever reason, it put Grub on the MBR. 2-the 42.2 installer saw familiar MBR code and chose to respect rather than hijack it, and put its Grub on PBR 3-update of 42.1 followed and its os-prober added 42.2 to the MBR Grub menu You should be able to use 42.1's YaST2 to reinstall/reconfigure its Grub to PBR, after which it should leave the MBR alone. This may not be a good idea, depending on the partitioning, and what is installed where among your logicals and primaries (ie. 42.1's / is one of the primaries and neither TW's nor 42.2's is). I completely avoid such problems by following a procedure incorporating this ancient wisdom: https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u... Following that here, generic/legacy MBR code is used, and Grub lives on one or more of the primaries, with whichever is to be master bootloader having the active/startable/bootable flag set. All GNU installations have Grub set up on their respective / partitions. Consequently, none ever have reason to disturb the MBR, regardless whether or not Windows shares the system. In such configuration the primary on which Grub lives can be managed either by one of the OS installations (mounted as /boot or as the operational /), or by the sysadmin (mounted other than on / or /boot). A conversion to this from what you now have would be simple for me. For you, I can't say without more info, but given you have had working multiboot apparently for quite some time, it ought not be traumatic. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/04/17 15:58, Felix Miata wrote:
Robin Klitscher composed on 2017-04-22 11:21 (UTC+1200):
On 22/04/17 09:02, Felix Miata wrote:
Without Grub on any MBR and with intent never to have Grub on any MBR I can't test this, but what I think could have happened:
1-your 42.1 went first, and for whatever reason, it put Grub on the MBR.
2-the 42.2 installer saw familiar MBR code and chose to respect rather than hijack it, and put its Grub on PBR
3-update of 42.1 followed and its os-prober added 42.2 to the MBR Grub menu
You should be able to use 42.1's YaST2 to reinstall/reconfigure its Grub to PBR, after which it should leave the MBR alone. This may not be a good idea, depending on the partitioning, and what is installed where among your logicals and primaries (ie. 42.1's / is one of the primaries and neither TW's nor 42.2's is).
I completely avoid such problems by following a procedure incorporating this ancient wisdom: https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u...
Following that here, generic/legacy MBR code is used, and Grub lives on one or more of the primaries, with whichever is to be master bootloader having the active/startable/bootable flag set. All GNU installations have Grub set up on their respective / partitions. Consequently, none ever have reason to disturb the MBR, regardless whether or not Windows shares the system. In such configuration the primary on which Grub lives can be managed either by one of the OS installations (mounted as /boot or as the operational /), or by the sysadmin (mounted other than on / or /boot).
A conversion to this from what you now have would be simple for me. For you, I can't say without more info, but given you have had working multiboot apparently for quite some time, it ought not be traumatic.
Thanks to you and the others who have commented. I'd asked on the back of a post from you 'cos I knew from previous exchanges that you'd have considered advice. I'll have another go at correcting the situation in the next little while. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-21 20:38, John Andersen wrote:
On 04/21/2017 11:27 AM, Felix Miata wrote:
What could how Windows gets exited have to do with Grub?
Google will find for you all the ways this can go wrong. Not only at initial install time, but any time windows gets an update.
Complaints are legion. Problems are many and varied and ufei complicates the matter even more. (Although if done correctly it can also be the solution).
You two are talking of different issues. Windows exit mode does not change grub. What happens is that Windows by default does not do a clean exit, but does a variation of hibernation, leaving the ntfs filesystem in open state, and thus, not mountable in Linux. It typically happens when stopping Windows and booting to Linux next. And if a partition listed in fstab can not mount, then booting may abort to rescue or emergency mode. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 04/22/2017 01:40 AM, Felix Miata wrote:
Dave Smith composed on 2017-04-21 13:20 (UTC-0400):
I am really stumped on this one. I just booted into 4.4.57-18.3 recovery. I wanted to get more info from journalctl. The system fully booted and I am typing this email from Leap 42.2. I did nothing except multiple boot attempts. No idea why it wouldn't boot and now why it will. I would like to figure it out to make sure it does not happen again.
Were any of the boots since right before the first failed boot boots into Windows? If yes, were any of the exits from Windows shutdowns rather than reboots? I don't ever shut Win10 down. I exit Win10 always by rebooting, so that the hocus-pocus it plays when supposedly shutting down won't bollix up booting Linux.
coming in late to the conversation, but I'll throw it in here for good measure... when I boot into Windows 10 on my dual boot machine, I shutdown windows with a particular set of keystrokes that makes sure windows shuts all the way down. You do it like this meta + x = gets you to the menu where shutdown is an option hold down the left shift key while clicking on shutdown That shuts down windows 10 completely. I do this regularly, and it works every time. Then when I reboot, I can boot straight into linux again and it is not a problem. If I don't hold down the left shift key while clicking shutdown, the disk hibernates and I can't boot into linux, and end up in emergency mode. It has happened several times for me. I have always been able to fix it (so far) by booting again into windows and going through the sequence to fully shut down windows again. -- George Box: 42.2 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.2 | KDE Plasma 5.8 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.2 | KDE Plasma 5.8 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 21 April 2017 19:20:51 CEST Dave Smith wrote:
I do not manually run fstrim. How can I tell if it has been run recently?
systemctl list-timers this will give you a list of timers including fstrim.timer showing last and next run date systemd timers have a really great interface unapreciated by the systemd haters and cron fanatics :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anthony Youngman -
Carlos E. R. -
Dave Smith -
Felix Miata -
George from the tribe -
John Andersen -
nicholas -
Robin Klitscher