grub blues - LMDE USB-to-USB install

[sdrubble]

Hi all,

I'm having some issues with GRUB when installing LMDE, most likely due to the tricky setup I'm using. Hope someone could throw some helpful tips in here...

I'm using an EEE 901 netbook, with no HD and two SSD's. That would be sda with 4 Gb (Windows installed), and sdb with 16 Gb with a number of partitions.

I've "burned" the LMDE-XFCE LiveCD to a 1 Gb pendrive (unetbootin) which runs normally. That makes it 'sdc'.

And finally, from the sdc pendrive, I've done a succesful install to a 160 Gb USB HD which became 'sdd'. sdd already had a number of partitions, to which I added -

Code: Select all

sdd8   2.2 Gb    swap
sdd9   1.0 Gb    /boot
sdd10  6.0 Gb    /
sdd11  5.0 Gb    /home

I've inspected the contents of all 3 partitions after install, all of them look good. All my current issues seem to be with GRUB, though.

When installing I've selected that grub be installed to /dev/sdd , so as not to mess with the current Windows install and letting me select from BIOS which drive I'd like to boot from.

Upon first boot, after selecting the USB HD among the BIOS boot options, I was greeted by GRUB with

Code: Select all

no such partition

and a 'grub rescue' prompt.

First thought was, "pendrive being present or not will also make the USB HD change between becoming sdc or sdd at boot". However, the error msg remains the same when I boot from the USB HD, regardless of the pendrive being also present or not.

After googling a bit I did, from the LiveCD:

Code: Select all

grub-install --root-directory=/mnt/sdd9 /dev/sdd

. This command returned a succesful result, but in the end the 'no such partition' remained at boot time.

I also thought of installing grub to sdb , which is a fixed SSD and not subject to device-name changes. So I did

Code: Select all

grub-install --root-directory=/mnt/sdd9 /dev/sdb

which also returned a succesful result.

Next, when booting and selecting sdb as booting option, things improved a tiny bit... Now I receive

Code: Select all

no such device: [UUID here]

So in the end I can try to boot GRUB from either sdb OR sdd, with different error msgs in either case.

Now I've got a number of options to follow, and also found lots of conflicting suggestions both inside and outside of Mint forums. Some of them are some years old, and as I'm aware that grub2 has undergone lotsa changes recently, I believe I'd better try to get some better advice from the folks here instead of blindly trying all kinds of wild stuff.

I suspect that sticking to the sdb boot and trying to fix the UUID pointers might be the easiest way to get around this. HOW exactly to do this is something I'm not so sure of... hope someone can come up with some hints in here.

Oh, and BTW - Windows still boots normally from sda.

Cheers

[sumski]

Can you see your usb disk/partition from grub shell? Also, did you ran update-grub after you installed it?

[sdrubble]

Thx sumski,

Can you see your usb disk/partition from grub shell?

Well, my knowledge of grub is a bit shallow, and even more so with grub2. What I DID find under 'grub shell' for grub2 so far has been quite misleading, such as these two examples:

- - - - The powerful grub shell has been removed.
- - - - where is grub shell ?

Would you pls point me to some docs explaining grub-shell usage under grub2 ?

Also, did you ran update-grub after you installed it?

Not really - since I didn't have any chance to boot into the installed system, I found no way of doing so.
Unless you mean I should run update-grub from the LiveCD session itself ? In that case, how could I direct update-grub to act upon the installed system and not upon the live one?

While I wait for any additional clarifications that might come up, I'll see what I can do with some grub-rescue tips I found at http://tuxcrux.com/inside-grub-shellcommandline/ . These seem tailored for grub2.

Cheers

[sumski]

Here are some nice pages you can see for grub2:
https://help.ubuntu.com/community/Grub2 ... cue%20Mode
http://forums.debian.net/viewtopic.php?f=16&t=48382
https://wiki.archlinux.org/index.php/Gr ... ue_console

I guess best way is to chroot inside your usb HDD instalattion:
STEP 1:
Boot into live cd/usb

STEP 2:
Become root

STEP 3:

Code: Select all

fdisk -l

and determine your usb HDD disk (is it sd(a,b,c,...))

STEP 4:
Then mount USB partition you set up to be root partition

Code: Select all

mount /dev/sdxy /mnt

STEP 5: (only if you have separate boot partition)

Code: Select all

mount /dev/sdxy /mnt/boot

STEPS 6,7,8:

Code: Select all

mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys

STEP 9:

Code: Select all

chroot /mnt

STEP 10:

Code: Select all

grub-install /dev/sdx

STEP 11:

Code: Select all

update-grub

STEP 12:

Code: Select all

exit

STEP 13:

Code: Select all

reboot

If these steps don't work , then repeat all the steps except step 11 , and edit /etc/defaut/grub , and uncomment

Code: Select all

#GRUB_DISABLE_LINUX_UUID="true"

, and then try step 11.

[sumski]

I use this script for these kind of thing , edit to your needs:

Code: Select all

    #!/bin/bash

    mp=/mnt # root
    #mpb=/mnt/boot # boot
    #boot=/dev/sdy #
    root=/dev/sdx #

    mount $root $mp
    #mount $boot $mpb

    cd $mp
    rm console ; mknod -m 600 console c 5 1
    rm null ; mknod -m 666 null c 1 3
    rm zero ; mknod -m 666 zero c 1 5

    mount -t proc proc $mp/proc
    mount -t sysfs sys $mp/sys
    mount -o bind /dev $mp/dev
    mount -o bind /dev/pts $mp/dev/pts
    cp /etc/resolv.conf /mnt/etc/
    chroot $mp /bin/bash 

And then go through steps 10 ->13

[Serendipity]

If Sumski's method doesn't work, you could try downloading Rescatux. Its an open source (Debian based) program designed to fix grub2. I frequently change partitions and operating systems, and I have used this several times to fix grub2.

[wayne128]

I've inspected the contents of all 3 partitions after install, all of them look good. All my current issues seem to be with GRUB, though.

When installing I've selected that grub be installed to /dev/sdd , so as not to mess with the current Windows install and letting me select from BIOS which drive I'd like to boot from.

Upon first boot, after selecting the USB HD among the BIOS boot options, I was greeted by GRUB with

Code: Select all
no such partition

and a 'grub rescue' prompt.

Reading from what you posted on your issue trying to boot USB drive installed ( with MBR written as /dev/sdd),
I would like to point out something that explained this issue.

First, BIOS always hand over to first boot drive's MBR.

Second, your error message of no such partition showed that Grub is there but it cannot find the boot partition (called by stanza that was installed as /dev/sdd, thus it prompt you with grub rescue.

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, landed with another issue that you may not be aware.

You don't have problem on booting from windows drive.
Now when you boot from USB drive, as BIOS select it, it becomes first boot drive, so when grub took over, this USB drive actually is first boot drive, but all your previously installation had it as fourth boot drive (sdd).
Your best approach is:
1. If you want to have your way, then change all grub stanza on sdd to first boot drive
2. forget about worry on having grub takes over MBR of first boot drive, sda ( currently your windows drive), then let grub take over and update-grub will take care of it.
Remember you must have grub install on sda, the first boot drive in order to work.


Now I guess somehow you like to use 1.

I would illustrate what I meant by actual example, I boot up my USB drive, which multiboot with several OS, I just illustrate two of them, both are PCLinuxOS, both used grub legacy so you need to adjust a bit but it is easy to understand grub legacy.

When I installed to USB drive I change these grub legacy stanza to reflect them as first drive, here is the portions that is relevant, for zen-mini at partition 3 and gnome at partition 1

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd0,2)/boot/gfxmenu
default 0

title zen-mini-gnome at Fujitsu usb-sda3
kernel (hd0,2)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=bfdbf20a-dea7-4a56-86b7-3f9e4266498f splash=silent vga=788
initrd (hd0,2)/boot/initrd.img


title PCLOS 2101.11 gnome chianload at Fujitsu usb to sda1
root (hd0,0)
chainloader +1

title Gnome direct at Fujitsu-usb-sda1
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE==Gnome root=LABEL=usb-gnome splash=silent vga=788
initrd (hd0,0)/boot/initrd.img

Take note, all the root highlighted as red colour on grub stanza are hd0 or first drive,

Now when I fdisk -l, this USB drive is shown as

Disk /dev/sdb: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x6e6824b4

Device Boot Start End Blocks Id System
/dev/sdb1 1 3825 30724281 83 Linux
/dev/sdb2 3826 4080 2048287+ 82 Linux swap / Solaris
/dev/sdb3 4081 7904 30716280 83 Linux
/dev/sdb4 7905 77826 561642609+ 5 Extended


Note that the drive is seen by kernel or OS as /dev/sdb, second drive.

Hope this 'confusion' makes some sense to you.
and good luck on getting your USB drive to boot and run, with proper grub stanza.

[sdrubble]

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

Cheers

[sdrubble]

Hi all, done some of my planned tests - findings follow.

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.

This process worked initially as expected: pendrive contents were copied to RAM (interestingly enough, htop didn't show this FS-in-RAM usage - only about 150 Mb used of the total 2000 Mb RAM).
LiveCD boot completed, pendrive removed, and then the USB HD was plugged in, becoming /dev/sdc this time.
Then I repeated sumski's 13 steps, which ran as usual...
And finally rebooted to the installed system, with no change to the previous results : 'error: no such partition' msg and the 'grub rescue' prompt.

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

This step was skipped, as it was a planned workaround for a possible 'insufficient RAM' issue that did NOT happen.

While the results from test #1 above are consistent with the previous situation (which will bring me next to the still planned tests #3 & #4 as outlined in my previous post), I found an additional issue.

Before performing 'grub-install' and 'update-grub', I made snapshots of files 'device.map' and 'grub.cfg'. And did the same again after running those commands. The changes to both were consistent with the absence of the pendrive this time - i.e., one less device inside device.map and changes in various places inside grub.cfg. Strange thing is, I have TWO 'device.map' files - one at /boot/grub/device.map (which was correctly updated after the commands), and a second one at /boot/boot/grub/device.map. This last file was NOT updated (I checked its timestamp), and its contents remained the same (both files were IDENTICAL BEFORE the commands). In other words, it looks just like an outdated dead weight.

Am I supposed to really have 2 differing 'device.map' files ? I'm sure I didn't move or copy stuff around in the installed system...(hadn't any chance to, anyway).

Any possible BUG in here ? Or maybe a consequence of a command I ran in the middle of the original fix attempt a couple of days ago ? I had run

Code: Select all

dpkg-reconfigure grub-pc

(as recommended on this bug report ubuntu-496435), and at the time didn't bother to mention it here as it brought nothing new to the scene.

Well that's about it for now... next in line are tests #3 & #4 as outlined in my previous post.

Cheers

[wayne128]

grub1 is easy to understand and manage, change only one file, menu.lst

however grub2 is more intelligent, but takes more time to learn its complexity, one file becomes three files with longer procedure.

since your USB-drive (Mint installed) had grub2 in MBR, you can boot up computer via usb-live, mount your USB-drive ( Mint installed), use editor to change grub config file which should look similar to below, change the highlighted 3 to 0. Save, reboot, select the USB-drive from BIOS menu, hope all is well.

menuentry "Linux Mint 10 64-bit, 2.6.35-22-generic (/dev/sda5) (on /dev/sda5)" {
insmod part_msdos
insmod ext2
set root='(hd3,msdos5)'
search --no-floppy --fs-uuid --set a8d57677-dacb-499e-9867-db75d792ff91
linux /boot/vmlinuz-2.6.35-22-generic root=UUID=a8d57677-dacb-499e-9867-db75d792ff91 ro quiet splash
initrd /boot/initrd.img-2.6.35-22-generic
}

[sumski]

@sdrubble
i would really try disabling UUID , at least for testing purposes. I would also try to label partitions, so it would be less confusing.You can also use this labels for grub.cfg. Another try would be to chroot inside your instalation and update the system. I'm saying this because i think there was an update to grub wich fixed some issues with usb installs. There's also an option to purge grub from both mbr and as a package, and install it cleanly... Good luck

[sdrubble]

Hi folks!

@wayne128:

grub1 is easy to understand and manage, change only one file, menu.lst

So... I had been toying in my mind with an additional idea: remove grub2 and install grub-legacy.

From what you've posted in this topic (and also on some other topics I've been browsing), I understand you keep dozens of OSes and manage them all with grub-legacy. So it doesn't look like you miss the added complexity of grub2 at all.

There's one feature in grub2 which I MIGHT miss (unless of course it's also present in grub-legacy and I'm not aware of that): the ability to boot directly from ISO files. Can you do that under grub-legacy?

Thx for the editing tips. It's along the lines of what I have been thinking (step #3, a couple of posts back), and your example will be definitely helpful.

So, besides the #3 test I'll be doing soon, I'll be looking forward for any thoughts you might have on my grub1 x grub2 questions.

Also, if you'd really support my idea of going to grub1, pls take a look below, on what I said to sumski, regarding the apt-get issue I'm having when inside a chroot . Maybe you could offer your insights there also... I'd need to have that issue solved first before I'd be able to exchange GRUBs.

@sumski:

i would really try disabling UUID , at least for testing purposes. I would also try to label partitions, so it would be less confusing.You can also use this labels for grub.cfg.

Well, I haven't totally discarded this UUID-disabling suggestion of yours yet. Just keepin'it on the back burner for a while.

Regarding labels, I'm also not so sure... I'm used to frequent re-labeling of partitions for whatever reasons, both from GParted and from Ms-Windows, which might bring other kind of headaches at boot time. Might keep an eye on that though.

Another try would be to chroot inside your instalation and update the system. I'm saying this because i think there was an update to grub wich fixed some issues with usb installs.

Well, although I didn't post it here (to avoid info overload...) I DID try exactly that with:

Code: Select all

apt-get update
apt-get install grub-pc grub-common

as the initial commands inside the chroot.

However, it seems that I'm having Internet connection issues when inside the chroot. The connection commands to the various source URLs roll by quite fast, as if no Internet connection was available.

I tried this twice: first with wi-fi, then with a cabled connection (so as to avoid any potential authentication issues from inside the chroot). There was no difference in the results.

I recall that some months ago I managed to successfully install Mint 9 to LVM (to another lappy which is now half-broken), which at the time required chrooting and installing the LVM package from the repos under the chroot... I had no issues with apt-getting stuff from the chroot at the time, so I'm puzzled as to why I can't get it to work this time. Just to be clear, Internet connection remains always ON at the LiveCD level.

Would you have any hints on how to validate the Internet connection from the chroot ? Or could it be a different issue like having to fix the sources file ? Any hints here would be helpful.

There's also an option to purge grub from both mbr and as a package, and install it cleanly...

I'm not sure of exactly what you're telling me here. Is this specific to the newer grub version or already present in the current one ? I recall having read 'somewhere' (I don't really remember WHERE, but it might have been a warning issued by dpkg-reconfigure grub-pc), stating something like "uninstalling GRUB will NOT remove anything from MBR - you'd have to install SOMETHING ELSE over it in order to remove it". Duuhh...

@all:

Thx again folks. It's being surprisingly fun (well, erm...almost !) to address these issues with so much helpful input.

Cheers

[sumski]

Here we go again!
Take a look at the script i posted.
Last command before the chroot one :

Code: Select all

cp /etc/resolv.conf /mnt/etc/resolv.conf

This should get you a working internet inside chroot.

If updating doesn't help , then you first need to eliminate errors in the relation UUIDs (you can check them with

Code: Select all

blkid 

command) - device.map (/boot/grub/device.map) -grub.cfg (/boot/grub/grub.cfg).

"uninstalling GRUB will NOT remove anything from MBR - you'd have to install SOMETHING ELSE over it in order to remove it". Duuhh...

This is somewhat true ; with purging grub packages , grub is still installed to mbr ; but you can erase your mbr with the

Code: Select all

dd

command; we should try that as a last resort.

[sdrubble]

Shiny and happy greetings to all...

I'm happy to report that my GRUB issues are finally solved.

Before I delve into the gory details, one small question begs to be asked first.

@sumski:

Take a look at the script i posted.
Last command before the chroot one :

Well, unless I got things all mixed up due to overworked brain cells, the line you posted on May 26 does not belong to the script you posted on May 23. The script BTW runs 'mknod', and I had since been wondering what in heaven would this have to do with booting issues... looks like the script is not THE one you really wanted to post.

As to the resolv.conf info bit, I will be taking note of this for next time I need Internet under chroot. Thx !!!

@all:

Regarding the main issue of this whole topic, it ended up being solved by paying closer attention to the actual error msg and even closer attention to the related docs.

Error msg from GRUB was - and had been from the very start BTW - the following:

Code: Select all

error: no such partition
grub rescue >

First of all I ran the 'ls' command at grub's prompt. It enumerated 3 drives, and as expected, the former /dev/sdd drive that I was booting from had become 'hd0'. However, 'ls' also enumerated the partitions under each of the 3 drives, and I noticed that the partition list for hd0 was incomplete - namely, sxy9 which should be /boot was NOT listed.

Then I read carefully what is stated here, and checked the partitioning on the drive I wanted to boot from. It's a 320 Gb beast, and I had defined the boot partition at around the 128 Gb mark. It *should* work according to that doc, where it's stated something about a 137 Gb limit. But since the drive has a somewhat convoluted partition sequencing which goes crazily up and down along the drive (thanks to the awesome flexibility of GParted) I decided to play as safe as possible.

So I did a major reshuffling of all partitions, which ended up changing the designations of all those I wanted to use. This time /boot went to /dev/sxy2, a meager 6 Gb from the start of the disk. I thought the best bet would now be a complete reinstall.

Well, I spent about 2 or 3 hours trying to workaround the infamous 'calculating file indexes' hanging stuff. Solved it finally - and posted the solution somewhere as pointed by Dr. Hu - after booting WITHOUT the 'toram' parm I had been booting from, which apparently steals part of the RAM expected by the installer.

So, as I had to install with the pendrive present, the 320 Gb target drive became sdd again. I requested that GRUB be installed to sdd.

After install was done, crossed my fingers, removed the pendrive, rebooted to the 320 Gb drive, to meet GRUB again which still played a final joke on me.

I was initially greeted with a "Welcome to Grub!", then a brief pause with some "error @#gjik*&¨*-whatever", a 2nd brief pause, and then - finally - at last - voilá - GRUB's menu !!!

I am under the impression that, at this very moment, grub2 did its own real-time magic and changed the boot specs on-the-fly from the original /dev/sdd to the resulting hd0, without any human intervention. If this was indeed so, it shows at last some of the refinements done from grub1 into grub2.

Well the story isn't fully over yet. System boots but I'm now facing an authentication issue (one error msg for a WRONG user password and a different error msg for the RIGHT password). But now that's another story, another day, another search, and maybe another forum topic.

Thx a lot everybody, once again, for all the mighty help and suggestions !

Cheers from the heart

sdrubble

[sumski]

@sumski:
Well, unless I got things all mixed up due to overworked brain cells, the line you posted on May 26 does not belong to the script you posted on May 23. The script BTW runs 'mknod', and I had since been wondering what in heaven would this have to do with booting issues... looks like the script is not THE one you really wanted to post.

As to the resolv.conf info bit, I will be taking note of this for next time I need Internet under chroot. Thx !!!

You are right , some things were unnecessery , and some were missing ...

Then I read carefully what is stated here, and checked the partitioning on the drive I wanted to boot from. It's a 320 Gb beast, and I had defined the boot partition at around the 128 Gb mark. It *should* work according to that doc, where it's stated something about a 137 Gb limit. But since the drive has a somewhat convoluted partition sequencing which goes crazily up and down along the drive (thanks to the awesome flexibility of GParted) I decided to play as safe as possible.

That did crossed my mind , but , as you say , i also had an overload of my brain cells , so i forgot to ask that

Anyway , i'm really glad you solved you isssues with grub!
Happy booting to you