Cloning a bootable USB stick to a different-sized stick












10














HARDWARE: 2 8GB USB flash drives

DISTRO: Mint 9 Xfce persistent Live Cd



One USB flash drive has two partitions:

1) FAT32 700MB Mint 9 partition

2) ext3 7.3GB casper-rw partition



GOAL:

I want to make a duplicate of that USB flash drive because I don't want to go through the time of installing and configuring from scratch again.



EXPERIENCE:

1) I have found that dd does not work for this job because if one of my flash drives is even 1MB different in size, which sometimes they are, then the copy gets corrupted.



2) I have found that using gparted and preformatting the second drive like the first and then rsync'ing each partition individually does not work because for some reason some files do not get copied and the drive remains unbootable.



I want to keep my working stick and just make copies of it and configure the sticks for my friends. This way if I goof up another stick I will always have my base stick just sitting around waiting.










share|improve this question
























  • what bootloader do you use (syslinux?). Please consider removing that rant from your post, it adds no value whatsoever to your question.
    – Mat
    Jun 5 '11 at 8:34










  • I used the mint live usb installer, so it was all automatic. I'm hoping the cloning process will avoid working with bootloaders and copy my current bootloader conf
    – Joshua Robison
    Jun 5 '11 at 8:40
















10














HARDWARE: 2 8GB USB flash drives

DISTRO: Mint 9 Xfce persistent Live Cd



One USB flash drive has two partitions:

1) FAT32 700MB Mint 9 partition

2) ext3 7.3GB casper-rw partition



GOAL:

I want to make a duplicate of that USB flash drive because I don't want to go through the time of installing and configuring from scratch again.



EXPERIENCE:

1) I have found that dd does not work for this job because if one of my flash drives is even 1MB different in size, which sometimes they are, then the copy gets corrupted.



2) I have found that using gparted and preformatting the second drive like the first and then rsync'ing each partition individually does not work because for some reason some files do not get copied and the drive remains unbootable.



I want to keep my working stick and just make copies of it and configure the sticks for my friends. This way if I goof up another stick I will always have my base stick just sitting around waiting.










share|improve this question
























  • what bootloader do you use (syslinux?). Please consider removing that rant from your post, it adds no value whatsoever to your question.
    – Mat
    Jun 5 '11 at 8:34










  • I used the mint live usb installer, so it was all automatic. I'm hoping the cloning process will avoid working with bootloaders and copy my current bootloader conf
    – Joshua Robison
    Jun 5 '11 at 8:40














10












10








10


2





HARDWARE: 2 8GB USB flash drives

DISTRO: Mint 9 Xfce persistent Live Cd



One USB flash drive has two partitions:

1) FAT32 700MB Mint 9 partition

2) ext3 7.3GB casper-rw partition



GOAL:

I want to make a duplicate of that USB flash drive because I don't want to go through the time of installing and configuring from scratch again.



EXPERIENCE:

1) I have found that dd does not work for this job because if one of my flash drives is even 1MB different in size, which sometimes they are, then the copy gets corrupted.



2) I have found that using gparted and preformatting the second drive like the first and then rsync'ing each partition individually does not work because for some reason some files do not get copied and the drive remains unbootable.



I want to keep my working stick and just make copies of it and configure the sticks for my friends. This way if I goof up another stick I will always have my base stick just sitting around waiting.










share|improve this question















HARDWARE: 2 8GB USB flash drives

DISTRO: Mint 9 Xfce persistent Live Cd



One USB flash drive has two partitions:

1) FAT32 700MB Mint 9 partition

2) ext3 7.3GB casper-rw partition



GOAL:

I want to make a duplicate of that USB flash drive because I don't want to go through the time of installing and configuring from scratch again.



EXPERIENCE:

1) I have found that dd does not work for this job because if one of my flash drives is even 1MB different in size, which sometimes they are, then the copy gets corrupted.



2) I have found that using gparted and preformatting the second drive like the first and then rsync'ing each partition individually does not work because for some reason some files do not get copied and the drive remains unbootable.



I want to keep my working stick and just make copies of it and configure the sticks for my friends. This way if I goof up another stick I will always have my base stick just sitting around waiting.







live-usb cloning bootable






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 12 '13 at 13:27









erch

2,000113461




2,000113461










asked Jun 5 '11 at 3:30









Joshua RobisonJoshua Robison

3582921




3582921












  • what bootloader do you use (syslinux?). Please consider removing that rant from your post, it adds no value whatsoever to your question.
    – Mat
    Jun 5 '11 at 8:34










  • I used the mint live usb installer, so it was all automatic. I'm hoping the cloning process will avoid working with bootloaders and copy my current bootloader conf
    – Joshua Robison
    Jun 5 '11 at 8:40


















  • what bootloader do you use (syslinux?). Please consider removing that rant from your post, it adds no value whatsoever to your question.
    – Mat
    Jun 5 '11 at 8:34










  • I used the mint live usb installer, so it was all automatic. I'm hoping the cloning process will avoid working with bootloaders and copy my current bootloader conf
    – Joshua Robison
    Jun 5 '11 at 8:40
















what bootloader do you use (syslinux?). Please consider removing that rant from your post, it adds no value whatsoever to your question.
– Mat
Jun 5 '11 at 8:34




what bootloader do you use (syslinux?). Please consider removing that rant from your post, it adds no value whatsoever to your question.
– Mat
Jun 5 '11 at 8:34












I used the mint live usb installer, so it was all automatic. I'm hoping the cloning process will avoid working with bootloaders and copy my current bootloader conf
– Joshua Robison
Jun 5 '11 at 8:40




I used the mint live usb installer, so it was all automatic. I'm hoping the cloning process will avoid working with bootloaders and copy my current bootloader conf
– Joshua Robison
Jun 5 '11 at 8:40










3 Answers
3






active

oldest

votes


















5














Introduction



For a drive with PC partitions (which is what you'll find on most USB sticks), the bootloader consist in a tiny part at the very beginning of the drive (the stage 1 bootloader, in the boot sector of the drive) and a larger part elsewhere (the stage 2 bootloader, in a file). The stage 1 data contains the physical location of stage 2. If you copy the whole device (what you tried with dd), the stage 1 part is in the same physical location and the stick works, but the new stick has to be at least as large as the original. If you recreate the partitions and copy the files, you're missing the stage 1 since it's not a file.



I think (but I haven't checked) that the stage 2 is in the first (FAT32) partition. If so, you can copy that partition wholesale, and copy the boot sector as well, then edit the partition table so that the second partition occupies exactly the space that's left, and copy the files on the second partition. You might as well keep a raw image of the boot sector and of the first partition in a file on a hard disk (but you can clone them from a USB stick too).



Making a clone of a different size



Below I'll call the device containing the original stick /dev/sdb and the device containing the clone /dev/sdc; substitute names as needed. Create mount points if needed. I assume that the FAT32 partition (at the beginning of the disk) is numbered 1 and the ext3 partition is numbered 2; substitute different numbers if needed.



First part, if cloning from a stick:



head -c 512 </dev/sdb >/dev/sdc
partprobe /dev/sdc
cat </dev/sdb1 >/dev/sdc1


First part, if cloning from image files:



cat boot_sector.img >/dev/sdc
partprobe /dev/sdc
cat first_partition.img >/dev/sdc1


The call to partprobe is needed so that the kernel reloads the partition table from the disk (it's in the boot sector, and the first command in either scenario above modifies the boot sector). If you omit it, either you'll get errors or the kernel will silently write garbage to the stick.



To make the image files:



head -c 512 </dev/sdb >boot_sector.img 
cat /dev/sdb1 >first_partition.img


Now after you've got the boot sector and the first partition, you need to edit the partition table again, to resize the second partition. You can do this automatically by feeding the right input to fdisk. Warning, this is extremely error-prone, and I haven't tested it. If you don't feel completely comfortable with this part, do it by hand.



sed -e 's/ *#.*//' <<EOF | tr -s ' ' 'n' | tr -d _ | fdisk /dev/sdc
d 2 # delete partition 2
n p 2 # new primary partition 2...
_ _ # ... using all available space
w q # write and quit
EOF


Finally reload the partition table again, create an ext3 filesystem, and copy the files there.



partprobe /dev/sdc
mke2fs -j /dev/sdc2
mount /dev/sdc2 /media/sdc2
cp -a /media/sdb2/ /media/sdc2/
umount /media/sdc2


Simplified method to make a larger clone



If you prefer, you can store an image of the whole stick. You'll be able to use that image directly on any stick that's at least as large: just copy that image onto the new stick with cat <whole.img >/dev/sdc, then run partprobe /dev/sdc (or unplug the stick and put it back in) to re-read the partition table.



Then, if you like, you can enlarge the clone. In this order:




  1. Enlarge the partition. Unfortunately, I don't know how to do this in a simple way. parted can do it with the move command (not resize, which resizes the filesystem), but you need to figure out the right arguments — switch to sectors (unit s) to avoid rounding errors.

  2. Enlarge the filesystem. That part is easy: just run resize2fs /dev/sdc2 to make the filesystem use the whole partition size.


If you're starting from a larger stick than necessary, you can shrink it by following the steps above in the reverse order (first shrink the filesystem with resize2fs, then shrink the partition with parted).



Alternatively, you can first copy the stick to an image file, then work on that image file. To access the partitions, use a loop device, specifically associating a portion of the file to a disk. Here's a sketch of the steps if you want to shrink the image (warning, untested, proceed carefully and double-check the math).



fdisk -lu whole.img  # note starting sector of partition 2: $S
losetup -fs -o $(($S * 512)) whole.img
# Let $D be the desired size of partition 2, in kB
resize2fs /dev/loop0 $ # replace /dev/loop0 by whatever losetup prints
losetup -d /dev/loop0
parted whole.img
# Use parted to resize the second partition
dd if=/dev/null of=/file/to/truncate seek=1 bs=$(($S/2+$D+1))k





share|improve this answer























  • hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
    – Joshua Robison
    Jun 7 '11 at 11:35






  • 1




    @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
    – Gilles
    Jun 7 '11 at 13:02










  • hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
    – Joshua Robison
    Jun 7 '11 at 13:43










  • Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
    – Joshua Robison
    Jun 7 '11 at 13:45










  • is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
    – antonio
    Oct 12 '13 at 11:27



















2















~$: sudo apt-get install gddrescue ddrescue



~$: ddrescue /dev/sda /dev/sdb -v




;



Syntax: utility /source/drive /destination/drive --verbose



Comment: shows progress and error checking so you know if it is acceptable or hanging up somewhere. You can also add b= whatever size blocks you want. "gddrescue" is gui based version of "ddrescue" but I only use the ddrescue as written above since it works without a problem.






share|improve this answer



















  • 2




    Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
    – Paul Fischer
    Oct 5 '16 at 0:04



















0














I just wanted to give my two cents, maybe this'll help out anyone else who's looking for this topic or perhaps in a similar situation.



So I had recently cloned my Kali live encrypted persistence from a 16GB to a 64GB 3.0 USB, My host OS is windows 10 pro. I hadn't attempted to clone using any Linux distro, I'm sure the answers above are what you need, but for any windows users; I had used AOMEI disk partition assistant. Super simple to use, used it for partitioning my SSD to fit Ubuntu, but I digress.



I had to make sure that the USB I was cloning to had already been formatted for live booting. Plugged in both USB's and simply right clicked on the 8GB drive; clicked on copy then selected the 64GB drive, it'll ask you a bunch of things like "are you sure this is the right drive, everything will be erased" all that jazz. Just read through it and make sure everything is in order, you really don't have to do much.



Just wait for the process to be finished and you're all set. Tested said USB and everything worked!



I found this to be the easiest way at least for me, cloning live distros from USB to USB, Hope this helps anyone inquiring now or in the future!





share





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f14435%2fcloning-a-bootable-usb-stick-to-a-different-sized-stick%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    5














    Introduction



    For a drive with PC partitions (which is what you'll find on most USB sticks), the bootloader consist in a tiny part at the very beginning of the drive (the stage 1 bootloader, in the boot sector of the drive) and a larger part elsewhere (the stage 2 bootloader, in a file). The stage 1 data contains the physical location of stage 2. If you copy the whole device (what you tried with dd), the stage 1 part is in the same physical location and the stick works, but the new stick has to be at least as large as the original. If you recreate the partitions and copy the files, you're missing the stage 1 since it's not a file.



    I think (but I haven't checked) that the stage 2 is in the first (FAT32) partition. If so, you can copy that partition wholesale, and copy the boot sector as well, then edit the partition table so that the second partition occupies exactly the space that's left, and copy the files on the second partition. You might as well keep a raw image of the boot sector and of the first partition in a file on a hard disk (but you can clone them from a USB stick too).



    Making a clone of a different size



    Below I'll call the device containing the original stick /dev/sdb and the device containing the clone /dev/sdc; substitute names as needed. Create mount points if needed. I assume that the FAT32 partition (at the beginning of the disk) is numbered 1 and the ext3 partition is numbered 2; substitute different numbers if needed.



    First part, if cloning from a stick:



    head -c 512 </dev/sdb >/dev/sdc
    partprobe /dev/sdc
    cat </dev/sdb1 >/dev/sdc1


    First part, if cloning from image files:



    cat boot_sector.img >/dev/sdc
    partprobe /dev/sdc
    cat first_partition.img >/dev/sdc1


    The call to partprobe is needed so that the kernel reloads the partition table from the disk (it's in the boot sector, and the first command in either scenario above modifies the boot sector). If you omit it, either you'll get errors or the kernel will silently write garbage to the stick.



    To make the image files:



    head -c 512 </dev/sdb >boot_sector.img 
    cat /dev/sdb1 >first_partition.img


    Now after you've got the boot sector and the first partition, you need to edit the partition table again, to resize the second partition. You can do this automatically by feeding the right input to fdisk. Warning, this is extremely error-prone, and I haven't tested it. If you don't feel completely comfortable with this part, do it by hand.



    sed -e 's/ *#.*//' <<EOF | tr -s ' ' 'n' | tr -d _ | fdisk /dev/sdc
    d 2 # delete partition 2
    n p 2 # new primary partition 2...
    _ _ # ... using all available space
    w q # write and quit
    EOF


    Finally reload the partition table again, create an ext3 filesystem, and copy the files there.



    partprobe /dev/sdc
    mke2fs -j /dev/sdc2
    mount /dev/sdc2 /media/sdc2
    cp -a /media/sdb2/ /media/sdc2/
    umount /media/sdc2


    Simplified method to make a larger clone



    If you prefer, you can store an image of the whole stick. You'll be able to use that image directly on any stick that's at least as large: just copy that image onto the new stick with cat <whole.img >/dev/sdc, then run partprobe /dev/sdc (or unplug the stick and put it back in) to re-read the partition table.



    Then, if you like, you can enlarge the clone. In this order:




    1. Enlarge the partition. Unfortunately, I don't know how to do this in a simple way. parted can do it with the move command (not resize, which resizes the filesystem), but you need to figure out the right arguments — switch to sectors (unit s) to avoid rounding errors.

    2. Enlarge the filesystem. That part is easy: just run resize2fs /dev/sdc2 to make the filesystem use the whole partition size.


    If you're starting from a larger stick than necessary, you can shrink it by following the steps above in the reverse order (first shrink the filesystem with resize2fs, then shrink the partition with parted).



    Alternatively, you can first copy the stick to an image file, then work on that image file. To access the partitions, use a loop device, specifically associating a portion of the file to a disk. Here's a sketch of the steps if you want to shrink the image (warning, untested, proceed carefully and double-check the math).



    fdisk -lu whole.img  # note starting sector of partition 2: $S
    losetup -fs -o $(($S * 512)) whole.img
    # Let $D be the desired size of partition 2, in kB
    resize2fs /dev/loop0 $ # replace /dev/loop0 by whatever losetup prints
    losetup -d /dev/loop0
    parted whole.img
    # Use parted to resize the second partition
    dd if=/dev/null of=/file/to/truncate seek=1 bs=$(($S/2+$D+1))k





    share|improve this answer























    • hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
      – Joshua Robison
      Jun 7 '11 at 11:35






    • 1




      @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
      – Gilles
      Jun 7 '11 at 13:02










    • hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
      – Joshua Robison
      Jun 7 '11 at 13:43










    • Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
      – Joshua Robison
      Jun 7 '11 at 13:45










    • is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
      – antonio
      Oct 12 '13 at 11:27
















    5














    Introduction



    For a drive with PC partitions (which is what you'll find on most USB sticks), the bootloader consist in a tiny part at the very beginning of the drive (the stage 1 bootloader, in the boot sector of the drive) and a larger part elsewhere (the stage 2 bootloader, in a file). The stage 1 data contains the physical location of stage 2. If you copy the whole device (what you tried with dd), the stage 1 part is in the same physical location and the stick works, but the new stick has to be at least as large as the original. If you recreate the partitions and copy the files, you're missing the stage 1 since it's not a file.



    I think (but I haven't checked) that the stage 2 is in the first (FAT32) partition. If so, you can copy that partition wholesale, and copy the boot sector as well, then edit the partition table so that the second partition occupies exactly the space that's left, and copy the files on the second partition. You might as well keep a raw image of the boot sector and of the first partition in a file on a hard disk (but you can clone them from a USB stick too).



    Making a clone of a different size



    Below I'll call the device containing the original stick /dev/sdb and the device containing the clone /dev/sdc; substitute names as needed. Create mount points if needed. I assume that the FAT32 partition (at the beginning of the disk) is numbered 1 and the ext3 partition is numbered 2; substitute different numbers if needed.



    First part, if cloning from a stick:



    head -c 512 </dev/sdb >/dev/sdc
    partprobe /dev/sdc
    cat </dev/sdb1 >/dev/sdc1


    First part, if cloning from image files:



    cat boot_sector.img >/dev/sdc
    partprobe /dev/sdc
    cat first_partition.img >/dev/sdc1


    The call to partprobe is needed so that the kernel reloads the partition table from the disk (it's in the boot sector, and the first command in either scenario above modifies the boot sector). If you omit it, either you'll get errors or the kernel will silently write garbage to the stick.



    To make the image files:



    head -c 512 </dev/sdb >boot_sector.img 
    cat /dev/sdb1 >first_partition.img


    Now after you've got the boot sector and the first partition, you need to edit the partition table again, to resize the second partition. You can do this automatically by feeding the right input to fdisk. Warning, this is extremely error-prone, and I haven't tested it. If you don't feel completely comfortable with this part, do it by hand.



    sed -e 's/ *#.*//' <<EOF | tr -s ' ' 'n' | tr -d _ | fdisk /dev/sdc
    d 2 # delete partition 2
    n p 2 # new primary partition 2...
    _ _ # ... using all available space
    w q # write and quit
    EOF


    Finally reload the partition table again, create an ext3 filesystem, and copy the files there.



    partprobe /dev/sdc
    mke2fs -j /dev/sdc2
    mount /dev/sdc2 /media/sdc2
    cp -a /media/sdb2/ /media/sdc2/
    umount /media/sdc2


    Simplified method to make a larger clone



    If you prefer, you can store an image of the whole stick. You'll be able to use that image directly on any stick that's at least as large: just copy that image onto the new stick with cat <whole.img >/dev/sdc, then run partprobe /dev/sdc (or unplug the stick and put it back in) to re-read the partition table.



    Then, if you like, you can enlarge the clone. In this order:




    1. Enlarge the partition. Unfortunately, I don't know how to do this in a simple way. parted can do it with the move command (not resize, which resizes the filesystem), but you need to figure out the right arguments — switch to sectors (unit s) to avoid rounding errors.

    2. Enlarge the filesystem. That part is easy: just run resize2fs /dev/sdc2 to make the filesystem use the whole partition size.


    If you're starting from a larger stick than necessary, you can shrink it by following the steps above in the reverse order (first shrink the filesystem with resize2fs, then shrink the partition with parted).



    Alternatively, you can first copy the stick to an image file, then work on that image file. To access the partitions, use a loop device, specifically associating a portion of the file to a disk. Here's a sketch of the steps if you want to shrink the image (warning, untested, proceed carefully and double-check the math).



    fdisk -lu whole.img  # note starting sector of partition 2: $S
    losetup -fs -o $(($S * 512)) whole.img
    # Let $D be the desired size of partition 2, in kB
    resize2fs /dev/loop0 $ # replace /dev/loop0 by whatever losetup prints
    losetup -d /dev/loop0
    parted whole.img
    # Use parted to resize the second partition
    dd if=/dev/null of=/file/to/truncate seek=1 bs=$(($S/2+$D+1))k





    share|improve this answer























    • hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
      – Joshua Robison
      Jun 7 '11 at 11:35






    • 1




      @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
      – Gilles
      Jun 7 '11 at 13:02










    • hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
      – Joshua Robison
      Jun 7 '11 at 13:43










    • Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
      – Joshua Robison
      Jun 7 '11 at 13:45










    • is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
      – antonio
      Oct 12 '13 at 11:27














    5












    5








    5






    Introduction



    For a drive with PC partitions (which is what you'll find on most USB sticks), the bootloader consist in a tiny part at the very beginning of the drive (the stage 1 bootloader, in the boot sector of the drive) and a larger part elsewhere (the stage 2 bootloader, in a file). The stage 1 data contains the physical location of stage 2. If you copy the whole device (what you tried with dd), the stage 1 part is in the same physical location and the stick works, but the new stick has to be at least as large as the original. If you recreate the partitions and copy the files, you're missing the stage 1 since it's not a file.



    I think (but I haven't checked) that the stage 2 is in the first (FAT32) partition. If so, you can copy that partition wholesale, and copy the boot sector as well, then edit the partition table so that the second partition occupies exactly the space that's left, and copy the files on the second partition. You might as well keep a raw image of the boot sector and of the first partition in a file on a hard disk (but you can clone them from a USB stick too).



    Making a clone of a different size



    Below I'll call the device containing the original stick /dev/sdb and the device containing the clone /dev/sdc; substitute names as needed. Create mount points if needed. I assume that the FAT32 partition (at the beginning of the disk) is numbered 1 and the ext3 partition is numbered 2; substitute different numbers if needed.



    First part, if cloning from a stick:



    head -c 512 </dev/sdb >/dev/sdc
    partprobe /dev/sdc
    cat </dev/sdb1 >/dev/sdc1


    First part, if cloning from image files:



    cat boot_sector.img >/dev/sdc
    partprobe /dev/sdc
    cat first_partition.img >/dev/sdc1


    The call to partprobe is needed so that the kernel reloads the partition table from the disk (it's in the boot sector, and the first command in either scenario above modifies the boot sector). If you omit it, either you'll get errors or the kernel will silently write garbage to the stick.



    To make the image files:



    head -c 512 </dev/sdb >boot_sector.img 
    cat /dev/sdb1 >first_partition.img


    Now after you've got the boot sector and the first partition, you need to edit the partition table again, to resize the second partition. You can do this automatically by feeding the right input to fdisk. Warning, this is extremely error-prone, and I haven't tested it. If you don't feel completely comfortable with this part, do it by hand.



    sed -e 's/ *#.*//' <<EOF | tr -s ' ' 'n' | tr -d _ | fdisk /dev/sdc
    d 2 # delete partition 2
    n p 2 # new primary partition 2...
    _ _ # ... using all available space
    w q # write and quit
    EOF


    Finally reload the partition table again, create an ext3 filesystem, and copy the files there.



    partprobe /dev/sdc
    mke2fs -j /dev/sdc2
    mount /dev/sdc2 /media/sdc2
    cp -a /media/sdb2/ /media/sdc2/
    umount /media/sdc2


    Simplified method to make a larger clone



    If you prefer, you can store an image of the whole stick. You'll be able to use that image directly on any stick that's at least as large: just copy that image onto the new stick with cat <whole.img >/dev/sdc, then run partprobe /dev/sdc (or unplug the stick and put it back in) to re-read the partition table.



    Then, if you like, you can enlarge the clone. In this order:




    1. Enlarge the partition. Unfortunately, I don't know how to do this in a simple way. parted can do it with the move command (not resize, which resizes the filesystem), but you need to figure out the right arguments — switch to sectors (unit s) to avoid rounding errors.

    2. Enlarge the filesystem. That part is easy: just run resize2fs /dev/sdc2 to make the filesystem use the whole partition size.


    If you're starting from a larger stick than necessary, you can shrink it by following the steps above in the reverse order (first shrink the filesystem with resize2fs, then shrink the partition with parted).



    Alternatively, you can first copy the stick to an image file, then work on that image file. To access the partitions, use a loop device, specifically associating a portion of the file to a disk. Here's a sketch of the steps if you want to shrink the image (warning, untested, proceed carefully and double-check the math).



    fdisk -lu whole.img  # note starting sector of partition 2: $S
    losetup -fs -o $(($S * 512)) whole.img
    # Let $D be the desired size of partition 2, in kB
    resize2fs /dev/loop0 $ # replace /dev/loop0 by whatever losetup prints
    losetup -d /dev/loop0
    parted whole.img
    # Use parted to resize the second partition
    dd if=/dev/null of=/file/to/truncate seek=1 bs=$(($S/2+$D+1))k





    share|improve this answer














    Introduction



    For a drive with PC partitions (which is what you'll find on most USB sticks), the bootloader consist in a tiny part at the very beginning of the drive (the stage 1 bootloader, in the boot sector of the drive) and a larger part elsewhere (the stage 2 bootloader, in a file). The stage 1 data contains the physical location of stage 2. If you copy the whole device (what you tried with dd), the stage 1 part is in the same physical location and the stick works, but the new stick has to be at least as large as the original. If you recreate the partitions and copy the files, you're missing the stage 1 since it's not a file.



    I think (but I haven't checked) that the stage 2 is in the first (FAT32) partition. If so, you can copy that partition wholesale, and copy the boot sector as well, then edit the partition table so that the second partition occupies exactly the space that's left, and copy the files on the second partition. You might as well keep a raw image of the boot sector and of the first partition in a file on a hard disk (but you can clone them from a USB stick too).



    Making a clone of a different size



    Below I'll call the device containing the original stick /dev/sdb and the device containing the clone /dev/sdc; substitute names as needed. Create mount points if needed. I assume that the FAT32 partition (at the beginning of the disk) is numbered 1 and the ext3 partition is numbered 2; substitute different numbers if needed.



    First part, if cloning from a stick:



    head -c 512 </dev/sdb >/dev/sdc
    partprobe /dev/sdc
    cat </dev/sdb1 >/dev/sdc1


    First part, if cloning from image files:



    cat boot_sector.img >/dev/sdc
    partprobe /dev/sdc
    cat first_partition.img >/dev/sdc1


    The call to partprobe is needed so that the kernel reloads the partition table from the disk (it's in the boot sector, and the first command in either scenario above modifies the boot sector). If you omit it, either you'll get errors or the kernel will silently write garbage to the stick.



    To make the image files:



    head -c 512 </dev/sdb >boot_sector.img 
    cat /dev/sdb1 >first_partition.img


    Now after you've got the boot sector and the first partition, you need to edit the partition table again, to resize the second partition. You can do this automatically by feeding the right input to fdisk. Warning, this is extremely error-prone, and I haven't tested it. If you don't feel completely comfortable with this part, do it by hand.



    sed -e 's/ *#.*//' <<EOF | tr -s ' ' 'n' | tr -d _ | fdisk /dev/sdc
    d 2 # delete partition 2
    n p 2 # new primary partition 2...
    _ _ # ... using all available space
    w q # write and quit
    EOF


    Finally reload the partition table again, create an ext3 filesystem, and copy the files there.



    partprobe /dev/sdc
    mke2fs -j /dev/sdc2
    mount /dev/sdc2 /media/sdc2
    cp -a /media/sdb2/ /media/sdc2/
    umount /media/sdc2


    Simplified method to make a larger clone



    If you prefer, you can store an image of the whole stick. You'll be able to use that image directly on any stick that's at least as large: just copy that image onto the new stick with cat <whole.img >/dev/sdc, then run partprobe /dev/sdc (or unplug the stick and put it back in) to re-read the partition table.



    Then, if you like, you can enlarge the clone. In this order:




    1. Enlarge the partition. Unfortunately, I don't know how to do this in a simple way. parted can do it with the move command (not resize, which resizes the filesystem), but you need to figure out the right arguments — switch to sectors (unit s) to avoid rounding errors.

    2. Enlarge the filesystem. That part is easy: just run resize2fs /dev/sdc2 to make the filesystem use the whole partition size.


    If you're starting from a larger stick than necessary, you can shrink it by following the steps above in the reverse order (first shrink the filesystem with resize2fs, then shrink the partition with parted).



    Alternatively, you can first copy the stick to an image file, then work on that image file. To access the partitions, use a loop device, specifically associating a portion of the file to a disk. Here's a sketch of the steps if you want to shrink the image (warning, untested, proceed carefully and double-check the math).



    fdisk -lu whole.img  # note starting sector of partition 2: $S
    losetup -fs -o $(($S * 512)) whole.img
    # Let $D be the desired size of partition 2, in kB
    resize2fs /dev/loop0 $ # replace /dev/loop0 by whatever losetup prints
    losetup -d /dev/loop0
    parted whole.img
    # Use parted to resize the second partition
    dd if=/dev/null of=/file/to/truncate seek=1 bs=$(($S/2+$D+1))k






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 13 '17 at 12:36









    Community

    1




    1










    answered Jun 5 '11 at 23:07









    GillesGilles

    530k12810621589




    530k12810621589












    • hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
      – Joshua Robison
      Jun 7 '11 at 11:35






    • 1




      @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
      – Gilles
      Jun 7 '11 at 13:02










    • hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
      – Joshua Robison
      Jun 7 '11 at 13:43










    • Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
      – Joshua Robison
      Jun 7 '11 at 13:45










    • is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
      – antonio
      Oct 12 '13 at 11:27


















    • hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
      – Joshua Robison
      Jun 7 '11 at 11:35






    • 1




      @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
      – Gilles
      Jun 7 '11 at 13:02










    • hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
      – Joshua Robison
      Jun 7 '11 at 13:43










    • Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
      – Joshua Robison
      Jun 7 '11 at 13:45










    • is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
      – antonio
      Oct 12 '13 at 11:27
















    hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
    – Joshua Robison
    Jun 7 '11 at 11:35




    hmm. Can't I just use head to just copy the first 300mb or so of the second partition into an img file? Won't that cut off all the empty space/ empty blocks at the end of the file?
    – Joshua Robison
    Jun 7 '11 at 11:35




    1




    1




    @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
    – Gilles
    Jun 7 '11 at 13:02




    @Joshua: No, because there's no reason why all the file data would be in the first 300MB, and even if it was you can't just take part of a filesystem like that. You need to make a valid filesystem of the right size. You also need to have a partition of the correct size; the size of the partition is stored in the boot sector. If you prefer to start from a minimum-sized image and enlarge it if desired, I've added a way to do that in my answer.
    – Gilles
    Jun 7 '11 at 13:02












    hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
    – Joshua Robison
    Jun 7 '11 at 13:43




    hmm. I tried copying the files before but for some reason everything didn't copy. I tried rsync too with sudo. and I think I tried su root and did it too .... It's just not working for me. I'm sure the drives were not mounted... anyways. I decided to shrink the drive in gparted and then make img files from that and then restore them onto a smaller disk. Pre-shrinking in gparted was the only simple solution I could find. Thanks for your help though.
    – Joshua Robison
    Jun 7 '11 at 13:43












    Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
    – Joshua Robison
    Jun 7 '11 at 13:45




    Your answer is probably correct and will most likely do what I am asking. It's just too complicated for me. So I went with gparted pre shrink method.
    – Joshua Robison
    Jun 7 '11 at 13:45












    is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
    – antonio
    Oct 12 '13 at 11:27




    is there a typo in this line head -c 512 </dev/sdb >/bev/sdc?
    – antonio
    Oct 12 '13 at 11:27













    2















    ~$: sudo apt-get install gddrescue ddrescue



    ~$: ddrescue /dev/sda /dev/sdb -v




    ;



    Syntax: utility /source/drive /destination/drive --verbose



    Comment: shows progress and error checking so you know if it is acceptable or hanging up somewhere. You can also add b= whatever size blocks you want. "gddrescue" is gui based version of "ddrescue" but I only use the ddrescue as written above since it works without a problem.






    share|improve this answer



















    • 2




      Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
      – Paul Fischer
      Oct 5 '16 at 0:04
















    2















    ~$: sudo apt-get install gddrescue ddrescue



    ~$: ddrescue /dev/sda /dev/sdb -v




    ;



    Syntax: utility /source/drive /destination/drive --verbose



    Comment: shows progress and error checking so you know if it is acceptable or hanging up somewhere. You can also add b= whatever size blocks you want. "gddrescue" is gui based version of "ddrescue" but I only use the ddrescue as written above since it works without a problem.






    share|improve this answer



















    • 2




      Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
      – Paul Fischer
      Oct 5 '16 at 0:04














    2












    2








    2







    ~$: sudo apt-get install gddrescue ddrescue



    ~$: ddrescue /dev/sda /dev/sdb -v




    ;



    Syntax: utility /source/drive /destination/drive --verbose



    Comment: shows progress and error checking so you know if it is acceptable or hanging up somewhere. You can also add b= whatever size blocks you want. "gddrescue" is gui based version of "ddrescue" but I only use the ddrescue as written above since it works without a problem.






    share|improve this answer















    ~$: sudo apt-get install gddrescue ddrescue



    ~$: ddrescue /dev/sda /dev/sdb -v




    ;



    Syntax: utility /source/drive /destination/drive --verbose



    Comment: shows progress and error checking so you know if it is acceptable or hanging up somewhere. You can also add b= whatever size blocks you want. "gddrescue" is gui based version of "ddrescue" but I only use the ddrescue as written above since it works without a problem.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jun 16 '16 at 5:24

























    answered May 5 '16 at 6:16









    SierraJulietSierraJuliet

    492




    492








    • 2




      Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
      – Paul Fischer
      Oct 5 '16 at 0:04














    • 2




      Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
      – Paul Fischer
      Oct 5 '16 at 0:04








    2




    2




    Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
    – Paul Fischer
    Oct 5 '16 at 0:04




    Note that proper format is ddrescue -v /dev/sda /dev/sdb (options come first before the names of the devices/files). Thanks for pointing out this tool! Much easier than using dd!
    – Paul Fischer
    Oct 5 '16 at 0:04











    0














    I just wanted to give my two cents, maybe this'll help out anyone else who's looking for this topic or perhaps in a similar situation.



    So I had recently cloned my Kali live encrypted persistence from a 16GB to a 64GB 3.0 USB, My host OS is windows 10 pro. I hadn't attempted to clone using any Linux distro, I'm sure the answers above are what you need, but for any windows users; I had used AOMEI disk partition assistant. Super simple to use, used it for partitioning my SSD to fit Ubuntu, but I digress.



    I had to make sure that the USB I was cloning to had already been formatted for live booting. Plugged in both USB's and simply right clicked on the 8GB drive; clicked on copy then selected the 64GB drive, it'll ask you a bunch of things like "are you sure this is the right drive, everything will be erased" all that jazz. Just read through it and make sure everything is in order, you really don't have to do much.



    Just wait for the process to be finished and you're all set. Tested said USB and everything worked!



    I found this to be the easiest way at least for me, cloning live distros from USB to USB, Hope this helps anyone inquiring now or in the future!





    share


























      0














      I just wanted to give my two cents, maybe this'll help out anyone else who's looking for this topic or perhaps in a similar situation.



      So I had recently cloned my Kali live encrypted persistence from a 16GB to a 64GB 3.0 USB, My host OS is windows 10 pro. I hadn't attempted to clone using any Linux distro, I'm sure the answers above are what you need, but for any windows users; I had used AOMEI disk partition assistant. Super simple to use, used it for partitioning my SSD to fit Ubuntu, but I digress.



      I had to make sure that the USB I was cloning to had already been formatted for live booting. Plugged in both USB's and simply right clicked on the 8GB drive; clicked on copy then selected the 64GB drive, it'll ask you a bunch of things like "are you sure this is the right drive, everything will be erased" all that jazz. Just read through it and make sure everything is in order, you really don't have to do much.



      Just wait for the process to be finished and you're all set. Tested said USB and everything worked!



      I found this to be the easiest way at least for me, cloning live distros from USB to USB, Hope this helps anyone inquiring now or in the future!





      share
























        0












        0








        0






        I just wanted to give my two cents, maybe this'll help out anyone else who's looking for this topic or perhaps in a similar situation.



        So I had recently cloned my Kali live encrypted persistence from a 16GB to a 64GB 3.0 USB, My host OS is windows 10 pro. I hadn't attempted to clone using any Linux distro, I'm sure the answers above are what you need, but for any windows users; I had used AOMEI disk partition assistant. Super simple to use, used it for partitioning my SSD to fit Ubuntu, but I digress.



        I had to make sure that the USB I was cloning to had already been formatted for live booting. Plugged in both USB's and simply right clicked on the 8GB drive; clicked on copy then selected the 64GB drive, it'll ask you a bunch of things like "are you sure this is the right drive, everything will be erased" all that jazz. Just read through it and make sure everything is in order, you really don't have to do much.



        Just wait for the process to be finished and you're all set. Tested said USB and everything worked!



        I found this to be the easiest way at least for me, cloning live distros from USB to USB, Hope this helps anyone inquiring now or in the future!





        share












        I just wanted to give my two cents, maybe this'll help out anyone else who's looking for this topic or perhaps in a similar situation.



        So I had recently cloned my Kali live encrypted persistence from a 16GB to a 64GB 3.0 USB, My host OS is windows 10 pro. I hadn't attempted to clone using any Linux distro, I'm sure the answers above are what you need, but for any windows users; I had used AOMEI disk partition assistant. Super simple to use, used it for partitioning my SSD to fit Ubuntu, but I digress.



        I had to make sure that the USB I was cloning to had already been formatted for live booting. Plugged in both USB's and simply right clicked on the 8GB drive; clicked on copy then selected the 64GB drive, it'll ask you a bunch of things like "are you sure this is the right drive, everything will be erased" all that jazz. Just read through it and make sure everything is in order, you really don't have to do much.



        Just wait for the process to be finished and you're all set. Tested said USB and everything worked!



        I found this to be the easiest way at least for me, cloning live distros from USB to USB, Hope this helps anyone inquiring now or in the future!






        share











        share


        share










        answered 4 mins ago









        ImNewHereImNewHere

        1




        1






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f14435%2fcloning-a-bootable-usb-stick-to-a-different-sized-stick%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            CARDNET

            Boot-repair Failure: Unable to locate package grub-common:i386

            濃尾地震