• clone ssd boot disk

    From attend@3:770/3 to All on Sun Dec 4 18:23:04 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to attend on Sun Dec 4 19:31:07 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?B?UGF1bCBGw7Zyc3Rlcg==?=@3:770/3 to attend on Sun Dec 4 20:31:44 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From attend@3:770/3 to Jim Jackson on Sun Dec 4 22:17:53 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From attend@3:770/3 to All on Sun Dec 4 22:20:45 2022
    On 04/12/2022 20:31, Paul Förster wrote:
    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

    Hi Paul,

    Thanks for the information. I haven't heard of this software before, and
    I'll have a try during Xmas break.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Schram@3:770/3 to attend on Mon Dec 5 00:30:28 2022
    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.
    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.

    No need for anything fancy here. I've been using the built-in SD Card
    Copier to backup my SSD to a flash Drive. The software doesn't care that there's no SD card in the mix. Oh, and by the way, My pi 4 boots and
    runs just fine from the flash drive, just a bit slower, due to the
    nature of the media.
    --
    chrispam1@me.com is a filtered spam magnet. Email replies may be lost.
    You're better off replying to this newsgroup.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Vincent Coen@2:250/1 to attend on Mon Dec 5 02:14:36 2022
    Hello attend!

    Sunday December 04 2022 18:23, you wrote to All:

    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.

    Consider using the Pi o/s installer on another system with the Pi turned off and the USB dongle removed and the USB drive port plugged into the other system
    and do similar to the spare SSD drive connecting it to the same system.

    Use the O/S installer to copy of the system to spare.

    At this momment you now have a bootable spare.

    If the OS installer did not transfer over the user directories do so using rsync from 128Gb to the spare 120GB.

    This, should work.

    You way would not have transferred over the boot areas as well as the boot tracks on the 128Gb and these are not so easy to copy over unless using as above or possibly using a migrate SSD copier that often is available from the SSD manufacturer although this will need to be run on a standard system using
    a Intel type processor - I could be wrong here and there is one for a ARM cpu.

    Vincent

    --- Mageia Linux v8 X64/Mbse v1.0.8/GoldED+/LNX 1.1.5-b20180707
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Jim Jackson@3:770/3 to attend on Mon Dec 5 12:20:51 2022
    On 2022-12-04, attend <attend@homesrv.net> wrote:
    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?


    It should be. I use the options -vauxXAH

    what does sudfo blkid say for the new disk?

    Have you got a monitor connected or a serial console connection? Do you
    get any output?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?B?UGF1bCBGw7Zyc3Rlcg==?=@3:770/3 to attend on Mon Dec 5 17:43:39 2022
    Hi attend,

    On 4 Dec 2022 at 23:20:45 CET, "attend" <attend@homesrv.net> wrote:
    Hi Paul,

    Thanks for the information. I haven't heard of this software before, and
    I'll have a try during Xmas break.

    It's not a special piece of software. It's just a shell script that does everything for you that needs to be done. All the tools the shell script uses are already part of your Linux distribution.

    Cheers,
    Paul

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From scott@alfter.diespammersdie.us@3:770/3 to attend on Mon Dec 5 20:43:55 2022
    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.
    I've also changed the disk identifier in /etc/fstab and cmdline.txt to
    match the 120G disk, but it won't boot.

    This is how I image storage devices for the Raspberry Pi. I use it with MicroSD cards, but I see no reason why it wouldn't work with other types of storage.

    1) Put the source card in your desktop machine and use gparted to shrink the
    root partition as small as possible.
    2) Use fdisk to get the block number of the last block of the root
    partition. This, plus one, should be the number of blocks you'll need
    to back up. It'll most likely be a multiple of 2048...go ahead and do
    that, and use the resulting number below. (For this example, let's say
    it's 5632 for a disk with 5.5 GB in use, and that your SD-card reader
    is /dev/sda.)
    3) Create an image with dd:
    dd if=/dev/sda bs=1048576 count=5632 status=progress | xz -9 >rpi-image.img.x
    4) Use gparted to restore the root partition to its normal size, then eject
    the source card and put in your destination card.
    5) Blast the image onto the destination card:
    xzcat rpi-image.tar.xz | dd of=/dev/sda bs=1048576 status=progress
    6) Use gparted to expand the root partition to fill up the card.

    --
    _/_
    / v \ Scott Alfter (remove the obvious to send mail)
    (IIGS( https://alfter.us/ Top-posting!
    \_^_/ >What's the most annoying thing on Usenet?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From paul lee@1:105/420 to attend on Mon Dec 5 17:05:46 2022
    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.

    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.........

    --- Mystic BBS v1.12 A48 2022/07/15 (Linux/64)
    * Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (1:105/420)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to paul lee on Tue Dec 6 08:53:01 2022
    On 2022-12-05 05:05, paul lee wrote:
    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.........


    120 < 128

    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Anssi Saari@3:770/3 to bnl@nowhere.com on Tue Dec 6 13:07:42 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to Anssi Saari on Tue Dec 6 17:42:21 2022
    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


    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Schram@3:770/3 to bnl@nowhere.com on Tue Dec 6 20:17:53 2022
    On 2022-12-06, Björn Lundin <bnl@nowhere.com> 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

    I made a comment earlier in this thread, but it may have been lost in
    the shuffle, perhaps due to me omitting a few key details. I boot and
    run my pi 4 from a 256 GB SSD, but at this time the drive is extremely under-utilized. I use SD Card Copier to backup this drive to a much,
    much smaller capacity flash drive. SD Card Copier doesn't care what size
    the destination drive is, as long as all the source data will fit.

    As I said before, my backup flash drive boots and runs just fine.

    Depending on the original poster's unique situation, it may be quite
    possible to backup a 128 GB SSD to to a 120 GB SSD using SD Card Copier.

    --
    chrispam1@me.com is a filtered spam magnet. Email replies may be lost.
    You're better off replying to this newsgroup.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Tauno Voipio@3:770/3 to All on Tue Dec 6 21:26:07 2022
    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:

    sudo losetup -f -P --show path_to_image_file

    You can then start gparted with the listed /dev/loop as an argument:

    sudo gparted /dev/loopn

    replacing /dev/loopn with the reported device, e.g. /dev/loop3

    Gparted can be used to shrink the ext4 partition to the size really
    used (leaving a few megabytes to spare). After the shrink check from
    the information menu the last sector of the ext4 partition, add one
    and divide by 2048 to get the new image size in megabytes.

    Remember to disconnect the loop device before adjusting the image file:

    sudo losetup -d /dev/loopn

    The image file can then be truncated with the truncate command:

    truncate -s new_file_size path_to_image_file

    Please note that a recent Linux distributions use a bunch of loop
    devices, so to be safe, it is a good idea to let losetup to find
    the loop device. My Kubuntu 2204 LTS uses 10 loop devices for itself.

    The copied disk can be expanded to fill the available space with
    raspi-config:

    sudo raspi-config

    Select 6 Advanced Options, then A1 Expand Filesystem, and follow
    the on-screen instructions, reboot when instructed so.

    HTH

    --

    -TV

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to Tauno Voipio on Tue Dec 6 21:53:55 2022
    On 2022-12-06 20:26, Tauno Voipio wrote:
    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:

    ---
    <many commands shrinking data/partitions snipped/>

    You are replying on a possible way to move the data.
    I was replying to why it does not work to use a 'standard dd'' (and i
    quote from above in this msg)

    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.


    And I stay with my first reply

    120 < 128

    It does not fit.


    Of course it *can* be moved if it is shrunk first.
    But I replied to why 'a standard dd' would not do


    Personally, I did the corresponding thing with gparted.
    I was then surprised it did copy/paste with partitions and its data


    ---


    --
    /Björn

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Nikolaj Lazic@3:770/3 to All on Wed Dec 7 17:39:20 2022
    Dana Sun, 4 Dec 2022 18:23:04 +0000, attend <attend@homesrv.net> napis'o:
    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 would use resize2fs to shrink the last partition on the source
    to make data under 120G.
    You should boot from SD card to do this.
    Than boot from source drive to confirm that everything is ok...
    Than boot from SD...
    Than copy the whole source drive to destination drive.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Deloptes@3:770/3 to attend on Wed Dec 7 21:25:45 2022
    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

    If you want identical UUIDs, then dd only the partition table and use the method above to transfer the content (after formatting)

    The cool thing with tar is, you can use it over SSH

    tar cf - . | ssh myhost 'cd /media/myuser/mydisk && tar xvf -'
    (see Unix Power Tools, 3rd Edition. ch10.13)

    BR

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Deloptes on Wed Dec 7 21:29:13 2022
    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

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to druck on Thu Dec 8 06:13:01 2022
    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.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Ahem A Rivet's Shot on Thu Dec 8 21:52:30 2022
    On 08/12/2022 06:13, Ahem A Rivet's Shot wrote:
    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.

    That is a possibility with certain software, so proceed with caution and
    always check that your backuped files are identical to the originals
    *BEFORE* you need to restore from it.

    However in practice, there are few problems with this approach.
    Particularly as frequently changing files such the contents of caches
    are best excluded from incremental backups, and recreated when needed.

    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.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to druck on Fri Dec 9 05:03:06 2022
    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.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Anssi Saari@3:770/3 to bnl@nowhere.com on Fri Dec 9 12:35:58 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Fri Dec 9 13:51:49 2022
    On 09/12/2022 05:03, Ahem A Rivet's Shot wrote:
    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.

    You can get away with it on a database server using C-ISAM files
    provided its relatively quiescent.

    --
    The biggest threat to humanity comes from socialism, which has utterly
    diverted our attention away from what really matters to our existential survival, to indulging in navel gazing and faux moral investigations
    into what the world ought to be, whilst we fail utterly to deal with
    what it actually is.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to druck on Sat Dec 10 18:00:18 2022
    On 2022-12-07, druck <news@druck.org.uk> wrote:
    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

    the -x option you quoted stops it cross filesystems - so no need to
    exclude /dev /proc /sys etc

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Nikolaj Lazic@3:770/3 to All on Sat Dec 10 20:59:30 2022
    Dana Fri, 09 Dec 2022 12:35:58 +0200, Anssi Saari <as@sci.fi> napis'o:
    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.

    True. I've done that few times.
    On different architectures. Worked every time.
    It should even be faster than rsync if one has lamost full partition.

    Or he could resize it to the size a bit over the size used in that partition, copy... and than resize to the full size of the partition.
    Much faster than rsync.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)