Categories: Install
Sam Denton, samwyse at gmail dot com
This are my steps to install CRUX 2.7 as a virtual machine using VMware Player with a minimal kernel. I did everything according to the handbook, but if something differs from it or needs special caution, it will be mentioned here.
VMware provides the free-with-registration Player, which will run most pre-existing VMware images, but does not allow you to create such images from scratch. Fortunately, EasyVMX provides web-based tools to create WMware images for use with VMware Player. I used the original builder, leaving all options at the defaults except as shown here:
Virtual Hardware | |
---|---|
Virtual Machine Name | crux-2_7 |
Select GuestOS | Generic Linux 2.6.x |
Memory Size | 768 MB |
# of CPUs | 1 CPU |
Virtual Machine Description | |
Virtual Machine Description | blah, blah, blah |
Virtual Machine Long Name | blah, blah, blah |
Virtual Machine URL | http://www.easyvmx.com/ |
Network Interface Cards | |
Ethernet0 | Enabled, NAT, vlance |
Ethernet1 | Disabled |
Floppy Disk Drive | |
Floppy Disk Drive | Disabled |
CDROM Drives | |
CDROM #2 | Enabled, crux-2.7.iso |
Hard Disk Drives | |
Disk #1 | Enabled, Disk size 1.0 GB |
Disk #2 | Enabled, Disk size 1.0 GB |
Sound and I/O-Ports | |
Soundcard | Disabled |
USB | Enabled, Disable USB Autoconnect |
Serial Port 1 | Disabled |
Serial Port 2 | Disabled |
Parallel port | Disabled |
I selected 768 MB of RAM because I couldn't compile the kernel with anything less. Note that after your system is built, you can change this to a different value.
I use two drives so I can mount disk #2 as /usr/src
during the system build and discard it once
I'm satisfied with my configuration. Note that specifying Disk #1 as 500 MB will hold the bare bones configuration, but adding packages will very likely push you over that size. Also note that these are sparse files, so they will only be as large as the stuff you put on them.
Especially during initial attempts, I suggest keeping the zip file handy so you can easily re-extract the unformatted disk images and start over if things go badly. Typically, the ISO image is not connected to the VM during boot. You can fix that by editing your .vmx
file (change ide1:1.startConnected
to "TRUE"
, and you may want to add the following lines to the .vmx
file:
# This adds a delay to the initial POST screen, showing it for # longer and giving you more time to access the BIOS setup, # where xxxx is the number of milliseconds to show the POST # screen. (There are 1000 milliseconds in a second.) bios.bootDelay = "5000"
Don't forget to put the modified .vmx
file back into the ZIP file!
I use an old 128 MB thumb drive to hold some simple scripts that I use during installation. This lets me avoid having to type in fdsk and mkfs commands, etc, over and over again. One issue is that there isn't a good place to mount the USB drive. I've resorted to creating a /usb
mountpoint for this purpose. What this boils down to is this: I insert my thumb drive, I boot a fresh VM, during the boot delay I connect the thumb drive to the VM, after logging in I enter the command mkdir /usb; mount /dev/sdc1 /usb; /usb/crux/setup.sh
, and then I go get a fresh cup of coffee while the script does its thing. :)
I'm trying to exclude all options that aren't needed by VMware in general, and in particular by the hardware configuration above.
General support ---> [ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
I'm booting straight from my (virtual) hard drive, so I don't need any of this.
[ ] Enable loadable module support --->
I had some problems with my kernel not finding all the device drivers it needed at boot time. The easiest solution seemed to be turning off loadable modules, as this changes all options that are set as modules to be set to static.
-*- Processor type and features ---> [ ] Symmetric multi-processing support Timer frequency (100 HZ) ---> (X) 100 HZ
My .vmx
file specified just one CPU, so there's no need for multiprocessing. And a virtual machine doesn't need a fast timer, since it's all virtual.
-*- Networking support ---> -*- Wireless ---> [ ] cfg80211 - wireless configuration API [ ] Wireless extensions sysfs files
No virtual WiFi devices means I don't need wireless networking.
Device Drivers ---> Serial ATA and Parallel ATA drivers [*] ATA SFF support [ ] *** DISABLE EVERYTHING EXCEPT THE FOLLOWING: *** [*] ATA BMDMA support [*] Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support IEEE 1394 (FireWire) support ---> [ ] FireWire driver stack ---> [*] Network Device Support ---> [ ] PHY Device support and infrastructure ---> [*] Ethernet (10 or 100Mbit) ---> [ ] *** DISABLE EVERYTHING EXCEPT THE FOLLOWING: *** [*] EISA, VLB, PCI and on board controllers [*] AMD PCnet32 PCI support [ ] Ethernet (1000 Mbit) ---> [ ] Ethernet (10000 Mbit) ---> [ ] Multiple devices driver support (RAID and LVM) [*] USB Support ---> -*- Support for Host-side USB [ ] *** DISABLE EVERYTHING EXCEPT THE FOLLOWING: *** [*] USB device filesystem (DEPRECATED) [*] UHCI HCD (most Intel and VIA) support [ ] USB Modem (CDC ACM) support
To keep my kernel small, I'm removing all drivers for devices that aren't part of my (virtual) hardware. I'm sure that some hacker somewhere has written a scdript to automate this, but I run the command lspci -v | grep 'Kernel driver is use'
and then look for the Kconfig
files that control those drivers. Once found, I run make menuconfig
and disable everything nearby.
Note that you can't disable PHY Device support and infrastructure until you disable those Ethernet devices that require it. And I should probably mention that before getting rid of 99% of the Ethernet devices, I noticed that during boot, I would get this message:
This appeared to be bogus, since TCP/IP I/O seemed to work just fine following boot. "cs89x0" is a driver for the CS8900-based ISA Ethernet Adapters from Cirrus Logic. "request_region" is a kernel routine to allocate an I/O port region, in this case 16 ports starting at 0x320. Disabling CS89x0 support got rid of the message.
Disabling the USB device file system caused the following message at boot:
Reading the menu config help for the option tells me that I should stop mounting that file system and start using udev. Until I educate myself, I've re-enabled the option.
File systems ---> < > Second extended fs support < > Ext3 journalling file system support <*> The Extended 4 (ext4) filesystem < > Reiserfs support < > JFS filesystem support < > XFS filesystem support < > GFS2 file system support < > OCFS2 file system support < > Btrfs filesystem (EXPERIMENTAL) Unstable disk format < > NILFS2 file system support (EXPERIMENTAL) [ ] Miscellaneous filesystems [ ] Network File Systems
I removed support for all file systems, except the one used by my root partition. After initial experimentation with JFS (which I could never succeed in booting), I eventually went back to ext4. Then I noticed that during boot, I would get these messages:
These appeared to be bogus, since the system would mount the device read-write during boot. After a bit of research, I discovered that the kernel probes for ext2 and ext3 before ext4. Adding "rootfstype=ext4" to the append line of /etc/lilo.conf got rid of the messages.
Cryptographic API ---> < > Run algolithms' self-tests
I could see no reason to include this, as I'm assuming that lots of other people run the tests all the time.
Using DHCP will allow maximum versatility when running multiple VMs.
I left this in so I can use thumb drives to transfer information to and from the VM.
I disabled this, as I don't need a noisy VM.
I left this alone since VMware Player will use ACHP interfaces as needed when suspending or shutting down a machine.
The Crux installation image doesn't contain a floppy driver. I'd have liked the ability to move my customization scripts from my USB drive to a floppy image, but it's not to be.
There are no network drivers loaded on the installation image. This means that I can't update the ports
or install contributed ports without a reboot. To that end, I've added a runonce process to /etc/rc.local. It scans an /etc/runonce.d
directory for executable files, runs them (duh!), and moves them into a success
or failure
subdirectory.