Status of Debian Boot Project
- I got the latest 38MB Debian (from http://kuro.kaguya.biz/data/) to
boot on a spare hard drive that I swapped into my linkstation.
1) I had put the drive in a Linux workstation, partitioned it,
formatted it, etc.
2) I "un-tarred" the tarbell into the first partition.
3) I then copyied over /lib/modules/2.4.17-mv... (the kernel modules
directory) over to it from my V1.44 Linkstation OS.
4) I recreated some "node" files in /dev that existed on the
Linkstation's OS, but not the 36MB Debian. Things like /dev/wdt
(watchdog timer), /dev/fl0 - 5 (flash memory access), and a couple
of other things (all had a major node number of "10"). I expect
that the thing would have still booted without doing #3 & #4 above,
but I was being extra cautious.
5) Two users on the Debian were suppose to be "root" and "tmp-kun"
with passwords same as the names for both, but it didn't seem to
work, also the telnet wouldn't let you log in as "root" anyway
(granted for good reason, but anyway to overide this?). So I
cleared the password out of /etc/shadow for "tmp-kun" and "root",
changed permissions of /etc/shadow, to "666" booted up on the drive
and logged in as "tmp-kun". I attempted to "su" to root, but it
demanded a password even though there was none, so I run "passwd" to
change to password of "tmp-kun" so somthing so I could then copy the
same encrypted version over to root, but then that process had
re-restricted access to /etc/shadow! So out the drive came and back
into my workstation again. (Could I have cleared the "*"
from /etc/passwd's root entry and avoided this?). So in the
workstation I copied the encrypted password over and returned the
drive and rebooted the Linkstation. I logged in as "tmp-kun" then
"su root" entered the same password and "Got Root".
6) Oh, and the IP was 192.168.0.100. If you need to change it,
7) After this I changed the urls in /etc/apt/sources.list to point
at Debian "unstable" (and to a closer site than Japan), and did an
"apt-get dist-upgrade" to get everything updated to the latest and
greatest. That all worked great.
8) I added and deleted a few software entries from the system, but
didn't go "hog wild" like I did with my "chroot" environment over on
the original drive.
The idea was that I wanted to keep this image small, but up-to-date
in case we want to then distribute this thing as a Debian image for
other Linkstations. Here is the problem: Who has 40MB or so of
public space to host this thing? If someone wants it, I can get it
to them somehow for hosting, but I really don't have the upsteam
bandwidth to host it myself.
Because of this problem, I think I'll return to my original project
of trying to get "debootstrap" to work because then we just need to
distribute a small (under a meg) little tarbell that you untar and
Here is where I could use some ideas: There seems to be a few ways
to go about this. One is to do a "cross-debootrap" where you put
the drive in a non native machine (like your PC) that boots up in
Linux (a bootable CD like "Knoppix" would be fine too I think) and
build the whole thing off line.
The other way is to use the Linkstation OS itself for this. It
looks like I'll have to distribute a few missing binaries like
"md5sum", "sort", "wget", etc., so "debootstrap" would work, but all
this wouldn't amount to much. The problem will be how to transition
to it. It seems to me that you would have to build the file system
somewhere else (like /dev/hda3, like I did for my "chroot"
environment), but then, for it to boot, you have to somehow move it
back to /dev/hda1 (and probably make /dev/hda1 bigger anyway unless
you want to either keep is small or move /usr to hda3 or something).
How do you do that while running the OS on /dev/hda1 at the same
time? Can I use the "EM" mode as describe below?
Since both of these methods get ugly too, I think the most ideal
thing is to figure out how the Buffalo firmware upgrader does it and
use (mis-use) that mechanism somehow. I guess I need to take the
drive out of the Linkstation and force it into what the Kuro-box
forum people call the "EM" mode and see if I can figure out how it
works. Again, I'm afraid: I guess there is a string of "NGNGNGNG"s
(No-Good?) writen into one of the flash regions to flag the
bootloader about what is going on. To get it to boot a drive again,
you have to write a string of "OKOKOK"s (OK) to it. It seems like
you can telnet into the "EM" OS at any time and do stuff, but again
I don't want to risk turning the thing into a useless brick.
Be patient, hopefully someday we'll figure out how to make all this
Looking around on the forums on the revgear site, it looks like
while two people have successfully compiled and installed their own
kernels, two others turned their Linkstation/kuro-boxes into
doorstops. Not good. There are some projects forming to try to
write a better bootloader so that replacing kernels isn't so
dangerous! I would really like to run a more capable kernel on my
Linkstation, but I am very afraid at this point. For awhile, I
would even settle for the Kuro-box kernel, which seems to have most
of the stuff I want anyway. It kind of makes me wish I bought a
Kuro-box instead, but I didn't know about them at the time. Has
anyone been brave enough to try installing the Kuro-box firmware
(which I'm assuming also installs the Kuro-box kernel in flash) on
the Linkstation and have it work?