Difference between revisions of "Talk:USB flash installation media"

From ArchWiki
Jump to: navigation, search
(Gentoo Linux LiveUSB HOWTO)
(UNetbootin should be removed)
(34 intermediate revisions by 10 users not shown)
Line 1: Line 1:
== unetbootin ==
 
I was unable to get my usb drive bootable with the steps provided. I ended up using UNetbootin, a small application which made my USB drive bootable without a charm. The application doesn't require any installation procedure.
 
 
--[[User:Serpent|Serpent]] 04:22, 25 March 2009 (EDT)
 
 
== General ==
 
I was not able to boot my Thinkpad X31 from USB stick without the lilo part first.
 
I understood it like that: syslinux puts a bootloader at the beginning of the first partition, but nothing in the MBR, so when you try booting from the stick, the bootloader cannot be found.
 
-anonymous
 
 
Shouldn't the info that you need to select boot from usbdisk in BIOS be selected for this to work be mentioned? Or isn't it needed to be able to boot from an usb disk? If it's needed perhaps one could get grub  and/or lilo to bootup an usb disk if the BIOS didn't support it and so how one would do that would also be needed as information.
 
-nut543
 
 
What about merging this article with [[Usb Drive Arch Install]]?
 
-Thujone
 
 
== Does not work anymore... ==
 
 
I was unable to run the new "live" arch-core-install-2008.04-rc-i686.iso off the USB stick.  I've copied the kernel, initrd, and .squashfs files to the stick, and added a minimal entry in syslinux.cfg.  Kernel + initrd boot fine, I even saw that the USB disk is detected, partitions parsed, and /dev/ entries created, but then init halts with something like 'unable to find /dev/cd/*'.  I've spent few minutes reading the initialisation code, but didn't find a kernel commandline option to override it.  I'm sure there is some easy way to make it work, but the process of mounting the CD-ROM should probably be implemented in a more robust way, so the initrd code finds and mounts the compressed filesystem even when booting from USB HDD.
 
  
 
== Verifying the USB ==
 
== Verifying the USB ==
Line 40: Line 21:
 
--[[User:Liquen|Liquen]] 14:55, 4 April 2009 (EDT)
 
--[[User:Liquen|Liquen]] 14:55, 4 April 2009 (EDT)
  
== But I don't want to overwrite the entire USB stick... ==
+
== About making the installation media without overwriting ==
 +
 
 +
I'm not totally sure if I misunderstood something, but I had to change the path of the entries of the *.cfg files. For instance:
 +
 
 +
INCLUDE boot/syslinux/archiso_sys.cfg
 +
 
 +
became:
 +
 +
INCLUDE syslinux/archiso_sys.cfg
 +
 
 +
It was the only way it worked with the unofficial ISO x86_64 image of march 13th, 2012. Looks like the syslinux command described in the page doesn't get the path as it should.
 +
 
 +
I edited all of the .cfg files, but probably only editing this ones should have been enough:
  
''I'll add this into the article soonish; recording here for reference.''
+
archiso.cfg
 +
archiso_head.cfg
 +
archiso_sys_inc.cfg
  
So you don't have to. The easier way is to download the ISO image, mount, then copy and install GRUB manually (a la "old method").
+
I hope it could be useful to somebody, because I spend some time with this (I even thought that was a problem with the hardware). I think it could be possible to make a simple script (or give some command lines) to patch the files once they are copied into the USB and run syslinux.
  
However, I already downloaded the IMG file and don't want to waste time. Then:
+
Thanks !!
  
sfdisk -l -uS /path/to/img
+
== Recovering the USB drive afterwards ==
  
outputs:
+
This didn't work for me:
  
?
+
# dd count=1 bs=512 if=/dev/zero of=/dev/sdx
  
Note the starting sector of the first partition (63, in this example). Then:
+
I tried this multiple times. No matter how I formatted the disk, 'devmon' always mounted '/dev/sdd' as /media/ARCH_whatever.
  
dd if=/path/to/img of=arch.img skip=63
+
I finally just zeroed as much of the disk as I thought the ISO might have been written to.
  
Now, I can mount the .img file without issue:
+
# dd count=100 bs=4M if=/dev/zero of=/dev/sdx; sync
  
mount -o loop arch.img /mnt/usb/
+
That worked. I believe we need to zero MORE than just the initial 512 bytes, but I have no idea how much. Maybe 2048?
  
== Remove Unetbootin ==
+
At any rate, put '; sync' in there somewhere.
  
Can we remove the Unetbootin paragraph? AFAIK, unetbootin has not been working with arch isos for a long time. [[User:Serpent|Serpent]] reported above to have made an install with it in May 2009, but I suspect he used an archboot image (which still works with unetbootin).  
+
This is what I did eventually, taking a tip from:
In my experience, the kernel boots fine but it somehow fails to mount the usb drive and therefore can't load the fs overlay stuff. Often people also report on bbs that they tried Unetbootin without luck. Just tried with the new 2010.05 isos, same problem.
+
[http://www.patriotmemory.com/forums/showthread.php?3696-HOWTO-Increase-write-speed-by-aligning-FAT32]
If someone else can confirm this, I suggest removing Unetbootin altogether since it only adds confusion.
+
  
Similary, is the third option (Gujin) still working? [[User:Hokasch|Hokasch]] 07:04, 18 May 2010 (EDT)
+
# dd count=100 bs=4M if=/dev/zero of=/dev/sdx; sync
 +
# fdisk -H 224 -S 56 /dev/sdx
  
: Ahh, understood why it is failing and updated the instructions. Still unsure if it wouldn't be better to remove it. [https://bugs.launchpad.net/unetbootin/+bug/582213 Bug report] [[User:Hokasch|Hokasch]] 07:33, 18 May 2010 (EDT)
+
(new partition, primary, 1, 2048, whatever, type of partition, c (fat32 LBA), x, beginning data sector, 256, write)
  
== Universal USB Installer ==
+
# mkfs.vfat -F 32 -n volume_label -s 32 -v /dev/sdx1; sync
  
This method works fine for me though I got a little stuck when Arch tried to get at the boot device and couldn't find it. Turns out UUSBI's default trick is to label your device "PENDRIVE" if it formats it during the process (user-selectable). I'd like to add a note about this to the section on this page which covers the tool, but as it'd be my first change here I want to be sure I'm not going to be shouted at...
+
See the link for more details on the beginning data sector.
  
[[User:Xyon|Xyon]] 09:57, 9 November 2011 (EST)
+
* Um, zeroing out the first 512 bytes is fine for MBR-formatted drives. Were you using GPT? Because then you would need to zero out the first 512+512+16k, and the last 16k+512. See [[GPT]]. But assuming you used {{ic|dd}}, we're talking about MBR-formatted because the ISO contains a MBR (hybrid) partition table.--[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 06:25, 8 September 2012 (UTC)
:Hi and welcome! I've moved your discussion at the bottom of the page according to [[Help:Style#Discussion pages]].
+
:Yes you can add such a note, just always remember to explain your edits in the Summary field. For more style guidelines see [[Help:Style]].
+
:-- [[User:Kynikos|Kynikos]] 06:41, 10 November 2011 (EST)
+
  
== Gentoo Linux LiveUSB HOWTO ==
+
== flush file system buffers after dd ==
  
try this
+
I found that after using dd to write the data to my USB I had to wait for the file system to actually write it to my drive. (as dd completed and returned its stats)
 +
This could cause confusion, should we add 'sync' after the dd command on the artical?
  
http://www.gentoo.org/doc/en/liveusb.xml
+
== Rationale for block size ==
  
and replace (if you on arch)
+
Why specifically ''bs=4M'' in the [[USB_Installation_Media#Overwrite_the_USB_drive|example]]:
 +
[[USB_Installation_Media#Overwrite_the_USB_drive|# dd '''bs=4M''' if=/path/to/archlinux.iso of=/dev/sdx]]
 +
[[User:NoobCp|NoobCp]] ([[User talk:NoobCp|talk]]) 11:08, 20 December 2012 (UTC)
  
dd if=/usr/share/syslinux/mbr.bin of=/dev/sdc
+
:Because it speeds up the process, that's why. I guess somebody decided that one warning, two notes and a tip would be too rainbow-like. See [https://wiki.archlinux.org/index.php?title=USB_Installation_Media&oldid=218405 this] older edit (which references [http://sprunge.us/SGIY this] script). I reduces the time it needs almost by half. --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 12:17, 4 February 2013 (UTC)
  
to
+
==<s>UNetbootin should be removed</s>==
  
dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdc
+
I think UNetbootin should be removed. It was just added more information that basically tells you to use something else. This program is way too intrusive. It installs its own version of the bootloader, a crappy syslinux.cfg, and doesn't give a shit about labels. Unetbootin is totally NOT recommended for Arch Linux and it should be removed from the wiki. --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 11:20, 16 September 2012 (UTC)
 +
:Thanks. Good riddance! But, perhaps we should keep the warning? Or just refer them to this discussion page. --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 06:01, 17 September 2012 (UTC)
 +
:: This is not the first time UNetbootin info is added and then removed (sadly by me.). Search the history you will find the same topic show up long time ago. If it is broken, we'd better clearly tell  people it is broken. And it can prevent it from being recommended again. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 10:30, 17 September 2012 (UTC)
 +
:::Yes, please don't take example from what [[User:Danielwallace]] did; content should never be removed without at least a valid explanation in the edit summary, and anyway, in this case UNetbootin must be mentioned, even only as an non-recommended, discouraged alternative in a Warning: following the philosophy of the ArchWiki and Arch Linux in general, no available option must be hidden to the users, who are the only ones who can choose what's best for themselves in the end. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:22, 17 September 2012 (UTC)
 +
:::: Deletion reverted. Close. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 12:09, 24 September 2012 (UTC)
 +
:::::Reopening as the section has been restored. My opinion is unchanged. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:16, 20 April 2013 (UTC)
 +
::::::I'm sorry for re-opening the section but it was my first time that I wrote on this wiki. I know that UNetbooting overwrite the syslinux.cfg, infact my guide is to edit that file to permit the boot of the installation media. So I think you could remove the disclaimer. [[User:Mathias|Mathias]] ([[User talk:Mathias|talk]]) 14:44, 21 April 2013 (UTC)
 +
:::::::Lol, silly me, I added the disclaimer back without re-reading the section just because I remembered this has been the cause of some edit warring in the past, sorry... Of course you're right, however I've merged the disclaimer into the introduction paragraph in order to try to prevent future disputes. Closed (again). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:57, 22 April 2013 (UTC)
 +
::::::::It appears to me that there has been an increase in the number of new users attempting to use unetbootin (and failing) since this section was changed. I think this tool should be more strongly discuraged. There really is no reason to use it, even with the syslinux warning. I'd like to at least amplify the warning about using another tool, and ideally return the original warning from DSpider (Do Not Use UNETBOOTIN). [[User:2ManyDogs|2ManyDogs]] ([[User talk:2ManyDogs|talk]]) 19:59, 13 June 2013 (UTC)

Revision as of 19:59, 13 June 2013

Verifying the USB

Before and after having performed the dd onto the USB disk, check that the md5sums are correct. For example:

- $ md5sum archlinux-2008.06-core-x86_64.img && echo && cat md5sums.x86_64

The next command will give similar results, but will also let you confirm that the data was written correctly and can be read correctly:

- dd if=/dev/sdb count=661159 status=noxfer | md5sum && echo && cat md5sums.x86_64

--Zatricky 06:45, 22 January 2009 (EST)

dd for Windows

There is also dd for Windows. I tried it and it works perfectly: [1]

 dd if=file.img of=\\.\e:

where e: is your USB drive letter.

--Liquen 14:55, 4 April 2009 (EDT)

About making the installation media without overwriting

I'm not totally sure if I misunderstood something, but I had to change the path of the entries of the *.cfg files. For instance:

INCLUDE boot/syslinux/archiso_sys.cfg

became:

INCLUDE syslinux/archiso_sys.cfg

It was the only way it worked with the unofficial ISO x86_64 image of march 13th, 2012. Looks like the syslinux command described in the page doesn't get the path as it should.

I edited all of the .cfg files, but probably only editing this ones should have been enough:

archiso.cfg archiso_head.cfg archiso_sys_inc.cfg

I hope it could be useful to somebody, because I spend some time with this (I even thought that was a problem with the hardware). I think it could be possible to make a simple script (or give some command lines) to patch the files once they are copied into the USB and run syslinux.

Thanks !!

Recovering the USB drive afterwards

This didn't work for me:

  1. dd count=1 bs=512 if=/dev/zero of=/dev/sdx

I tried this multiple times. No matter how I formatted the disk, 'devmon' always mounted '/dev/sdd' as /media/ARCH_whatever.

I finally just zeroed as much of the disk as I thought the ISO might have been written to.

  1. dd count=100 bs=4M if=/dev/zero of=/dev/sdx; sync

That worked. I believe we need to zero MORE than just the initial 512 bytes, but I have no idea how much. Maybe 2048?

At any rate, put '; sync' in there somewhere.

This is what I did eventually, taking a tip from: [2]

  1. dd count=100 bs=4M if=/dev/zero of=/dev/sdx; sync
  2. fdisk -H 224 -S 56 /dev/sdx

(new partition, primary, 1, 2048, whatever, type of partition, c (fat32 LBA), x, beginning data sector, 256, write)

  1. mkfs.vfat -F 32 -n volume_label -s 32 -v /dev/sdx1; sync

See the link for more details on the beginning data sector.

  • Um, zeroing out the first 512 bytes is fine for MBR-formatted drives. Were you using GPT? Because then you would need to zero out the first 512+512+16k, and the last 16k+512. See GPT. But assuming you used dd, we're talking about MBR-formatted because the ISO contains a MBR (hybrid) partition table.--DSpider (talk) 06:25, 8 September 2012 (UTC)

flush file system buffers after dd

I found that after using dd to write the data to my USB I had to wait for the file system to actually write it to my drive. (as dd completed and returned its stats) This could cause confusion, should we add 'sync' after the dd command on the artical?

Rationale for block size

Why specifically bs=4M in the example:

# dd bs=4M if=/path/to/archlinux.iso of=/dev/sdx

NoobCp (talk) 11:08, 20 December 2012 (UTC)

Because it speeds up the process, that's why. I guess somebody decided that one warning, two notes and a tip would be too rainbow-like. See this older edit (which references this script). I reduces the time it needs almost by half. --DSpider (talk) 12:17, 4 February 2013 (UTC)

UNetbootin should be removed

I think UNetbootin should be removed. It was just added more information that basically tells you to use something else. This program is way too intrusive. It installs its own version of the bootloader, a crappy syslinux.cfg, and doesn't give a shit about labels. Unetbootin is totally NOT recommended for Arch Linux and it should be removed from the wiki. --DSpider (talk) 11:20, 16 September 2012 (UTC)

Thanks. Good riddance! But, perhaps we should keep the warning? Or just refer them to this discussion page. --DSpider (talk) 06:01, 17 September 2012 (UTC)
This is not the first time UNetbootin info is added and then removed (sadly by me.). Search the history you will find the same topic show up long time ago. If it is broken, we'd better clearly tell people it is broken. And it can prevent it from being recommended again. -- Fengchao (talk) 10:30, 17 September 2012 (UTC)
Yes, please don't take example from what User:Danielwallace did; content should never be removed without at least a valid explanation in the edit summary, and anyway, in this case UNetbootin must be mentioned, even only as an non-recommended, discouraged alternative in a Warning: following the philosophy of the ArchWiki and Arch Linux in general, no available option must be hidden to the users, who are the only ones who can choose what's best for themselves in the end. -- Kynikos (talk) 13:22, 17 September 2012 (UTC)
Deletion reverted. Close. -- Fengchao (talk) 12:09, 24 September 2012 (UTC)
Reopening as the section has been restored. My opinion is unchanged. -- Kynikos (talk) 07:16, 20 April 2013 (UTC)
I'm sorry for re-opening the section but it was my first time that I wrote on this wiki. I know that UNetbooting overwrite the syslinux.cfg, infact my guide is to edit that file to permit the boot of the installation media. So I think you could remove the disclaimer. Mathias (talk) 14:44, 21 April 2013 (UTC)
Lol, silly me, I added the disclaimer back without re-reading the section just because I remembered this has been the cause of some edit warring in the past, sorry... Of course you're right, however I've merged the disclaimer into the introduction paragraph in order to try to prevent future disputes. Closed (again). -- Kynikos (talk) 10:57, 22 April 2013 (UTC)
It appears to me that there has been an increase in the number of new users attempting to use unetbootin (and failing) since this section was changed. I think this tool should be more strongly discuraged. There really is no reason to use it, even with the syslinux warning. I'd like to at least amplify the warning about using another tool, and ideally return the original warning from DSpider (Do Not Use UNETBOOTIN). 2ManyDogs (talk) 19:59, 13 June 2013 (UTC)