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 _______________________________________________ pkg-fso-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint
