I am assuming this is straightforward. I used to easily do this in Ubuntu.
I have a distro I want to try out on a USB stick.
I would also like to make it persistent also?
On Sun 30 Nov 2014 01:06:01 AM CST, homebrewdude wrote:
I am assuming this is straightforward. I used to easily do this in
Ubuntu.
I have a distro I want to try out on a USB stick.
I would also like to make it persistent also?
Hi
If it’s openSUSE or from SUSE Studio, then imagewriter, else probably
unetbootin.
I see it’s in the filesystems repo and built for 13.2, but not
published;
https://build.opensuse.org/package/show?project=filesystems&package=unetbootin
You would need to contact the repo maintainers;
https://build.opensuse.org/package/users/filesystems/unetbootin
First user at the top, hover over email icon on the right and send them
a personal email, shouldn’t take long to sort.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
On 2014-11-30 02:06, homebrewdude wrote:
> I have a distro I want to try out on a USB stick.
> I would also like to make it persistent also?
Read the instructions of that other distro you wish to try.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I use Imagewriter
And it works obviously with openSUSE but also with images from Ubuntu, Mint, Fedora
It’s also much quicker than the default software now supplied in the likes of Ubuntu
I typically use “dd_rescue” at the command line. This does require installing “dd_rescue”.
# ls -ldt /dev/sd? ### the last line should be the most recently plugged in device
# fdisk -l /dev/sdX
# dd_rescue iso-file /dev/sdX
(Change the “X” as appropriate. The “fdisk” is just a cross check to be sure that I have the correct device.)
This seems to work with most of the distros that I have tried, including those that give different instructions. So I ignore the instructions and try this first. Only if it doesn’t work, do I follow the instructions.
As best I can recall, the only time it didn’t work was with an iso intended to reflash the BIOS. That was creating a DOS executable. So, instead, I followed the instructions and used “rufus” (on Windows) for that one.
On 2014-11-30 07:06, nrickert wrote:
>
> I typically use “dd_rescue” at the command line. This does require
> installing “dd_rescue”.
If the intention is to copy an image file to the destination raw device,
unmodified, there are many tools. But some distributions require you do
some manipulations, because the image itself does not boot as is from a
usb stick.
And to copy an image the easiest CLI thing is, well, can you imagine,
the copy command! 
cp iso-file /dev/sdX
no need for fancy concoctions. Yes, we have said many times to use dd or
similar, but a plain ‘cp’ does it just fine, and it is also a fully
correct tool.
However, if you use “dd” you can use speed tricks.
One thing that people comment is that the computer becomes unresponsive
while copying the image to the usb stick. The reason is that the kernel
caches as much as it can from the copy process before actually writing
to the slow writing destination, which “removes” memory from being used
as cache/buffers for other processes, which then have to wait for the
physical i/o to happen.
This caching of slow devices is wonderful with reasonably sized files,
because the system is faster, overall. But when you write a 5 gigabyte
file, and your memory is “only” 8 gigabytes, you have problems.
‘dd’ does have switches to work around this.
dsync use synchronized I/O for data
nocache
discard cached data
direct use direct I/O for data
dsync writes asap, leaves a copy in cache.
Not useful for the intended purpose.
nocache first caches, then flushes.
Perhaps useful, to avoid filling the cache.
But not if the cache is emptied after dd finishes.
direct uses no cache. Machine is responsive
full time, but the copy /might/ go slower.
There is also the idea that memory control groups could be used to limit
the ammount of cache memory used by the CG, but I have no idea how to
try this out.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I have always used the procedure from openSUSE
https://en.opensuse.org/SDB:Live_USB_stick
You could use a GUI like ImageWriter if you prefer, but executing a simple dd command is so easy.
dd if=/path/to/downloaded.iso of=/dev/sdX bs=4M