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.

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

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 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

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

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 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 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

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 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 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