First and foremost, it is very important that you realize the need to run both update-initramfs and update-grub.  update-grub re-configures grub based on your current system configuration.  Things like where /boot resides,  and things of that nature, will be automagically updated in the grub configuration by running update-grub.  update-initramfs takes care of any booting issues you might have post grub, such as raid.  So, any time you make a system change that might affect booting, run these commands before rebooting (thanks to Jordan_U on irc.freenode.org for tips)...

update-grub
update-initramfs -ck all # all kernels and create (not update) the initramfs.

In the event of changing your /boot fs to another location, you should run the following as well.  Thanks again to Jordan_U.

dpkg-reconfigure grub-pc

This ensure that

1. You can configure the devices that grub will install to
2. Ubuntu is aware of proper system configurations, for when upgrades occurs and what not, so that it doesn't write the improper grub.cfg
3. update-grub is run automatically
4. installs grub to the devices configured

Now, the particular problem I was having, even though I was running the above commands, is that I kept getting dropped to a shell, with an error that said "ALERT! /dev/mapper/sys-ubuntu does not exist. Dropping to a shell".   So, as we can see, it was not finding my lvm root system.  So, the big question is "Why?"  Well, after poking around the system a bit, to find out what update-initramfs was doing, I found a file in /usr/share/initramfs-tools/hooks/mdadm that was copying /etc/mdadm/mdadm.conf verbatim to the initramfs.  Well, it's supposed to "auto detect" my raid arrays, with that configuration, but it doesn't.  So, the way I fixed it was to run the following commands...

mdadm --detail --scan > /etc/mdadm/mdadm.conf
update-initramfs -ck all

I then rebooted, and my system was very happy, and booted up very quickly. I have since filed a bug report on ubuntu's launchpad.

The problem is that you can't do a simple for loop, on the results of a find command, because the delimiter for the for loop is the space character. So essentially, the task involves converting the filename to something that the for loop is happy with. We need to replace spaces with an arbitrary character, then convert it back to the version with spaces, and the version you want. I use '+' for the arbitrary character, because I know that I don't use spaces in my filenames. I use dash (-) for the final space replacement, as it looks sharp IMO.

for file in $(find ./ -iname '*.avi' | grep ' ' | sed 's/ /+/g'); do
  mv "$(echo $file | sed 's/+/ /g')" $(echo $file | sed 's/+/-/g');
done

I figured if it takes me a couple minutes each time to figure it out, it's worth documenting. And, if it's worth documenting, it's worth sharing with others. I hope this was useful. If it is, please leave a comment.

Shrinking

Shrinking an ext3 volume is fairly straight forward, but it's important you don't mount your drive and start doing stuff, before you verify everything worked correctly.

1. e2fsck -f /dev/vg/lv1
2. resize2fs -p /dev/vg/lv1 ###G
3. e2fsck /dev/vg/lv1
4. lvresize -L ###G /dev/vg/lv1
5. e2fsck /dev/vg/lv1

Step #5 is the most important step; as steps 1-3 will not have any problems unless you have a system failure, a corrupted file system to start with, disk failure, or hardware failure.  Step 5 however, could be due to sys-admin error, from shrinking the LVM volume too much.  If you receive an error similar to the following, then you probably shrunk the volume too much, and your file system is not completely accessible.

e2fsck 1.41.9 (22-Aug-2009)
The filesystem size (according to the superblock) is 113634135 blocks
The physical size of the device is 112197632 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? cancelled!

If the error is due to shrinking too far, then this is easy to recover from; simply do another lvresize, with a large size specified, and do another e2fsck afterward.

Generally speaking, you should make the LVM maybe 2% or so larger than the file system was reduced to, so that there's room for file system overhead.

Recently I started having problems with my Intel Corporation PRO/Wireless 5300 AGN card.  It simply quit working after I did a kernel upgrade.  It was giving errors like "Unknown error 132", and "deauthenticated (Reason: 9)".  The hardware switch did not seem to affect it, and the errors were the same whether I had the switch on, or off; so I'm assuming it had to do with the hardware not being initialized properly when the module loaded.

I'm using gentoo linux, and I had previously been using kernel "2.6.30-gentoo-r5".  when I upgraded to "2.6.31-gentoo-r6", my system started having trouble with the Intel Wifi.  I was getting errors like the following.

tdanotebook ~ # /etc/init.d/net.wlan0 restart
* Stopping wlan0
*   Bringing down wlan0
*     Shutting down wlan0 ...                                    [ ok ]
*     Stopping wpa_cli on wlan0 ...                              [ ok ]
*     Stopping wpa_supplicant on wlan0 ...                       [ ok ]
* Starting wlan0
RTNETLINK answers: Unknown error 132
RTNETLINK answers: Unknown error 132
*   Starting wpa_supplicant on wlan0 ...                         [ ok ]
*   Starting wpa_cli on wlan0 ...                                [ ok ]
*     Backgrounding ...

/var/log/messages
Dec 20 15:20:04 tdanotebook kernel: wlan0: direct probe to AP 00:1f:f3:c3:88:b4 try 1
Dec 20 15:20:04 tdanotebook kernel: wlan0 direct probe responded
Dec 20 15:20:04 tdanotebook kernel: wlan0: authenticate with AP 00:1f:f3:c3:88:b4
Dec 20 15:20:04 tdanotebook kernel: wlan0: authenticated
Dec 20 15:20:04 tdanotebook kernel: wlan0: associate with AP 00:1f:f3:c3:88:b4
Dec 20 15:20:05 tdanotebook kernel: wlan0: associate with AP 00:1f:f3:c3:88:b4
Dec 20 15:20:05 tdanotebook kernel: wlan0: deauthenticated (Reason: 9)
Dec 20 15:20:05 tdanotebook kernel: wlan0: deauthenticating by local choice (reason=3)

So, I decided to try the latest unmasked vanilla kernel "2.6.31.6", and everything just started working.

Performing Global Updates: /usr/portage/profiles/updates/3Q-2009
(Could take a couple of minutes if you have a lot of binary packages.)
 .='update pass'  *='binary update'  #='/var/db update'  @='/var/db move'
 s='/var/db SLOT move'  %='binary move'  S='binary SLOT move'
 p='update /etc/portage/package.*'
......................................................                    

Performing Global Updates: /usr/portage/profiles/updates/4Q-2009
(Could take a couple of minutes if you have a lot of binary packages.)
 .='update pass'  *='binary update'  #='/var/db update'  @='/var/db move'
 s='/var/db SLOT move'  %='binary move'  S='binary SLOT move'
 p='update /etc/portage/package.*'
..................
Traceback (most recent call last):
 File "/usr/bin/emerge", line 40, in <module>
 retval = emerge_main()
 File "/usr/lib64/portage/pym/_emerge/main.py", line 1328, in emerge_main
 return action_sync(settings, trees, mtimedb, myopts, myaction)
 File "/usr/lib64/portage/pym/_emerge/actions.py", line 2173, in action_sync
 if portage._global_updates(trees, mtimedb["updates"]):
 File "/usr/lib64/portage/pym/portage/__init__.py", line 8572, in _global_updates
 moves = bindb.move_ent(update_cmd)
 File "/usr/lib64/portage/pym/portage/dbapi/bintree.py", line 273, in move_ent
 mytbz2.recompose_mem(portage.xpak.xpak_mem(mydata))
 File "/usr/lib64/portage/pym/portage/xpak.py", line 106, in xpak_mem
 indexglob=indexglob+encodeint(len(x))+x+encodeint(datapos)+encodeint(mydatasize)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xb0 in position 49: ordinal not in range(128)

The solution is simple, but not necessarily easy to think of.  All that needs to be done is to move the 4Q-2009 and 3Q-2009 files somehwere else, and then update python/portage.

[19:31 root@joseph updates] # eselect python list                    
Available python interpreters:                                       
 [1]   python2.4                                                    
 [2]   python2.5 *                                                  
 [3]   python2.6                                                    
[19:31 root@joseph updates] # eselect python set 3
[19:35 root@joseph updates] # emerge -1 portage

Then, move the 4Q-2009 and 3Q-2009 back to the proper locations, and everything should be working.  Next, it's probably good to do a "python-updater -p", followed by your world update.

I quickly found a few places that talked about setting the model to 3stack, and various other options.  But, none of that worked for me.  So, I decided to search for the problem on my own.  I ended up checking out the alsamixer again, from the command line.  Last time I checked, I saw that the "Speaker" volume was set to about two thirds, but I had thought that was referring to the volume of the PC Speaker, as on many sound cards, it is actually an option.  As it is, that is actually the volume of the external speaker.  Once you pump that puppy up to 100% the volume level is good.  From there, you can simply adjust the master or PCM volumes as you choose.

Kernel Configuration

I happen to be using kernel 2.6.30, so your configuration may vary.

<M> MMC/SD/SDIO card support  --->
<M>   MMC block device driver
[*]     Use bounce buffer for simple hosts
<M>   SDIO UART/GPS class support
<M>   Secure Digital Host Controller Interface support
<M>     SDHCI support on PCI bus

Gentoo Module Loading

Add the mmc_block and sdhci-pci modules to the configuration at /etc/modules.autoload.d/kernel-2.6
Then I just loaded them by issuing...

modprobe mmc_block
modprobe sdhci-pci

My System

For those searching on the internet, who might have the same MMC/SD chipsets as me.

tdamac linux # lspci -vvnn | grep Ricoh
09:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05) (prog-if 10 [OHCI])
09:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22) (prog-if 01)
09:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
09:01.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 12)
09:01.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev ff) (prog-if ff)

Keep in mind that this will only work for a maximum of 8 users per system.  Anything more than that, and you will have to resort to either full disk encryption, or some other method of encrypting your /home files.

I would try this out on a 1G volume or something just for fooling around.  Then once you've got that working, do it to your actual home directory.  I use LVM with mine, but it could also be a raw partition if you prefer that.  If it is a removable drive, I HIGHLY recommend using LVM, because you will be able to reference it by lvm "name".  Using a partition for external drives becomes difficult, because you cannot name an encrypted volume.

The default encryption algorithm for LUKS is AES with a cipher mode of cbc-essiv:sha256.  There are essentially 2 steps to creating a LUKS based encrypted volume.

1. LUKS Volume
2. Automounting

LUKS Volume

Tip: If you are the only user, just give your account password during luksFormat, and skip point #1.2

1. Create Encrypted Volume

   1. cryptsetup luksFormat /dev/s/home    # use CAPITAL "YES" to say yes, and enter main key

   2. cryptsetup luksAddKey /dev/s/home    # add your account password as a key password

2. Mount and Sync to Encrypted Volume

   1. cryptsetup luksOpen /dev/s/home home # opens to /dev/mapper/home

   2. mkfs.whatever /dev/mapper/home

   3. mount /dev/mapper/home /mnt/newhome

   4. rsync -a /home/ /mnt/newhome/

If you really want to overwrite your entire hard drive with random data, to make sure that there is no residual data on the drive somewhere, just use a dd from /dev/urandom to output to a file with no count option, and the volume will eventually run out of space, and the entire disk will then have random encrypted data; then just remove the file.

Automounting

Auto mounting on login is taken care of by pam_mount.  It knows how to mount encrypted volumes.  PAM will pass your user account password to pam_mount.  pam_mount will use that as the password for decrypting the volume.  That means it's important to use the luksAddKey step above to add your user account password to the list of keys.

We need to setup pam by

1. Configuring the location of the volume
2. Having KDE use pam_mount
3. Optionally having the default shell login (console mode logins) decrypt the volume.

1. Modify /etc/security/pam_mount.conf.xml

<volume sgrp="users" fstype="crypt" path="/dev/mapper/s-home" mountpoint="/home/"/>

2. KDE pam configuration
/etc/pam.d/kde

auth       optional pam_mount.so try_first_pass
session    optional pam_mount.so

3. Setup the default shell login to load pam_mount.
/etc/pam.d/login

auth       optional pam_mount.so try_first_pass
session    optional pam_mount.so

I think that's all.  If you have questions, just fire away.

echo 2 > /sys/module/hid_apple/parameters/fnmode

The valid values are (0 = disabled, [1] = fkeyslast, 2 = fkeysfirst)

This effectively reverses the function key/media key mappings.

I have tried these changes on 2.6.30-rc3, and 2.6.30-rc7, and they seem to work fine.  I would imagine that they would work on 2.6.30-rc3, 2.6.30-rc4, 2.6.30-rc5, 2.6.30-rc6, and 2.6.30-rc7, but I have not confirmed.  They may also work on 2.6.30 versions that are less than rc3.

Once you have finished installing vmware, put the following files all in the same directory and run the shell script.  It should backup and then patch the original source.

• vmware-modules-2.6.30-rc3-portable.patch
• vmware-modules-2.6.29-portable.patch
• vmware-modules-2.6.30-rc3.sh

sh vmware-modules-2.6.30-rc3.sh

You will find backup copies of the original source in /usr/lib/vmware/modules/source-backup.

Once you are finished, you will be asked to run another command to install the new modules.

vmware-modconfig --console --install-all

If it fails on a newer version of the kernel, you should be able to simply find out what the problems are, and why it's incompatible with the new kernel, and then...

1. create a new patch file
2. modify the shell script to apply the patch after the two patches above
3. move the "source" folder to a backup name
4. move the source-backup folder to the "source" folder
5. re-run the shell script

I hope this is useful for someone.  If you find it useful, I would appreciate hearing about it by a comment.  Also, feel free to link to this blog.

Thanks.