My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk.
On 2022-12-04, attend <attend@homesrv.net> wrote:
My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
How did you copy the partitions?
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.
you've not given a lot of information.
For instance what was your cmdline.txt file and what is it now?
Are you sure the new /boot partition is in VFAT format?
Hi attend,
On 4 Dec 2022 at 19:23:04 CET, "attend" <attend@homesrv.net> wrote:
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk.
I use "rip-clone" which creates a bootable backup of the current boot disk. Size differences don't matter as long as te target disk is big enough to hold the whole contents of your current boot disk.
Also, I found it to be good practice to format the target disk. If you don't then you're backup may or may not boot.
https://github.com/billw2/rpi-clone
Hope this helps,
Paul
My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.
On 04/12/2022 19:31, Jim Jackson wrote:
On 2022-12-04, attend <attend@homesrv.net> wrote:
My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
How did you copy the partitions?
I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.
you've not given a lot of information.
For instance what was your cmdline.txt file and what is it now?
Are you sure the new /boot partition is in VFAT format?
Yes, two partitions. FAT32 for boot and ext4 for root.
cmdline.txt in 128G disk (current running) is as below:
console=serial0,115200 console=tty1 root=PARTUUID=7295e545-02
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
And I've changed root=PARTUUID=7295e545-02 to the 120G disk partuuid,
which I have manually changed to 7295e546-02 by fdisk.
From my understanding, files in boot partition are not required in particular sectors of hard drive and there is no such thing like MBR.
Having read some information about the boot sequence of the Raspberry Pi
from website http://www.diy.ind.in/raspberry-pi/55-run-scripts-on-startup-in-raspberry-pi
1. Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
2. Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
3. Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
4. start.elf loads kernel.img. It then also reads config.txt,
cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at
0??100 & kernel @ 0??8000 If disable_commandline_tags is set it loads
kernel @ 0??0 Otherwise it loads kernel @ 0??8000 and put ATAGS at 0??100
5. kernel.img is then run on the ARM.
At stage 4, system will read config.txt and cmdline.txt. I believe there
is no partition information in config.txt, and only cmdline.txt is
required to change in boot partition for the partuuid.
I suppose rsync is not suitable for this?
Hi Paul,
Thanks for the information. I haven't heard of this software before, and
I'll have a try during Xmas break.
My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to match the 120G disk, but it won't boot.
at> As the 120G ssd is not the same size and brand as the 128G one, I
at> couldn't use dd to clone whole disk. Then I did it manually by copying
at> boot partion and root partion to the 120G disk partitions seperately.
at> I've also changed the disk identifier in /etc/fstab and cmdline.txt to
at> match the 120G disk, but it won't boot.
Why wouldn't a standard 'dd if=/src of=/destination' work? So long as the /destination is LARGER than the /src, it should write [clone] with no issues.
|07p|15AULIE|1142|07o
|08.........
On 2022-12-05 05:05, paul lee wrote:
Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with no issues.
|07p|15AULIE|1142|07o
|08.........
120 < 128
Björn Lundin <bnl@nowhere.com> writes:
On 2022-12-05 05:05, paul lee wrote:
Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with no issues.
|07p|15AULIE|1142|07o
|08.........
120 < 128
Even then, assuming there's space on the 128 GB card, he could've just resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.
On 2022-12-06 12:07, Anssi Saari wrote:
Björn Lundin <bnl@nowhere.com> writes:
On 2022-12-05 05:05, paul lee wrote:
Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with no issues.
|07p|15AULIE|1142|07o
|08.........
120 < 128
Even then, assuming there's space on the 128 GB card, he could've just
resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.
You also seem to miss OP's first sentence :
"My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk ..."
That is the new disk is smaller.
The destination is not larger - it is SMALLER
On 2022-12-06 12:07, Anssi Saari wrote:
Björn Lundin <bnl@nowhere.com> writes:
On 2022-12-05 05:05, paul lee wrote:
Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with
no issues.
|07p|15AULIE|1142|07o
|08.........
120 < 128
Even then, assuming there's space on the 128 GB card, he could've just
resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.
You also seem to miss OP's first sentence :
"My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk ..."
That is the new disk is smaller.
The destination is not larger - it is SMALLER
On 6.12.2022 18.42, Björn Lundin wrote:
On 2022-12-06 12:07, Anssi Saari wrote:
Björn Lundin <bnl@nowhere.com> writes:
On 2022-12-05 05:05, paul lee wrote:
Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with
no issues.
|07p|15AULIE|1142|07o
|08.........
120 < 128
Even then, assuming there's space on the 128 GB card, he could've just
resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.
You also seem to miss OP's first sentence :
"My respberry pi 4 is currently booting from a 128G ssd disk thourgh
usb and everything is fine. I just got a spare 120G ssd disk ..."
That is the new disk is smaller.
The destination is not larger - it is SMALLER
The image file of the disk can be shrunk on another Linux computer
by setting up a loop drive with partitions:
Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with
no issues.
My respberry pi 4 is currently booting from a 128G ssd disk thourgh
usb and everything is fine. I just got a spare 120G ssd disk and I'm
going to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.
My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.
As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.
I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.
I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.
attend wrote:
I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.
I do following trick
given /dev/sda1 is boot and /dev/sda2 is root of the source drive and /dev/sdb1 is boot and /dev/sdb2 is root of the target drive
I mount /dev/sda2 on /mnt/source and /dev/sda1 /mnt/source/boot
then I mount /dev/sdb2 on /mnt/target and /dev/sdb1 /mnt/target/boot
so now cd /mnt/source && tar cf - . | (cd /mnt/target; tar xvf -)
tar would preserve groups and permission.
However this would not boot if UUIDs are used. One should modify /etc/fstab in /mnt/target and update initram if used
rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc
On Wed, 7 Dec 2022 21:29:13 +0000
druck <news@druck.org.uk> wrote:
rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc
You need not to have any active databases or similar cached stores operating at the time also any files being written at the time of the copy will be corrupt or at least truncated.
I have dozens of large sqlite databases which are receive updates during backups, and have not suffered any corrupted, verified by checking
against remote replicated copies.
That is the new disk is smaller.
The destination is not larger - it is SMALLER
On Thu, 8 Dec 2022 21:52:30 +0000
druck <news@druck.org.uk> wrote:
I have dozens of large sqlite databases which are receive updates during
backups, and have not suffered any corrupted, verified by checking
against remote replicated copies.
Don't try it with a real database server.
On 07/12/2022 20:25, Deloptes wrote:
attend wrote:
I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.
I do following trick
given /dev/sda1 is boot and /dev/sda2 is root of the source drive and
/dev/sdb1 is boot and /dev/sdb2 is root of the target drive
I mount /dev/sda2 on /mnt/source and /dev/sda1 /mnt/source/boot
then I mount /dev/sdb2 on /mnt/target and /dev/sdb1 /mnt/target/boot
so now cd /mnt/source && tar cf - . | (cd /mnt/target; tar xvf -)
tar would preserve groups and permission.
However this would not boot if UUIDs are used. One should modify /etc/fstab >> in /mnt/target and update initram if used
That is fine for small amounts of data but is terribly inefficient for
entire discs with GB of data.
rsync is a much better tool for the job, and had the advantage that
should the copying be interrupted for any reason, just issuing the
command again will cause it to continue from exactly where it went off.
rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc
Björn Lundin <bnl@nowhere.com> writes:
That is the new disk is smaller.
The destination is not larger - it is SMALLER
That was clear but what I said also stands. Take one 128 GB drive,
resize the file system(s) on it so that they take up at most 120 GB of
the drive and dd away. dd will error out when the smaller drive is full
but it doesn't matter since everything contained in the file system(s)
was copied at that point.
I can see someone else proposed this as well so it shouldn't be a
radical concept. Tools to resize common file systems have been around
for a few decades now.
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 231:26:30 |
| Calls: | 55 |
| Calls today: | 1 |
| Files: | 50,127 |
| D/L today: |
29 files (3,538K bytes) |
| Messages: | 275,359 |