Prolixium dot com: News >> Blog

I tried using it on / and /home when installing Ubuntu 6.10 on taco, this evening. It installed fine, except for missing xfsprogs, which provide fsck.xfs, by default.

Upon installing a bunch of packages via apt while editing a Perl script at the same time, the machine proceeded to hard lock. I suspect that there's some hardware glitch in the PC, which is why it's not used all that frequently. Anyhow, when it rebooted, I first went to my script, to see if vim would be able to recover unsaved changes. To my dismay, however, the file was full of nulls. I then tried to resume my package install with "dpkg --configure -a" but soon realized that /var/lib/dpkg/{available,available-old} were also filled with nulls.

I ended up redoing the system with ext3, since I didn't care to spend the time mucking with data recovery. Was that just some random occurrence, or have other people seen this?

Doesn't give me a great deal of confidence in XFS ...

This makes me sad:

!!! All ebuilds that could satisfy "xmms" have been masked.
!!! One of the following masked packages is required to complete your request:
- media-sound/xmms-1.2.10-r16 (masked by: package.mask, ~amd64 keyword)
# Diego Pettenó <flameeyes@gentoo.org> (23 Oct 2006)
# Pending removal 23 November for multiple bugs
# Use anything but this, like media-sound/audacious
# media-sound/amarok media-sound/mpd media-sound/rythmbox
# media-sound/muine media-sound/banshee

See bug thread, too.

Just for fun, I ran his first suggestion through valgrind:

==27656== ERROR SUMMARY: 27 errors from 4 contexts (suppressed: 72 from 1)
==27656== malloc/free: in use at exit: 2,947,026 bytes in 29,456 blocks.
==27656== malloc/free: 547,958 allocs, 518,502 frees, 170,510,497 bytes allocated.

Keep in mind, I only kept it open log enough to play 15 seconds of an MP3 that was already queued in my playlist. Oh yeah, it also causes X to chew up 22% of my Athlon64 3200+.

Neat:

[lepton:13:40]% ping -nc2 monica.cs.rpi.edu
PING monica.cs.rpi.edu (128.213.7.2) 56(84) bytes of data.
64 bytes from 128.213.7.2: icmp_seq=1 ttl=48 time=26.0 ms
64 bytes from 128.213.7.2: icmp_seq=2 ttl=48 time=25.6 ms

[lepton:13:41]% ping6 -nc2 monica.cs.rpi.edu
PING monica.cs.rpi.edu(2001:468:903:d507:240:33ff:fed3:1c39) 56 data bytes
64 bytes from 2001:468:903:d507:240:33ff:fed3:1c39: icmp_seq=1 ttl=54 time=30.1 ms
64 bytes from 2001:468:903:d507:240:33ff:fed3:1c39: icmp_seq=2 ttl=54 time=29.7 ms

Those are both from my laptop, at work. This is progress, right?

If you have Comcast or Optimum Online, it might not be a bad idea to check out the interface MTU on your public interface:

% ip link show eth1
4: eth1: <BROADCAST,MULTICAST,UP> mtu 576 qdisc pfifo_fast qlen 1000
link/ether 00:48:54:8e:e0:30 brd ff:ff:ff:ff:ff:ff

See that 576? I'm not sure why this happens, but I'm speculating it's due to a misconfigured DHCP server on the ISP's side of the house. RFC 879 specifies 576 as the IP maximum datagram size. However, we know that the link type is Ethernet, so it should be 1500. Also, if you're using dhclient, it's probably actively requesting the option "interface-mtu" along with a couple others. You can remove this option from dhclient.conf, and bounce the interface. Here's a portion of Debian"s dhclient.conf:

#prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope, interface-mtu;
#require subnet-mask, domain-name-servers;

The "netbios-name-servers" and "netbios-scope" options can, and probably should be removed, too. I can't imagine why anyone would need that data from a residential ISP.

Just as a test, I configured dhclient to request the "interface-mtu" option on an Ubuntu box here. My DHCP server (ISC dhcpd, 3.x) refused to return anything for the option, so I'm guessing the cable companies are using something other than ISC for their DHCP server.

I typically spell it: Mark.

The folks at Panera Bread so far spell it one of three ways:

Marc
Mar
Merk

It's not.. too hard of a name, is it?

A friend of mine recently gave me his old Sun Ultra 10 workstation, which was apparently headed for the dump. The hardware is in pristine condition, aside from the power button and LED being initially disconnected, which I corrected. I also had to resolder the PC speaker connections.

I installed the latest version of Solaris 10, which ended up being the 6/06 release. As expected, the freeware (companion disc) packages had all sorts of broken dependencies. I had to roll a couple things by hand, which took ... awhile.

Thinking that I might want to play around with CDE (nostalgic value, only), I picked up a cheap PCI USB 2.0 host adapter with the intent of connecting it to my KVM. The first mistake was not checking for compatible adapters, so I ended up with stuff like this:

[...] (ehci0): Due to recently discovered incompatibilities
[...] (ehci0): with this USB controller, USB2.x transfer
[...] (ehci0): support has been disabled. This device will
[...] (ehci0): continue to function as a USB1.x controller.
[...] (ehci0): If you are interested in enabling USB2.x
[...] (ehci0): support please, refer to the ehci(7D) man page.
[...] (ehci0): Please also refer to www.sun.com/io for
[...] (ehci0): Solaris Ready products and to
[...] (ehci0): www.sun.com/bigadmin/hcl for additional
[...] (ehci0): compatible USB products.

I don't think it even works correctly as a 1.x controller, either. No amount of changes to /usr/openwin/server/etc/OWconfig seemed to make the mouse or keyboard work, and if the system boots with both plugged in, mounting of the root filesystem times out. (What the heck?) Ah well..

I need to stop missing cool new features in OpenSSH. For example, the -w option seems to have slipped in under my nose. From the manpage:

Requests a tun(4) device on the client (first tunnel arg) and server (second tunnel arg). The devices may be specified by numerical ID or the keyword ``any'', which uses the next avail-able tunnel device. See also the Tunnel directive in ssh_config(5).

So.. EoSSH, anyone?

In other news, it's fun to confuse waitresses at Macaroni Grill. This tends to result in free meals.