[pkg-fso-maint] [PATCH] install.sh: add support for vfat on the /boot partition (was Re: install.sh - 4 proposals for patches)

[Steffen Moeller]

Hi Luca,

Luca Capello wrote:


> On Fri, 13 Feb 2009 02:47:31 +0100, Steffen Moeller wrote:
>>> >From 865dcafc9ef910746dd5420de9381d9c7b6ac464 Mon Sep 17 00:00:00 2001
[...]

> 
>> -Thus, you should continue at your own risk.
>> +Thus, you should continue at your own risk. You can still use Debian's
>> +kernel for the OpenMoko, just don't mount your vfat boot partition to /boot
>> +yet. Install the regular kernel package, then manually copy /boot/uImage.bin
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is not possible if /boot is on vfat

only if the vfat is already mounted to /boot at the time that dpkg is executed.
I suggest not to mount and instead to copy over manually afterwards. My main concern is
that the regular user should not be demotivated of using vfat. Otherwise, the qtopia would
stop working and at least I am myself not prepared to victimise that for the moment. The
message as it is put for the moment seems likely to be a hurdle for newbies.

>   http://lists.linuxtogo.org/pipermail/smartphones-userland/2008-November/000456.html
> 
> Thus, if we really want to support /boot on vfat (if it was not clear, I
> do not), we need something similar (but not the same) to the
> cdebootstrap installation.  Would you mind implementing it?  The idea is
> simple: the kernel stage is wrapped into a big if/else statement:

You mean that cdebootstrap should get a bootdir argument. Hm. We might truly need that for
the debian-installer.

> --8<---------------cut here---------------start------------->8---
> if [ "$SD_PART1_FS" = "vfat" ]; then
> 	# download (but not install) the Debian kernel with apt-get,
> 	# then extract it into the correct place
> 	# please use only Debian tools, i.e. apt-get and dpkg
> else
> 	chroot $INST_DIR /bin/sh -e <<__END_CHROOT__
> apt-get --yes install linux-image-2.6.28-openmoko-gta02
> apt-get clean
> __END_CHROOT__
> fi
> --8<---------------cut here---------------end--------------->8---

The above is something different (and easier). I still think the first partition should
not be mounted to the boot directory of the SD by default. If so, then the sniplet from
above would read in my simplified 'don't mount boot' version:

--8<---------------cut here---------------start------------->8---
chroot $INST_DIR /bin/sh -e <<__END_CHROOT__
apt-get --yes install linux-image-2.6.28-openmoko-gta02
apt-get clean
__END_CHROOT__

if [ "$SD_PART1_FS" = "vfat" ]; then
	echo "Copying over the kernel to the vfat boot partition."
	BOOTDIR=""
	NEWLYMOUNTED=""
	if mount|cut -f1 -d\  | grep -q "/dev/mm*p0"; then
		BOOTDIR=$(mount| grep "^/dev/mm*p0"|cut -f3 -d\  )	
	else
		BOOTDIR="/tmp/bootdir_for_process_$$"
		if [ -d "$BOOTDIR" ]; then	
			echo "Found directory '$BOOTDIR' to already exist. This should not  happen."
			exit 1
		fi
		mkdir "$BOOTDIR"
	
		mount /dev/mm*p0 "$BOOTDIR"
		NEWLYMOUNTED="true"
	if

	cp $INST_DIR/boot/uImage.bin $BOOTDIR
	
	if [ "true" = "$NEWLYMOUNTED" ]; then
		umount "$BOOTDIR"
		rmdir "$BOOTDIR"
	fi
	
fi
--8<---------------cut here---------------end--------------->8---

It is longer than I had expected. And I need to test it, still. I could possibly also have
unmounted the boot directory from the chroot prior to runnign dpkg. However, you have
noticed that with this approach, all the bits that go into installing to the Debian /boot
can be shared with the vfat approach. I like that. It is so easy that I had previously
thought that the user should do it manually. And the possibly unfortunate wording from
above should have stimulated the user to do so. If you can agree to the above, then I
would prepare a patch for it that I have then also tested.

I'll check out what the Debian installer will say about it. From my current perception,
the debchroot utility should not be hapered with. It should just perform its installation.
The install scripts should have the complete picture, instead. But I may change my mind
upon some first looks at how d-i works internally.

Best regards,

Steffen