Skip to content

How to hose a Fedora 17 system

The tg3 driver in this Ideapad S10 is acting weird and I wanted to install a new kernel that was built elsewhere:
$ cd /
$ xz -dc /var/tmp/linux-3.4.0.tar.xz | tar -xvf -
./
./boot/
./boot/System.map-3.4.0
./boot/config-3.4.0
./boot/vmlinux-3.4.0
./boot/vmlinuz-3.4.0
./lib/
./lib/firmware/
./lib/firmware/tigon/
[...]
Nothing new here, this is what I usually do. So far, so good. But then all hell broke loose:
# ls -l
-bash: /bin/ls: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Huh? Our current shell is still working, let's look around:
# echo /*
/bin /boot /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var

# echo /lib/*   
/lib/firmware /lib/modules

# echo /lib64/* 
/lib64/*
What happened? Well, with Fedora 17, the UsrMove feature got implemented. This means /lib is just a symlink to /usr/lib. Not sure what this has to do with a /usr move, but that's what they did.

Apparently, when extracting the tarball, /lib (which is now symlinked to /usr/lib) got replaced by a directory and filled with the contents of the tarball. Of course, the tarball contains only the kernel and some kernel modules - that's why all the libraries could not be found anymore. The real libraries are located in /usr/lib - but all the userspace apps are still linked to /lib :-\

However, I wasn't able to reproduce this on this Debian/Squeeze system:
$ mkdir lib && touch lib/{foo,bar}
$ tar -cvf baz.tar ./lib
./lib/
./lib/foo
./lib/bar
$ rm -rf lib

$ mkdir -p usr/lib && ln -s usr/lib 
$ ls -lgo
total 28
-rw------- 1 10240 May 31 03:14 baz.tar
lrwxrwxrwx 1     7 May 31 03:15 lib -> usr/lib
drwx--x--x 3  4096 May 31 03:15 usr
$ ls -l lib/
total 0

$ tar -xvf baz.tar 
./lib/
./lib/foo
./lib/bar

$ ls -lgo . lib/
.:
total 8
-rw------- 1  196 May 31 03:24 baz.tar.xz
lrwxrwxrwx 1    7 May 31 03:25 lib -> usr/lib
drwx--x--x 3 4096 May 31 03:25 usr

lib/:
total 0
-rw------- 1 0 May 31 03:24 bar
-rw------- 1 0 May 31 03:24 foo
This time /lib was not replaced by a directory, but merely filled with the contents of the tarball. So, what went wrong on this Fedora system? Let's try again after the system has been recovered, shall we? ;-)

Driving directions

After visiting Mono Lake, CA, we wanted to go back home. Due to bad cellphone coverage we referred to the dutiful Garmin nüvi 250 to suggest a route. It looked something like this:

Yahoo Maps: Mono Lake Tufa State Reserve, Mono County, CA to San Francisco, CA

The route went via CA-108 and not through Yosemite National Park. We figured this was a good choice, because we just went through the park a day earlier: it was Memorial Day weekend and we knew that the park would just be crowded today as it was yesterday. Going via CA-108 instead of CA-120 W (through the park) added ~20 miles but it still felt like a good choice.

When the phone had better reception again, I was wondering what other map services would have suggested:

So why would Google and Bing lead me through Yosemite National Park, adding even more traffic to the already car crowded forest? Both have access to traffic conditions, my Garmin nüvi 250 does not. Also, going through the park costs $20 per car. Sure, its landscape is just beautiful and we had already purchased a permit (Google wouldn't know that, right?) but it's still puzzling why anyone would suggest going through a designated wildlife area to save ~20 miles.

dpkg: invalid character in version number

After upgrading to "PrecisePangolin", this message got printed whenever dpkg wanted to install a package:
dpkg: warning: parsing file '/var/lib/dpkg/available' near line 262698 \
          package 'lightning-extension-locale-hu':
 'Depends' field, reference to 'lightning-extension': error in version: \
          invalid character in version number
dpkg: warning: parsing file '/var/lib/dpkg/available' near line 76038 \
          package 'am-utils':
 'Replaces' field, reference to 'amd': error in version: \
          version number does not start with digit
This got printed a few times, for every package with a weird entry. Apparently /var/lib/dpkg/available got mangled during the upgrade:
Package: lightning-extension-locale-hu
Depends: lightning-extension (>= 0.7), lightning-extension (<< 0.7.*)
[...]
Package: am-utils
Replaces: amd (<= upl102-35)
Bug reports for this issue are usually being closed, so I refered to the suggested practice of clearing the available database:
$ dpkg --clear-avail
And it worked, dpkg installs much quieter now :-)

Can't keep data. Incompatible partition. Press DELETE if data loss OK or any other key to cancel

This v40z has an LSI 53C1030 SCSI Controller and I wanted to build a RAID1 array out of the two disks present. However, once in the configuration menu (press CTRL+C when the MPTBIOS is being initialized), it's impossible to add any disk to a RAID array:
 Adapter PropertiesRAID Properties → 
 Select a disk and press +
Now the following choices appear:
       F3 – Keep Data (Create 2 disk array)
 Delete – Erase Disk (Create 2 to 6 disk array)
I didn't care for the data and pressed Delete to build a fresh array. But this didn't happen, instead the following was printed:
 Can't keep data. Incompatible partition.
 Press DELETE if data loss OK or any other key to cancel
The user guide even has entry for this, suggesting to remove any partitions of type 8e (Linux LVM) from the primary disk. Well, the disks in question had an operating system installed, not a single partition was of type 0x8e.

Anyway, I booted the system into a recovery, deleted all partitions and created just one single partition of type 0x83 (Linux). Again in the MPTBIOS and I still cannot create a RAID array, as the very same error message appeared. Grrr.

Back into recovery and to delete the single 0x83 partition created earlier. That did the trick, now MPTBIOS did not complain and the RAID array is now in place. Yay! :-)

T-Mobile & ICS - but no tethering?

The wait is finally over, T-Mobile USA releases ICS for the HTC Sensation. But once the update is installed, tethering won't be "free" anymore? With "free" I meant "included in their already ridiculously expensive plans for their lousy 4G service", of course.

Sure, their Terms & Conditions are pretty clear on that:

Your Data Plan is intended for Web browsing, messaging, and similar
activities on your Device and not on any other equipment. Unless
explicitly permitted by your Data Plan, other uses, including for
example, using your Device as a modem or tethering your Device to
a personal computer or other hardware, are not permitted.
So, while having (and using) this feature before, T-Mobile was simply not enforcing their own policies. But come on, guys - it's 2012: releasing a belated ICS and at the same time disable on of the more useful features (not to mention cluttering it with your "branding") seems like one step forward, two steps backward to me. With no CyanogenMod readily available, I guess I'm gonna stick to v2.3.4 for now :-\

MacOS: This document could not be autosaved.

Every now and then TextEdit.app complains that it cannot autosave a document:
The document "foo.txt" could not be autosaved.
Your changes will not be saved until the problem is resolved.
You can also duplicate the document or discard your changes to close it.
I don't make use of Auto Save and Versions and I'm not using Time Machine either, so this whole autosaving business is kinda annoying. The usual way to remediate this particular error message (no, it's not a permission issue) is to quit TextEdit.app (and possibly discarding the latest modifications) and try again. Sometimes it takes a few iterations of this :-\

Syslog has a few more details:
[0x0-0x74074].com.apple.TextEdit[19479]: [ERROR] GSLibrary.c:_AddGenerationInternal:393 \
Failed to consume sandbox extension; error 12 (Cannot allocate memory)

TextEdit[19479]: NSFileVersion tried to tried to add a new generation and failed. \
 Versioned file URL: file://localhost/Users/bob/Documents/foo.txt, \
 contents URL: file://localhost/Users/bob/Documents/foo.txt, error: \
 Error Domain=GSLibraryErrorDomain Code=1 "The operation couldn’t be completed. \
 (GSLibraryErrorDomain error 1.)" UserInfo=0x7fe3e8652c10 {}

TextEdit[19479]: NSDocument failed to preserve the old version of a document.\
 Here's the error: Error Domain=GSLibraryErrorDomain Code=1 \
 "The operation couldn’t be completed. (GSLibraryErrorDomain error 1.)" \
 UserInfo=0x7fe3e8652c10 {}
Very annoying. Here's how to disable "Auto Save and Versions". Apparently, revisiond(8) ("storage manager for document revisions") is responsible for this task:
$ launchctl list | grep revisiond
73      -       com.apple.revisiond

$ locate revisiond | grep plist
/System/Library/LaunchDaemons/com.apple.revisiond.plist

$ launchctl unload -w /System/Library/LaunchDaemons/com.apple.revisiond.plist

$ rm -rf /.DocumentRevisions-V100 && touch /.DocumentRevisions-V100 
The next time TextEdit.app wanted to save a document, the following was displayed:
The document "foo.txt" is on a volume that does not support permanent version storage. 
You will not be able to access older versions of this document once you close it.

[x] Do not show this message again
Perfect! Be sure to tick that "Do not show this message again" box :-)

NFSv4: /mnt/nfs was not found in /proc/mounts

This machine had a stale NFS mount. But attempting to unmount gave a rather strange message:
$ umount /mnt/nfs
/mnt/nfs was not found in /proc/mounts
Let's look at mtab first:
$ mount | grep nfs
server:/mnt/export/dir0 on /mnt/nfs type nfs (ro,vers=4,addr=10.0.0.10,clientaddr=10.0.0.30)
OK, but why isn't it found in /proc/mounts then?
$ grep nfs /proc/mounts 
server:/mnt/export/dir0 /mnt/nfs\040(deleted) \
                   nfs4  ro,nosuid,nodev,noexec,relatime,\
                   vers=4,rsize=131072,wsize=131072,namlen=255,\
                   hard,proto=tcp,port=0,timeo=600,retrans=2,\
                   sec=sys,local_lock=none,clientaddr=10.0.0.30,\
                   minorversion=0,addr=10.0.0.10 0 0
Hah! Somehow the entry in /proc/mounts got mangled. OK, \040 is octal for SPACE. But umount(8) still fails:
$ umount /mnt/nfs\ \(deleted\)
umount.nfs: /mnt/nfs (deleted): not found
umount.nfs: /mnt/nfs (deleted): not found
Apparently umount(8) tried to find the entries from /proc/mounts in /etc/mtab but failed, due to the mismatch of both files. After adding \040(deleted) to the local-directory part in /etc/mtab, umount(8) did something:
$ umount /mnt/nfs*
umount: /mnt/nfs Stale NFS file handle
The entry got removed from /etc/mtab, but the mangled entry still shows up in /proc/mounts. Now all is left is a stale NFS file handle:
$ umount -f /mnt/nfs
umount2: Stale NFS file handle
umount: /mnt/nfs: Stale NFS file handle
Sadly, this could only be cured by a reboot :-\

Update: the "Stale NFS file handle" error is covered quite nicely in this bugreport. According to this report, the error should be a thing of the past since Linux 3.12.