predetermined OSes
customizable OSes
virtual machines
info
Preferring a GNU/Linux OS for emacs because emacs is supported by its developers first and foremost in a GNU/Linux OS. Likely in a virtual machine such as VirtualBox, or maybe on a external drive for booting a computer. There are also other distributions based on the Linux kernel.
Considering using QEMU as the virtual machine software, which seems to be CLI oriented. While VirtualBox does use QEMU for some uncommon tasks, VirtualBox is its own thing (and under GPL, too). Thinking about interfacing with QEMU through emacs, f.e. call-process, in order to create images and VMs with the same settings without the dozens of dialogs and panels of VirtualBox. Though, VirtualBox also has CLI commands, so will probably try that first.
For a VM, thinking of mounting files for editing in emacs. That means leave those files outside of the VM or wherever the OS is installed.
Willing to compile emacs (and ImageMagick) manually.
Trying to setup the smallest system for fewest dependencies and general ease of maintenance, thereby consequently small in file size.
After dozens of Linux installs of numerous distributions in virtual machines, it seems like the simplest approach for testing emacs (after installing emacs…Why is it not installed by default?!) is using F11 to put an application into fullscreen, then toggle menu-bar-mode, tool-bar-mode, scroll-bar-mode, blink-cursor-mode, and then set fringe-mode to no-fringes. [All of that is already set in my emacs initialization file (init.el).] Fullscreen is more maximized than maximized.
Sometimes there's an option to login without a window manager, f.e. the login window of NixOS (obscure installation and package management). That works fine as long as it begins with an xterm (with X) rather than simply as console (without X), and as long as F11 works for toggling fullscreen.
Except for TinyCore, Linux-kernel based operating systems usually have keyboard shortcuts using ControlAltF1–ControlAltF6 for switching between console interfaces. Then, ControlAltF7 returns to the desktop interface. TinyCore has the bootcode multivt that will activate the keys for that purpose.
With console logins, the keys are probably ALTF1–ALTF6. The ALT key combined with the right/left arrow keys might switch to the previous/next console.
ReactOS is an MS Windows replacement, favoring NT. Tried version 0.4.5, and 0.5 dev. They were unsuitable because of failure to copy large files from mounted directores, even from USB. Hangs with a runaway process, thereby overheating computer. Also doesn't refresh interface when changes are made, f.e. adjustments to Taskbar, or deleting files in a folder (which can be refreshed from contextual menu).
Also, will never be completed, obviously.
Ubuntu uses Gnome as its desktop environment (DE), Kubuntu uses KDE, and Lubuntu uses LXDE. They are all based on the same core, Debian GNU/Linux, just different desktop environments.
interesting install options
Choosing "minimal system" reveals an extra package named "Basic server". That might be what is left out.
"minimal virtual machine" reveals "Basic Server" package, and does not offer "standard system utilities" package. About half size of "minimal system" after updates (only 1 GB before), for whatever reason.
"Virtual Machine host" package always available
Like Tiny Core, the Ubuntu 17.04 server doesn't seem to go fullscreen in the VM. Seeking alternatives.
Got Lubuntu working in a virtual machine very easily, and de-emphasizing the window manager was rather straightforward. Handled software removal and updates without issues, unlike Ubuntu (desktop version) which failed to do that without errors. Peppermint was similar to Lubuntu, though I think it might have had window manager issues.
gNewSense is confirmed by gnu.org as free(dom) software. Tried version 4.0 (Debian 6 "squeeze"). Simple install into VirtualBox vm. Guest additions required installing headers; also installed make, gcc, and the linux-kbuild package (though maybe that would have been enough if I had installed it before make and gcc). Full screen works automatically after install of guest additions.
Package manager is responsive and seems reliable. Menus are supposedly customizable, had some issues. Top and bottom bars in window manager seem non-customizable.
Version of emacs was 23. Full screen had title bar, and the top and bottom bars of the window manager remained.
The Core Project develops operating systems for minimal storage use and minimal resource use. The whole operating system is loaded into RAM, then the boot partition is immediately unmounted afterwards. Offers "persistence" as a means of restoring previous sessions, however, that is incompatiable with MS-DOS (FAT) storage (though support for that might be provided with remastering).
Their book Into the Core is very straightforward with how to package extensions for their Core operating system (chapters 14 and 15), and how to remaster it for a custom base install (chapters 11 and 12).
The operating system is based on the Linux kernel combined with the typical command names symlinked to the busybox command instead of using GNU utilities. Its package management is tce with ".tcz" files. Its repositories has "coreutils.tcz" which provide the GNU utilities to make it into a type of GNU/Linux system, if desired.
New extensions for the Core operating system are made by simply building software with the typical configure/make, then gzip, and then finalizing it with the squashfs program (available from their repositories). Much of the install can be done with just a text editor rather than the package manager, itself being rather small shell scripts.
The Micro Core version begins without view management software, and is essentially the most barebones setup without remastering it. Tiny Core has FLWM, which provides overlapping-view management. piCore begins without view management software, and its repositories have less extensions pre-made (as of version 11.x).
In a VM on macOS, Tiny Core seems to be without a 16:9 resolution. Installing onto external storage is as simple as using dd. Using piCore with a Raspberry Pi, a 1600x900 monitor had a slight overscan (expanded beyond the edges) which was readily resolved with the "config.txt" file on the boot partition.
Lots of details about the various packages used for compiling a Linux kernel and associated software, which helps with making an informed decisions about the packages. Lacking in some basic details such as partitioning disks. Therefore, experience in making and installing a Linux-based OS is crucial, such as from having installed Gentoo or Arch. Beyond LFS has information about additional software beyond the operating system needs, like X Windows and emacs.
In addition to prebuilt downloads there are customizable builds. Somehow I ended up at SUSE Studio and tried those instead, in particular the option for very convenient virtual machines for VirtualBox. None of those I made at SUSE Studio worked out. Couldn't install the guest additions for VirtualBox because they have to be built on the OS and their build always failed. I might try again now that I've noted more instructions for installing guest additions. Also might try out the openSUSE build options (might need a separate account there).
Noticed on CIcv that the link to SUSE Studio (formerly "susestudio.com") gets redirected to SUSE Studio Express.
Gentoo is similar to Arch with its installation requiring the CLI, and in not really being based on some other Linux, nor having a version number. Uses the portage package management system from BSD operating systems. Lots of documentation, including a beginner's approach of 10 very detailed (though generic) steps for complete installation.
Making an operating system with Gentoo is essentially a three-part approach.
Setup the build environment. Download an operating system for making an operating system. Then either start the computer with it, or start a VM with it.
Setup the tools. Within that operating system, download the tools needed for making the command to make the kernel. Make the command to make the kernel.
Make the new operating system. Use the command for making the kernel to make it, then download more software to put with the kernel.
Trying basic installation using VirtualBox 6.0 and a VM. Using Gentoo's "Minimal installation CD" from the downloads webpage, dated 2019-03-13, for amd64 (x86_64).
About 35 minutes to complete the first two parts. A few minutes for the beginning of the third part, then making the kernel was about 1.5 hours (and seemed to fail...). The kernel is about 20 minutes, and the modules a lot longer.
Download the temporary operating system, configure the storage drive, and configure the environment.
Create within VirtualBox a new "Gentoo (64-bit)" VM with 2048 MB RAM and a 8 GB virtual disk (because 4 GB was too small when making the kernel). In the System settings set "Enable EFI (special OSes only)", in hopes of simplifying partitioning of disks and enabling use of GPT without MBR. Increase to 128 MB video memory in the Display prefence settings. Set the virtual disk to "Solid-state Drive" in the Storage settings. Add the ISO to the optical drive. Start the VM.
Explored the options, which turned out to be mostly for the hardware and really only if things don't work out for some reason or another. So, simply choose the kernel "gentoo" from the menu.
At one point it provided a list of keymappings, which I initially mistook as ascii art of a word (but it wasn't). After a few seconds it proceeded with the default (whatever that was) without my choosing anything. It finished rather quickly and produced a prompt.
Note in the messages that it said the root password had been scrambled (for security). Be sure to set the root password with passwd root, otherwise it won't be known.
Said to check the kernel configuration, however, the file said not to edit it because it was autogenerated.
Has the typical Linux option of using the Alt (Option) key with the left/right arrow keys to switch to other terminals. Useful for running commands in one without losing documentation in another.
Also the prompt has the typical history, accessible with the up/down arrow keys.
Used ping -c 3 gnu.org to test network. Networking had apparently been autoconfigured.
Verify the date and time with date. With the VM, it's likely correct because of the "Hardware Clock in UTC Time" option in System settings for the appliance. (UTC is fine, timezone is set later.)
Partitioning the disk. The Handbook recommends GPT (GUID Partition Table) rather than MBR (Master Boot Record). Have never had that actually work, but maybe it will with Gentoo? Use parted or gdisk for GPT, or fdisk for only MBR.
Used parted. Set the units to mebibytes. Use mklabel gpt to convert to GPT, or mklabel msdos for MBR. It warns about not being properly aligned for best performance when starting from 0, but no warning when starting from 1. Use -1 for the remainder of the diskspace. Need a separate boot partition, likely not more than 100 MiB, though the kernel has been less 10 MiB. Went with 33 MiB because anything less produced an error with mkfs.fat of not enough clusters. Use set to make it the boot partition.
> parted -a optimal /dev/sda (parted) unit mib (parted) mklabel gpt (parted) mkpart primary 1 34 (parted) mkpart primary 34 -1 (parted) set 1 boot on (parted) quit
Then at the standard prompt apply the filesystems to the partitions. Use FAT32 for the boot partition because of UEFI requires FAT and the handbook recommends FAT32, and use BTRFS for the storage.
> mkfs.fat -F 32 /dev/sda1 > mkfs.btrfs /dev/sda2
Mount the main partition, but wait until after the tools are installed before mounting the boot partition.
> mount /dev/sda2 /mnt/gentoo
Downoad the latest tools for making the command needed to make the kernel, and configure them.
Obtained the stage 3 tarball by changing directory to /mnt/gentoo, and then using links:
> cd /mnt/gentoo > links https://www.gentoo.org/downloads
Arrow keys move to next link in page, then RET to activate link. Default directory to save file is the directory in which links was started. Use q to quit.
Chose the "no multilib" version, pure 64-bit. (Even though it says not to do that, because it's practically impossible to convert to multilib (32-bit and 64-bit). So what? Just create a new VM with multilib if it turns out to be needed.)
Also, the DIGESTS file is on the website and can be verified (with TAB completion):
openssl dgst -r -sha512 stage3<TAB>
Unpack it.
> tar xpvf stage3-* --xattrs-include='*.*' --numeric-owner
Configure the compile options. An example file with all possible variables should be at:
/mnt/gentoo/usr/share/portage/config/make.conf.example
Edit the configuration file for portage with the -w for preventing hard-wrapping long lines (see nano --help, because man isn't available).
"/mnt/gentoo/etc/portage/make.conf"
> nano -w /mnt/gentoo/etc/portage/make.conf
Prepend "-march=native" to the COMMON_FLAGS variable. Also add the MAKEOPTS variable set to the number of processors plus one, f.e. 3 for 2 processors.
COMMON_FLAGS="-march=native -O2 -pipe"...# Added. Number of processors plus one, for quicker completion.MAKEOPTS="-j3"
Configure the Gentoo ebuild repository for downloading future packages. Just make a directory and copy (and rename) a file to it.
> mkdir /mnt/gentoo/etc/portage/repos.conf > cp /mnt/gentoo/usr/share/portage/config/repos.conf /mnt/gentoo/etc/portage/repos.conf/gentoo.conf
Copy DNS info.
> cp --dereference /etc/resolv.conf /mnt/gentoo/etc/
Mounting filesystems before chrooting. The --make-rslave operations are needed for systemd support later in the installation.
> mount --types proc /proc /mnt/gentoo/proc > mount --rbind /sys /mnt/gentoo/sys > mount --make-rslave /mnt/gentoo/sys > mount --rbind /dev /mnt/gentoo/dev > mount --make-rslave /mnt/gentoo/dev
Change root.
> chroot /mnt/gentoo /bin/bash
> source /etc/profile
> export PS1="(chroot) ${PS1}"
From this point, all actions performed are immediately on the new Gentoo Linux environment.
In particular, if the Gentoo installation is interrupted anywhere after this point, it should be possible to 'resume' the installation at this step. There is no need to repartition the disks again! Simply mount the root partition and run the steps above starting with copying the DNS info to re-enter the working environment. This is also useful for fixing bootloader issues. More information can be found in the chroot article.
Mount the boot partition to /boot.
> mount /dev/sda1 /boot
Configure portage. Install an ebuild repository snapshot from the web.
> emerge-webrsync
The current profile can be viewed with eselect profile list, and a different profile (such as desktop oriented) can be selected by number, f.e. emerge profile set 1.
Update the @world set.
> emerge --ask --verbose --update --deep --newuse @world
After world updates, it is important to remove obsolete packages with emerge --depclean.
Configure the USE variable, if desired. The currently active USE settings can be checked with emerge --info | grep ^USE and a full description can be found at:
/usr/portage/profiles/use.desc
It can be adjusted by including a definition of the USE variable within "/etc/portage/make.conf", from which the values will be added or removed (when prepended with -) from the active USE settings.
For example, could add (but likely is unecessary, so not added):
# Amend USE variable. Add a few basics.USE="emacs imagemagick X"
Configure the ACCEPT_LICENSE variable, if desired. The current setting can be viewed with:
portageq envvar ACCEPT_LICENSE
It can be adjusted by including a definition of the ACCEPT_LICENSE within "/etc/portage/make.conf". Can use * to include all options, and -* to remove all predefined options.
Consider adding (but skipped when it seemed to interfer later with compiling the kernel, so try again sometime):
# Install only Free Software Foundation approved software,# as well as documentation and works of practical use (f.e. fonts).ACCEPT_LICENSE="-* @FSF-APPROVED @FSF-APPROVED-OTHER"
Configure the timezone. Check the directories/files within "/usr/share/zoneinfo" for the timezone. Then add it to the file "/etc/timezone", and reconfigure the "sys-libs/timezone-data" package so it will update the "etc/localtime" file.
> echo "US/Eastern" > /etc/timezone > emerge --config sys-libs/timezone-data
Configure the locales. Uncomment the lines for the needed locales within "/etc/locale.gen", and then generate the locales. It can be verified with locale -a. Then set the system-wide locales and reload the environment.
> nano -w /etc/locale.gen ...[edit and save] > locale-gen > eselect locale list ...[find the number of the needed locale] > eselect locale set 1 > env-update && source /etc/profile && export PS1="(chroot) $PS1"
Configure the Linux kernel. Install the sources:
> emerge --ask sys-kernel/gentoo-sources
Configure and make the kernel in one of two ways. Either way, be sure the filesystem support for any of the partitions are built-in rather than merely modules. This means using the menuconfig, choosing "File systems", then scrolling and selecting the various filesystems.
The main difference between manual and automatic configuration is how likely the default configuration will work for the hardware. The default configuration for the automatic approach has a lot more built-in so it will match with almost any hardware. Or course, if it doesn't, then the configuration will have to be changed.
Either way, the configuration is done with the same menuconfig program. Tip: quickly type the ESC key twice in order to go back to a previous menu; too slowly doesn't do anything.
Manually configured is said to compile faster than the automatic configuration, and it did seem to: 20 min compared to 1.5 hours. That makes sense because there was likely more to compile in the automatic configuration.
Notes of using manual or automatic approaches.
Manual configuration requires starting the menu-driven configuration screen. The commands lspci and lsmod supposedly can be used to find out system information for configuring the kernel. The lspci command can be obtained by installing "sys-apps/pciutils".
> emerge --ask sys-apps/pciutils # if desired # switch to the kernel source directory > cd /usr/src/linux > make menuconfig
This requires using a lot of "?" to learn about each option, and other suggestions from the manual. Choose to save it to ".config".
The list of options is daunting, at first. These are a list of changes made to the default manual configuration for a VirtualBox VM on a MacBook Air mid-2013 (if the actual hardware matters).
Compile and install the kernel. The -j flag is same as the MAKEOPTS variable for portage earlier, so use number of processors plus one. Will be installed in "/boot".
> make -j3 && make -j3 modules_install > make install
Compiling began at CIcqbZ. Finished: CIcqco. 19 minutes.
Began: CIcrbó. Finished: CIcrbS. 19 minutes.
The kernel can be automatically built with genkernel instead.
> emerge --ask sys-kernel/genkernel
However, it complained that a configuration file needed updating. There should be a "._cfg..." file with the config file, so just move that into the config file, then try again. For example:
> mv /etc/portage/package.use/._cfg0000_zz-autounmask /etc/portage/package.use/zz-autounmask > emerge --ask sys-kernel/genkernel
Compile the kernel. The genkernal command generates a kernel that supports almost all hardware, so it will likely take a while. The all option means all steps: kernel, modules, ramdisk. Use the "--menuconfig" option to edit the configuration, in particular make the btrfs filesystem not a module.
> genkernel --menuconfig all
The text output of genkernel is saved into "/var/log/genkernel.log". The configuration file is "/etc/genkernel.conf".
ERROR: Binary /sbin/btrfs could not be found.
This means the programs for reading a BTRFS type of filesystem either were not compiled or were compiled as a module; which is important because the filesystem of this partition is BTRFS. The --btrfs option for genkernel should work for genkernel, or use --menuconfig to select it from a long list of optoins and mark it as built-in (rather than as a module).
> genkernal --btrfs all # ...or... > genkernal --menuconfig all
With that it said "Kernel compiled successfully". There were other messages, too.
Required Kernel Parameters:
root=/dev/$ROOT
Where $ROOT is the device node for your root partition as the one specified in /etc/fstabIf you require Genkernel's hardware detection features; you MUST tell your bootloader to use the provided INITRAMFS file.
Need to make note of the names in the "/boot" directory for the generated kernel and initrd. Those will be used later when editing the boot loader configuration file.
> ls /boot/kernel* /boot/initramfs* /boot/initramfs-genkernel-x86_64-4.19.27-gentoo-r1 /boot/kernel-genkernel-x86_64-4.19.27-gentoo-r1
Configure the kernel modules. Can specify certain modules be loaded automatically, and provide options for each. However, didn't know of any that needed to be.
Filesystem. Edit the "/etc/fstab" file, which is only a template at first. Use blkid or lsblk --fs to discover the label names and UUID of disks and partitions. Then use them in the fstab file.
# file-system mount-point type options dump/pass/dev/cdrom /mnt/cdrom auto noauto,user 0 0 /dev/sda1 /boot fat32 noauto,noatime 0 2 /dev/sda2 / btrfs noatime 0 1
Networking. Didn't need to do any setup for it to work with in VM. Just installed dhcpcd.
> emerge --ask net-misc/dhcpcd
System information. Set the root password with passwd.
Edit the services, startup, and shutdown for the system in "/etc/rc.conf" (when using OpenRC). Review keyboard configuration in "/etc/conf.d/keymaps". Options for the hardware clock can be adjusted in "/etc/conf.d/hwclock". All of this seemed fine as it was.
System tools. There are few options at Installing system tools in the handbook, including logging, cron, remote access, filesystems, and networking with DHCP.
Install the VirtualBox guest additions. Using --ask leads to two results being returned (the CDROM and the module) instead of installing, so leave it out and it will install the module. (Try using --pretend to see what would happen...Maybe it would work, too?)
> emerge app-emulation/virtualbox-guest-additions
Either a bootloader or depend on EFI (checkbox in the System settings for the VM).
Use emerge and in its listing at the beginning be sure GRUB_PLATFORMS has "efi-64" listed.
> emerge --ask --verbose sys-boot/grub:2
Then use grub to install the bootloader.
When using BIOS (though I didn't make a BIOS partition...but it works to do this anyway):
> grub-install /dev/sda
When using UEFI (which hasn't worked...):
> grub-install --target=x86_64-efi --efi-directory=/boot
This is probably because the filesystem was BTRFS instead of FAT. Fine when a separate partition was made as type FAT32.
Likely need to remount the efivars filesystem as read-write:
> mount -o remount,rw /sys/firmware/efi/efivars
Then configure the bootloader. The results must say it found a linux image.
> grub-mkconfig -o /boot/grub/grub.cfg
Let's try the efibootmgr command instead of a bootloader.
> emerge --ask sys-boot/efibootmgr
In order for this to work, certain kernel configuration variables have to have been enabled: EFI runtime service support (CONFIG_EFI); EFI stub support (CONFIG_EFI_STUB); and Built-in kernel command line (CONFIG_CMDLINE_BOOL) set to the root partition path (f.e. root=/dev/sda2).
Need to make directories "/boot/EFI/Gentoo" and copy the kernel to it while also adding the ".efi" extension.
Verify the EFI variables filesystem is available. It will show it is read-only (ro), so make it writable. Then list the boot entries. Then create the new entry. The boot order will automatically update with the latest addition as first.
> mount | grep efivars efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,relatime) > mount -o remount,rw -t efivarfs efivarfs /sys/firmware/efi/efivars > efibootmgr -v > efibootmgr -c -d /dev/sda -p 1 -L "Gentoo" -l '\efi\gentoo\vmlinuz-4.19.27-gentoo-r1.efi'
Hmm, that didn't work for rebooting... Maybe the VM is getting in the way, such as not keeping the EFI variables set. (Actually, yes, it is. The Funtoo variant of Gentoo says as much in their documentation.)
The next thing to try is to copy the kernel to the default boot location for EFI:
/boot/efi/boot/bootx64.efi
(Instead, tried grub, so would like to come back to this because I likely would have only one OS anyway, f.e. not dual booting.)
> exit
> cd /
> umount -l /mnt/gentoo/dev{/shm,/pts,}
> umount -R /mnt/gentoo
> shutdown -P now
Eject the ISO from the VM, then start from the VM.
After reboot, login as root and add a new account, with options to create a home directory and add to list of groups. Must create a new password, too, in order to login. For a new account named "account":
> useradd --create-home --no-user-group --groups users,wheel,vboxusers account > passwd account # or remove an account > userdel --remove account
Keep Portage up to date and install software from it by using emerge.
# update repository info > emerge --sync # update the system > emerge --ask --update @world # ...and dependencies > emerge --ask --update --deep @world # ...and build dependencies > emerge --ask --update --deep --with-bdeps=y @world # ...and the USE settings might have changed > emerge --ask --update --deep --with-bdeps=y --newuse @world # search package names, or their names and descriptions > emerge --search something > emerge --searchdesc something # preview installation > emerge --pretend category/package-name # installing needs just the name of the package > emerge --ask category/package-name # uninstall > emerge --unmerge category/package-name # remove orphaned dependencies > emerge --depclean
It's possible to install a package from the testing branch. Add the category/package-name to the file:
/etc/portage/package.accept_keywords
For a specific version, prepend an operator such as "=" (or <, >, <=, >=) and use a name that has the version.
=app-emulation/virtualbox-guest-additions-6.0.4 =app-editors/emacs-vcs-27.0.50_pre20180831 ~amd64
Modify the USE flags individually within the file "/etc/portage/package.use", rather than it beign a directory of files.
app-editors/emacs-vcs X dynamic-loading gif imagemagick jpeg lcms mailutils png svg tiff wide-int xft media-gfx/imagemagick X fontconfig jpeg jpeg2k lcms pango png postscript svg tiff truetype app-text/ghostscript-gpl X tiff # required by app-editors/emacs-vcs-27.0.50_pre20180831::gentoo # required by virtual/emacs-26::gentoo >=app-emacs/emacs-common-gentoo-1.6-r1 X
The Arch website has excessively documented non-detailed instructions. Supports only x86_64, t.i. 64-bit processors. Uses its own pacman package management system. Potentially useful pages:
Installing Arch is essentially a two-part approach.
Pre-installation. Download an operating system (an ISO disk image) for installing an operating system. Then either start the computer with it, or start a VM with it. Configure the environment.
Install and configure the new system. Within that operating system, use its package manager for downloading and installing the base packages. Ensure the new system recognizes the hardware, is localized, and can boot.
Customize the new system by downloading any desired software. Use the command pacman -Syu to keep the OS updated, no need to download another ISO disk image.
Tried with Arch's ISO disk image from the downloads webpage dated "2019.04.01".
Download the temporary operating system and start it within a new VM, configure the environment, and then configure the storage drive (virtual disk) for the new system.
> gpg --keyserver-options auto-key-retrieve --verify archlinux-2019.04.01-x86_64.iso.sig > openssl dgst -sha1 archlinux-2019.04.01-x86_64.iso
Create within VirtualBox a new "Arch Linux (64-bit)" VM with 2048 MB RAM and a 8 GB virtual disk (VDI, dynamically allocated). Increase to 128 MB video memory in the Display prefence settings. Set the virtual disk to "Solid-state Drive" in the Storage settings. Add the ISO to the optical drive. Start the VM.
Choose "Boot Arch Linux (x86_64)", likely the first option, by typing the RET key. After booting, it automatically logs in as root.
The default console keymap is "US".
Verify the boot mode as either BIOS or UEFI by looking for the "/sys/firmware/efi/efivars" directory. The boot mode is UEFI when that directory is present, otherwise its BIOS (because these are the two options within a VirtualBox VM). The default is BIOS, and EFI has to be explicitly set within the VM settings.
The installation disk image enables dhcpcd for wired network devices on boot, which is availble within a VirtualBox VM. Test it.
> ping -c3 archlinux.org
Synchronize the time and date of the system clock.
> timedatectl status > timedatectl set-ntp true
Determine the available disks with the command lsblk and then partition the desired disk. Consider using cfdisk rather than fdisk or gdisk.
> lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop 7:0 0 489.5M 1 loop /run/archiso/sfs/airootfs sda 8:0 0 8G 0 disk sr0 11:0 1 602M 0 rom /run/archiso/bootmnt > cfdisk /dev/sda
With cfdisk, choose "dos" for the type. Afterwards, up/down arrows select a different partition in the list. Left/right arrows select a different menu item at the bottom, then press RET to choose it. Choose "New"; default size is the whole partition, so choose that; default type is "primary", so choose that. Then make it bootable by choosing "Bootable". Finish by choosing "Write" and then typing "yes", and then choose "Quit".
Format the partition as BTRFS. Then mount it to "/mnt".
> mkfs.btrfs /dev/sda1 > mount /dev/sda1 /mnt > lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop 7:0 0 489.5M 1 loop /run/archiso/sfs/airootfs sda 8:0 0 8G 0 disk └─sda1 8:1 0 8G 0 part /mnt sr0 11:0 1 602M 0 rom /run/archiso/bootmnt
Use the package manager (pacman) for downloading and installing the base packages, and then configure the new system.
Optionally edit the list of mirrors in file "/etc/pacman.d/mirrorlist" by referencing the list of mirror servers. The file will be copied to the new system by the pacstrap script. It is also recommended to reconsider the listing before each system update, too.
Install the base system with pacstrap. The "-i" flag prompts for confirmation of each package. Additional packages can be appended to the command, or install them after switching to chroot.
> pacstrap /mnt base
Downloads and installs binaries, no compiling. Was done in less than five minutes.
Generate an fstab (file system table), and check it to be sure it's okay. The "-U" flag uses UUID and the "-L" flag uses labels. Specifically, consider using "noatime" rather than "relatime".
> genfstab -U /mnt >> /mnt/etc/fstab
Change root into the system:
> arch-chroot /mnt
Adjust the localization. Uncomment "en_US.UTF-8 UTF-8" within the locale settings, then generate the locale. Create the "/etc/locale.conf" file and add the variable "LANG=en_US.UTF-8". Also, apply it to the current shell.
> nano -w /etc/locale.gen > locale-gen > echo LANG=en_US.UTF-8 > /etc/locale.conf > export LANG=en_US.UTF-8
Setup the time zone by referring to the "/usr/share/zoneinfo/" subdirectories. Also set the hardware clock from the system clock.
> ln -sf /usr/share/zoneinfo/US/Eastern /etc/localtime > hwclock --systohc
Enable networking with systemd using DHCP.
> systemctl enable dhcpcd.service
Set the root passwd.
> passwd
Install the grub package as the bootloader. Then install grub on the disk (but not on a partition) and generate its configuration file. Then exit chroot and reboot into the new system (not into the ISO disk image).
> pacman –S grub > grub-install /dev/sda > grub-mkconfig –o /boot/grub/grub.cfg > exit > reboot
After rebooting into the new system, test the network with ping to be sure the network is functioning.
Check whether the screen resolution fits the full screen. Otherwise, will need to edit variables for grub on the guest and variables for the VM on the host.
The resolution can be added to the kernel parameters using grub, however, this has yet to work at all. Edit the default grub config file at "/etc/default/grub" and append the video variable with the desired resolution to GRUB_CMDLINE_LINUX_DEFAULT, space separated.
# /etc/default/grub # GRUB boot loader configuration # ... # Was just: "quiet". # However, the video seems to have no effect. GRUB_CMDLINE_LINUX_DEFAULT="quiet video=1440x900" # ...
Instead, edit the default grub config file at "/etc/default/grub" and change the "GFX" variables for grub to modify the resolution. Prepend the desired resolution to GRUB_GFXMODE for the grub menu resolution, and to GRUB_GFXPAYLOD_LINUX for the kernel resolution. Multiple values are separated by commas or semicolons, and bit depth is optional. Setting GRUB_GFXPAYLOD_LINUX to "keep" means the kernel resolution will be the same as what is achieved from GRUB_GFXMODE.
# /etc/default/grub # GRUB boot loader configuration # ... # Was just: auto GRUB_GFXMODE=1440x900x24,auto GRUB_GFXPAYLOD_LINUX=keep # Or even something like this... #GRUB_GFXMODE=auto #GRUB_GFXPAYLOD_LINUX=1440x900x24,keep # ...
Update the configuration file for grub.
> grub-mkconfig -o /boot/grub/grub.cfg
The desired resolutions have to be available.
Restart the VM and check the available resolutions within grub before booting completely. The instructions at the bottom of the grub menu say to press c for the command-line. After doing that, use videoinfo command to determine the available resolutions and the currently selected one (with an asterisk). If there are too many, then type pager=1 at the command-line to enable paging, allowing the results to be paused one page at a time (simulating more and less), and try the videoinfo command again. Typing help will list lots of other commands, too. Can type normal or reboot to return to the menu. If the desired resolution was listed, then continue booting into the new system.
Otherwise, when the desired resolutions are not listed then they will need to be added to the VM using the CLI on the host. First, confirm the bit depth of the resolution from the System Profile for the host. Then, on the command line for the host use VBoxManage with setextradata for the VM to add "CustomVideoMode1" with the desired resolution and bit depth. (There can be up to 16 similarly named.)
[host]> VBoxManage setextradata "the-vm-name" "CustomVideoMode1" "1440x900x24"
Shutdown the VM, then restart it and boot into the new system. The desired resolutions should have taken effect at the grub menu and at the login.
The only desired reason to have VirtualBox guest additions seems to be the mounting options, the means for shared folders. For example, being able to resize the guest in a window isn't desirable because I plan on using emacs full screen. Unlike with Gentoo, mounting works fine in Arch, following the mounting instructions in the VirtualBox section. However, automounting hasn't worked by itself, but it can be done.
Install VirtualBox guest additions. Will need to choose "virtualbox-guest-modules-arch" when asked.
> pacman -S virtualbox-guest-utils
Enable the VirtualBox guest additions with systemd.
> systemctl enable vboxservice.service
Choose a folder to share within the settings for the VM in VirtualBox; automount isn't important, and neither is the mount point. The mount point will show up in "/media/" as the value of "sf_" combined with the "Folder Name" text field if the "Mount point" text field is left empty. Be sure to make permanent, if desired, when this setting is edited while the VM is running, otherwise it will be "Transient" and not remain in the settings after the VM is shutdown.
Add an entry to the "/etc/fstab" file. Prevent automounting and conflicts with systemd or booting by adding "noauto,x-systemd.automount" as options. That will cause systemd to mount as soon as needed, such as when using ls or cd. Also, add the group id (gid) for "vboxsf" from the "/etc/group" file so the files can be viewed/edited by the accounts belonging to that group.
# /etc/fstab # file-system mount-point type options dump/pass# ...share /media/sf_share vboxsf gid=109,rw,noauto,noatime,x-systemd.automount 0 0
Then shutdown, and shutdown the VM. Restart the VM. Test it by changing directory to the shared folder and listing the files.
Everything should be ready for customization.
Use pacman for package management. Refresh outdated info in the sync database with "-Syu", and force refreshing with "-Syyu". Search the repositories with "-Ss" and a regular expression. Query the installed software with "-Qs". Specifically search for outdated packages with "-Qu", but be sure to refresh the sync database with "-Syu" first.
Login as root and add a new account, with options to create a home directory and add to list of groups. Must create a new password, too, in order to login. For a new account named "account":
> useradd --create-home --no-user-group --groups users,wheel,vboxsf account > passwd account # or remove an account > userdel --remove account # or modifiy an account, f.e. add a group > usermod -aG vboxsf account
Need the X Window System and xinit for using emacs with EXWM. Also, mailutils for emacs, and imagemagick in general.
> pacman -S xorg-server xorg-xinit imagemagick mailutils pigz emacs
In order to use EXWM (Emacs as X Window Manager): logging in starts the bash shell; the init file for the shell starts the X server; the init file for the X server starts emacs; the init file for emacs uses the EXWM package. So, three initialization files need to be edited, though in no particular order.
Within the new account (not root), start emacs and it will create the directory "~/.emacs.d/"; otherwise, make that directory, such as with dired. Install the EXWM package by means of ESC x list-packages. Then create the emacs initialization file "~/.emacs.d/init.el", if none other is available, and add the necessary lines to start EXWM (which will happen when emacs is started).
Create the xinit initilization file "~/.xinitrc" and add emacs as the program to start when the X server is started. Optionally, enable the shared clipboard provided by the VirtualBox guest additions (as it's the only feature that seems to work, other than shared folders).
Add a condition to the file "~/.bash_profile" for starting startx after logging in to the bash shell.
;~/.emacs.d/init.el ; ... (require 'exwm) ; Only this is needed when using a personal configuration. ; See EXWM. ;(exwm-enable) ; Otherwise, these are needed in order to use the default config. (require 'exwm-config) (exwm-config-default)
# ~/.xinitrc # Optionally, enable the VirtualBox shared clipboard. # /usr/bin/VBoxClient --clipboard exec emacs
# ~/.bash_profile # ... # Add to the bottom a condition for automatically starting X at login. # Can use "-le" instead of "-eq", # f.e. "-le 3" for the first three virtual terminals ($XDG_VTNR). if [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then exec startx fi
Parabola is confirmed at gnu.org as free(dom) software. It is Arch, but using only the packages that meet the GNU Free System Distribution Guidelines (FSDG). It considers itself bleeding-edge yet stable enough. In fact, the Parabola website has instructions for converting an existing Arch system by simply removing or replacing (perhaps by downgrading) the non-free(dom) software.
The packages for the new operating system being installed are downloaded by the installation software, so it doesn't matter whether the installer is OpenRC or systemd, nor CLI or a desktop environment. Any version of the Parabola installer from the download page can install anything.
Notably, the VirtualBox guest additions are unavailble with Parabola. They've been delisted, likely because of a licensing issue. That means no shared folders (or even USB filters?) when using VirtualBox. Consider QEMU, or installed directly on hardware.
The most successful has been migrating from Arch to Parabola because the networking continued to work and systemd was available for Xorg. Installing Parabola with OpenRC failed to work with Xorg because Xorg expects systemd, but can be fixed by creating the file "/etc/X11/Xwrapper.config". Installing Parabola with systemd failed to fully configure the domain name resolving, f.e. ping worked with numbers but not names.
Followed the instructions outlined for Arch, with variations for Parabola. In particular, trying out OpenRC instead of systemd.
Downloaded the ISO disk from Parabola's download page, and verified checksum: "parabola-openrc-2019.03.10-dual.iso". Created same type of VM.
The localectl command for listing available keymaps (localectl list-keymaps) mentioned on Parabola's beginner's guide is not available. The timedatectl command is not available. Instead, try ntpd -qg, and then hwclock -w. (Perhaps this is just because of the OpenRC version of the installer?)
Very short list of mirrors to edit.
Before installing, supposed to add and refresh the keys for verifying the downloaded software. Installation with pacstrap failed because of a corrupt package (maybe signed incorrectly): "archlinux32-keyring". Looked for the package and could not find it at either the Arch repositories or the Parabola repositories. So, leave out the packages for the other architectures, such as "archlinux32-keyring" and "archlinuxarm-keyring".
> pacman -Sy archlinux-keyring parabola-keyring > pacman-key --populate archlinux parabola > pacman-key --refresh-keys
Unfortunately, the "archlinux32-keyring" is a dependency, so it still causes problems for the actual installation. Found the "--assume-installed" option for pacman. Revised the pacstrap command and installation finished without that error. (For pacstrap, this option must be placed at the end of the command.)
There are two installation options.
The systemd management system is very common, been around for a while. The Xorg server from Arch expects systemd to be available.
> pacstrap -i /mnt base --assume-installed archlinux32-keyring
When given choices, at the very least favor systemd to match the base installation.
The OpenRC management is actually from Gentoo, and is kind of new. The Xorg server didn't seem to work with OpenRC, and its error logs had messages expecting systemd.
> pacstrap -i /mnt base-openrc --assume-installed archlinux32-keyring
When installing "base-openrc" with pacstrap, must use the "-i" flag in order to answer one of the prompts correctly. Otherwise, the default answer will result in an error and no installation. The question is about "systemd-libs"; obviously, when installing OpenRC the answer is to not use systemd, so pick "systemd-libs-dummy" (a placeholder).
When given other choices, choose the package from either "pcr" (Parabola Community Repository) or "libre" (also Parabola oriented) for software freedom.
Before setting the root passwd or installing the bootloader, activate the network instead. Remember, this is OpenRC rather than systemd.
> rc-update add dhcpcd default * service dhcpcd added to runlevel default
After installing grub as the bootloader, immediately added the desired video resolution to the "/etc/default/grub" file, then generated the config file. Also added the custom video mode to the VM before rebooting, but the VM still needed to be shutdown completely rather than just a reboot before it took effect.
After restarting the VM, the new system seems to work, including networking and the video resolution.
Trying to migrate a cloned VM with Arch: "arch-linux-CIda-2".
Make full clone of a VM that has Arch installed on it. Removed shared folders from "/etc/fstab" and then from VM settings, just to be safe. Then, ensure everything is updated in the cloned VM.
> pacman -Syu
Install the Parabola keyring and its mirror list. First, temporarily disable the signature verification within "/etc/pacman.conf".
# /etc/pacman.conf# ...RemoteFileSigLevel = Never# ...
Install the keyring and mirror list.
> pacman -U https://www.parabola.nu/packages/libre/x86_64/parabola-keyring/download > pacman -U https://www.parabola.nu/packages/libre/x86_64/pacman-mirrorlist/download warning: /etc/pacman.d/mirrorlist installed as /etc/pacman.d/mirrorlist.pacnew
Reenable the signature verification. The instructions at Parabola declares the value to be "Required DatabaseOptional", but the conf file simply had the variable commented out and with a value of only "Required".
Replace the previous mirror list with the new one by either copying or renaming, t.i. without the ".pacnew".
Replace non-free packages with liberated version from Parabola. First, add the "[libre]" repository above the "[core]" repository in "/etc/pacman.conf". Similarly, add any other repositories, such as "[pcr]" (Parabola Community Repository), or the privacy oriented repository "[nonprism]".
# /etc/pacman.conf# ...[pcr] Include = /etc/pacman.d/mirrorlist[nonprism] Include = /etc/pacman.d/mirrorlist[libre] Include = /etc/pacman.d/mirrorlist# ...[core]
Clean the pacman cache, force a database refresh, and update the keyring. Then, update libre packages and install the "your-freedom" package to remove non-free software that has been installed with Arch and are still without "libre" replacements. That's what makes it Parabola. Additionally, install the "your-privacy" package, especially if the "[nonprism]" repository has been added.
> pacman -Scc > pacman -Syy > pacman-key --refresh > pacman -Suu pacman your-freedom > pacman -Suu pacman your-privacy
Had to agree to remove the VirtualBox guest additions and kernel module, because of "your-freedom".
Failed to install with the "your-freedom" package, for the same reason as with the Parabola installer: the "archlinux32-keyring" download was corrupt in some way. Of course, because it doesn't exist anywhere.
Found the "--assume-installed" option. Revised command and it seems to have worked. Had to do the same for the "your-privacy" package because "archlinux32-keyring" was a dependency.
> pacman -Suu --assume-installed archlinux32-keyring pacman your-freedom > pacman -Suu --assume-installed archlinux32-keyring pacman your-privacy
Update the bootloader, in this case grub. There is a new file "/etc/default/grub.pacnew", so should diff with "/etc/default/grub" to see the differences. After making any changes, just remake the configuration file.
> grub-mkconfig -o /boot/grub/grub.cfg
Rebooted and it worked. So far.
Installed X, ImageMagick (and ghostscript), emacs (and mailutils), and pigz, minus various packages by means of the "--assume-installed" flag.
> pacman -S xorg-server --assume-installed libwacom --assume-installed systemd --assume-installed systemd-common --assume-installed wayland > pacman -S xorg-xinit > pacman -S ghostscript imagemagick > pacman -S mailutils emacs --assume-installed gtk3 --assume-installed hicolor-icon-theme --assume-installed desktop-file-utils --assume-installed alsa-lib > pacman -S pigz
Failed to start emacs because its binary has been linked to gtk3, which was excluded with the "--assume-installed" flag. Maybe recompile emacs somehow, if it really matters that much. Instead, trying to install gtk3 with only a small part of its dependencies, f.e. without sound, themes, etc.
> pacman -S gtk3 --assume-installed adwaita-icon-theme --assume-installed colord --assume-installed desktop-file-utils --assume-installed gtk-update-icon-cache --assume-installed rest --assume-installed sound-theme-freedesktop --assume-installed wayland-protocols
Unfortunately, gtk3 is deeply linked to its own dependencies, so eventually allowed all packages except for systemd.
Also noticed that systemd was expected by the Xorg server, and there was no documentation to help with getting it to work with openrc (which actually originates from Gentoo). Turns out, it's because Arch has made Xorg rootless by means of using systemd. The fix is to create a new file at "/etc/X11/Xwrapper.config". See the man page for "Xorg.wrap".
# Xorg.wrap configuration fileneeds_root_rights = yes
GuixSD 0.16.0 is considered beta software. GuixSD is the standalone distribution known as "Guix System Distribution" and it uses the "shepherd" init system. Guix is the package manager, and it can be installed on top of other systems.
The Guix package manager is based on Nix and uses Guile, the "GNU Ubiquitous Intelligent Language for Extensions", the official extension language for the GNU Project. Guile is an implementation and dialect of Scheme, and Scheme is a dialect of Lisp.
When installing, there is documentation in the second console accessible with either AltF2 or the ALT key with the left/right arrow keys. It uses the Info reader, the same that emacs uses for its documentation. The installation documentation seems to be the same as what's on the website. The directory of manuals is available with d, and h shows the help for using Info.
Tried the 0.16.0 beta version "GNU with Linux-Libre 4.19.6" in it.
Download the temporary operating system and start it within a new VM, configure the environment, and then configure the storage drive (virtual disk) for the new system.
> gpg --keyserver-options auto-key-retrieve --verify guixsd-install-0.16.0.x86_64-linux.iso.xz.sig
Create within VirtualBox a new "Linux (64-bit)" VM with 2048 MB RAM and a 8 GB virtual disk (VDI, dynamically allocated). Increase to 128 MB video memory in the Display prefence settings. Set the virtual disk to "Solid-state Drive" in the Storage settings. Add the ISO to the optical drive. Start the VM.
There was only one option in the bootloader menu, which starts within five seconds by default. After booting, it automatically logs in as root. Clearing the screen can be done with Controll.
There is documentation in the second console, accessible with either AltF2 or the ALT key with the left/right arrow keys. It is uses the Info reader, the same that emacs uses for its documentation. Seems to be the same as what's on the website. Use d to see the directory of manuals, and h for help.
The default console keymap is "US".
Verify the boot mode as either BIOS or UEFI by looking for the "/sys/firmware/efi/efivars" directory. The boot mode is UEFI when that directory is present, otherwise its BIOS (because these are the two options within a VirtualBox VM). The default is BIOS, and EFI has to be explicitly set within the VM settings.
Determine the network interfaces with ifconfig -a, and then configure one, likely the wired interface (starts with "e"). Then configure that interface with DHCP, and test it.
> ifconfig enp0s3 up > dhclient -v enp0s3 > ping -c3 gnu.org
Determine the available disks with the command lsblk and then partition the desired disk. Consider using cfdisk rather than fdisk or gdisk.
> lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 8G 0 disk sr0 11:0 1 1G 0 rom > cfdisk /dev/sda
With cfdisk, choose "dos" for the type. Afterwards, up/down arrows select a different partition in the list. Left/right arrows select a different menu item at the bottom, then press RET to choose it. Choose "New"; default size is the whole partition, so choose that; default type is "primary", so choose that. Then make it bootable by choosing "Bootable". Finish by choosing "Write" and then typing "yes", and then choose "Quit".
Format the partition as BTRFS. Then mount it to "/mnt".
> mkfs.btrfs /dev/sda1 > mount /dev/sda1 /mnt > lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 8G 0 disk └─sda1 8:1 0 8G 0 part /mnt sr0 11:0 1 1G 0 rom
Configure the installation, and then use the package manager to install everything at once.
> herd start cow-store /mnt
Create the declaration of the operating system. Consider beginning with a copy of one of the example files in "/etc/configuration". Save it to the "/mnt" directory so it will still be available after reboot, perhaps "/mnt/etc/config.scm".
> mkdir /mnt/etc > cp /etc/configuration/bare-bones.scm /mnt/etc/config.scm > nano -w /mnt/etc/config.scm
The timezone can be determined from the command line with tzselect.
The target for the grub bootloader should be the disk, not the partition, f.e. "/dev/sda". The device for "file-systems" is the partition, either as a string, or a file-system-label, or a uuid. The file system can also have options as a string same as the value added in a fstab file, f.e. "noatime". Adjust the "users" values with a name and home directory.
Need to adjust the bootloader value when the computer has EFI or UEFI. The target should be the mount point of the EFI file system.
... (bootloader-configuration (bootloader grub-efi-bootloader (target "/boot/efi"))) ...
Initialize the system with the configuration file, f.e. "/mnt/etc/config.scm", for the target root system mounted at "/mnt". (It finished within 3 minutes.)
> guix system init /mnt/etc/config.scm /mnt
Halt, remove the ISO image, and then reboot. Use root to set the password with passwd for any accounts that were created.
Use guix for package management, section 3.2 of the manual. Keep in mind installing packages is per account, even with root. No other account than the account that installed the packages will have them.
Update package list with guix pull. Upgrade with guix package -u. Search with guix package -s something. Show info for a specific package with guix package --show=something. Remove a package with guix package -r something.
So far, installed "xorg-server", "xinit", "emacs". Thought emacs was dependent on X11, but it wasn't like that; X11 needs to be explicitly installed.
QEMU is a machine emulator and virtualizer. Installable with brew (homebrew) for macOS.
From its documentation page, first create a disk image, then reference that disk image and the ISO install image when booting to install an OS.
An 8GB disk image as the recommended QCOW2 format (dynamically allocated).
> qemu-img create -f qcow2 some-os.img 8G
Boot with 256MB of RAM, the disk image as the first (hda) of four possible disks (hdb, hdc, hdd).
> qemu-system-x86_64 -m 256 -hda some-os.img -cdrom some-os-install.iso -boot d
The VirtualBox software can be downloaded from the VirtualBox website rather than from the Oracle website. The VirtualBox guest additions are usually needed for sharing folders and responsive resizing of the guest window.
On various GNU/Linux systems, the VirtualBox guest additions seem to need running at the CLI as admin. After inserting the Guest Additions disc from the option in the "Devices" menu, the disc should be accessible in /media/cdrom/. In a terminal as admin, root, or with sudo run the Linux version of the guest additions. If it fails, then simply view the log file it references in the error. Likely it will say it needs make and that likely will mean the headers are needed, too.
According to Installing the Linux Guest Additions, information about failure can be obtained by executing the command as root:
> rcvboxadd setup
In general, use uname -r to determine the system and then try to install the linux-headers-… matching the system, make, and gcc either with a software application from the window manager menus or at the CLI as admin.
For example with Debian (f.e. gNewSense) the Add/Remove application in the window manager menus can be used. VirtualBox documentation said linux-kbuild would also be needed.
For Ubuntu (or similar systems), VirtualBox documentation said linux-kbuild would be needed. Vagrant suggested basic developer tools might be build-essential and dkms. At the CLI that might be:
> sudo apt-get install linux-headers-$(uname -r) build-essential dkms
Fedora, Red Hat, and other RPM-base systems, the kernel version sometimes has a code of letters or a word close to the end of the version name, for example "uek" for the Oracle Enterprise kernel or "default" or "desktop" for the standard SUSE kernels. In this case the package name is kernel-uek-devel or equivalent. If there is no such code, it is usually kernel-devel. reference
> sudo mount /dev/cdrom /media/cdrom > sudo sh /media/cdrom/VBoxLinuxAdditions.run
> wget http://download.virtualbox.org/virtualbox/5.1.22/VBoxGuestAdditions_5.1.22.iso > sudo mkdir /media/VBoxGuestAdditions > sudo mount -o loop,ro VBoxGuestAdditions_5.1.22.iso /media/VBoxGuestAdditions > sudo sh /media/VBoxGuestAdditions/VBoxLinuxAdditions.run > rm VBoxGuestAdditions_5.1.22.iso > sudo umount /media/VBoxGuestAdditions > sudo rmdir /media/VBoxGuestAdditions
Must install the Guest Additions. Then within VirtualBox choose the settings for Shared Folders. When adding a folder the default folder name will be the actual folder name, but it can be changed, preferably something simple. For MS Windows OSes the mount point is a drive letter which will be picked automatically if not chosen, and for other OSes it's a file path to a directory that needs to exist already (or be sure to make it later). The various folder names don't need to be the same, and the mount point is very optional.
Within UNIX-like OSes, be sure to add the accounts to the "vboxsf" group for access to shared folders. Similarly, the filesystem for a shared folder is of type "vboxsf", and is what makes the magic work.
Confirm the shared folders exist.
> VBoxControl sharedfolder list ... Shared Folder mappings (1): 01 - share [idRoot=0 automount writable host-icase mnt-pt=/mnt/share]
Mount the folder being shared.
> mount --types vboxsf share /mnt/share
...but that might not work...
/sbin/mount.vboxsf: mounting failed with the error: No such device
Otherwise, it'll be in the mount listing.
mount | grep vboxsf share on /mnt/share type vboxsf (rw,noatime)
Interestingly, the "automount" setting for the shared folder in the VM settings has no effect with GNU/Linux systems, and seems to not be required. Consequently, the mount point in the VM settings is not used for them either. If mounting does work, then add the mount to the file "/etc/fstab" and it will be automounted wherever desired.
# /etc/fstab # file-system mount-point type options dump/pass# ...share /mnt/share vboxsf noatime 0 0
So far, shared folders has worked for MS Windows OSes and for Arch Linux, not for other OSes. It hasn't work with Gentoo, yet.
For USB devices, either the host gets access to it or the guest VM gets access to it, not both at the same time. A USB device can be targeted with a USB filter in the settings for a VM. In that way, the guest VM gets access to the USB device rather than the host getting access to it. Guest additions are needed for that.
Looking into using Vagrant, which coordinates with VirtualBox.
Distributed as a package (.pkg) and with an uninstall tool. Otherwise, Vagrant uninstall instructions:
rm -rf /Applications/Vagrant (Incorrect. File "uninstall.tool" reveals files are in /opt/.) rm -f /usr/local/bin/vagrant sudo pkgutil --forget com.vagrant.vagrant
Also remove the ~/.vagrant.d directory to delete the user data.
Steps to initialize within the current directory, install a new box, and clone the new box. From the online documentation.
vagrant box add hashicorp/precise64
Or whatever box desired.
Might be asked to choose provider, f.e. VirtualBox. This downloads the box from the default box catalog online into the .vagrant.d directory.
config.vm.box = "hashicorp/precise64"
This clones an instance of the box the first time. The current directory is automatically synced (or mounted?) at /vagrant within the guest vm. Access its CLI with:
vagrant ssh
Within the directory of the Vagrantfile on the host use the vagrant command to suspend, resume, or halt the current guest vm, or to destroy its instance. Original box remains for cloning another when desired, and can be removed with the vagrant box remove command. Or, the vagrant global-status command will reveal the ids for the Vagrant environments, then an id can be used without having to be in the same directory as the Vagrantfile.
Installing packages into a guest, IOW provisioning, can be scripted by providing a file in the directory with the Vagrantfile, f.e. in a file named bootstrap.sh. Example of installing a webserver:
#!/usr/bin/env bash
apt-get update
apt-get install -y apache2
if ! [ -L /var/www ]; then
rm -rf /var/www
ln -fs /vagrant /var/www
fi
This example also replaces the default DocumentRoot with the synced /vagrant directory.
Then adjust the Vagrantfile:
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/precise64"
config.vm.provision :shell, path: "bootstrap.sh"
end
Port forwarding can be done by adding another line:
config.vm.network :forwarded_port, guest: 80, host: 4567
That allows access with a web browser from the host accessing http://127.0.0.1:4567/ by connecting with port 80 in the guest.
Possible to create an account at their website (transitioning to a new website June 27), and then share access to the guest vm over the Internet. Signin with the vagrant login command then share with the vagrant share command. Not intended for production traffic. Seems like that means it could be a way of sharing a test website temporarily.
Some sort of "push"-ing can be implemented by Vagrant, such as with FTP or SFTP. Perhaps this could be convenient for updating the task files for the JCF website. Still thinking some sort of emacs command within ibuffer or dired would be convenient for uploading files in general.
It's possible to run programs on the vm and have them open graphically in XQuartz on the macOS.
config.ssh.forward_x11 = true
Any X programs should open in XQuartz. For example, install emacs in the vm and then run emacs. It should open in XQuartz.
Background processes through ssh has failed because it immediately closes the connnection. The documentation recommended looking into using nohup or disown to prevent the job being killed. After much research and trial with attempting to start emacs through ssh X forwarding without keeping a terminal window open, was totally unsuccessful with that.
An ISO image can be written to a USB device in a manner that allows booting from it with the dd command. The "of" flag is the output file, generally a path to a device (not a partition). No other data can exist on the device because the whole device will be overwritten, or at least inaccessible beyond what is written. The "bs" flag is the block size, and might be optional. The "status" flag is optional. Might need to unmount the USB device while leaving it attached before using the dd command.
> dd bs=4M if=/path/to/iso of=/dev/sdX status=progress > sync
4th generation, Intel, codename: Haswell;
64-bit, 2 cores, 4 threads; 1.7 GHz, turbo (2.0) 3.3 GHz; 4MB L3 SmartCache;
virtualization: VT-x and EPT (Extended Page Tables), VT-d (Directed I/O);
multi-threading with TSX-NI (Transactional Synchronization Extensions New Instructions);
ACPI and C-states (Advanced Configuration and Power Interface), aka idle states;
Enhanced Intel SpeedStep Technology;
DMI 2.0 (Direct Media Interface);
thermal monitoring with a DTS (Digital Thermal Sensor);
Intel Smart Connect Technology (aka Apple's Power Nap feature);
Intel ME FW 9.5 (Intel Management Engine Firmware);
AES-NI (AES New Instructions) for data encryption/decryption;
TXT (Trusted Exectution Technology); Execute Disable Bit;
Secure Key for truly(?) RNG (random number generation)
EXWM is emacs used as a window manager for X, according to its user guide. The package exwm is installed from C-x list-packages.
Has been incompatible with Xquartz on macOS so far.
It supposedly can be used as the window manager in LXDE, the desktop environment in Lubuntu. Yet to confirm on any system, partly because of recently found and partly because of requiring emacs >24.4 for it.
From within emacs (>24.4):
M-x package-install RET exwm RET
Add to emacs initialization file (f.e. init.el):
(require 'exwm);(require 'exwm-config);mostly inapplicable;(exwm-config-default);has conflicting keybindings;;From exwm-config.el: Make class name the buffer name (add-hook 'exwm-update-class-hook (lambda () (exwm-workspace-rename-buffer exwm-class-name)))(exwm-enable)
All configuration code should be put in the initialization file rather than evaluated after EXWM has finished starting, unless otherwise specified.
Link or copy xinitrc (from source directory) to ~/.xinitrc. Add exec emacs for starting the window manager.
Sometimes you should disable access control by prepending a line to this file if you get a No protocol specified error:
xhost +SI:localuser:$USER
Other than X automaticlaly launching emacs as a window manager from .xinitrc, EXWM can be launched in the console with:
xinit -- vt01
The default/example configuration provides s-& for launching applications:
(exwm-input-set-key (kbd "s-&") (lambda (command) (interactive (list (read-shell-command "$ "))) (start-process-shell-command command nil command)))
Avoid launching applications with M-! (shell-command) though as it will block Emacs and therefore freeze EXWM. OTOH, using M-& (async-shell-command) works, though it produces an output buffer. Note that there is no need for processes to be created by Emacs.
According to Emacs is My New Window Manager, just uses a "server" version of Ubuntu in a VM and installs only emacs configure to open as full screen, and no window manager.
Install
Graphical interface:
sudo apt-get install -y xinit
sudo apt-get install -y emacs
For a spelling checker:
apt-get install -y ispell
In order to install the VirtualBox extensions, do:
sudo apt-get install -y build-essential
sudo mount /dev/cdrom /mnt
sudo /mnt/VBoxLinuxAdditions.run
Configure
exec emacs
(set-frame-parameter nil 'fullscreen 'fullboth)
"You can kick off a graphical browser to a specific URL by binding a function that calls this":
(start-process "" nil "xdg-open" "http://mail.google.com")
"to have EWW use Chromium, add this to your init file":
(setq shr-external-browser "chromium-browser")
The defaults for Xquartz can be seen with:
defaults read org.macosforge.xquartz.X11
Notably there is the startx_script key.
According to the FAQ Suppressing xterm launching by default it is possible to change the intial application launched.
defaults write org.macosforge.xquartz.X11 app_to_run [whatever you want to run]
Attempting to start without any application by "remove"-ing the attribute was ineffective. In order to disable that the FAQ recommends setting the value to /usr/bin/true, however, I noticed an empty quoted string "" also disables it.
defaults write org.macosforge.xquartz.X11 app_to_run ""
The terminals launched from the "Applications" menu of the menubar has the proper PATH. A terminal launched by the app_to_run value in the defaults for XQuartz has the proper PATH. A terminal launched from ~/.xinit.d/ has a different PATH than the other approaches, notably without /usr/local/bin. Yet to track down whence comes the PATH.
When using xrdb the ~/.Xresources file should be on the server (because the server loads it) rather than the client. In this case that means on the computer running Xquartz. This is in contrast to the X Window approach of long ago of using ~/.Xdefaults which was also loaded by the clients.
Can pick a different window manager by creating a file in home directory.
$ mkdir .xinitrc.d $ cat >.xinitrc.d/99-wm.sh #!/bin/sh exec twm ^D $ chmod +x .xinitrc.d/99-wm.sh $ open /Applications/Utilities/XQuartz.app
To use a window manager (f.e. i3) from a different server (through ssh):
#!/bin/sh exec ssh -AY workstation i3
Tried this with vagrant for Xquartz. Failed. I think it might because emacs isn't recognized as a window manager, so Xquartz continues to start quartz-wm.
from the xmodmap manual (man xmodmap), save current keymap to a file:
xmodmap -pke > ~/.Xmodmap
load a keymap
xmodmap ~/.Xmodmap
from the xev manual (man xev), show only keyboard events
xev -events keyboard
The modifier keys are identified as only "Left" when sticky keys are active in macOS. Turn off sticky keys and the keycodes for the rightside keys become correct.
The power key went unnoticed.
The fn key and the secondary functions for the function keys (screen brightness, keyboard brightness, etc.) also went unnoticed. Perhaps because of the fn key. Regardless of the option in System Preferences for swapping the primary response of functions, t.i. when to use the fn key.
the listing of emacs X resources
Basic set of resource attributes typically supported by programs made with X Toolkit, from X Window System's user guide : for X11 R3 and R4 of the X Window System (1990). Updated in the more recent X manual (man X) under "Options" (xorg-docs 1.7.1), and also partly available in the xterm manual (man xterm) under "X Toolkit Options" (dated 2016-09-25).
The value is simply the same as what would be in a .Xresources file. Must be of the same or greater specificity (precedence) than what has already been loaded. This is in contrast to other CLI flags which always override for that instance of the program.
Resources begin with a client name (or the value of -name) and end with the attribute name, and optionally can have a hierarchy of dot-delimited (.) widgets in between. The value is declared after a colon. A widget in between can be skipped with "?", or more than one widget can be skipped with "*". For example,
client*attribute: value
would set value for attribute of any widget hierarchy for client.
The attribute can also be a class name. The xterm program has attributes for the color of the text (foreground), the text cursor (cursorColor), and the pointer (pointerColor), and all are within the Foreground class. That means they can all be set with:
xterm*Foreground: black
For specificity, names (client, widget, or attibute) trump classes trump "?" and "*".
Color can be any name from the rgb.txt file, usually in /usr/lib/X11 somewhere. Though no longer recommended, it could be 1–4 hexdecimal digits for each of red, green, and blue, prepended with "#": #111, #121212, #123123123, #123412341234. A more modern way similarly uses hexadecimal values : black is rgb:0/0/0.
Logical values can be on/off, True/False, or yes/no.
The emacs manual has a fonts reference. Fonts can be specified in the traditional XLFD (X Logical Font Description). It consists of fourteen values, each beginning with a hyphen "-". An asterisk "*" represents any value, and a "?" represents any character.
-maker-family-weight-slant-widthtype-style-pixels-height-horiz-vert-spacing-width-registry-encoding
A lisp oriented window manager. Requires Common LISP of some sort. Interested in figuring out what it does so maybe I can do something from within emacs instead.
Interesting FAQ with info about redefining keys on keyboard.
A web browser written in JavaScript that uses FireFox. Inspired by emacs, keyboard-oriented, perhaps scriptable with JavaScript.
This seems to need an MS-DOS (FAT) formatted USB drive.