From Newsgroup: alt.os.linux.mint

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC)
alan <alan@asandco.co.uk> wrote:

I don't want to lose the contents by reinstalling. Is there a procedure I
can take to recover it?

If you trust AI, here is what deep seek say.

This is a common issue when moving a Linux installation between
different hardware, especially motherboards from different
manufacturers. The problem is typically related to hardware detection,
driver compatibility, and initramfs configuration.

Here are the steps to resolve this:

1. Boot from Live USB and Chroot
First, boot from a Linux Live USB and mount your system:

bash
# Mount the root partition
sudo mount /dev/nvme0n1pX /mnt # replace X with your root partition
number

# Mount other necessary partitions
sudo mount /dev/nvme0n1pY /mnt/boot # if separate boot partition
sudo mount /dev/nvme0n1pZ /mnt/boot/efi # if EFI partition

# Mount virtual filesystems
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

# Chroot into your system
sudo chroot /mnt
2. Reconfigure Initramfs and Kernel
bash
# Update initramfs for all installed kernels
update-initramfs -u -k all

# Reinstall kernel packages (Ubuntu/Debian)
apt install --reinstall linux-image-generic linux-headers-generic

# For other distributions:
# Fedora: dnf reinstall kernel
# Arch: pacman -S linux
3. Check and Update GRUB
bash
# Update GRUB configuration
update-grub

# Reinstall GRUB to the EFI partition
grub-install /dev/nvme0n1 # replace with your drive
4. Check Hardware-Specific Drivers
bash
# Install common hardware support packages
apt install firmware-linux firmware-linux-nonfree

# Check for missing firmware
dmesg | grep -i firmware
5. Alternative: Boot with Fallback Options
Try booting with these kernel parameters at the GRUB menu (press 'e' to
edit):

text
nomodeset acpi=off noapic
If this works, you can make it permanent by adding to /etc/default/grub:

bash
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
update-grub
6. Filesystem Check
bash
# Check filesystem integrity
fsck /dev/nvme0n1pX # replace with your root partition
7. If All Else Fails: Fresh GRUB Installation
bash
# Completely reinstall GRUB
apt purge grub-efi-amd64 grub-common
apt install grub-efi-amd64 grub-common
grub-install /dev/nvme0n1
update-grub
After completing these steps, reboot and you should be able to boot successfully. The key is regenerating the initramfs with the new
hardware detection and ensuring all necessary drivers are included.

PLEASE DON'T KILL ME ;-)
--
Running Linux Mint 22.1 (Xia) using Kernel=6.14.0-28-generic on x86_64 , Cinnamon, lightdm, x11
AMD Ryzen 7 5700G with Radeon Graphics (16) @ 5.288GHz

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 8/21/2025 1:17 PM, 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?

Linux distros can be moved from machine to machine.
I'm not concerned about that part. From what I've seen, even
if you used Driver Manager for one video card, then had a different
video card in the machine with the moved distro, it still boots
and comes up and you can see the screen. The distro knows enough
to handle any driver issue. This works best with "mature" video cards
which have been around long enough to be handled by the release.

How are you cloning ?

You can't use "dd" to clone a GPT partitioned drive to a
larger GPT partitioned drive, since the secondary partition table
(at the end of the disk), is no longer sitting at the end.

This shows me "fixing" my big disk after a dd clone to it.

Select the "fix" option when it is offered!

I am using "gparted" package to do it, and just pointing
gparted at the disk when started gparted, is enough to
trigger the repair dialog. Once repaired, only BIGDSK is in the
machine during its first boot (to avoid duplicate identifier
issues caused by dd cloning).

sudo gparted /dev/sdb # Point gparted at the BIGDSK not the SMALLDSK
# You can do this right after the dd clone if you want.

[Picture]

https://i.postimg.cc/htKvjgFt/fix-small-big-clone-via-gparted.gif

I noticed during boot of the repaired BIGDSK, a complaint of
corrupt inodes being removed, so at some point in my "dd adventure"
some cloning was not done properly and some write data was not
flushed out to the BIGDSK. I'm not sure where that came from,
but I don't like to see crap like that. I pride myself on treating
mounted partitions properly so that does not happen, which is why
I like to know how such things happen.

*******

If you used some other cloning method, the "handler" in the cloning
method should do a much better job of such things, and damaging
the secondary GPT partition table won't be an issue when moving
to the larger disk.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC), alan wrote:

It is cloning the contents of a 1TB drive to a 2TB drive. When it is finished, the 1TB drive will be removed.

Is rCLcloningrCY going to end up with only a 1TB usable volume on the 2TB drive? DonrCOt do that.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 8/21/2025 5:36 PM, Lawrence DrCOOliveiro wrote:

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC), alan wrote:

It is cloning the contents of a 1TB drive to a 2TB drive. When it is
finished, the 1TB drive will be removed.

Is rCLcloningrCY going to end up with only a 1TB usable volume on the 2TB drive? DonrCOt do that.

I only tested in a VM, as it was the quickest thing to do.
I tested LM221 EFI/GPT, then cloned with dd to a 2x larger disk.

My VM seemed to freeze at some step during UEFI boot, when using
the larger disk (with its invalid secondary partition table). And the
virtual environment isn't capable of Secure Boot, as there is no TPM.
Control never seemed to get handed off to LM221. After I booted the
LM221 DVD again, and used "gparted" on it, the "size fix" which moves
the GPT table, seemed to be sufficient to make the larger disk boot OK.

*******

The boot part of it (if damaged) can be fixed with the Boot Repair disc,
which is easier than doing the chroot as the AI advised.

The Boot Repair disc (Yann), it does the chrooting for you. But at this point, we don't know the extent of the damage, whatever the damage happens to be.
The current Boot Repair disc, downloads from SourceForge, and it uses a Ubuntu core to make the disc bootable, plus a copy of the Boot Repair code.

Of the two disks, the 1TB and the 2TB, when doing the Boot Repair, only
the 2TB would be plugged in. Anything which is sensitive to "disk identifiers", should be done with its clone unplugged from the machine. The 1TB and 2TB can't be plugged in at the same time, when Boot Repairing. Since we're trying to
get the 2TB booting, it needs to be Boot Repaired (if the first procedure
was still un-bootable), and you would boot repair it when it is by itself.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

Paul wrote:

On Thu, 8/21/2025 1:17 PM, 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?

Linux distros can be moved from machine to machine.

great!-a :)

I'm not concerned about that part. From what I've seen, even
if you used Driver Manager for one video card, then had a different
video card in the machine with the moved distro, it still boots
and comes up and you can see the screen. The distro knows enough
to handle any driver issue. This works best with "mature" video cards
which have been around long enough to be handled by the release.

How are you cloning ?

You can't use "dd" to clone a GPT partitioned drive to a
larger GPT partitioned drive, since the secondary partition table
(at the end of the disk), is no longer sitting at the end.

This shows me "fixing" my big disk after a dd clone to it.

Select the "fix" option when it is offered!

I am using "gparted" package to do it, and just pointing
gparted at the disk when started gparted, is enough to
trigger the repair dialog. Once repaired, only BIGDSK is in the
machine during its first boot (to avoid duplicate identifier
issues caused by dd cloning).

sudo gparted /dev/sdb # Point gparted at the BIGDSK not the SMALLDSK
# You can do this right after the dd clone if you want.

[Picture]

https://i.postimg.cc/htKvjgFt/fix-small-big-clone-via-gparted.gif

I noticed during boot of the repaired BIGDSK, a complaint of
corrupt inodes being removed, so at some point in my "dd adventure"
some cloning was not done properly and some write data was not
flushed out to the BIGDSK. I'm not sure where that came from,
but I don't like to see crap like that. I pride myself on treating
mounted partitions properly so that does not happen, which is why
I like to know how such things happen.

*******

If you used some other cloning method, the "handler" in the cloning
method should do a much better job of such things, and damaging
the secondary GPT partition table won't be an issue when moving
to the larger disk.

Paul

--
Linux Mint 22.1

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 21 Aug 2025 22:32:43 -0400, Paul wrote:

Anything which is sensitive to "disk identifiers", should be done
with its clone unplugged from the machine.

This wouldnrCOt be a problem if you did a regular file copy from the old
disk to the new.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 2025-08-21, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC), alan wrote:

It is cloning the contents of a 1TB drive to a 2TB drive. When it is
finished, the 1TB drive will be removed.

Is rCLcloningrCY going to end up with only a 1TB usable volume on the 2TB drive? DonrCOt do that.

You can then use the "dead" 1TB of space. Gparted will help you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 2025-08-21, alan <alan@asandco.co.uk> 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

From Newsgroup: alt.os.linux.mint

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC)
alan <alan@asandco.co.uk> 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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Sun, 8/24/2025 8:40 AM, pinnerite wrote:

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC)
alan <alan@asandco.co.uk> 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Sun, 24 Aug 2025 16:29:32 -0400
Paul <nospam@needed.invalid> wrote:

On Sun, 8/24/2025 8:40 AM, pinnerite wrote:

On Thu, 21 Aug 2025 17:17:33 -0000 (UTC)
alan <alan@asandco.co.uk> 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



--- Synchronet 3.21a-Linux NewsLink 1.2