D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Arch Linux Installation for Fun and Profit

 

Hi Bad

This is superb. I was going to write and ask you how you put together
your cut down Linux distro that you mentioned in the laptop thread.
This not official guide is really useful. Would you use this distro
for the cut-down version or another one please? Thank you for this
guide though. I did try to take a couple of school kids through a Arch
install and we ended up using Ubuntu!

On 13 December 2013 02:37, bad apple <mr.meowski@xxxxxxxx> wrote:
> Ladies and Gentlemen:
>
> Let me present my hacked together guide on how to get Arch Linux running
> with relative quickness, ease and most importantly, laziness. Extra
> typing is stupid when we can just copy/paste stuff instead, directly
> into our SSH terminals. God knows this isn't an official guide, and
> you'd be insane to treat it as such: however, for those who are
> relatively inexperienced, find Arch daunting and it's many wikis
> somewhat... labyrinthine, I do promise that this will be far more to the
> point. If you can follow instructions properly, and are planning a test
> install to specifically a VirtualBox VM, you *will* have a functional
> Arch install complete with VBox integration, a graphical logon, GUI and
> Desktop Environment ready to explore and configure properly at your
> leisure in short order.
>
> However, there is no proper substitute for actually RTFM: all that
> follows is described far more comprehensively, accurately and with much
> better formatting at these (official) links: they have been my sole
> source for this howto.
>
> https://wiki.archlinux.org/index.php/Installation_Guide
> https://wiki.archlinux.org/index.php/Beginners%27_Guide
> https://wiki.archlinux.org/index.php/VirtualBox
> https://wiki.archlinux.org/index.php/yaourt
>
> You are *highly* encouraged to make use of them if you run into
> problems, want to modify the instructions here slightly and need
> parameters or for further reading of any kind. Arch's documentation is
> absolutely first class, luckily, and a great resource for Linux
> generally, let alone Arch-specific stuff. You can also ask on the list
> generally or ask me directly of course.
>
> For this operation we will be using the Arch 2013.12.01 iso for
> installation - get the full 522Mb version from here before you do
> anything: https://www.archlinux.org/download/
>
> Or run:
> wget
> http://www.mirrorservice.org/sites/ftp.archlinux.org/iso/2013.12.01/archlinux-2013.12.01-dual.iso
>
> Firstly, a word about my setup: this isn't as important as the
> configuration (below) of the VM you'll be practising on but probably has
> some bearing, so for completeness: Intel i5 2500k CPU w/16Gb RAM, Ubuntu
> 13.04 64bit, kernel 3.12.1-pf-meowski (custom). I use the 'proper'
> VirtualBox package direct from Oracle complete with the Extensions
> package, and so should you.
>
> My target for this install is a fresh instance, which I have called
> "archivist", of a VirtualBox 4.3.4 VM with the following configuration:
> 2 CPU cores, 2048Mb RAM, 25Gb dynamically allocated VHD hard drive (VHD
> because it's compatible with VMWare, Hyper-V, etc in case I want to move
> it later) and 64Mb video memory with 3D acceleration enabled. All other
> options I have left at the defaults with the following important
> exceptions: I have configured my VM as a 64bit Arch Linux system (32bit
> would be fine though), disabled the floppy (useless) and have set it's
> single network interface to *bridged*, not NAT - I want my VM to get
> assigned a DHCP address on the same subnet as my workstation without
> fiddling with virtual network devices. Change any of these settings only
> if you know what you are doing, or obviously if you're installing on to
> real hardware you'll have to use whatever you've physically got.
>
> Just to make things more interesting, I have made one other critical
> change: in VirtualBox's settings tabs for this VM I have enabled EFI.
> That's right, I have purposefully made things more difficult for myself
> but we're here to learn right? You might want to change this individual
> setting, but be warned that it will effect things like the partitioning
> layout and boot loader, so you will by necessity have to deviate from my
> instructions as I can't cover every possible alternative. I'd recommend
> enabling EFI - before long, it's going to be ubiquitous and for most of
> you this will be the first time you've ever installed Linux to an
> EFI/secureboot system without first disabling it and falling back to
> BIOS mode anyway, which is silly. The multiboot Arch installer we'll be
> using supports 32/64bit and EFI loading so either way we're good.
>
> So, let's get on with this!
>
> ====================================================================
>
> 0: HAVE BACKUPS. Not really relevant here, but make sure you're not
> about to scribble over real data, overwrite a VM or something else
> stupid. As we're going straight onto a blank VM or perhaps a spare blank
> PC, this step for once should be fine, but double check.
>
> 1: Get your target booted, VM or otherwise, from the Arch iso, which I'm
> going to assume goes ahead without any problems. Don't change the
> default options and let it boot even if the screen stays black for a
> while. If it really doesn't work, check the official instructions for
> disabling modesetting, ACPI and so on (this won't happen in a VM). In a
> short time you should be looking at the booted Arch system, logged in
> automatically as root in a zsh session. You'll see this:
>
> Arch Linux 3.12.1-3-ARCH (tty1)
>
> archiso login: root (automatic login)
> root@archiso ~ #
>
>
> Now the fun starts. Arch doesn't have an installer per se, it's more
> like using a Linux boot disk to chroot into a system and modify it. We
> are immediately going to start ignoring the official guide and won't
> bother setting locales or fonts - we want to spend as little time as
> possible actually interacting with this clumsy root console, using it
> only to get SSHD running so we can connect from our main machine and
> start copy/pasting commands with ease. Here are the very few steps we
> actually do at the VM console:
>
> 2: loadkeys uk
> #just to avoid messing up step 3 by accident
> 3: passwd
> #set the installer root password, otherwise SSH login will fail
> 4: ping -c 3 www.linux.org
> #check and see if Arch has picked up a valid DHCP and is networked
> 5: ip link show
> #no ifconfig on Arch: this lists available network interfaces
> #ignore the "lo" interface, and look for the one starting "enp..."
> 6: ip addr show enp0s3
> #gets actual IP address details for your network card
> #mine is called "enp0s3", yours probably will be too: get this from 5.
> #in my case, DHCP has given my enp0s3 device 192.168.0.2/24
> 7: systemctl start sshd
> 8: systemctl status sshd
> #enable SSHD server and check its status
>
>
> Ok, a lot of the work has already been done now, and we can now stop all
> interaction with the actual installer console at this point: from your
> host PC or wherever else you like, connect via SSH to the Arch VM.
>
> In my case, Arch VM has the address 192.168.0.2 assigned via DHCP so on
> my host PC, I start a new terminal and issue:
>
> ghost@failbot:~$ ssh -l root 192.168.0.2
>
> The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
> ECDSA key fingerprint is d5:c4:4b:28:f8:c7:a8:44:30:eb:34:c3:b6:5b:30:2b.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added '192.168.0.2' (ECDSA) to the list of known hosts.
> root@xxxxxxxxxxx's password:
> Last login: Thu Dec 12 21:05:42 2013
> root@archiso ~ #
>
> Excellent: I can continue all of the installation comfortably from my
> terminal now, with all the advantages of copy/paste, etc. This saves a
> lot of typing, and potentially very frustrating typos. This is also the
> *ONLY TIME IT IS ALLOWABLE TO SSH AS ROOT*.
>
> Now the serious installation begins.
>
> The very first issue is to partition the disk: if you want to create a
> custom disk layout, *not* use EFI or vary in any way from my
> instructions, you'll have to adapt what follows. Arch themselves
> recommend that for absolute beginners, you'd be best off using something
> like a Gparted live CD to boot the VM with and arrange your disks there:
> if this sounds good to you, then reboot the VM, sort out your partitions
> and then repeat the above, to get back to this step. Otherwise, read on.
>
> A "normal" Linux single disk layout would typically be something like:
>
> 25Gb virtual disk - MBR disklabel - /dev/sda
> sda1 500Mb ext2 (/boot)
> sda2 10Gb ext4 (/ - the root filesystem)
> sda3 12Gb ext4 (/home)
> sda4 2.5Gb swap
>
> That's fussy and annoying, so we're not going to do anything like that:
>
> 25Gb virtual disk - GPT disklabel - /dev/sda
> sda1 1Gb FAT32 (EFI and /boot)
> sda2 24Gb BTRFS (/ root and everything else)
>
> Much better. Now it's time to start copy/pasting into your SSH session.
>
> 9: cgdisk /dev/sda
> #this starts the partitioner: don't do this in the wrong terminal!
>
> cgdisk will warn about your empty disk (if it isn't empty, nuke
> everything so it is and create a new GPT disk label) and present you
> with a simple interface.
>
> 10: Hit "New", accept 2048 as first sector, type "+1G" for last sector
> 11: Change default hex code from "8300" to "ef00" and finish
> #you've now created a 1Gb EFI system partition
> 12: Hit "New" again, accept defaults for first and last sectors
> 13: Accept "8300" as code, accept blank name, finish.
> #you've filled the rest of the disk with a standard linux partition
> 14: Select "Write", type "yes" to confirm and then "q" to quit.
> 15: fdisk -l /dev/sda
>
> The fdisk command spits out your new disk structure in friendly format:
> mine now looks like this (note the disklabel=GPT and the correctly
> aligned offset of 2048 for the start of sda1):
>
> root@archiso ~ # fdisk -l /dev/sda
>
> Disk /dev/sda: 25 GiB, 26843545600 bytes, 52428800 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 86CC77AC-8834-45FA-9CAB-AA91AE03BE77
>
> Device           Start          End Size Type
> /dev/sda1         2048      2099199   1G EFI System
> /dev/sda2      2099200     52428766  24G Linux filesystem
>
>
> We have now partitioned the raw disk, so it's time to make filesystems
> and mount them - again, if you have deviated from my setup you're going
> to have to use common sense and the official guide to extrapolate from
> the following instructions.
>
> 16: mkfs.fat -F32 /dev/sda1
> 17: mkfs.btrfs /dev/sda2
> 18: mount /dev/sda2 /mnt
> 19: mkdir -p /mnt/boot
> 20: mount /dev/sda1 /mnt/boot
> #the order of mounting is important, always mount / first
>
> 21: date
> #check and correct the date+time if necessary
> 22: pacstrap /mnt base
> 23: genfstab -U -p /mnt >> /mnt/etc/fstab
> 24: cat /mnt/etc/fstab
> #check the generated fstab is correct
> 25: arch-chroot /mnt /bin/bash
>
>
> This is a major milestone: we have now chrooted into the actual base
> system we have just created, and can start configuration properly. From
> now on, everything you do is carried over into your finished system -
> we're not going to do very much here, just get some basics organised and
> then reboot natively without having to bother with the live CD installer
> any more. If you doing this in a VM, you could do worse than snapshot
> your progress at this point. I will be using vi as my editor for the
> following steps, but feel free to substitute it for nano if you prefer
> (and you probably should).
>
>
> 26: vi /etc/locale.gen
> #uncomment the "en_GB.UTF-8 UTF-8" line and save the file
> 27: locale-gen
> 28: echo LANG=en_GB.UTF-8 > /etc/locale.conf
> 29: export LANG=en_GB.UTF-8
> 30: echo KEYMAP=uk /etc/vconsole.conf
> 31: ln -s /usr/share/zoneinfo/GB /etc/localtime
> 32: hwclock --systohc --utc
> 33: echo myhostname > /etc/hostname
> #change myhostname to whatever you want to call your new VM
> 34: systemctl enable dhcpcd.service
> 35: passwd
> #set the root password for the current root, inside our chroot
>
>
> We have done quite a lot of basic but essential stuff here, all of which
> applies to our finished system. If you want to edit or change stuff feel
> free, but if you're happy editing locales, want a static IP address or
> to enable wifi you should be reading the official guide and using that,
> not following this hackjob! Now we are nearly done with the major
> installation stage, we just setup the bootloader properly and take care
> of a couple of last things:
>
> 36: pacman -S gptfdisk
> 37: mount -t efivarfs efivarfs /sys/firmware/efi/efivars
> #this should throw an error about already being mounted, which is fine
> 38: pacman -S gummiboot
> 39: gummiboot install
> 40: vi /boot/loader/entries/arch.conf
>
> Whether you are using vi or nano, copy all of the following into the
> file and save it:
>
> title          Arch Linux
> linux          /vmlinuz-linux
> initrd         /initramfs-linux.img
> options        root=/dev/sda2 rw
>
> Note that in the last line, I have set "root=/dev/sda2 rw" because sda2
> is where my root partition lives: if you're not following along exactly,
> you'll have to edit this line (and a whole lot of other stuff as well).
>
> 41: cat /boot/loader/entries/arch.conf
> #check the file you've just created looks correct, as above
>
> Now we do some final bits of setup, to make our life easier for when we
> reboot in a moment into our new Arch system:
>
> 42: pacman -S openssh
> 43: systemctl enable sshd.service
> 44: useradd -D
> #check defaults, they can and do differ on various *nix systems
> 45: useradd -m ghost
> #change your username from "ghost" to your preferred login name
> 46: passwd ghost
> #set the password for your new user, who probably isn't called ghost
> 47: pacman -S sudo
> 48: visudo
> #in visudo, uncomment the line "%wheel ALL=(ALL) ALL" and save
> 49: usermod -a -G wheel ghost
> #obviously change "ghost" to your chosen username instead
> 50: id ghost
> #inspect your new users permissions: should now have "wheel" for sudo
>
> We could do more at this point, but have the basics of a functional
> system now so we're going to reboot straight away to check our progress.
> We should have our new Arch system boot itself, start the DHCP service
> and get an address, enable SSHD and let us login as a user this time,
> but one with sudo access immediately. Let's do it:
>
> 51: exit
> 52: umount -R /mnt
> 53: shutdown -hP now
>
> Once the VM/test PC is down, you can remove the Arch boot iso to prevent
> it immediately restarting straight into the installer again. Now for the
> true test: if you've been following exactly, and doing this in
> VirtualBox it will definitely work. I make no promises if you've been
> customising or otherwise tampering with things. Restart your VM, and the
> first thing you will notice is the ridiculous, crazy speed at which Arch
> boots in this state - that's EFI and systemd doing their work. My modest
> test VM, archivist, boots from cold to the login screen in 4 seconds.
>
> Congratulations, you've installed Arch! Now you could login at the
> console and start playing around, but I promised you a more usable
> system so we're going to do some more work, mostly installing things
> we're going to need - we don't even have Xorg yet. Reconnect from your
> terminal on the host machine over SSH, so we can get back to
> copy/pasting instructions but be prepared for the following warning:
>
> ssh -l ghost 192.168.0.2
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
> This is completely expected: remember, we connected to the SSHD instance
> in the Arch installer system last time, and now we're connecting to the
> same IP (I'm going to presume your VM comes back up on the same
> DHCP-assigned address as before) but this time it's not the installer,
> it's our new Arch system and it has regenerated it's SSHD keys on
> startup. Hence the large scary warning.
>
> Follow the instructions your system just gave you about removing the
> offending key, I did this:
>
> ssh-keygen -f "/home/ghost/.ssh/known_hosts" -R 192.168.0.2
>
> But you can just manually edit the file and remove the line yourself if
> you prefer. As soon as you're done, reconnect again but remember you're
> not connecting as root anymore, but the user you created during the
> setup process.
>
> Running "ssh -l ghost 192.168.0.2" again drops me happily here:
>
> Last login: Thu Dec 12 23:41:34 2013
> [ghost@archivist ~]$ uname -a
> Linux archivist 3.12.4-1-ARCH #1 SMP PREEMPT Sun Dec 8 21:18:00 CET 2013
> x86_64 GNU/Linux
> [ghost@archivist ~]$
>
> Excellent. From now on in we are just finishing things up. Because we're
> now running as a normal, albeit priviledged, user, we now start
> prefixing commands with "sudo".
>
> 54: sudo pacman -S pacman -S xorg-server xorg-server-utils xorg-xinit
> 55: sudo pacman -S xterm mesa virtualbox-guest-utils virtualbox-guest-dkms
> 56: sudo pacman -S fakeroot linux-headers
> 57: sudo vi /etc/modules-load.d/virtualbox.conf
> #copy in the following, one per line like so:
> vboxguest
> vboxsf
> vboxvideo
> #save the file and exit
> 58: sudo vi /etc/mkinitcpio.conf
> #edit the HOOKS line near the end and add "vboxguest", so it looks like:
> HOOKS="base udev autodetect modconf block filesystems keyboard fsck
> vboxguest"
> #save the file and exit
> 59: sudo systemctl enable dkms.service
> 60: sudo systemctl enable vboxservice
>
> We have now pretty much done all the VBox integration stuff to make the
> new VM behave properly, but first we need a couple of extra tools, from
> the dreaded AUR repository: this means building stuff from source. Arch
> do *NOT* handle this particularly elegantly, so we're going to do the
> usual hacky job of getting around it, because life is too short.
>
> 61: sudo vi /etc/pacman.conf
> #add the following lines at the very bottom of the file:
> [archlinuxfr]
> SigLevel = Never
> Server = http://repo.archlinux.fr/$arch
> #save the file and exit
> 62: sudo pacman -Sy yaourt
> 63: yaourt -Sy yaourt-gui
> #respond to the questions: you don't want to edit the PKGBUILD, do want
> to proceed with the build, and do want to install it
> #also, this is not a typo: do NOT run yaourt with sudo or as root
> 64: yaourt -Sy vboxguest-hook
> #again, respond to the prompts and let it do it's thing
>
> Now, we don't have to use horrid pacman anymore, can automate
> downloading, compiling and installing from AUR source archives and can
> crack on with the final steps. Our system is nearly done, now we're just
> going to install a LOT of stuff, intentionally dragging in
> dependencies left right and centre.
>
> 65: yaourt -Sy gdm firefox thunderbird
> #choose the default of 1 when it asks about providers
> 66: yaourt -Sy cinnamon
> #this finally installs an actual DE - feel free to change this, or to
> add more DEs as you like... Mate, KDE, Gnome and just about all others
> are available
>
> And that's it :]
>
> It may not seem like it, but if you reboot at this point, *and you
> should*, you now have a basic, incredibly un-optimised but fully
> functional current Arch Linux VM running in VirtualBox, complete with
> VBox extensions and a GUI to explore. Don't blindly login at the login
> screen though: input your name first, and then choose whichever DE you
> like best from the little settings gear icon, otherwise it will by
> default log you into a barely functional gnome-shell session. If you've
> been following along, chose "Cinnamon" (you can have the full-on 3D
> accelerated version as well, not just the fallback mode) and then login:
> as soon as you have logged in, the VBox extensions will kick in and you
> can then manually resize the VBox window, etc. Success.
>
> At this point a wise person would snapshot their VM, and begin to play:
> you'll have a lot of missing packages and an unfamiliar Linux distro to
> explore so have fun, and at this point as you've been cheating so far,
> should actually start reading the excellent documentation.
>
> Last tips and tricks: ignore "pacman", the apt-get/yum equivalent on
> Arch, it sucks. Do package management via yaourt instead, which can also
> handle your installed AUR source packages as well.
>
> yaourt -Syua
>
> Is sufficient to synchronise, download and update all of your stuff in
> one go. For an even better experience, especially for potential newbies
> who feel out of their depth, try the truly excellent yaourt-gui which we
> installed earlier as a one-stop package management, search, updating and
> organisation tool. It's an excellent bash script, do:
>
> yaourt-gui
>
> And just follow the menus. Do *NOT* run yaourt or yaourt-gui as root or
> under sudo: they are smart enough to escalate as required and will ask
> for your password when they need it.
>
> Also, I chose GDM for a reason over other greeters: GDM is "smarter"
> than other greeters on Arch, and automatically picks up nearly all DEs
> for inclusion in it's "log into..." section. If you chose to install
> MDM, KDM, SLiM or are running startx out of a custom .xconfig and it
> doesn't work, that is your problem and you'll have to fix it yourself.
>
> Due to installing and configuring virtualbox-* properly, you DO NOT want
> to and indeed should NOT install the virtualbox guest additions manually
> through the VirtualBox interface: it's unnecessary. The modified
> /etc/mkinitcpio hooks and packages we've installed will call dkms
> properly on kernel upgrades and additions upgrades automatically. This
> is cleaner and easier than manually doing it.
>
> That pretty much covers it: this guide has been tested, and if you
> follow the instructions properly, particularly by doing the install in
> VBox, you pretty much can't go wrong. I tested it during writing this
> "guide", and earlier today it went to two reluctant testers (thanks
> guys!) for idiot proofing: whilst both are experienced IT pros, both are
> utter Linux n00bs, and one is actually a die-hard Linux hater. Tester1
> used VirtualBox hosted on Windows 7 with putty for a SSH client, and
> completed the entire operation perfectly in ~40 mins. Tester2 is a pain
> in the ass and a senior programmer/engineer, and only agreed to do it
> because he owes me a favour and I'm a bully. I had to modify some bits
> and manually intervene once, but only because he wanted to do it on his
> existing Server 2012r2 Hyper-V infrastructure, which required different
> virtio drivers and some other mods. It still only took him about an
> hour, even with some hiccups. Both were still unimpressed, except by the
> boot speed, which is insane to be fair.
>
> Any comments, corrections, questions or suggestions gratefully received,
> and I hope somebody may find this useful - I certainly hope so, because
> it took a lot bloody longer than expected to type this up and do the
> testing... no more tutorials for me for a while.
>
> Regards, and good luck.
>
>
> --
> The Mailing List for the Devon & Cornwall LUG
> http://mailman.dclug.org.uk/listinfo/list
> FAQ: http://www.dcglug.org.uk/listfaq



-- 
---
Richard Brown
Youth Worker, Dad and Husband
http://wild-woods.org.uk/

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq