LinuxQuestions.org - [SOLVED] First impressions of Archlinux on a MacBook Pro 5,1

I like Ubuntu well enough, but rather than upgrading to the current version I thought I'd try something interesting. I had already tried Debian, but never liked it. So here are my first impressions of Archlinux, which so far looks like what I want. I had to install it from my existing Ubuntu, since I found out to my chagrin that

Code:

<flame intensity="110%">

<!-- There is always that one line of documentation among tens of thousands that would have solved all your problems if only you'd thought of looking there -->

ALL THE ARCHLINUX INSTALL MEDIA SUCK ***MOST SEVERELY***!

THEY BLOW OUT OF ALL PROPORTION!

THEY ARE INCREDIBLY ***LOSING, CRETINOUS, BRAIN-DAMAGED AND DEFICIENT***!

</flame>

With that out of the way, I have to admit that I originally installed to an external disk, which is not trivial with a Mac (no BIOS). This was never a problem with the Ubuntu isos, but with the Archlinux install media I had no luck. The archboot graphical installer (probably outdated) didn't even install a kernel, besides, the install procedure was incredibly slow and boring. So I ended up building the install scrips and pacman in the Ubuntu (12.04 64bit) on my MacBook Pro 5,1 (which I have since replaced with Archlinux). Turns out that pacman builds perfectly in Ubuntu (I had to install a lot of extra junk though. As this is Archlinux I don't feel compelled to detail my steps, which is a relief. I just followed the existing documentation). So if one already has an existing linux install, I recommend building pacman and the install scripts there and install from the existing system, rather than relying on the _less_than_impressive_ install media. Incidentally, the Ubuntu isos suck in their own way, particularly at setting the locale ("Where are you").

I had to manually edit grub.cfg to say hd1 instead of hd0, but this was kept on subsequent runs of mkinitcpio and grub-install. The mkinitcpio.conf hooks I use are "base udev block filesystems shutdown"

And genfstab blows; I soon gave up on it. My (handmade and modelled on Ubuntu) fstab looks like this (true geeks would use reiserfs for /var, but I don't want to experiment with unfamiliar and unmaintained filesystems. Also I am not sure that MacFUSE could handle it).

Code:

# 

# /etc/fstab: static file system information

#

# <file system>                <dir>                <type>                <options>                                        <dump>        <pass>

proc                        /proc                proc                nodev,noexec,nosuid                                0        0

/dev/sdb3                /                ext4                defaults,relatime                                0        1

/dev/sdb1                /boot                ext2                defaults                                        0        2    #Possible: defaults,nodev,nosuid

/dev/sdb5                /var                ext4                defaults,nodev,relatime                                0        2    #Possible: defaults,nodev,nosuid

/dev/sdb6                /home                ext4                rw,nodev,nosuid,acl,user_xattr,relatime                0        2

/dev/sdb2                  none            swap              defaults                                          0        0

As for the graphics, I tried LXDE first but was quite horrified at the result. So I installed KDE, which works well enough (though I'll never be a fan), and then MATE-Desktop, which I still hate least. I hear though that LXDE is being ported to Qt and merging with razor-qt, so eventually it will become an option. (MATE is a usable stopgap, nothing more, nothing less).

To enable fast user switching from the mate-panel logout menu (I am using kdm), I created a script that says

Code:

#!/bin/sh

kdmctl reserve

and saved it as /usr/bin/gdmflexiserver. User switching works perfectly with MATE and kdm (lock screen is disabled in dconf-editor), except for the slow nvidia driver. At present though I am experimenting with no login manager at all. User switching is possible with the following bash function, which starts a new X server. I found it on bbs.archlinux.org (thanks to user muunleit) and modified it to my liking. Add it to your .bashrc, switch to a new console with Ctrl-Alt-F# and run it after logging in. (In my case the relevant line in .xinitrc is exec mate-session).

Code:

gui ()

{

if [ "$WINDOWPATH" ]; then

echo 'To be run from the Console - Aborting.' #Edit: This should properly read: "To be run from a login shell"

exit 1

fi

WINDOW=$(pidof X | wc -w)

startx --:$WINDOW 1>/tmp/.gui${WINDOW}-`date +%a%d%b%Y-%T`.log 2>/tmp/.gui${WINDOW}-`date +%a%d%b%Y-%T`-error.log #tmp is sticky, so every login needs a unique file pair (whose output is worth paying attention to). Note: no space between -- and :

}

KDE still has problems automounting devices. I sort of solved it (following the documentation) by creating an udev rule /etc/ude/rules.d/99-udisks2.rules:

Code:

ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1"

to revert to the traditional /media mountpoint. Also I changed the Device Notifier Settings for Device Actions of "Open with file manager" to Content Conjunction and the device type to "Disk". Still, KDE only mounts devices that have been manually mounted before (that needs to be enabled). The link in /media can be deleted after a reboot. BTW the fact that udev uses "goto" explains a lot, and what the ***hell*** is "Content Conjunction"?

In the beginning I had to use pacman -S --force quite a lot to install software. Probably a residue from my early trouble with the separate /var partition, which did not work correctly until I added the "shutdown" hook.

With pulseaudio at first I had no sound in the headphones. I solved it, as in the good old Ubuntu Jaunty days, by creating a file /etc/modprobe.d/alsa-base that says

Code:

options snd-hda-intel model=3stack

and rebooting.

The nouveau driver does not work in Arch any more than in Ubuntu. I had to install the proprietary nvidia driver (in the chroot) to be able to boot from the MacBook Pro. Kernel and nvidia updates seem to work perfectly though - I have already survived two kernel updates an an nvidia update (doing pacman -Syu from the console). /etc/default/grub needs to be modified: GRUB_CMDLINE_LINUX_DEFAULT="nomodeset nouveau.blacklist=1" (The nvidia driver blacklists nouveau automatically, but with the nouveau.blacklist option one might get an emergency login without a working driver - haven't needed that *yet*). The nomodeset option may not be necessary, but I seem to have trouble switching users without it.

The overall display colour of the nvidia driver is a little too blue by default, which I solved by adjusting the blue gamma in xorg.conf (gksu nvidia-settings should also work). Here's the relevant part of xorg.conf (edited manually after nvidia-xconfig):

Code:



Section "Monitor"

    Identifier            "Monitor0"

    VendorName            "Unknown"

    ModelName              "Unknown"

    HorizSync          28.0 - 33.0

    VertRefresh        43.0 - 72.0

    Option                "DPMS"

    Gamma                1.0        1.0        0.778

EndSection



Section "Device"

    Identifier            "Device0"

    Driver                "nvidia"

    VendorName            "NVIDIA Corporation"

    BoardName                "GeForce 9600M GT"

    Option                "NoLogo" "true"

    Option                "OnDemandVBlankInterrupts" "1"

EndSection

As for font configuration, all I have done so far is copy a default local.conf from the documentation into /etc/fonts which already looks pretty good.

To remap my keyboard (not only to swap the traditional § and ` keys, but also moving ISO_Level3_Shift to the Ctrl key which is freed by mapping Ctrl to the Command keys) I use the following .Xmodmap:

Code:

keycode 49 = section plusminus section plusminus notsign notsign

keycode 94 = grave asciitilde grave asciitilde brokenbar bar

remove Control = Control_L

remove mod5 = ISO_Level3_Shift

keycode 133 = Control_L

keycode 37 = ISO_Level3_Shift

add mod5 = ISO_Level3_Shift

add Control = Control_L

The relevant MATE desktop settings in System>Preferences>Keyboard>Layouts are:
Keyboard: "English (US) English (Macintosh)" (which has umlauts and ß accessible with ISO_Level3_Shift. I don't like the German keyboard because it is inconvenient for using the shell)
Alt/Win key behavior: "Control is mapped to Win keys (and the usual Ctrl keys)"
Key to choose 3rd level: "Right Alt key never chooses 3rd level" and "Right Ctrl" (But see the Xmodmap file: It's actually mod5, not mod3, and there is no right Ctrl. All this sucks majorly and should be easier)

This frees the right Alt key for Caja's window commands (for which I'd otherwise need both hands) while retaining the mode shift capability (using the left and only Ctrl key, with the actual Ctrl being remapped to the Command keys). WIBNI Caja's shortcuts could be remapped *persistently*? Moving selected files to the trash works with fn_BackSpace; deleting permanently works with Shift_fn_BackSpace. Once you have a keymap that works you should create an xkb dump (xmodmap .Xmodmap; xkbcomp $DISPLAY current.xkb), so you can load the whole thing into your display in a lump at startup (xkbcomp current.xkb $DISPLAY). The command cannot be entered directly in System>Preferences>Startup Applications because MATE's startup applications cannot handle variables, but a script /usr/local/bin/load-keymap that calls /usr/bin/xkbcomp /path/to/current.xkb $DISPLAY will work. The command to be entered in "Startup Applications" is

Code:

/usr/bin/sh -c "/usr/bin/sleep 1; exec /usr/local/bin/load-keymap"

The script /usr/local/bin/load-keymap goes like this:

Code:

#!/bin/bash

/usr/bin/xkbcomp /path/to/current.xkb $DISPLAY

#a good place is /usr/local/etc/current.xkb, especially if more than one user wants to use this keymap

*****

Want a shortcut to empty the trash? Create a script /usr/local/bin/trash and assign a shortcut to it:

Code:

#!/bin/bash

TRASH="$HOME/.local/share/Trash"

if [[ `ls -A "$TRASH/files"` ]]; then

find $TRASH/{expunged,files,info} -mindepth 1 -print0 2>/dev/null | xargs -0 rm -rf

echo -e "[Cached]\nSize=0" > $TRASH/metadata

ffplay -vn -nodisp -autoexit /usr/share/sounds/freedesktop/stereo/trash-empty.oga #Mac users should love this :-)

fi

(Sorry, but I'll never get used to #!/usr/bin/bash which is a bad idea anyway as it will make scripts unportable).

*****

Installing grub-EFI on a MacBook Pro 5,1:

To install grub-EFI on a backup volume on /dev/sdb (which I hope will give me an emergency boot in case I mess up grub2 again), I did the following as root while booted from the backup volume (there is no grub-efi-x86_64 package, the standard grub2 is efi-enabled by default):

Add EFI to /etc/fstab:

Code:

/dev/sdb1 /boot/efi vfat defaults 0 0

Edit /etc/default/grub:

Code:

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset nouveau.blacklist=1 console=tty0 console=ttyS0,38400n8"

#but do NOT add a serial console section as in the documentation! nomodeset may not be necessary, but on the mbp5,1 the virtual consoles won't work either way. The console entries seem to be necessary to get the keyboard to work at the login prompt.

Put the following in /etc/grub.d/40_custom (adjust paths as necessary):

Code:

menuentry 'Arch Linux EFI boot on /dev/sdb6' {

insmod part_gpt

insmod ext2

set root=(hd1,gpt4)

linux /vmlinuz-linux root=/dev/sdb6 ro nomodeset

initrd /initramfs-linux.img

}

(Running grub-mkconfig -o /boot/grub/grub.cfg will generate menu entries for the internal install automatically). Then generate an EFI boot image:

Code:

#we are still root

mkdir /boot/efi

mount -t vfat /dev/sdb1 /boot/efi #/dev/sdb1 is the 200MB EFI partition that Mac-formatted gpt disks have by default

modprobe dm-mod

grub-install --target=x86_64-efi --efi-directory=/boot/efi --recheck --force #otherwise grub will barf on the non-existent efibootmgr (DO NOT INSTALL IT!)

cp /usr/share/locale/en@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo

grub-mkconfig -o /boot/grub/grub.cfg

mkdir /boot/efi/EFI/BOOT

cp /boot/efi/EFI/arch/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI #do not delete /boot/efi/EFI/arch!

After this, rebooting with the Alt key held down should give you an "EFI boot" entry with an orange icon. No need to bless anything. The virtual consoles won't work (they stay blank, but I can switch back to the standard kdm login with Ctrl-Alt-fn-F7). User switching with kdm will work. As I intend to use the console I'll stick with grub-pc for this machine - I don't think running pacman -Syu in the graphics is a good idea. It is possible though to enable the multi-user target (systemctl disable kdm.service; systemctl enable multi-user.target) and start the graphics by hand after system maintenance (see above; that will also work with grub-efi and the modified /etc/default/grub, but the console won't work any more until rebooting after starting X).

Commands to run after a kernel update:
#mount -t vfat /dev/sdb1 /boot/efi; grub-mkconfig -o /boot/grub/grub.cfg #if you are in arch-chroot
cp /boot/efi/EFI/arch/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

User switching with EFI and without a login manager will work after installing xorg-xhost:

Code:

xhost +localhost # this needs more investigation; probably just xhost

su - <username>

gui #this is the above script, basically startx --:1

This can be expanded into a /usr/bin/gdmflexiserver script for use with MATE:

Code:

#!/bin/sh

SELECTED_USER=`zenity --list --title="User Switching" --text="Available Users:" --column="[Use arrow keys to select]" <user1> <user2> ...` #Insert your users; it might be wise to leave out root ;-)

if [ "$SELECTED_USER" ]; then

mate-terminal -e "su - $SELECTED_USER" #the gui script can be started automatically from the .bash_profile of $SELECTED_USER

fi

It should be possible to implement this without opening a graphical terminal, but that would involve the chvt command, which would require editing /etc/sudoers to allow users to run it without a password (And of course that would defy the point of this script, which is to work without functioning virtual terminals).