On Sunday, 16 March 2025 11:40:14 Greenwich Mean Time you wrote:
> On Sunday, 16 March 2025 09:58:42 Greenwich Mean Time Dale wrote:
> > Dale wrote:
> > > Well, this got interesting.  I booted the spinning rust drive again and
> > > redone the /boot from the old system.  I rebuilt the init thingy because
> > > the one that was there was for the old drive.  I then ran the usual grub
> > > commands to generate the config file and even reinstalled grub just to
> > > be sure.  When I tried to reboot the SSD drive, I was back to the
> > > original screen at the start of this thread.  While I'd like to fix this
> > > and perhaps that fix help someone else in the future, this is just
> > > getting annoying.  I should have put a DOS partition on the thing and it
> > > could be that is the problem despite the parted trick that I've used in
> > > the past.  I dunno.
> > > 
> > > So I'm just going to start over and use a DOS partition table this
> > > time.  That may fix it.  If that fails, I'll just reinstall from
> > > scratch.  That should fix it for sure.  I got all the config files,
> > > world file and such that I need.  I just wish it was colder outside.
> > > That little mobo creates some heat.  LOL
> > > 
> > > In the future, if someone runs into this thread, try rebuilding the init
> > > thingy and all the grub update commands.  It should work.  It did here
> > > once.
> > > 
> > > Thanks to all for helping.
> > > 
> > > Dale
> > > 
> > > :-) :-)
> > > 
> > > Hmmm.  I usually use dd or shred to erase a spinning rust drive.  How in
> > > the heck do I do this on a SSD and not affect it in a negative way?  I
> > > never thought about erasing one of those before.  :-|
> > 
> > Update.  I found a command that wipes partition tables in my little
> > file, where I put things I forget about quite often.  This is my little
> > note.
> > 
> > 
> > wipefs -a -f /dev/sdX   # erase partition table for DOS or GPT
> > 
> > 
> > It's very fast so I assume it erases only the needed bits but doesn't
> > write to other areas, erase user data to prevent recovery or anything.
> > Still, since I was going to put something else on it right away, I
> > wasn't worried about that anyway.
> 
> You can use fdisk/gdisk/parted to change the partition table from legacy
> DOS- MBR to GPT, then create the new partitions, finally format them with a
> suitable filesystem.
> 
> However, you did not need to do this, GPT would be totally suitable for your
> disk.

Ugh!  I didn't provide a comprehensive answer - sorry.  All this MBR nostalgia 
I've been trying to forget.  LOL!

If you are installing GRUB on a GPT disk, which is meant to boot on a legacy 
BIOS MoBo, you *must* create a BIOS Boot Partition (gdisk code EF02).  GRUB 
will drop its boot.img in the disk's MBR (sector 0) then would try to install 
its core.img in sector 1, exactly where GPT has stored its own primary table.  
With a BIOS Boot Partition this clash is averted.

Or, alternatively, you stick with a conventional MBR-DOS partition table which 
will work fine as long as the partitionable space is no larger than 2TB (using 
512-byte sectors) and the total number of partitions (primary plus logical) is 
not ridiculously large.


> > After all that, I partitioned the SSD, copied everything over, chrooted
> > into the SSD OS and then made a new init thingy, updated grub, installed
> > grub and I also re-emerged the linux firmware package.  It puts a .img
> > file in /boot and grub picks that up.  I don't know if it matters but
> > since I did everything else, that was one that I hadn't done before.
> > Maybe it was wrong on the SSD and grub loads it first.  If it fails, no
> > boot.  It's possible anyway.
> 
> I wouldn't think your aged system wouldn't boot if some firmware file was
> missing - unless such firmware was necessary to access your drives.
> 
> > Oh, I also set the labels on the file systems for boot, root and home,
> > like I usually do.  I didn't have to update fstab this time.  Those
> > still matched up just fine with labels.
> > 
> > Again, thanks to all who helped.  It could be the GPT partition table or
> > it might have been that firmware image.  I dunno.  It works now tho.
> > Oh, it might boot a tiny bit faster.  Maybe.
> > 
> > Dale
> > 
> > :-)  :-)
> 
> I think the problem was with your initrd, plus the missing grub and other
> files from /boot fs indicate you may have not mounted it the first time you
> chrooted.

Rethinking all this techno-legacy, I think a critical problem was the lack of 
a BIOS Boot Partition as explained above. 

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to