OMFS support added to the new kernel
OMFS stands for “Sonicblue Optimized MPEG File System support”. It is the proprietary file system used by the Rio Karma music player and ReplayTV DVR. Despite the name, this filesystem is not more efficient than a standard FS for MPEG files, in fact likely the opposite is true.
Weird - just goes to show you that if it is out there - eventually Linux will support it…
Now I just wish they would be able to do ZFS read/write in the kernel.
So my old Ipod’s battery has given up the ghost. I was thinking about getting another replacement battery but my wife convinced me I’d be much happier if I could watch video on my ipod.
I haven’t been paying much attention to them lately - so I didn’t know about the new hash required to allow Amarok and gtkpod to talk to the newer Ipods. I’ll get to that in a second.
Let’s start with a more boneheaded issue I’ve found myself in.
I have two shuffles (old and new) and now I’m adding in the new Ipod. I wanted to make sure that it was clear which was which. The easiest way to do this in Ubuntu is to edit the mount point. You can let Gnome auto mount the Ipod and right click and select “Properties”.
On the last tab “Volume” you can actually set the Mount Point. There is one small trick to this -
This isn’t the first time I’ve run into this situation. It turns out there is an arcane solution - run gconf-editor (it’s the registry editor for Gnome). Now navigate to /system/storage/volumes - inside there should be a _org_freedesktop entry for your ipod with the bad mount point. Correct it. Disconnect the Ipod. Reconnect. You should be good to go.
I’m sorting through a problem with my laptop and I wanted to do a fresh install of Gutsy - without formatting the drive. I just moved all my old system files into a directory and fired up the installer. I wanted it to use my old root file system without formatting. The installer won’t let you do that :(
Don’t worry there is an easy work around. Before you start the installer open a shell and type
sudo mv /lib/partman/check.d/12system_partitions_formatted /tmp
That turns off the check to make sure you are formatting your root partition. Now you can reinstall without formatting your main partition (assuming you choose the manual option on the installer screen). Make sure you have enough room for the install or bad things probably happen :)
It looks like Tomboy (A really nice note/wiki Gnome widget) has released a great new feature. As of version 0.8 you can now sync your notes to a remote server. I was kind of doing that already using Subversion - but it never really worked the way I wanted it to.
I ran into a series of problems getting this thing to work. I’ll spare you some pain if you want to follow along.
Ok first hurdle was the issue that the 0.8 package is only out for Gutsy - which hasn’t officially been released yet. I figured in this case it wouldn’t be a big deal. On the other hand, Tomboy is shipped as part of Gnome which gets an upgrade as part of Gutsy so I wasn’t sure if this was going to be an easy package to build.
It turns out Ubuntu ships a tool that makes your life in backport land very easy. (Following the advice from here)
That took a while even on my beefy machine - mostly because Tomboy needs a lot of libraries to build. After that you get the new version of Tomboy in
/var/cache/prevu/fiesty-debs
Pretty cool - I killed Tomboy and then restart it and bam I have 0.8
Tomboy offers two means of syncing - sshfs and wdfs. Both are fuse based remote file mounting systems. I tried to get sshfs to work - but for some reason it changed the permissions on the mounted directory in a way that didn’t allow my to sync. I would have preferred to go this route because it is way easier to sync via ssh (sshfs) than WebDav (wdfs).
After being thwarted by sshfs ( If someone figures it out let me know), I switched over to wdfs. Unlike most people I happen to have a personal webdrive up that uses WebDav already. Even given that head start it was still annoying.
It turns out that wdfs doesn’t exist as a package in Ubuntu. Since I generally prefer packages to anything else I did the CheckInstall dance. (I am a huge fan of check install for this very situation - I can have package to use with other machines and uninstalling is easy). wdfs requires some packages to compile.
I actually have a personally signed SSL cert on my webdrive. In theory, this makes things a little more secure. Unfortunately, wdfs doesn’t like that non-trusted cert. It turns out that the URL you put into Tomboy is passed without any special kind of escaping. This allowed my to add “-o accet_sslcert” to the url and get it past my cert.
I actually had to manually unmount the wdfs and then tell it to sync and things finally worked.
In the end, it was more work than I expected but at least now it works and since I have packages for both tomboy-0.8 and wdfs putting it on my other Ubuntu boxes should be seriously easy.
Ok so I’ve been playing with VM Server lately (Who isn’t?) - I’ve installed in on a test box - and was going to admin it from my primary workstation.
In theory - this is dead simple on Feisty
add this to your /etc/apt/sources:
deb http://archive.canoncial.com/ubuntu feisty-commercial main
Then go get a SN from their web site and do
apt-get install vmware-server vmware-tools-kernel-modules
That’s when I hit the wall -you see the deb expects eth0 in the install scripts. For some strange reason I don’t have an eth0 on my workstation. It was driving me crazy - then I learned about /etc/iftab
This little file allows you to put in a label and a mac address and you can then assign that label any time that card is up. It looks like I don’t have an eth0 because it was being reserved for my old network card (which is gone and never coming back). A quick edit to the file and a reboot (because I’m lazy) and everything is fixed.
Kind of useful - but a shame it is in such a strange place…
philbull: Feisty feature of the day #34 - Reliable NTFS support? Surely not…
This is nice - I don’t have to mess with fuse and I get a nice little app in the menu to set this up.
Ok I have mostly finished the upgrade process. I tried to upgrade three computers to Feisty - my workstation, my laptop, and my home file server.
I didn’t get very far with the file server. I have a boot partition of 30MB on it (That is only RAID1 since Linux won’t boot off of software RAID5). Right now 17MB is taken up with the current kernel (Who knew they had gotten so big). The installer needs 30MB of free space on boot to even start the install. I guess I’m going to leave that box alone until I revamp the arrays - annoying…
I would say that my experience on the laptop was the best so far. I copied over all the packages downloaded to my workstation so that sped up the install process nicely. I didn’t have to many conflicts that needed to be sorted out. It pretty much just worked. The only thing that didn’t was for some reason the Compviz stuff isn’t installed so I don’t get any desktop effects. I really wanted the cube desktop thing - going to have to dig into that.
It proved to be an overall nightmare. It wouldn’t boot off of the generic kernel - it could only use the 386 kernel. The bummer is that the 386 kernel doesn’t support dual core/SMP. So I resorted to something I haven’t had to do forever - I compiled my own kernel. I found this article which made it pretty easy to recompile and install everything. The hard part was waiting for the kernel to build. I had to do it twice because I accidentally copied over the SMP settings on the first build. My custom kernel isn’t handling my RAM properly (I’m about a GB short).
So the custom kernel combined with the custom NVidia driver meant it took me a long long long time to get the machine up and mostly running. I’m going to assume this will get better as my hardware gets a little more behind the curve. (Compviz doesn’t work on my machine - so no new hotness here either).
Update: Ok now I know why I hate compiling my own kernel. Turns out I no longer have VMWare. I’m having a hard time getting it to compile…GRRR
Ok I haven’t taken the plunge of migrating to Feisty yet. I figured it would be a good idea to get Edgy working on the new workstation before I try to migrate. Turns out it is a good thing I did.
When I did a clean install of Feisty as a test run - I clicked on the new handy control panel - “Enable Restricted Drivers”. When I did that X completely broke. I figured that the feature might be a little bumpy - but I didn’t realize it wouldn’t work at all.
It turns out that the control panel worked fine - in that it installed the nvidia driver. The problem is that my video card only got Linux support starting on March 7th (Well after the Feisty freeze). I guess I should have looked into that before I started the install process. I was able to download the latest greatest driver from Nvida and thanks to a little help from the nvidia-settings tool I was able to get back up in Dual head mode in no time.
Now that my new machine works just like my old one - it’s time to dive into the migration. I’m crossing my fingers that the migration will be completely uneventful - especially since I need to migrate three different computers (workstation, laptop, and file server).
I recently built a new computer for my home workstation. I decided I would start switching to the newer stuff - aka - PCI-Express and SATA. Yes I know they aren’t “new”. I got along fine without them for a long time. The idea being that now that everyone else has had them for a while all the kinks would be worked out under Linux.
I was also timing it to go with the release of Fiesty so I could do all the upgrading at about the same time. That was the plan anyway…
I wanted to keep my old workstation safe and sound so I copied my old Ubuntu filesystem onto the new drive. I figured it wouldn’t be that hard to sort out. Turns out I was wrong. I seem to be missing a setting somewhere for the UUID to get this all to work.
To try and make some progress I moved everything on the new drive to a directory called old and then tried to do a fresh install of Fiesty. This basically the same procedure I’ve done every time. (For both ubuntu and debian)
The installer flat out refused to let me do this. It insisted on formatting the root partition - which is where all my old files live. It wanted to do this even though there was 100GB of diskspace availabe. Very annoying!
Basically to override the installer you have two(or three) things. If you want to stick with the new partitioner you have to comment out some lines in /usr/lib/ubiquity/ubiquity/validation.py
Lines 139-143:
# if path.startswith('/') and not format:
# pathtop = '/'.join(path.split('/')[:2])
# if (pathtop in (’/', ‘/boot’, ‘/usr’, ‘/var’) and
# path not in (’/usr/local’, ‘/var/local’)):
# result.add(MOUNTPOINT_UNFORMATTED)
Your other option is to run ubiquity with the old partitioner (gpartd) You can do that by running
ubiquity gtkui --old-partitioner
You aren’t done yet -
sudo mv /lib/partman/chek.d/12system_partitions_formatted /tmp
That turns off the final check for formatting.
I’m sure they added the data checking to save a noob from not formatting a drive - but it is annoying that there is no way to opt out other than hacking on their system (though at least this is all python/bash so it is pretty easy to hack on).
Now to repair the grub/fstab and whatever else I missed and get back to work.
Update Turns out that the problem wasn’t with the UUIDs at all. I didn’t update the hd0 in grub to point at the new partition properly….details details…
