Problems with the "Alternate, Simpler" method
Users should be aware that the script seems to require a full-blown bash shell. Neither Debian nor Ubuntu rescue environments were able to run it as they both use stripped down shells. Also, neither rescue environment has xz installed so even trying to brute force it as I did, won't work.
The last paragraph was a real killer. "You will still need to do any final configuration touches as you would in a normal Arch install" should link to something or else the section should begin with a disclaimer not to try this unless you already know how to do a "normal Arch install."
- You tried to brute force it? ...trying to brute force xz uncompression, without having xz... does not make a lot of sense ^_^ (sudo all you want, that is not gonna make xz appear, :P) I don't think is necessary to explain that is a requirement to know how to do a normal arch install; installing from another distro is an expert installation method, one that is a bit harder to do than the vanilla, official way. Users should not be trying to do such thing if they can't even do a vanilla install. Anyway, I'm preparing a tutorial for a different way, one that is similar to the alternate way, and that can be used instead of that one (using the minimalist and simple style of the wiki)... and yeah, I'm going to mention the official install guide.
As per a "This article or section needs language, wiki syntax or style improvements" flag for Install_from_existing_Linux#lvmetad I am going to clean this up. The new structure should be less ambiguous and point to both mkinitcpio's wiki and grub's wiki. Example:
- After installing the system, double check your Mkinitcpio#Overview and GRUB settings if appropriate.
Because I have ZERO experience with setting up arch from an existing Linux OS, I wanted to mention my changes in the talk page. Basically, I want to cleanup the section language/style wise and style wise ONLY. The meaning must be the same. Hopefully this works as intended. :) JohnBobSmithWiki (talk) 16:54, 30 November 2016 (UTC)
Problems with Parted Magic CDROM boot
`pacstrap /mnt base` failed
mount: mount point /mnt/dev/pts does not exist
Guide might need updating
At the section "Selecting a mirror and downloading basic tools" when I attempted to update my package list with "pacman -Syyu"
I got this error
error: could not determine cachedir mount point /var/cache/pacman/pkg error: failed to commit transaction (not enough free disk space)
I "solved" it by mounting my chroot'd directory to itself
mount --bind / /
and exiting and re-opening it Whether or not that was a good idea or not, I'll find out soon enough!
Anyone know why this guide uses the bootstrap image as a chroot instead of actually using it to bootstrap? Makes little sense to me.
Add a cron job before reboot to avoid being locked out of the new system in case of network misconfiguration
I apologize if my note about the cron job did not pleased the editor. Please allow me to explain the reasons behind that note and, after that, kindly ask the editor to maintain my revision.
The original article already states reasons for installing the OS from other Linux, including remote installations and when you can't use a live CD. Naturally, these scenarios are limited of available operational procedures to handle unexpected situations. Let me develop such argument using a virtual machine in a headless server as an usual example. If one has privileges to access the hypervisor, installation from live CD will suffice and this wiki article won't be useful to such user. On the other hand, without hypervisor access, the installation from other already installed Linux may be the only option available and the user may follow this wiki article. But please note that, without hypervisor access, a simply restart of the whole system may only be done by a formal request to a system administrator on a higher hierarchical level, which may be (very) cumbersome in certain institutions and is contrary to the KISS principle of Arch distribution. Moreover, note that if the bootloader was configured to boot the new system as default, a manual intervention in the boot process to select the old bootable system is needed in addition to the reboot command (or 'button', whatever it was meant there).
An interesting parallel case can be drawn from Grub also.
This bootloader has a
fallback environment variable to set a default boot entry to load in case any other entry fails to boot.
But what if the system de facto boot but a network connection that you depend on to ssh into the new installation do not start properly?
IMHO, configuring a cron job to autoreboot to the old system after a couple of minutes is the next fallback step.
One may argue that if I misconfigure my network connection, I am not experienced enough to do the installation from other Linux.
Well, that may be correct, but in this case, to be fair, this person should also question Grub developers why they decided to program the fallback option into Grub then. If one can't boot the system properly, they are not allowed to use the system nor have the tools to handle the situation?
I apologize I didn't understood why my little unobtrusive note that just want to help the community with a tool to avoid them have headaches was rejected with a single phrase using the 'X was assumed for this' kind of argument.
Finally, for all that was stated above I would like to kindly ask the editor to accept the note I've added to the wiki article. In case the decision is to still keep it out, please at least add a note warning the user that any network misconfiguration may lead to an inaccessible OS and they need to find him/her way out of the situation by their own.