From: pinnerite@gmail.com
On Sun, 24 Aug 2025 16:29:32 -0400
Paul wrote:
> 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
The good thing about modern machines are the USB-3 ports. I bought a
Ugreen adapter that holds my original 1TB NVMe. It makes a handy
transporter. At some stage I will install a Linux live system that
supports persistence which I will then be able to plug in any machine
and boot up!
Alan
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
