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:

+

+

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:

+

+

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

+

+

# 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?

However, I already downloaded the IMG file and don't want to waste time. Then:

+

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

−

sfdisk -l -uS /path/to/img

+

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

−

outputs:

+

* 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)

−

?

+

== flush file system buffers after dd ==

−

Note the starting sector of the first partition (63, in this example). Then:

+

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?

−

dd if=/path/to/img of=arch.img skip=63

+

== Rationale for block size ==

−

Now, I can mount the .img file without issue:

+

Why specifically ''bs=4M'' in the [[USB_Installation_Media#Overwrite_the_USB_drive|example]]:

: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)

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:

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.

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?

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

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)