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)
Using manual formatting In GNU/Linux
Is it truth that fs on partition _must_ be FAT32? For uefi it is guaranteed to work, but for some firmware implementations it is also possible to use other fs types as I know. For legacy it could be also ext2/3/4 I guess (even syslinux is called extlinux). So I think it is better to say something like "for better compatibility" instead of "must" here.
When copying files from mounted iso, maybe add exclude arguments to the command? For example, we could exclude isolinux folder.
Actually, in instructions here: https://gitlab.archlinux.org/archlinux/archiso/blob/master/docs/README.transfer.rst they mention another FSs and use excludes in extraction command. Ashark (talk) 17:47, 25 April 2019 (UTC)
dd-ed ISO to USB device + new partition for user data transfer - without failing to boot
If for whatever reason, user does not want to use either of USB_flash_installation_media#Using_manual_formatting (because it requires FAT32 for example) or USB_flash_installation_media#Using_a_multiboot_USB_drive, then here's a way to still be able boot (without failing into rescue shell) in the case when you did dd the image to the usb (via USB_flash_installation_media#Using_dd) and took the additional step to make a new partition for extra data that you wanted to have available during installation for example.
Due to the way systemd identifies
by-label mounts for isohybrid ISOs (see issue in https://github.com/systemd/systemd/issues/12409 ) of which archlinux*.iso is one, you have to use kernel cmdline
ISOUUID is what you get when you execute
blkid -p archlinux-2019.04.01-x86_64.iso seen in its output as
PTUUID="377032cf" (don't forget to add that
-01 which means the first partition (which is the 600M iso one)), for example:
archisodevice=/dev/disk/by-partuuid/377032cf-01. For other ways to pass archisodevice to kernel cmdline, see how it's being done inside the section USB_flash_installation_media#Using_manual_formatting. Note: I've only tested grub boot (so non-UEFI) with this method and I was thus able to mount my new partition this way. Without this
by-partuuid trick, booting the iso from the USB device will fail at mounting airootfs, then if workaround it by just giving your new partition a label, it will boot ok but you won't be able to mount this new partition (details in the aforementioned systemd issue on github). Howaboutsynergy (talk) 22:35, 13 May 2019 (UTC)