Migration

[millpond]

My Debian 10 system is on an ancient Seagate 320Gb drive that started clanking the other day (but is OK for now).
Time to change drives.

I have a 2Tb Hitachi formatted as:
100Gb Ext2 (Bootg)
~1.89 Tb Ext4 (Main - I do not separate /usr and /Home)
10Gb Linux Swap.


While I do have migration software, they do have a tendency to create identical partitions sizes - something I particularly do not want.

I am physically copying over the working drive to the 2TB using mc. Working off the old Seagate drive.

Some files will not copy. When I get to them, I will probably finish the job off of a Live DVD bootup. I am copyting over millions of files so want a usable system while that goes on.

This an an ancient C2D using MBR with no UEFI.

SO my question is: Is there a FAQ on this type of issue?
Do I need to fire up grub to set the MBR? Do I need to manually set the Swap partition in fstab? Any other 'issues' I should be aware of?

Is there a size issue with /Boot? I want it to be large, since I want to experiment with alot of different kernel compilations. As well as use it as temp storage as it can be seen from my Win7 boot (Ext4 does not seem to work there).

Reinstalling is a non-starter. The system is highly customized and should remain as-is outside of new drive size.

[Head_on_a_Stick]

I would use https://wiki.archlinux.org/index.php/Rs ... tem_backup to copy the system over to the new drive then correct /etc/fstab & grub.cfg and install GRUB to the MBR of the new disk. If you use grub-mkconfig to generate grub.cfg then you would have to chroot into the backup with the API filesystems bind mounted[0] then run update-grub.

Is there a size issue with /Boot? I want it to be large, since I want to experiment with alot of different kernel compilations. As well as use it as temp storage as it can be seen from my Win7 boot (Ext4 does not seem to work there).

Why on Earth would you want to use /boot (not "/Boot", there is no directory by that name in the FHS) as a shared partition with Windows? That's just weird. I wouldn't bother with a separate /boot partition at all, it seems like a lot of bother for no benefit.

[0] The arch-chroot command from the arch-install-scripts package will do that for you automatically.

[p.H]

I wouldn't bother with a separate /boot partition at all, it seems like a lot of bother for no benefit.

One benefit with old broken BIOS and large drives is to make sure that /boot contents and any metadata required to access it do not extend beyond the addressable capacity.

[sgosnell]

Instead of using /boot (which is fat32) to share with Windows, why not make a data partition formatted as NTFS? It probably wouldn't need to be large, but only you would know the needed size. Windows can certainly see and work with that, and so can Linux, if you have ntfs-3g installed.

[p.H]

Where do you see that /boot is FAT32 ? According to the OP, it is ext2.

[millpond]

I have just lost my lengthy reply, due to this boards odd insistence of not remembering the login when going to post!

In short:

The drive is fully copied over with mc.
Does ryync provide any extra capabilites I amy have missed?

Indeed it is /boot and not /Boot!

The basic steps from what I understand so far:
1. Set MBRwith Grub with chroot.
2. Set fstab with /boot (if used as separate partition), main, and swap partitions.
3. Is boot flag needed? Do not see this option in gparted!

And most of all:
Merry Christmas to all, and to all a good night!


PostScript:
The reason for the /boot sector partition is that was how the Debian DVD set up the system. I was not sure whether this was a new requirement, as Linux seems to be ever shifting these days, to the point where older FAQs are often no longer usable! I may go without it, as if it is a simple security enhancement, I can probably forego it on my single user system.

[CwF]

I have just lost my lengthy reply, due to this boards odd insistence of not remembering the login when going to post!

When that happens, log in again and then go back in the browser history two pages, to the page with your long post, and press post again.

[p.H]

I have just lost my lengthy reply, due to this boards odd insistence of not remembering the login when going to post!

Most boards I use have a session time-out too. This one is not the shortest.
When this happens, open a new tab and log in again. Then refresh/resubmit the previous tab.

The drive is fully copied over with mc.
Does rsync provide any extra capabilites I amy have missed?

I don't know what mc does. Does it copy all attributes (not only standard permissions but filesystem attributes, ACLs, capabilities...), preserve hardlinks... ?

1. Set MBRwith Grub with chroot.

Actually you do not need chroot to install GRUB on the target drive. You can run grub-install with proper --boot-directory option from the source system. You only need chroot to run update-grub and generate grub.cfg (alternatively you can edit grub.cfg by hand like you do with fstab).

3. Is boot flag needed? Do not see this option in gparted!

Neither GRUB nor Linux need it. But some broken BIOS may require it in order to consider a drive bootable.
I would be surprised that Gparted does not have the option to set the boot flag, but you can use any other partitioning tool (parted, fdisk...).

[millpond]

mc is Midnight Commander. I use it to manage the filesystem. It copies everything that I know of (hidden, symlinks, etc).
Except, of course for /proc and possibly parts of /sys which I assume a bootup would fix anyway.

If I am incorrect about this:
I have lookied into debbootstrap, but am concerned that it is not appropriate as it appears to try to use the repo to add files.
Not acceptable here.

I did find that the boot flag is avaialble under gparted, but not on the main menu (where I am used to finding such things!).
I've set it.

BUT....
In going over fstab I noticed its mutated from what I am used to. The main partition is not listed as such, and is apparently as /dev/mapper. Also it has a lvm flag. To be on the safe side I have put an lvm (as well the previously noted *boot* ) flag on the new drive.

For the forum, I guess I just need to copy replies before pasting.
And hope somebody gets around to fixing timeouts.

[p.H]

mc (...) copies everything that I know of (hidden, symlinks, etc).

I am sure it does. But does it copy all the properties such as extended attributes, ACLs, capabilities ?
Also, does it preserve hard links ? This means that if multiple pathnames in the source share the same inode, then the pathnames in the destination also share the same inode instead of having independent inodes.

I have lookied into debbootstrap

debootstrap is for installing a new Debian system, not moving an existing one.

The main partition is not listed as such, and is apparently as /dev/mapper. Also it has a lvm flag.

LVM is the Logical Volume Manager. This means that the filesystem is not in a plain partition but in a logical volume.
If you want to use LVM on the new drive, there are several ways :
- Create a new physical volume (LVM partition) and volume group on the new drive, create new logical volumes inside the new group, format them, copy the data, change logical volume names in fstab.
- Or create a new physical volume (LVM partition) on the new drive, add it to the existing volume group and move the existing logical volumes to the new physical volume and remove the old physical volume. Then you can extend the volumes to their new sizes.

I have put an lvm (as well the previously noted *boot* ) flag on the new drive.

As most partition flags, the "lvm" flag is only informative. It does not turn a partition into an LVM physical volume.

[millpond]

Is there a way to get rid of the entire LVM system.
I do not need it, do not want it, do not like it!

The migrated paerition will partially boot, even into X, but breaks at networking and a bunch ofother things. Apparently an LVM thing.
I cannot get to the net for repairr tools. Not saying I even knwo which ones to use.
Butt at least grub installs and the system can boot to my Win partition.

Somehow, some way it buggered up the original Seagate system. Same problem, though I did not putz around with grub or partitions with it. While testing the new drive the old one was *offline*. Weird.

The drives tested fine both in fsck and HDSentinel (low level testing). In fact it comes up at first saying the main LVM system drive is OK.

There are plemty of FAQS for removing drives from LVM (and they dont seem to work here), but noting about removing LVM itself.

Edited to add:
blkid is:
tretch:~# blkid
/dev/sda1: UUID="0db01b73-2b29-4381-9245-c7372d1a8e49" TYPE="ext2" PARTUUID="456b9605-01"
/dev/sda5: UUID="Ge1cEg-kpPA-U2QL-zct2-DCn4-UJjy-Mz10jL" TYPE="LVM2_member" PARTUUID="456b9605-05"
/dev/sdc1: UUID="01D3E5B2406CAE00" TYPE="ntfs" PTTYPE="atari" PARTUUID="0002961b-01"
/dev/sdb1: UUID="1608BE2508BE0431" TYPE="ntfs" PARTUUID="000acd9a-01"
/dev/mapper/stretch--vg-root: UUID="92afb13b-f740-4b15-98f6-e37f6b066a33" TYPE="ext4"
/dev/mapper/stretch--vg-swap_1: UUID="7e135e6a-3a24-4be9-8a2b-787e9b166b50" TYPE="swap"
/dev/sdd1: UUID="78bd93ca-75d9-d601-709d-91ca75d9d601" TYPE="ext2" PARTUUID="66ee5d26-01"
/dev/sdd2: UUID="fefa2514-76d9-d601-d0fa-251476d9d601" TYPE="ext4" PARTUUID="66ee5d26-02"
/dev/sdd3: UUID="703a0cd0-b294-40e7-b545-1b53f9452dc8" TYPE="swap" PARTUUID="66ee5d26-03"

It is /dev/sda5 that is the bugger.
Its got a non-standard UUID that is not in grub.cfg

I would want it removed totally from LLVM and assigned to its rightful place as /dev/sda2

[p.H]

Please explain what is each drive sda, sdb, sdc, sdd.

[sgosnell]

Removing the LVM setup you have involves reformatting the partitions and reinstalling the OS. It's certainly possible. When you do the reinstallation, do not choose to use LVM, and it won't be used.

[millpond]

OK. To recap:
OLD *SEAGATE* system 200Mb EXT2 /Boot, typically /dev/sda1 ; 320 Gb Ext4 as LVM on /dev/sda5 (from /dev/sda2) Swap also LVM
NEW *HITACHI* system 1.8TB Primary on /dev/sda2 (/boot merged into main partition) . Separate 10Gb /swap.

Grub updated, fstab set with drive uuids for main and boot partitiobns. root, and swap.
On Hitachi (new) system it now is trying to boot but totally fails after erroring with trying to find 'stretch-vg' LVM group. I deleted the group with the LVM utilities.
And grepping -i -r both /boot and /etc can find no reference it it. Grub.cfg seems happily pointing to the main drive.

There is a reference while booting to a /scripts dir, but cannot seem to find it .

On the older Seagate things are just as grim. I haven been putzing with it, but it too seems unable to find its LVM drive. Right now I just want be be able to access the darn thing, copy it (perhaps with dd) and reformat it entirely.

So it looks like I need to be able to access an LVM drive from another machine, or at least restore its full functionality. On the OLD Seagate system,.
Plus utterly remove LVM bindings and associations on the new Hitachi drive. I have taken LVM out of /init.d there.

[millpond]

Please explain what is each drive sda, sdb, sdc, sdd.

dev/sda1: UUID="0db01b73-2b29-4381-9245-c7372d1a8e49" TYPE="ext2" PARTUUID="456b9605-01" Old Seagate Boot Drive
/dev/sda5: UUID="Ge1cEg-kpPA-U2QL-zct2-DCn4-UJjy-Mz10jL" TYPE="LVM2_member" PARTUUID="456b9605-05" Old Seagate Main Drive
/dev/sdc1: UUID="01D3E5B2406CAE00" TYPE="ntfs" PTTYPE="atari" PARTUUID="0002961b-01" 1Tb NTFS drive
/dev/sdb1: UUID="1608BE2508BE0431" TYPE="ntfs" PARTUUID="000acd9a-01 500GB Win7
/dev/mapper/stretch--vg-root: UUID="92afb13b-f740-4b15-98f6-e37f6b066a33" TYPE="ext4" ???
/dev/mapper/stretch--vg-swap_1: UUID="7e135e6a-3a24-4be9-8a2b-787e9b166b50" TYPE="swap"
/dev/sdd1: UUID="78bd93ca-75d9-d601-709d-91ca75d9d601" TYPE="ext2" PARTUUID="66ee5d26-01" (Original 100Gb 'Boot' for New Hitachi - Now NTFS)
/dev/sdd2: UUID="fefa2514-76d9-d601-d0fa-251476d9d601" TYPE="ext4" PARTUUID="66ee5d26-02" (Main partition (now with \boot) for Hitachi)
/dev/sdd3: UUID="703a0cd0-b294-40e7-b545-1b53f9452dc8" TYPE="swap" PARTUUID="66ee5d26-03" (Hitachi Swap partition)


Dont really understand what /dev/mapper is about.