For Debian, use:
set isofile="/path/to/debian-live.iso" loopback loop (hdX,msdosY)$isofile linux (loop)/live/vmlinuz boot=live findiso=$isofile toram console=ttyS0,115200n8 initrd (loop)/live/initrd.img bootFor Ubuntu, use:
set isofile="/path/to/ubuntu-live.iso" loopback loop (hdX,msdosY)$isofile linux (loop)/live/vmlinuz boot=casper iso-scan/filename=$isofile toram console=ttyS0,115200n8 initrd (loop)/live/initrd.img bootNote the slight variations in the secret mantras to chant. If you are booting in UEFI mode, you might need to rmmod tpm as well. For Fedora you may need this variation. In all cases, I needed the ISOs to be on an MBR-formatted SSD; a GPT-formatted SSD did not work.
Support for nVidia GPUs is slightly more seamless on Ubuntu than Debian. You probably want similar distros, perhaps the same version, on your servers, desktops, and laptops. Ubuntu is heaver on laptops than stock Debian, but the above convenience makes Ubuntu slightly preferable on nVidia-based laptops now. If you want minimal CPU activity while idle, stock Debian with XFCE or Cinnamon seems the way to go.
Update: As of April 2014, stock Debian seems even better compared to Unity and Gnome Shell (a mere shell of Gnome 2!). I am moving to Debian testing with XFCE. I might try MATE when it becomes more stable and distributed from Debian repos.
Update: In Spring 2011, I tried to find a decent new Linux distribution to replace the aging Jaunty 9.04 on my IBM Thinkpad X40. The results were discouraging. Most Linuxen are leaving old hardware behind. After quite some trial and error, I converged on stock Debian Squeeze 6.0.1a with some tweaks.
I started from debian-6.0.1a-i386-CD-1.iso with MD5 sum b0307432f0af51c2e821c8075907d171. Given what's going on with Intel graphics and kernels, you need to be very specific about this.
I like Debian because of their slow-and-sure package updates. I
just added squeeze, squeeze-updates, and squeeze-proposed-updates to
my apt sources,
You have to install pm-utils by hand.
sl-modem* will
It's well-known that the Linuxes keep their user population within limits by clever user-unfriendly ploys. Here are some notes to foil those intentions. These notes pertain to Debian Etch 4.03 and Ubuntu Hardy Heron 8.04, ca. summer 2008. No warranty for severe tire damage.
When you cut power to the UPS, the UPS starts the shutdown sequence, Debian uses ACPI to cut power to the PC before the UPS kills power, so when power returns, the PC does not power up. (Some BIOSes will let you power up on utility return no matter how the shutdown happened.) Anyway, the remedy is:
As usual, the Web knows everything.
If you were running FC5, user IDs were assigned from 500 up. Because each Linux has to be refreshingly different, this magic number is 1000 by default in Ubuntu. As a result, Gnome user-admin will not even show users with lowly IDs. The remedy consists of (at least) the following steps:
The vmware sites offers a number of downloads with names like VMware-server-1.0.1-29996.i386.rpm, VMware-server-1.0.5-80187.tar.gz, and VMware-server-1.0.6-91891.tar.gz. Only the last one will work (easily or at all) on Ubuntu 8.04. But not before you jump through a few hoops.
The usual symptom is:
$ vmware /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)and the remedy is this:
$ sudo ln -sf /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1 $ sudo ln -sf /usr/lib/libpng12.so.0 /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0Will be fixed soon, I am sure, but not before wasting a few thousand hours worldwide.
Suppose /var/svn/foo is an svn repository and /var/trac/foo is the corresponding trac repository. Trac uses sqlite. If you were running sqlite-2.x, Ubuntu 8.04 is unhappy and cryptic because it wants sqlite-3.x databases. The remedy follows:
# cd /var/trac/foo/db # mv trac.db trac.db.2 # sqlite trac.db.2 .dump > trac.sql # sqlite3 trac.db ".read trac.sql" # cd .. # trac-admin . upgrade # trac-admin . resync # chown -R www-data /var/trac/foo/db /var/svn/foo/db