On 6/5/21, Martin McCormick <marti...@suddenlink.net> wrote: > First I greatly appreciate all this information as the idea is to > fix a problem I probably created long ago though I am not sure > how but the short story is that apt-get upgrade ran update-grub > and update-initramfs late last Fall and I was able to rescue it > but it happened again at the end of April so I figured I had > better fix it correctly since I didn't know it was a ticking > bomb.
In a different email where deloptes says... On 6/5/21, deloptes <delop...@gmail.com> wrote: > I have cloned many installations. You are right if done with dd UUID is the > same - but this is perhaps not exactly what you want. I usually either boot > in rescue (initrd shell) or have a USB or Debian installation medium to > chroot and adjust some settings Right there at that part is where I run "update-initramfs -u" in my own similar kind of maneuvering. THEN I do this > and finally execute install/update-grub. > Now with UEFI it is more likely you have a slightly different use case but > UUIDs are what they are. My success rate has been much higher since taking that tactic. One caveat. I'm using LILO these days because GRUB refused to acknowledge GPT hard drives in my usage case. One thing I noticed toward the end before I dumped GRUB was that there were repeatedly mismatches down my whole grub.cfg file. Multiple blocks would have two different UUIDs that GRUB found for what should have been one singular UUID per each partition. Because there is SO MUCH information in that file, that tiny detail didn't immediately leap off the page as surely being a problem in the making. I never did figure out what was occurring because the second UUID, the wrong one, NEVER matched anything in my system. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
