Installing Debian on "Slug" NSLU2

Essence of this blogpost: Log in with a shell on the device to tail the syslog while the installer runs for much finer grained feedback during install. This can be OK, since it often takes "half a year" to format the disk and install the device, and one start to wonder whether it is hung.

How cool: You can install the actual Debian newest version 5.0 system onto a Slug!

This is a quick note on the installation of the Cisco Linksys NSLU2 device.

The debian install works like this: You "upgrade" the device "to the installer" using one of three methods, one of which is to simply use the web console of the device and direct that to the "di-nslu2.bin" file you downloaded.

The device then reboots, and after some minutes emits three beeps. You now log in to it using ssh (for Windowers, this means putty). The standard ip of any new Slug is 192.168.1.77, but if you enabled DHCP using the web console before you "updated the firmware", it will still use DHCP after booting, normally getting the address it got the first time (DHCP clients always asks for the same IP they got the first time from a DHCP server), or being given the static configured DHCP IP address you've configured on the DHCP server (which IMHO is the right thing to do).

The username/password is installer/install. You end up on the "Network console for the Debian installer". Here you can select either "install it damnit" or "install (expert mode)", or "start shell".

You select one of the install options, and you're on your way.

The point of this blogpost is that the installer takes some time (like in the 4 hour range!). And just the formatting of a 1TB disk takes at least a full hour, where at least 95% of the time the progress bar shows "33% finished"! This makes one wonder what is happening.

What is cool, is that one can log in once more to the installer. This time, select "Start shell". Now tail the syslog:

cd /var/log
tail -f syslog


.. or, when the device is formatting your disk, which takes ages, instead tail "partman". Ctrl-C to stop. Since the Slug has very little memory, you should not do much creative stuff with the shell you've got there during the install, or else the installer itself might be terminated by Linux' OutOfMemoryKiller.

Subversive svn: authentication cancelled

I just wanted to record this for anyone that gets a problem that I had, as I didn't find the solution "by the way of Google". Do note that I'm no expert on either Subversion or Subversive..!

Before doing anything described here, please back up your workspace! I'm not talking about fetching that monster tape drive, install and run some huge backup software and then ship the tapes off to another continent - just make a copy somwhere of your Eclipse workspace. This so that you can start over, trying another angle, when things doesn't work out and your whole workspace is accidentially encrypted using your lavalamp's current formation as the key! (You then shut down Eclipse, delete your workspace, and "restore" the backup by copying it back. Start eclipse, and try your new approach.)

Before going further, first just attempt to start Eclipse with the "-clean" argument. You should not even need to worry about that backup then - and it might fix everything.

I have recently upgraded Eclipse to 3.4.0. I backed up my Workspace to some temp space, and then just pointed the new Eclipse to the same Workspace (the existing, "old" copy..). This magically worked nearly flawlessly: The Workbench looked exactly the same, all views set up the same, all Mylyn local tasks (which was the only type I had) was set up with contexts and everything.

But there were apparently some problems. The first one I don't quite remember, but Eclipse/Subversive at some point asked me if I wanted to reconnect to "the now-deleted repository location" something "https://blahabla...". And I then also noticed that all the Subversive markings (where you are (trunk), version numbers, colours, markings, whatevers you've configured Subversive to adorn your project with) were gone. I just said yes, and hoped for the best. Nothing happened. But after a reboot of Eclipse (I've found that much fixes itself by booting this application!), everything seemed to work.

But today, I wanted to commit something. This didn't work out at all, and in the Console window, I got "svn: authentication cancelled" and "blahblah Error". The annoying thing was that it just never asked me for credentials, so I couldn't give it my password (the username was saved, at least earlier). When this happened, Eclipse popped up a screen stating that some error had occurred (I don't remember the wording here, it was terse and useless), stopping up.

So, I did a couple of things which apparently seemed to work:

• Deleted "C:\Documents and Settings\<username>\Application Data\Subversion", based on this Oracle bug. You'll then be asked whether the certificate is correct etc etc upon next attempt to do Team->Update. Do note, however, that I don't think this is a part of the solution! So you may go ahead without doing this, at least the first round..
• Back up the project in question, in particular if you have heaps of uncommitted stash there! (If you don't have uncommitted data, you might just as well delete the entire project, and just start with a fresh checkout).
  
• Right-click on the problematic project -> Team -> Disconnect
• Choose "Do not delete the SVN meta-information (e.g. .svn subdirectories)", click Yes.
• After a while, you'll see that the project disconnects, and the Subversive markings disappears.
• Now, you go Right-click -> Team (Don't freak out by this menu being pretty much empty!) -> Share Project...
• Pick SVN (Obviously), click Next
  
• Pick the "Create location using project settings" (second choice here).
• You'll come to the "Enter Repository Location Information" page.
• At this point, the one thing that I immediately noticed, was that it suggested URL "https://blahblah/svn/<projectname>/trunk". I don't think the "trunk" part shall be a part of the location, so I removed it.
  
• Check the "Validate Repository Location on finish".
• Enter your username and password. I don't want to store the password, so I leave "Save password" unchecked.
• You may at that point click the "Browse" button to check if your URL is good - it should show the "branches", "tags", "trunk" directories.
• On the Advanced tab, check "Enable Structure Detection".
• I don't have anything fancy for the SSH Settings nor SSL Settings.
• When I clicked Finish, the Subversive markings reappeared, everything worked, and I could update and commit right away!
• Note that the repository location, which you may enable the project name node to be adorned with by Subversive, reads "https://blahblah/svn/<projectname>", leaving out the "trunk" part. The full text on my project name node is "[https://blahblah/svn/<projectname>: trunk]" - but this isn't standard config for Subversive, I believe.

The "trunk" in the URL stuff is actually what I think might have gone wrong the first time around with the first problem described above, where I just accepted what Eclipse suggested to me as solution. So this is furthermore what I suspect has been the reason behind the whole authentication cancelled thing: it really had the wrong URL, but the Subversive client handles this aspect (as it still points to the same place: either, wrongly, "trunk" on the URL and "" on the branch-selection, or more correctly, sans "trunk" on the url, but "trunk" on the branch-selection), but don't any longer know how to handle authentication..

Actually, I have ended up with something rather like this once before: I didn't know what URL Subversive wanted, so I navigated using the browse button, and navigated all the way into the "trunk" directory, as it was trunk I wanted to check out and work with, and I didn't immediately see any other way to select that. Subversive is seemingly quite happy with this, checking out your project and whatnot. But then, later in the game, things start to weird out. I don't quite remember how this manifested itself, but I do remember that I got some strange recursion problem, where I could see the entire trunk/branch/tags structure within my project. When I realized the URL thing, deleted the project and started anew, everything cleared up.

I think Subversive should be nice enough to point out that you've most probably navigated wrongly now, as the latter part of the SVN URL is at this point looks like a "known structural ending", and this should not be a part of the URL blah blah. See, Subversive does know what the standard structure of a SVN setup is - so it could easily have done this. I filed a bug about this (a year or so ago), but so far nothing have happened.

Update 2008-09-08: I got the same problem again some days ago. Subversive doesn't use the normal Preferences screen to define subversion repositories. It has its own view, called "SVN Repositories" (in the same way that Mylyn has "Task Repositories"). Here you can find the different repositories. Right click, and select "Location Properties..." (Not "Show properties", as that refers to subversion properties; Those things that you can stick on directories and files within the repo, e.g. "svn:ignore" @ trunk). Hitting the Location Properties, you get that Edit Repository Location dialog which I refer to in the above hundred or so bullets. If you here click the Browse button, you will get a username/password dialog (given that they aren't correct on the parent dialog). You should be able to browse the repository. When this works, stick in the username/password in the Edit Repository Location dialog again, tick off "Validate Repository Location on Finish", and hit the "Finish" button. The authentication problem is now gone.

In addition, I believe I might still be mistaken about what URL the location should be. I have now changed it to not include the <projectname> part as I stated above, as the URL without that part would be the location to the actual Subversion repository. This seems more logical (and it still works!).

Furthermore, after a couple of those "svn: authentication cancelled" rounds, I tried starting eclipse with the "-clean" argument. I have not had the problem afterwards. Whether it was the location URL, or the -clean that finally fixed it, I am not sure about, although I tend to believe the latter.

Finally, it is actually also possible to completely disconnect from the repository (Team->Disconnect), choosing "Also delete the SVN meta-information from the file system" from the Confirm Disconnect from SVN dialog. You can then Team->Share, make a new repository location, and from that pick the same project you have the files for. Subversive apparently realizes that the project name you try to share it as, already has information in it, and apparently checks it out at a temp location, then copy back the files, seemingly keeping your changes. I would however not bet on that - this really seems just as risky as to start afresh with a new checkout of the project. In any case here, back up your workspace before trying anything!!