tce bootcode

[JohnS]

Hi all.. I'm using TC as a base OS for an embedded device, and also for the installer for that device...

I put TC+installer onto a USB key using unetbootin, then plug the USB key into the device, and boot to an installer.. The installer then installs TC onto the device (along with the application)..

In the boot params for the USB key's TC, I specifiy the TCE directory, in this case sdb1... I have to do this, because if I don't, the autodetect will find the /tce on sda1 on the device itself (if we're updating a previous install)..

This works for the most part..

The problem we're running into, is that occasionally, we run into USB keys that do not have a partition table. The entire device is a single partition, so it gets mounted as sdb, instead of sdb1...

Is there any trick to the tce bootcode so that I can specify 2 areas to look /tce? (in this case, sdb and sdb1)?

My other solution is to modify unetbootin to fdisk these oddball keys, which is something I would prefer to avoid, since the keys may have other data that they don't want to lose..

[roberts]

Use UUID or LABEL see: http://distro.ibiblio.org/tinycorelinux/faq.html#pendrives

BTW tc-install automatically uses UUID

[JohnS]

The problem is that I don't know ahead of time what the UUID or the label is..

How it currently works is that I created a series of extensions that contain the drivers, installer, and application for the device.. I then build up an iso image from those... At this point, I create the isolinux.cfg, which contains the boot params... The iso image then gets embedded into a self-extracting acrhive with branded version of unetbootin...

The client will then download this archive, run it, and proceed to burn the iso to the USB drive that they supply... Somehow, the way the unetbootin does it, it uses the existing partition on the USB drive, and makes it bootable..

So in this case, I do not know the label or the UUID... I suppose I could modify unetbootin to try and get the uuid and re-write the isolinux.cfg, but then I would need to do that on windows, linux and mac..

Any other thoughts?

[maro]

I'm not sure whether I understand why and how you are using 'unetbootin' as I've got zero experience with that tool. But I'm pretty sure that you've got not much of an alternative to using 'tce=UUID=...' in the boot loader configuration of the target device. This is due to the "Never, ever use a hard coded device name like 'sdb' or 'sdb1' in a boot loader configuration file" rule. Maybe in your case using 'tce=LABEL=...' might be better, if you can force the label of the target device to a specific value.

So I guess you'll have to somewhat "clue up" the 'unetbootin' process. After browsing around the unetbootin home page for a short time I wonder how you are approaching this: Do you use some sort of a plugin, or are you releasing a custom build? In any case I've noticed that the source code contains a 'getuuid()' method (in the 'unetbootin.cpp' file), but I could not identify any usage example of said method. But if you create a customised version of 'unetbootin' I'd imagine you could use that method for your needs (albeit for the "price" of having to compile up to three executables).

[Rich]

Hi JohnS
Since the client has to provide the USB drive, you could require them to set the volume name to a
specific label.

[curaga]

Alternatively, put the installer files in a second initrd, and boot with the base bootcode. You'd need to scan for the usb stick, but this way there'd be no need for the stick to be mounted for the TC boot.

[JohnS]

@Rich: Can't do that, the clients are assumed computer illiterate (farmers, device runs on a tractor (well, drives the tractor actually.. So all you TC devs, your stuff is grown up, and driving now, though without a license..)..

@curaga, @maro: Both of these sound good.. We're going to be 'branding' unetbootin, so modifying it is somewhat reasonable.. I didn't realize that they had a get uuid/label method already.. I was assuming the worst.. That'll make the whole process easier..

I had never heard of multiple initrd's, so if plan A doesn't work out, I'll investigate that..

Thank you!

[curaga]

It's called dynamic root fs remastering in the wiki, IIRC.

[JohnS]

Just a quick update...

I was able to successfully use the UUID in the bootparams, and catch that in my install scripts.. Using a method in /etc/init.d/tc-functions, I was able to translate the UUID to the real mountpoint..

In other words: Success!

Thanx for the ideas everyone.