Can A Bootable Usb Be Used For Storage
Kenneth
I have a 16gb flash drive, which I want a live ISO to boot from (via unetbootin or something similar). It'll be some 32bit distro that I can plug-in and boot on whatever computer I need to. Since it will be a live ISO, I'll need somewhere to save data. I want the USB drive to have about 1gb for the distro, and the other 15gb for data storage.
How can I make the data accessible on Windows, and still have a bootable distribution? If the answer is how to partition it, please include the order and type of each partition. Do I need swap space for this, or is this handled differently?
Using a graphical partition editor (Like Disk Utility on a Mac or GParted) simply make two FAT32 partitions and use the first one as your Windows-readable partition (as Windows only reads the first partition on a disk) and then use the second partition as your bootable startup disk (as the BIOS recognizes both partitions and knows which to boot from).
1) Partition the drive (I used GParted) in 2 partitions with the SECOND partition being large enough to hold your operating system. My drive was a 2gb Flash Drive so I created a 500Mb Partition 1 and the remainder as Partition2.
Create First partition for Data storage with file system as NTFS because FAT32 does not support individual file not more than 4GB. Second partition as FAT32 and make it bootable. Windows always recognizes first partition, so it can read contents from first partition and boots from 2nd partition.
DummyDisk or DiskMod to recognise as Fixed Disk then Partition the "USB Drive" and Format the partition with the Bootable ISO and the other partitions are reserved as storage. (That's what I think anyway.)
Create the bootable disk, then go to windows disk management (Create and format hard disk partitions), find the unmountable weird persistant storage partition on your USB drive that rufus made, delete it, and then recreate it as a normal NTFS partition.
I know I could use diskpart and xcopy to do something similar in the pre-boot menus, but I will have to walk a remote user through the process of doing this and would rather have something with a GUI that I can provide instructions for.
Disk cloning software can be used to create an exact copy of your disk, and copy all data from the source disk to the target disk, including files, disk layout, configurations, etc. This post will introduce 12 free disk cloning software that helps...
I would have to cast my vote to Acronis Cyber Protect Home Business Premium and if you can get your hands on Acronis TI. I have made 2 USB boot drive one for Windows and one for Linux covers both for booting and cloning drives, adding drives and other utilities. Have used them for years very reliable and quick. I even still have a couple of bootable DVD drives with Acronis TI, they work great.
A boot disk is a removable digital data storage medium from which a computer can load and run (boot) an operating system or utility program.[1] The computer must have a built-in program which will load and execute a program from a boot disk meeting certain standards.
While almost all modern computers can boot from a hard drive containing the operating system and other software, they would not normally be called boot disks (because they are not removable media). Fixed drives (such as hard drive)s that are bootable may be called boot drives. CD-ROMs are the most common forms of media used, but other media, such as magnetic or paper tape drives, ZIP drives, and more recently USB flash drives can be used. The computer's BIOS must support booting from the device in question.
The term boot comes from the idea of lifting oneself by one's own bootstraps:[5] the computer contains a tiny program (bootstrap loader) which will load and run a program found on a boot device. This program may itself be a small program designed to load a larger and more capable program, i.e., the full operating system. To enable booting without the requirement either for a mass storage device or to write to the boot medium, it is usual for the boot program to use some system RAM as a RAM disk for temporary file storage.
As an example, any computer compatible with the IBM PC is able with built-in software to load the contents of the first 512 bytes of a floppy and to execute it if it is a viable program; boot floppies have a very simple loader program in these bytes. The process is vulnerable to abuse; data floppies could have a virus written to their first sector which silently infects the host computer if switched on with the disk in the drive.
Bootable floppy disks ("boot floppies") for PCs usually contain DOS or miniature versions of Linux. The most commonly available floppy disk can hold only 1.4 MB of data in its standard format, making it impractical for loading large operating systems. The use of boot floppies is in decline, due to the availability of other higher-capacity options, such as CD-ROMs or USB flash drives.
There's been a number of questions regarding disk cloning tools and dd has been suggested at least once. I've already considered using dd myself, mainly because ease of use, and that it's readily available on pretty much all bootable Linux distributions.
What is the best way to use dd for cloning a disk? I did a quick Google search, and the first result was an apparent failed attempt. Is there anything I need to do after using dd, i.e. is there anything that CAN'T be read using dd?
Be aware that while cloning every byte, you should not use this on a drive or partition that is being used. Especially applications like databases can't cope with this very well and you might end up with corrupted data.
CAUTION: dd'ing a live filesystem can corrupt files. The reason is simple, it has no understanding of the filesystem activity that may be going on, and makes no attempt to mitigate it. If a write is partially underway, you will get a partial write. This is usually not good for things, and generally fatal for databases. Moreover, if you screw up the typo-prone if and of parameters, woe unto you. In most cases, rsync is an equally effective tool written after the advent of multitasking, and will provide consistent views of individual files.
However, DD should accurately capture the bit state of an unmounted drive. Bootloaders, llvm volumes, partition UUIDs and labels, etc. Just make sure that you have a drive capable of mirroring the target drive bit for bit.
When using dd to clone a disk which may contain bad sectors, use conv=noerror,sync to ensure that it doesn't stop when it encounters an error, and fills in the missing sector(s) with null bytes. This is usually the first step I take if trying to recover from a failed or failing disk - get a copy before doing any recovery attempts, and then do recovery on the good (cloned) disk. I leave it to the recovery tool to cope with any blank sectors that couldn't be copied.
Also, you may find dd's speed can be affected by the bs (block size) setting. I usually try bs=32768, but you might like to test it on your own systems to see what works the fastest for you. (This assumes that you don't need to use a specific block size for another reason, e.g. if you're writing to a tape.)
Of course, make sure that you have proper permissions to read directly from /dev/hdb (I'd recommend running as root), and that /dev/hdb isn't mounted (you don't want to copy while the disk is being changed - mounting as read-only is also acceptable). Once complete, image.img will be a byte-for-byte clone of the entire disk.
There are a few drawbacks to using dd to clone disks. First, dd will copy your entire disk, even empty space, and if done on a large disk can result in an extremely large image file. Second, dd provides absolutely no progress indications, which can be frustrating because the copy takes a long time. Third, if you copy this image to other drives (again, using dd), they must be as large or larger than the original disk, yet you won't be able to use any additional space you may have on the target disk until you resize your partitions.
As far as issues or gotchas go, dd, for the most part, does an excellent job. However, a while ago I had a hard drive that was about to die, so I used dd to try and copy what information I could off it before it died completely. It was then learned that dd doesn't handle read errors very well - there were several sectors on the disk that dd couldn't read, causing dd to give up and stop the copy. At the time I couldn't find a way to tell dd to continue despite encountering a read error (though it appears as though it does have that setting), so I spent quite a bit of time manually specifying skip and seek to hop over the unreadable sections.
I spent some time researching solutions to this problem (after I had completed the task) and I found a program called ddrescue, which, according to the site, operates like dd but continues reading even if it encounters an error. I've never actually used the program, but it's worth considering, especially if the disk you're copying from is old, which can have bad sectors even if the system appears fine.
The reason behind this is that, on read errors, dd keeps trying and trying and trying - potentially waiting for a long time for timeouts to occur. dd_rescue does smart things like reading up to an error, then picking a spot further on on the disk and reading backwards to the last error, and dd_rhelp is basically a dd_rescue session manager - cleverly starting and resuming dd_rescue runs to make it quicker again.
The end result of dd_rhelp is maximum data recovered in minimum time. If you leave dd_rhelp running, in the end it does the exact same job as dd in the same time. However, if dd encountered read errors at byte 100 of your 100Gb disk, you'd have to wait a long time to recover the other 9,999,900 bytes*, whereas dd_rhelp+dd_rescue would recover the bulk of the data much faster.
Note that depending on the size of disk, speed of cpu on source, speed of cpu on destination, speed of network, etc. You may want to skip compression, or do the compression on the remote side, or enable ssh's compression.
e59dfda104