Hi all again...
I took a long while for coming back... I'm still alive, after some real-life issues and also after some investigation over all the offered alternatives - plus some additional research.
Well, first of all many thanks to everybody for all the helpful input.@sumski:
I've checked your 3 docs suggestions, which are very interesting (mostly the Ubuntu one).
I've also performed your 13 steps, which went all smoothly. However at the end it seems I was only replicating the exact steps done by the Mint installer in the first place - since at the end, there was no change in boot behaviour or in the contents of grub files (at least none that I could have noticed).
I actually didn't try your last suggestion about disabling UUIDs. If I'm gonna have 2 or 3 systems, plus 2 or 3 USB external devices, UUIDs is something I don't definitely wish to get rid of... lest I get myself even more confused and lost than GRUB itself when managing disks & partitions.@Serendipity :
I did take a look at Rescatux's pages - there's a demo video there which 'sort of' explains how it works. However, judging by what Google and Distrowatch tell me, it doesn't seem to be a very widely known distro or a very well supported one, what doesn't make me highly enthusiastic about testing it.
I do have an old friend of a rescue distro which is System Rescue CD, and giving a quick look at their manual pages I found they have some grub-fixing stuff in place. I might be trying that soon.@wayne128 :
Your overall reasoning seems sensible, in the sense that GRUB's booting order becomes different than BIOS's disk order.
However it's my understanding that, at install time
(either by Mint installer or by chroot actions from LiveCD), when I specify /dev/sdd
as the target partition, GRUB installs itself to the right place I intended it to
. The reason why I understand that this is what happened, is the fact that, when I boot from that particular drive, there's now a GRUB prompt there (which, as we know, doesn't work fully, but it shows me that GRUB was indeed installed to the drive I intended it to). There was no GRUB there before the install.
OTOH, the fact that GRUB doesn't work fully is indeed a hint that, at boot time, the disk ordering as done by GRUB became different from the disk order at install time.
So, whilst GRUB is indeed installed to the drive which WAS sdd at install time, it's no longer sdd at boot time
- or hd4 / hd3 / whatever (seems this notation differs between grub1 and grub2) - so GRUB doesn't find the remainder of its files that it searches for at 'sdd'.
While your reasoning seems sensible, your actual examples are from grub1. I don't feel confident enough in transposing your suggestions to my grub2 setup, not only because the drive notation scheme differs between both grub versions, but also because grub2 uses a somewhat more involved setup procedure than the traditional manual edition of files employed by grub1.
And for the same reason above, I don't think it would be wise in my current situation to dare install grub to /dev/sda.
My Windows is booting normally and I intend to exhaust all available options to boot Mint from USB before attempting to risk my Windows boot.
And well, try as I might I couldn't make sense of your following statement -
What I think with your desire to keey windows drive totally with windows boot loader and Linux drive on USB as totally Linux drive and using BIOS boot order to control which drive to boot from
But I believe that didn't detract from my overall understanding of your suggestions.@all:
well, I believe I've still got some additional tricks to try, whenever - God knows when - I have some more testing time. In order of tackling preference:
1. trying to boot Mint's LiveCD with option ''toram=filesystem.squashfs". I understand that this option, if indeed workable, will allow me to remove the pendrive
from which Mint Live is booting from. This is currently /dev/sdc. At this point I'd redo sumski's steps, but now the target drive will have become sdc instead of the original sdd it was previously.
The logic behind this is that fewer drives will reduce the problem and might simplify the solution.
2. I have some doubts if a 980 Mb squash FS will indeed fit, after expansion, into my 2 Gb RAM. So if #1 doesn't work, I'll boot from SystemRescue
- which is about half of Mint's size and whose 'toram' option will surely work - and redo sumski's steps from there,
with the target drive now transmogrified into sdc instead of the original sdd (similar to #1).
3. Next, if GRUB remains stubborn (don't we ever run out of options ???) I'll try manual fiddling with grub-rescue,
as outlined here
4. And finally, as a last-resort (for now at least) I might try a poor man's temporary solution, creating another small /boot partition at /dev/sdb
(which is a fixed SSD
), installing grub's files in there, and installing the MBR code in there too - all the while leaving the remaining Mint partitions on USB drive.
That's all folks, at least for now. Thx very much again for all the good suggestions - hope to be back soon (maybe not SOOO soon) with more news.