From: nospam@needed.invalid
On Sun, 8/24/2025 8:40 AM, pinnerite wrote:
> On Thu, 21 Aug 2025 17:17:33 -0000 (UTC)
> alan wrote:
>
>> After months without a working system, one with a new motherboard actually
>> started up and is currently running off a Mint 22.1 install flash drive.
>>
>> It is cloning the contents of a 1TB drive to a 2TB drive. When it is
>> finished, the 1TB drive will be removed.
>>
>> The problem is that the 1TB Nvme drive was set on an Asus motherboard
>> whereas the replacement is a Gigabyte board. When trying to boot from it,
>> it gets to the grub menu but comes to a halt after scrolling several lines
>> up the screen.
>>
>> I don't want to lose the contents by reinstalling. Is there a procedure I
>> can take to recover it?
>>
>>
>> --
>> alan
>
> I appreciate the comments but this is what I did:
>
> 1) Booted on the Mint 22.1 installation drive.
> 2. Cloned the contents of the 1TB drive to the 2TB drive.
> 3) Booting from the 2TB drive only got just past the grub menu, as
> expected.
> 4) Discovered that boot menu access did not work using F8 (per Asus
> boards) but eventually found F12 did.
>
> 5) Selecting the Mint 22.1 install drive from the boot, and
> instructions from Google's AI:
> 6) Open terminal.
> 7) $ sudo mount /dev/nvme0n1 /mnt
> 8) $ sudo mount --bind /dev /mnt/dev
> 9) $ sudo mount --bind /proc /mnt/proc
> 10) $ sudo mount --bind /sys /mnt/sys
> 11) $ sudo chroot /mnt
> 12) $ sudo update-initramfs -u
>
> //returned possible missing firmware /lib/firmware/(amdgpu/ ... (12
> items)
>
> 13) $ sudo update-grub
> 14) $ reboot.
>
> and of course it didn't work.
>
> I decided that I was out of my depth and decided to reinstall.
>
> 15) Used gparted to shuffle partitions to free up contiguous space.
> 16) The space is now partition 3 when it would normally be partition 1.
>
> However it installed OK and a started to recover access to the data:
>
> 17) I installed Virtualbox. I have two virtual machines: XP and Win 10.
> 18) After a struggle I got XP to work. Win 10 will take longer.
> 19) More important was to get Sylpheed, Claws-mail and Thunderbird to
> access existing data.
>
> As I write, I still have Thunderbird to re-acquire access.
>
> Believe it or not, it was 18 May since my machine was last working and
> I had to go back a 16-year old one. That packed up yesterday!
>
> Thanks for all the suggestions.
>
> Alan
>
To be honest, I have never tried moving a Linux on an NVMe from
one motherboard to another. I only own one NVMe, and not a lot of experiments
have involved NVMe as a result. I bought the NVMe, so I could have at
least one "specimen" for hardware detection type info. I use mostly SATA
in the room, because they are so much easier to install and remove. A current
experiment for example, has an orbit of five drives. I couldn't be doing that
with NVMe drives, a screwdriver, and hair loss (I've plugged my single
NVMe in before and got no response from it... grrr, and yes, it still works).
It sounds like there is some sort of boot identifier issue, by moving
the device. GRUB is not completely independent of /dev dependencies,
most of the activity is fluid enough to use BLKIDs and so on. But
one part of GRUB is dependent on the physical device, which means
moving something /dev wise could screw it up. When moving SATA drives,
the partition numbers don't seem to change, and for me... it boots.
A bad guess on my part then, that moving NVMe around, the identifier
scheme is systematic-enough for this to work. It would not be the BLKID
parts of the boot sequence that broke it.
The Boot Repair DVD might have worked then, to tip it upright. Because
that does your chroot sequence for you. I have two discs, a much older
Boot Repair (CD version) and a more recent Boot Repair (DVD version).
The DVD version file, being stored on SourceForge right now. The software
itself is small, but the hosting OS on the DVD is there so there can
be an emergency boot capability. Presumably you could boot any other
Ubuntu-family DVD and install Boot Repair and use it from there. I just
like to have the DVD version available, as there is no messing around and
it goes right to work for you.
My assumption on hardware, is you moved components from old motherboard
to new motherboard, so generation-wise, the OS image should be sufficiently
modern enough to bring it up.
For the VirtualBox, there could be some storage identifiers in the control
file that need correction, depending on the differences in the new install
you've done (username). You could use the OVA route, but with no original
machine
available to make the OVA, that's not going to be easy to do anyway, and
my success rate using OVA hovers around zero. Only a few OVA tries have
worked here. Moving it manually, as you've done, is the most practical
route to success.
At least you're making forward progress -- good to hear!
There must be a mess of broken hardware sitting in the room at this
point, what with the 16 year old machine biting the dust. I've lost two
old machines, and it leaves quite a hole when that happens (blown ICH5
on P4 system (thank you Intel), blown ICH10 on Core2 system (powering issue)).
I know some of the root causes, because of the symptoms thrown before
they died completely.
Paul
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
