Re: [patch] Add support for Kurobox Pro to Debian Installer

["Per Andersson" <avtobiff@gmail.com>]

On Wed, Jul 16, 2008 at 4:33 PM, Jérémy Bobbio <lunar@debian.org> wrote:
> On Wed, Jul 16, 2008 at 04:25:21PM +0200, Per Andersson wrote:
>> > As far as I have seen, a KuroBox Pro has, out of the box, a writable
>> > filesystem in one of the mtdblock that is used as the system root.
>> > IIRC, there is enough room on this filesystem to store a standard d-i
>> > kernel and initrd.
>> >
>> > Is there anything that prevent such scheme to work?  I would find the
>> > process easier than eventually having to wipe an already existing
>> > hard drive to store the d-i images.
>>
>> No, it works. Earlier I wrote d-i kernel and ramdisk directly to
>> flash partitions and load them. It works but destroys the
>> original firmware.
>
> Why?  Can't a path for a specific kernel be specified to uBoot?

AFAIK not when loaded from flash. When you load binary
files from flash you use nboot, which works like this

nboot addr mtdblock offset

addr, is where to load the file (into memory),
mtdblock, which block to read from,
offset, how much to skip before starting read.

With ext2load OTOH it is possible to define a specific path.


>> Even though having a disk inside the Kurobox Pro makes it impossible
>> to boot the original firmware without a serial console, it can be a
>> good thing to keep it.
>
> Use case:
>  * I have installed Debian on my Kurobox Pro and have been an happy
>   user.
>  * One day, I manage to remove /usr by doing sysadmin work before the
>   morning coffee.
>  * I would be happy to be able to use the debian-installer again but
>   without having to format /dev/sda1 partition in order to keep what
>   was in /home.

This would still work, a critical assumption, that I forgot to
mention, is that /dev/sda1 has to be mounted as /boot.

So with your use case you would just boot the device,
login backup current kernel and ramdisk in /boot. Put d-i
images in /boot, reboot, et voilá, you are in d-i with your
system intact (or broken, due to the use case).


> It might not be the best use case, as what I would actually prefer would
> be to be able to install the root filesystem on the mtdblock, but it
> sounds like an acceptable one as well.

I agree. It is not possible to install to MTD because of
parted/partman limitations (lacks MTD support).

I plan to work on this after summer.


-- Per