First time installation observations

I found your excellent tutorial and installation procedure a few days ago, when trying to determine if I should install PogoLinux or OpenWRT on my Dockstar. I was quite glad to find a Debian install since I'm very familiar with Debian, though I have no familiarity with the ARM architecture at all. The installation went ok. I ran into a annoyances which I'm posting here to hopefully help the next person, and possibly better your installation system.

I decided to partition a 1GB USB stick from the default Pogo shell environment. I noticed that hbplug automounted the disk as vfat since it was fat32 formated, but I couldn't unmount it; the device was busy. For giggles I decided to try and re-partition it via fdisk anyway. (BTW fdisk is not in the path so you need to use /sbin/fdisk or "busybox fdisk.") Surprisingly it let me do so even though it was mounted. I still couldn't unmount the disk so I removed and re-inserted it. The automounter again stupidly mounted it as vfat. Very bizarre. And I still couldn't unmount it but I decided to ignore it and try to continue anyway, hoping your installer script had some way of dealing with this.

So I continued following the tutorial, downloading and running the installer. Everything was humming along fine. I said OK to stop the Pogoplug service since I wouldn't need it anymore anyway. The uBoot mtd0 partition was wiped and replaced. Then the script failed. Ouch. Why? Apparently /dev/sda wasn't valid so both mke2fs and mkswap failed. And the script exited out.

This caught my attention because I knew it was there before. I took a look at the script to see what exactly it tried, and I did some experimentation by restarting the Pogoplug service. If you killall the hbwd service, anything mounted by hbplug gets removed, but cannot be remounted. They only way to remount was to remove and re-insert my stick.

You may want to account for this in the install script by checking the mounts first and displaying some text to remove it. Now I'm also curious what would happen if I didn't say OK to stop the Pogoplug service but that train has left already. I would also suggest doing this before replacing uBoot. My heart skipped a beat when I saw that the installer script failed after replacing uBoot. I knew that if I powered down the box now it would be lost until I get my CA-42 cable (which is still in transit.)

Once I figured out what was wrong, I just killed hbwd and re-inserted my USB stick before re-running the script. It happily picked right up from where it left off but then had a problem getting debootstrap. The default cdn.debian.net mirror was unreachable. I couldn't even ping it from any of my systems. I found it in the script and just changed the mirror to ftp.us.debian.org which is what I use on all my other systems (after confirming that was pingable, just in case.) I restarted the script again, let it run and voila! Debian is now running on my dockstar :)

root@debian:~# uname -a
Linux debian 2.6.32-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux

Thanks! I now have a new toy. I plan on using it as both a NAS and a print server but have some questions on how to get there ... The system seems pretty sparse looking at "dpkg --list".

I assume it's ok for me to just "apt-get install" packages now? (First thing I'd install is aptitude.) Is it also safe to "apt-get upgrade" the entire system or do I need to be careful with that?

On my Debian desktops, removable disks are automounted via gnome-volume-manager. How do you all accomplish this without gnome? I see udev but I found no rules regarding automounting. Do I need to craft them myself? Is there some other package I should install to provide this? Any guidance would be appreciated.

If Jeff's script fails after installing Uboot but before finishing the Debian installation, you're not lost without a serial cable. The script saves a backup of the original boot loader to the internal Pogo flash memory partition and the new Uboot chainloads it to start the Pogoplug system if no external bootable device is detected and the Pogoplug system hasn't been replaced by the rescue system.

The Debian installation is a minimal installation (the "minbase" variant) of Debian Squeeze. You can build up from the minbase installation by installing more packages with apt-get. Before starting the script, you could have modified it and changed the variant to get a more complete system (which of course takes more space and has more background tasks running). See Debian debootstrap tutorials for more details.

Hey thanks for the reply. So the new uBoot chain loads a copy of the old uBoot if it can't find a root file system on /dev/sda1? If I remove my boot /dev/sda flash drive, will the system boot back into Pogoplug or is this just a fallback during the installation?

Last night I was thinking about exactly what you suggested. I was just cautious about running apt. But I figured I have a serial cable on the way so I can always recover so why not give it a try. I wound up apt-get installing aptitude and tasksel and then used tasksel to install the print and file server packages.

But my original question remains, am I ok to fully apt upgrade? Should I pin any packages, like the kernel?

kraqh3d Wrote:
-------------------------------------------------------
> Hey thanks for the reply. So the new uBoot chain
> loads a copy of the old uBoot if it can't find a
> root file system on /dev/sda1? If I remove my
> boot /dev/sda flash drive, will the system boot
> back into Pogoplug or is this just a fallback
> during the installation?

The original U-Boot in mtd0 is replaced by Jeff U-Boot, no more chain load after you successfully install Debian Squeeze into your USB stick.

> But my original question remains, am I ok to fully apt upgrade?
> Should I pin any packages, like the kernel?

Why don't you make a complete backup your USB stick and try, if anything goes wrong you just restore the stick.

The boot scripts installed by Jeff's Uboot installation script try three different boot sources: An external OS on one of the USB ports, an internal rescue system and the old Pogoplug system. To load the old Pogoplug system, if it hasn't been replaced by a rescue system or something else, the scripts chainload a backup copy of the original boot loader which then executes the original boot parameters which still reside in a part of mtd0 that isn't overwritten by the new boot loader. The Debian installer does not wreck or delete the Pogoplug system. If you remove the USB stick, the boot loader looks for a rescue system in the internal flash memory and if there isn't one then it attempts to load the old Pogoplug system.

Regarding the distribution upgrade: Kernel package updates have been a problem because the kernel and the initial ramdisk need to be in a special format so that the boot loader can load and start them. I don't know if that's been solved or not, but be aware of that potential pitfall. Except for the boot loader part, the Debian on the Dockstar is not much different from other installations. The processor architecture is abstracted away by the package management system, so use and manage the system like you would use and manage any other Debian installation.

John Doe Wrote:
-------------------------------------------------------
> the scripts chainload a backup
> copy of the original boot loader which then
> executes the original boot parameters which still
> reside in a part of mtd0 that isn't overwritten by
> the new boot loader.

1) Size of the stock U-Boot and Jeff U-Boot are both 512KBytes.
2) The first 512KBytes were being completely erased before installation of Jeff U-Boot
2) By checking the mtd0 install script both the Jeff U-Boot and the stock U-Boot are located in the first 512KBytes of mtd0.
3) Stock U-Boot reads and writes its environment to NAND at 0xa0000 on mtd0 while Jeff U-Boot at 0xc0000,so 0xa0000-0xbffff (the stock U-Boot environment) is the only area left un-touch but it is not used by the new U-Boot.
4) Backup of the stock U-Boot is stored as file "uboot-original-mtd0.kwb" in Pogoplug rootfs in mtd2 and will be fsload by Jeff U-Boot when the USB or rescue system is not detected upon boot up.



Edited 2 time(s). Last edit at 01/20/2011 06:19PM by sluk.

Thanks for the replies. I did all of that already this past weekend :)

I didn't understand the new U-boot system. But I figured I couldn't really screw anything up so I just booted up with my Debian boot stick removed. It booted right into Pogo. Thats when I figured out its loading the kwb file from mtd2. Pretty cool.

I also made a dd copy of my boot stick as a backup before doing a full aptitude safe-upgrade. Everything seems good. (Here's a question... I'm planning on picking up another dockstar. On that one I would just need to do the U-boot install, and it will boot up from a dd image that I copy to another usb stick, right?)

My next thing will be to install the rescue system but it seems like there's still a minor issue with it if I use the correct arcNumber which provides LED support on the kirkwood kernel. But I've been away from the forums for a bit so I need to see what the latest is.

A different Dockstar with an updated U-boot and Jeff's boot scripts will boot from a byte-for-byte copy of an existing Dockstar Debian installation, but it won't be accessible over the net, due to some device naming magic. It sees the new Dockstar's Ethernet interface as a new device because it has a different MAC address, so it makes it eth1. Since all network configuration data is for eth0, you won't be able to access it. There are multiple ways to approach this problem. You'll find them by searching this forum.

Or just look here:

http://forum.doozan.com/read.php?2,3465,3649,page=1#msg-3649

Hey thanks for that tip. That really would've annoyed the heck out of me for a while. Thankfully it's easy to fix by mounting the copy and removing the /etc/udev/permanent-net.rules file which maps interface by mac address before booting it on the other dockstar. (Hmm... any other persistent rules that may need to be removed??) It probably would even make sense to keep a backup of the virgin image for later recovery purposes. From reading the forums, it sounds like the file system can get corrupted.

restamp Wrote:
-------------------------------------------------------
> Or just look here:
>
> http://forum.doozan.com/read.php?2,3465,3649,page=
> 1#msg-3649


restamp, the link points back to this page.

Oops. I have no idea how that happened. How about:

http://forum.doozan.com/read.php?3,323,2038#msg-2038

Thanks! it's great to be able to use the same stick and let the system figure out eth0.

While I have sadly "first time installed" far too many times attempting to get a project to completion on my Dockstar, I was curious about something. I decided after about the 5th reinstall that I prefered a swapfile rather than a swap partition. So I decided to not create the swap partition. Fortunately the install script doesn't seem very bothered by this, just whines a bit and installs Debian anyhow.

While I did this to make it a bit easier for me to alter the size of the swapfile as I see fit and conserve as much space as I can on my USB stick (which is also the reason for the multiple reinstalls) is there any downside to not having a swap partition? According to what little I could research on the subject, a swapfile is supposed to be just as fast in any recent kernels.

Swap is orders of magnitude slower than memory so I don't think it will make much of a difference really. The biggest gotcha with swap files is that you really want them to be allocated on contiguous disk space. When its fragmented, its even slower. And you don't necessarily even need any swap if everything you run fits in the available memory.

My experience is that swap space isn't needed during the Debian installation, and afterwards a swap file is much more flexible than a swap partition. Swap avoids the file system overhead either way, so there is no slowdown from using a swap file instead of a swap partition. Placement of the swap space and fragmentation may be an issue on spinning disk storage. Unless the file system is heavily fragmented and almost full when you create the swap file, fragmentation is not going to be a problem. Placement considerations like putting the swap space in the fastest area of a spinning disk are always trade-offs, because that also places the swap farther away from other data, which results in longer seek times. Solid state storage has negligible seek times anyway. Like Kraqh3d already mentioned, once the system starts swapping, it's going to be dead slow no matter what you do, so a few percent faster or slower don't make a difference. Swap is important for keeping rarely used pages out of main memory, and for that, swap performance doesn't matter. (The official stance on swap performance is that swap files are not slower than swap partitions. All I'm saying is that there might be some rather unlikely situations when that isn't exactly the whole truth, but even then it doesn't matter. I'm using a swap file.)