Michael wrote: > 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. >
When I first did this and got through with the copy process, grub complained about that. I ran into that before and found a fix. Of course, I couldn't remember how to fix it tho. Off to my little cheat file, my memory file. This is what I put there to fix this, worked a couple times before. # grub-install fails with "grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible." Using parted command. # # parted /dev/sdX # set 1 boot off # set 1 bios_grub on # q # # then install grub. This happens on drives where GPT is used instead of MBR. I did that but I think it messed up the file system for /boot when I did it. I don't recall it doing that when I used it before tho. When I ran lsblk, it showed a file system for root and home but not /boot anymore. I know I formatted it because it was the first one I did and it is always ext2, others are ext4. I also ran du -shc /* after the copy process to make sure that /dev, /sys, /proc and such were empty and others that should have files were about the right size. I know I mounted and copied /boot. When I finish mounting things to chroot, I type in mount to be sure I did them all right. >>> 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. I think me fixing not having it is what caused the problem. I figure if we kept banging at the problem, we could have fixed it. Thing is, given things I got going on, I don't have time to keep arguing with that old thing. LOL It was easier to just start over and put a DOS partition table on it and be done with it. Now it is done the right way, for that old thing anyway. I booted it up twice now. I think it is going to be OK. I'll update my backups later. I got some new videos to rename first tho. Found some vintage stuff. :-D Dale :-) :-)