Both of the two issues demonstrate how important is to really pay attention to all details when flashing the NSLU2 firmware, even by experienced heavy-weights. It really doesn’t pay off to skip ahead! Firstly, after a successful flash, I didn’t know how to proceed with unslinging the firmware to external USB disk drive, rather than keeping it in the internal flash storage (all this in order to be able to start installing additional packages, such as openssh etc). I could not find the instructions on any of the two above websites. After a little moment I found the detailed and very well written instructions packaged inside the zip file with the firmware (Unslung-6.8-beta-README.txt).

The second problem occurred, how surprising, again after I skipped ahead a tiny bit of the README file. I connected the external USB disk to the port 1 and executed

/sbin/unsling disk1

This, however, did not work, the disk was not found (and it wasn’t displayed in the Linksys web interface either). I assumed the problem was the fact that I’ve formatted the disk already before, with the original NSLU2 firmware. Because I didn’t have any important data on the disk yet, I decided to use the web interface to format the disk again. Despite the “Formatting…” message in the interface, there was no disk activity and the disk again wasn’t recognized after the subsequent reboot. After consulting the README file and actually following what was written there (i.e. using the port 2) the disk was recognized and I could continue. The disk, formatted using the NSLU2 in question with the original Linksys firmware, did not have to be re-formatted to work with Unslung-6.8-beta, the data are accessible without problems. The only this that changed was the Samba share name assigned by the device by default (DISK 2 instead of DISK 1).

I guess the moral of the story is that README files are here to be read and in case of anything related to NSLU2 firmware upgrade read at least twice.

The X session would not initialize because of the following error:

X.Org X Server 1.4.0.1
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.20-1.3002.fc6xen i686
Current Operating System: Linux tank.matrix.local 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686
Build Date: 13 November 2007 05:47:17PM
Build ID: xorg-x11-server 1.4.99.1-0.10.fc9
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/var/log/Xorg.0.log”, Time: Thu Nov 15 22:31:35 2007
(==) Using config file: “/etc/X11/xorg.conf”
dlopen: /usr/lib/xorg/modules/drivers//nvidia_drv.so: undefined symbol: xf86GetPciVideoInfo
(EE) Failed to load /usr/lib/xorg/modules/drivers//nvidia_drv.so
(EE) Failed to load module “nvidia” (loader failed, 7)
(EE) No drivers available.Fatal server error:
no screens found
giving up.
xinit: Connection refused (errno 111): unable to connect to X server
xinit: No such process (errno 3): Server error

I immediately thought that the update broke something related to Nvidia driver, see the undefined symbol above. So I re-installed the driver:

[ikendra@tank][~] sudo yum remove kmod-nvidia
[ikendra@tank][~] sudo yum install kmod-nvidia

This didn’t help and I started to suspect Fedora from releasing a broken update. However, because I have never seen such a major problem after Fedora update, I decided to log on IRC to discuss this with competent people. On the #fedora-qa channel I chatted with a friendly and helpful tester from Fedora, Will Woods. After a few questions, he found the root cause of the problem: I had the fedora-development repository enabled which means that the packages from current development head repository were downloaded. This was easy to be confirmed by issuing

[ikendra@tank][~] cat /var/log/yum.log | grep “fc9″

So it was entirely my mistake. Will asked me, what made me enable the repository at the first place. Good question! I confused fedora-development with fedora-updates-testing – I was interested in the test updates not realizing that I enabled the Rawhide repository. Although I was entirely aware of the fact that the Rawhide cannot be considered stable, I wasn’t aware of the fact I was actually enabling it and the UI did not warn me:

I tried to save the day by disabling the fedora-development repository and issuing…

[ikendra@tank][~] sudo yum install yum-utils
[ikendra@tank][~] package-cleanup –orphans

…to get the list of all fc9 package installed in order to remove them and re-install the fc8 packages – the list was however too long, I will have to reinstall the system. I was glad that Will acknowledged the fact that the repository name “fedora-development” was confusing. It was a good school for me, too, but I could have imagined to spend the evening in a different way!

Due to a change in the way that the Linux kernel handles storage devices, the device names like /dev/hdX or /dev/sdX may differ from the values used in earlier releases. In Fedora 7, for instance the first partition on my first disk (ATA) is now

/dev/sda1

instead of

/dev/hda1

and for instance the first partition on my second disk (SATA) is now named

/dev/sdb1

instead of

/dev/sda1

I wasn’t aware of this change before upgrading to Fedora 7. And because I had previously modified my /etc/fstab manually using the device names linked to the mount points instead of using labels, Fedora 7 installer now refused to upgrade.

The solution was to boot back to the original installation and to run “e2label” to create a label for each partition on your disk. It is pretty simple:

[ikendra@tank][~] sudo /sbin/e2label /dev/hda6 HOME

After that, modify your /etc/fstab to use the labels instead of device names. Example: modify the fstab line which used to be for instance

/dev/hda6 /home ext3 defaults 1 2

to

LABEL=HOME /home ext3 defaults 1 2

I recommend a single reboot to the original Fedora installation to check if all partitions were mounted as expected. After that, run the installer again, it will work.