You are not logged in.
Hi I have read the wiki
http://wiki.archlinux.org/index.php/Put … _a_USB_key
And I have tried the unetbotin and dd methods. I execute
sudo dd if=~/Various\ images/archlinux-2009.08-core-i686.img of=/dev/sdb
This dd method will boot in qemu perfectly but not on the computer. The BIOS is right. When I try to use unetbootin to use the .iso file the computer boots but fails when waiting for the root device /dev/arch/whatever. I can't seem to fix this. When I use the .img. The initrd image file just spurts out LOADS of dots. In qemu it says I don't have enough RAM to load and on the other computer it just goes on forever.
I read the help USB install file in qemu but where is kernel-parameters.txt? Where should I create it?When I use dd the computer looks like it tries but can't. A little dash on the left travels down the screen to about halfway, then it boots into windows 7.
Please help because I just want this to work. The computer is an ASUS netbook UL20A series if that helps.
Thanks in advance.
Offline
Did you clean the usb stick before issueing the dd command?
The .iso files won't work because they don't support usb as root device.
a little ot:
As fas as the dd command goes you don't need sudo and i'd feel more comfortable first cding to the directory where you stored the image instead of using a relative path with spaces in the name.
no place like /home
github
Offline
a little ot:
As fas as the dd command goes you don't need sudo and i'd feel more comfortable first cding to the directory where you stored the image instead of using a relative path with spaces in the name.
Are you sure? If you dont need sudo you system is screwed.. So an user can use dd to destroy all the data on your disks...
@OP Try the test builds http://build.archlinux.org/isos/
Offline
Well I did run mkfs.vfat -I on disk and I have run mkfs.msdos -I. I have to run these things as root or I don't have permision to do anything to /dev/sdb. Is this wrong?
bash: /dev/sdb: Permission denied
should I chmod 0777on it? How should I clean it and should it have partitions on it. And if qemu can boot from qemu /dev/sdb then why can't A computer boot from it.
Thank you.
Offline
Use fdisk and create a new partition table.
@kazuo:
I was surprised too but I'm pretty sure i used dd without sudo when copying the arch image to an usb stick.
Of course i might be wrong or it doesn't apply to all devices. Maybe because my user is in the group storage?
I'd test it in my virtualbox but I'm so tired.
Last edited by demian (2010-05-14 19:29:31)
no place like /home
github
Offline
OK. I will try chmod 0777 /dev/sdb
Offline
Oh I see if I don't need to use sudo my system is screwed. Right but I suppose I can just chmod it back.
EDIT: @demian I used cfdisk to make a single VFAT partition then just dd and it boots in qemu but I don't have the computer to try it on.
Last edited by bananaoomarang (2010-05-14 19:34:38)
Offline
Why would partitions or filesystems make any difference, if you are going to low-level copy an image onto the media with dd anyway? You could fill it with zeros before if you liked...
bananaoomarang, don't screw with /dev/sdb's permission, just use "sudo dd" and it will be fine. The testing build isos can be copied over with dd, unlike the old 2009 ones.
If you have no luck with the tesing builds either, you can still try the unofficial "archboot" - images (search the announcement forum).
Last edited by hokasch (2010-05-14 20:25:34)
Offline
OK thanks for the nice straight foward answer. I will try tommorow.
Offline
I now see that the 'testing builds' are no longer in testinga nd have used dd accordingly however it still does not boot from it and using unetbootin causes a ramfs prompt again. I will try the archboot images soon. In the mean time, any ideas?
EDIT: hey how come all the important tools such as space invaders are no longer on the disk. Booting into space invaders from an arch disk was brilliant.
Last edited by bananaoomarang (2010-05-18 19:38:45)
Offline
I now see that the 'testing builds' are no longer in testinga nd have used dd accordingly however it still does not boot from it and using unetbootin causes a ramfs prompt again. I will try the archboot images soon. In the mean time, any ideas?
If you use unetbootin, you need to make sure the file system label of the stick matches the label in syslinux.cfg (archisolabel=).
Why dd wouldn't work, I have no idea.
Offline
It works now with unetbootin + new images and changing the name with mkfs.xxx -I -n <name> and then putting that name in the syslinux.cfg. THANKS!!!
Offline