[pkg-fso-maint] [PATCH] install.sh: add $SD_PART1_SIZE and $SD_SWAP_SIZE user variables

[Steffen Moeller]

Hello again,

Luca Capello wrote:

> On Wed, 18 Feb 2009 22:39:47 +0100, Steffen Moeller wrote:
>> Luca Capello wrote:
>>> 1) why would one like a bigger /boot partition?
>>>
>>>    * please always think about the ordinary user, i.e. someone who
>>>      installs Debian on the Openmoko without being an expert GNU/Linux
>>>      user
>> It is because the first partition is also /media/card in Qtopia and a
>> series of applications share it with the booting for Debian. The phone
>> number database goes there, or the OpenStreetMap data, or ...
> 
> There is an important fact to be clear here: the /boot partition *must*
> contain everything which is needed to boot the machine and that is all,
> no more, no less.  Thus, I would say that we should not care about a bug
> in other distributions, otherwise we end up adding workaround for
> everything.
> 
> I know I am a bit harsh, here: the fact that Qtopia (or $WHATEVER) not
> automatically mounts, but also automatically uses the microSDHC is a
> bug, no matter what I think.  And it should be solved there, not on the
> Debian side, which BTW does not ship any Qtopia software (yet, because
> sometime in the future it could do it as there is interest for it [1]).
> 
> [1] http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2008-November/000321.html
> 
> If Qtopia (or $WHATEVER) wants to go on with this behavior (which BTW is
> against the FHS [2], to which Debian adheres), there could be another
> solution: installing everything on a single partition, which is possible
> with Qi (I have never tried it and probably will never try), but not
> with U-Boot (and this is a bug in the latter as well).

Apparently I perceive the world as less buggy/evil here. For a start, a larger boot
partition is a safe bet, IMO. It doet not cost us much to allow for that.


> [2] http://www.pathname.com/fhs/
> 
>>>    * there is no automatic way to switch between various U-Boot kernel
>>>      images (the reason for a bigger /boot partition), thus if you know
>>>      how to deal with symlinks and know what you are doing, then you
>>>      also know how to manually create a bigger /boot partition since the
>>>      beginning (this is why install.sh is separated into self-contained
>>>      stages)
>> With vfat there is no symlinks, so one would rename to uImage.bin
>> whataver shall be used.
> 
> My fault, sorry.
> 
>> I would now for instance copy the 2.6.24 version next to the installed
>> 2.6.28 one and start comparing the two more.
> 
> I, at least, will support only one Debian kernel version, the latest
> packaged.  This because not only building the kernel is time consuming
> (it requires at least 5-6 hours on a native ARM machine, not the FR, and
> with a minimum set of modules), but because I am already out of time.
> Moreover, AFAIK there is no kernel hacker in the pkg-fso team, which
> means that the low-level support we can provide for the kernel is really
> suboptimal.

The option for a larger boot partition from my understanding is not adding to anything
that you should support. It only increases freedom for users.

> 
> In your case, a better option would be to install upstream FSO-MS5
> kernel, which should behave exactly like the Debian one, since the
> latter has been compiled with the same config.  Then, if you find a bug
> in both kernels, the bug is upstream, otherwise it is Debian-specific.

Good plan!

>>> 2) why do you need a swap partition?  I have not followed the
>>>    discussion on this matter, so providing link to constructive
>>>    threads is enough
> 
> This question is still valid, but I would prefer to discuss it in a
> proper thread, where only the swap partition issue (and not also the
> /boot on vfat one) is dealt with.

Started it.

>>>>  # run partitioner
>>>> -if [ "$SD_PART1_FS" = "vfat" ]; then
>>>> +rootpartno=2
>>>> +bootfstypeno=83
>>> Please, use uppercase variables.
>> They are intentionally lowercase since they are of internal use only.
> 
> I was expecting this answer: in this case, I would prefix them with
> something like INT_NAME.

Fine. If you could accept (what you want to accept) the way it is, then I will go over it
and change variable names to receive an "intern_" prefix.

>>>> +if [ "vfat" = "$SD_PART1_FS" ]; then
>>> Semantically, this test (and some following ones) order is wrong.
>> I did not know how to change a patch afterwards. I wished you would
>> decide over that functionality by looking at the latest version. I had
>> added some logics to allow the swap partition to be the last partition
>> of the device.
> 
> The problem here is the workflow when you submit patches: if you submit
> single-issue patches, it is easier to submit a new version afterwards.
> 
> BTW, there is no way to modify a patch once it has been applied without
> providing a new commit.  In your case, what you should have done is
> 
>   $ git reset $COMMIT_BEFORE_YOUR_PATCH
>   [do your corrections]
>   $ git commit
>   $ git format-patch
>   $ git send-email

Many thanks!

Should I better follow Joachim's suggestion to find a publicly accessible location of my
git repository? Every change would then become a branch, and you diff against or between
these branches, right?

For now, I wish you could accept of what seems remotely acceptable for you, and you
specify a list of changes that I should come up with for me to chase up. Maybe a second
file, install-dev.sh, would be a good target? Or the current one becomes install-stable.sh?

>>>> +	if fdisk $SD_DEVICE < /tmp/argsToFdisk$$; then
>>>> +		echo "Partitioning was successful."
>>>> +		#rm /tmp/argsToFdisk$$
>>>> +	else
>>>> +		echo "Partitioning failed, could not execute with fdisk:"
>>>> +		cat /tmp/argsToFdisk$$
>>>> +		exit -1
>>>> +	fi
>>> I am not sure if this is clearer: I would prefer the previous way of
>>> partitioning, because it is easier to repeat manually (you just
>>> follow the order the commands are given).
>> If something went wrong, then cat `ls -lt /tmp/argsToFdisk*|head -1`
>> will print the commands sent to fdisk.
There seems to be a bug with busybox since "head -1" does not seem to work there.

> While I agree on this, IMHO it renders the install.sh script harder to
> read, because different conditions are mixed together.

You mean the single vs the dual partition setups, right? I had felt that this would help
to reduce the redundancy in code. A triple-partition setup with swap was a straight
extension. And adding a fourth would now be no problem either. So, it felt right to me
(having the situation after patch 9 in mind).

Many greetings

Steffen