Today my upgrade to Windows 10 Fall Creators Update was complete and it wasn't without surprises, so I thought I could share some of the things I learned with my fellow Slackers. This writeup began as a Slashdot comment but now I added more specific details.
I use -current 64-bit) and Windows 10 in a dual boot setting managed by GRUB. Both OSes are in partitions of a single drive (/dev/sda).
My Linux partitions are just two, since space is limited and this is not a server machine: a /home partition, and a root partition with everything else. Let's say that root was /dev/sda6 and /home was /dev/sda7.
I thought of this setup as highly stable. It started as a dual boot between Slackware and Windows 8.1, just when I bought the laptop. Subsequently, it managed to survive upgrades to Windows 10 (original version), Anniversary Update and Creators Update without any hassle, so I thought this time would be equally painless. I was wrong.
This Windows upgrade totally b0rked my previous partitioning scheme. Upon the first reboot I got the dreaded message "GRUB error: Unkown filesystem" and a generic GRUB rescue prompt.
That was scary.
I googled and thanks to
these sites I was able to recover the GRUB menu.
First order of business was to type 'ls' in order to see which partitions were seen by GRUB. Fortunately, the number of partitions appeared to be the same.
Now, the sites I visited suggested to enter at the prompt these commands:
Code:
set root=(hd0,6)
set prefix=(hd0,6)/boot/grub
insmod normal
normal
After some time trying various partitions, when I set root and prefix to (hd0,gpt4) (fictitious values), I struck gold and I was able to boot the kernel.
After that I was on my own. All that Ubuntu-centric advice just assumed that the system booted correctly, and then I just had to 'sudo' a reinstall of GRUB. But that was not the case for my system.
Surprise! e2fsck complained of a bad magic number on /dev/sda6. Then I was dropped to an emergency prompt. I was able to see everything on my root partition but it was mounted read-only.
And then it came something telling: e2fsck said that /dev/sda6 was a NTFS partition labeled 'Recovery'.
It turned out, that this Windows upgrade somehow changed the partitioning scheme. So, if my root partition previously was, say /dev/sda6, now it was /dev/sda4. But GRUB and the whole system kept looking for root still in /dev/sda6, which now was something else.
After realizing what was going on, I had to restore things to an usable state.
For that, I did something quite simple. Booted into Windows, where, thanks to ext2fsd, my Linux partitions were accessible. There, edited /boot/grub/grub.cfg so that the main option would boot into (hd0,gpt4) or /dev/sda4, and also edited /etc/fstab accordingly. Saved the changes, booted, and lo! Linux now booted normally to a login prompt! In this case, a SDDM prompt at runlevel 4.
So, went back to the console prompt, logged in as root. Ran grub-install and grub-mkconfig to ensure that GRUB would boot normally now. Rebooted... and now GRUB ran normally. Great!
Once again I booted, and Linux ran normally all the way through the SDDM prompt in runlevel 4.
I entered my username, password, just to be returned to the same SDDM prompt, again and again. What was going on?
I went to the console prompt, logged in with my username/password, and next, login told me that there was no home directory available and it was using / (root) as home directory.
Of course! I had /dev/sda7 as /home; but again, now this was not recognized.
So this is what I did: went into runlevel 3. Logged in as root. In xwmconfig, I selected a very simple window manager (IceWM). Ran GParted and there it was, my home partition was now /dev/sda5. Then, I edited /etc/fstab again to reflect the change. Rebooted, and you guessed it right: now I had a /home directory again.
EDIT: Another "gift" (?) from this upgrade. It turned out that it also enabled Fast Shutdown again. That means that I was unable to get read-write access to the NTFS partitions from Linux; they were read-only. I had to disable Fast Shutdown again.
That was scary, but thankfully Slackware enables you to solve such snafus with minimum damage. Thanks to Pat, the Slackware Crew and every fellow Slacker that at some time guided me with patience for enabling us to recover from such pickles
Hope this is useful to someone who is exposed to similar troubles. Thanks!