Talk:USB flash installation media
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:
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.
- I cannot find that this is still relevant to the article as it now exists. I am striking it out as it looks like it could be good to remove. AdamT (talk) 10:33, 8 August 2013 (UTC)
- Just lunched from USB drive without UUID(don't have any idea why it didn't have one). Solution was to change label to appropriate in loader/entries/archiso-x86_64.conf. Not sure weither this should be added to article.
- Ok. For some reason ubuntu did not see USB UUID. So blkid -o value -s UUID /dev/sdx1 were returning empty string. The solution was:
- $ sed -i "s|label=ARCH_.*|label=$(blkid -o value -s LABEL /dev/sdx1)|" loader/entries/archiso-x86_64.conf
- It seems that sometimes you have to get the UUID by running the command as root. --Rongmu (talk) 11:23, 3 October 2013 (UTC)
BIOS and UEFI bootable USB in Windows
Maybe this applies also for Linux...
In section 1.2, where one reads:
It should be
At least with the ARCH_201311 iso...
Making an UEFI/BIOS ISO should be KISS
Following up on the discussion in the the bbs, I disagree that this edit should be kept as the first thing users see when hitting this page. I based this opinion on my feeling that the instructions are too many steps and, arguably too vague. Example, this method is 7 steps (depending on how you count) and requires that user read linked articles (i.e syslinux install and modifying master boot records). In contrast, the dd method is simple (KISS principal) and is both implemented and documented as pointed out by one of our developers in the aforementioned bbs thread.
- Well, I have been keeping an eye on this since the.ridikulus.rat's extensive edits on and after 2013-11-20. I have kept quiet because the maintainers and admins seemed to accept the changes. However, from the start, I disagreed along lines similar to what Graysky has mentioned above.
- I did not, and do not, understand why the Arch Wiki should be recommending a specific method without any references or firm reasoning. Instead the.ridikulus.rat seemed to be prescribing a method that was believed was superior based on their own preferences. This method is slightly more complicated than writing the image directly with
dd, but it does keep the drive usable for data storage.
Please note this quote from the BBS thread Graysky linked above (emphasis mine): It took me some time to read through the syslinux docs and other blog [sic] to understand the syslinux installation process under Windows, and I don't appreciate you simply removing the entire part that I thought out and typed for the sake of the community.I just realized I completely mistook what the.ridikulus.rat meant to say here. Please disregard.
- While I do think the technical information that the.ridikulus.rat provided was needed in general, and I had in fact proposed something similar shortly before, the extensive reordering of the page and the subjective recommendations does not seem in keeping with the ideals and established processes of the Arch Wiki as I understand them.
Further, referencing the quote above, egos definitely seem to be coming into play in a place where they should not matter. The sake of the community is what matters here, not individual investments. See also The Arch Way.
- Moving forward, as of this writing, the changes that Teateawhy has been making seem to be in keeping with the practices put forth in the Arch Wiki's documentation while also mitigating the subjective recommendation that was put forth during the.ridikulus.rat's changes.
- As a fairly new contributor, one aspect I have not been able to determine from reading over the Arch Wiki's documentation is when and how to make recommendations. As such, and keeping an eye on the bigger picture here, I would like to take this opportunity to suggest something be added to Help:Style or elsewhere regarding when and how recommendations and suggestions are justified. There seems to be a willingness for some contributors to make claims without references or supporting statements. Similar to Wikipedia's "reference needed" template, a flag or at least cohesive policy may be warranted for the Arch Wiki and it may help prevent situations like this in the future! : )
I don't want to hijack the main discussion, but I'd like to answer a couple of AdamT's observations:
- please do not assume that admins and maintainers can follow everything that happens on the wiki; if you have something to say about somebody else's edits just do it ;)
- I'd be glad to add some guidelines about recommendations to the style guide; the problem is that it's still very subjective to distinguish between what is a justified recommendation and what is a personal recommendation... Technically The.ridikulus.rat did justify his suggestion. If you have an idea for the wording of an effective style guide, please propose it here or in Help talk:Style, but I think that most of these cases will have to be solved in discussion pages like it's happened here.
Does `sync` have any effect?
The line in question is:
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sdx && sync
The manual says "sync - flush file system buffers" and "Force changed blocks to disk, update the super block."
So the question is: does sync have any use when you're writing straight to a block device? There is no filesystem, therefore no buffers to flush and no superblock. --Cantabile (talk) 09:47, 2 January 2014 (UTC)
- sync is not limited to file system. See here and the info page by
$ info coreutils 'sync invocation'--Fengchao (talk) 12:32, 4 January 2014 (UTC)
Other Methods for BIOS systems
- Are they outdated, i.e. you're sure they don't work? Otherwise I don't see the reason to delete them, we let users choose their preferred method. -- Kynikos (talk) 03:55, 29 January 2014 (UTC)
Graphical dd methods for Linux and Windows
Hi from Fedoraland, Arch folks! I just finished updating the Fedora wiki page for doing USB writing - with some references from the rather good SUSE pages on the same topic - main page, Windows, OS X. I think Arch, Fedora and SUSE all prefer a 'dd' style writing method, so we can take cues from each other here. The Fedora and SUSE pages both now feature ways to do a dd-style write on Windows and OS X, and the Fedora page has a rather convenient method for doing a dd-style write from GNOME - perhaps Arch might like to pick these up too? Could be handy for your users. I tested the recommended Windows tools (SUSE's Studio writer, and rawrite32) on a Windows laptop, and they both clearly did a clean direct write of the image, with Fedora's complex disk label setup to ensure BIOS, UEFI and Mac boot all work kept intact. i.e., they don't screw crap up like unetbootin or that Ubuntu tool does.
I suppose we could even think about providing a unified set of instructions / tools somewhere - there's quite a bit of redundancy going on at the moment. Thanks! AdamW (talk) 19:06, 30 January 2014 (UTC)
- Hi AdamW, thank you for your work and for trying to involve our community! For the moment I've referenced the Fedora and openSUSE articles from our See also section, however let's keep this discussion open to see if somebody wants to adapt the methods we're missing for Arch on this article. We may even add some Expansion templates where needed, as reminders and to encourage contributions. In alternative, since in general instead of duplicating external sources we prefer to just provide links to them if they're well maintained, we may just add more specific links to the Fedora article in the proper sections.
- Of course it would be great if we managed to reduce the redundancy among our articles with a unified article "somewhere", but the problem would be how to make it easy for our respective wiki users to edit such article without forcing them to register on another wiki (which clearly would instead have the effect of discouraging contributions). Maybe we could keep part of our articles synchronized with a bot?
- -- Kynikos (talk) 04:25, 1 February 2014 (UTC)