<font size=2 face="sans-serif">Hello Nikolaus and Andreas,</font>
<br>
<br><font size=2 face="sans-serif">> sudo does not pass the variables
on (security reasons, you could do funny things).</font>
<br><font size=2 face="sans-serif">> So makesd did not know about your
DEV=/dev/sdg</font>
<br>
<br><font size=2 face="sans-serif">indeed I aghastly realized that this
was the mistake I made. Admittedly a stupid oversight. But easily to understand:
sudo is a command that if you use it at all, you'll ever use it in the
most restrictively way possible! So of course especially if you're in a
hurry or stupid (or both) you don't think about sudo'ing a whole command
line but only a single command!</font>
<br>
<br><font size=2 face="sans-serif">> makesd should simply have no default
for DEV and not do anything if not set.</font>
<br>
<br><font size=2 face="sans-serif">To tell it in clear words: NEVER NEVER
NEVER a script should access any path that the user never had provided
by himself except "." !!!</font>
<br>
<br><font size=2 face="sans-serif">It's in no way acceptable that a script
- especially if it's such basic and essential - contains hardcoded paths
that are valid on no other machine than the one of the developer!!! Especially
not for doing actions like deleting and/or formatting!!!</font>
<br>
<br><font size=2 face="sans-serif">It was an incredible luck that my now
erased harddisc /dev/sdc mostly had been backuped. But still it contained
some data that are lost now! By a hair it could have affected another external
harddisc of mine that I need for my daily work. It would have been an horrific
catastrophe if this would have been affected!!! I currently don't have
time left over to we wasted for doing huge recovery cycles!!! </font>
<br>
<br><font size=2 face="sans-serif">> do not automatically use /dev/sdc
if no device is specified</font>
<br><font size=2 face="sans-serif">> instead print usage and an error
message.</font>
<br>
<br><font size=2 face="sans-serif">I would even accept if in such a case
the script would use ".", resulting in writing the rootfs into
the local directory from where the script had been called, because this
would just follow the principle GIGO: Garbage in - garbage out!</font>
<br>
<br><font size=2 face="sans-serif">But why does it want to have such an
essential parameter like the path to be erased and formatted as environment
variable at all??? Why not pass it as commandline parameter? You can easily
also pass an environment variable by that way!</font>
<br>
<br><font size=2 face="sans-serif">> Well, it has to have some default
because if you make 20 sd cards</font>
<br><font size=2 face="sans-serif">> per day, every keystroke counts.
And in 19 times you type</font>
<br><font size=2 face="sans-serif">> /dev/sdg correctly and then you
mistype /dev/sdh + Enter.</font>
<br><font size=2 face="sans-serif">></font>
<br><font size=2 face="sans-serif">> So it needs some default you do
not have to think about too much.</font>
<br>
<br><font size=2 face="sans-serif">Ok, I understand. But then I strongly
suggest a parameter like "--hell" for activating such hardcoded
values that are valid on your machine only!!!</font>
<br>
<br><font size=2 face="sans-serif">> There is already a secondary default
which reads the file ~/.makesd.conf</font>
<br><font size=2 face="sans-serif">> to set such a default. And the
/dev/sdc is only used if that file</font>
<br><font size=2 face="sans-serif">> does not exist or is empty.</font>
<br><font size=2 face="sans-serif">></font>
<br><font size=2 face="sans-serif">> I have already updated the documentation
page because that</font>
<br><font size=2 face="sans-serif">> feature is available for a while.</font>
<br>
<br><font size=2 face="sans-serif">Sorry Nikolaus, but for using a command
that had been suggested per mail as a quick hack, I don't expect to be
expected to read a documentation first. I already hesitated several days
before I decided to overcome my doubts and just try it, although already
at the first glance I could see that the line was suspicious. Then I did
one small step after the other in order to avoid exactly such disasters!</font>
<br>
<br><font size=2 face="sans-serif">> Well, it is impossible to perfectly
prevent erasing the wrong device, because only the user can know what the
SD card reader with an SD really is.</font>
<br>
<br><font size=2 face="sans-serif">Exactly because of that a script never
should dare to fool you!!!</font>
<br>
<br><font size=2 face="sans-serif">> I usually use an SD card reader
of some SBC where I did ssh root access to so I never thought</font>
<br><font size=2 face="sans-serif">> about needing sudo.</font>
<br>
<br><font size=2 face="sans-serif">Ok, that explains many things. Especially
it confirms that my decision was right to first get a night of sleep before
I tell you how exorbitant furious I am currently be. Seems to need the
whole weekend in order to come down again!</font>
<br>
<br><font size=2 face="sans-serif">> Maybe we should add a check that
you really have write access to the specified device.</font>
<br>
<br><font size=2 face="sans-serif">As a Linux user you don't expect such
actually self-evident things anymore, especially not on the raw developer's
side. But meanwhile you can expect Linux to reliably act in the already
mentioned way GIGO: Stupid users will get stupid results. But normally
no disasters anymore like in early days.</font>
<br>
<br><font size=2 face="sans-serif">> There is at least one protection:
you can't overwrite /dev/sda.</font>
<br>
<br><font size=2 face="sans-serif">Under Linux indeed this can already
be seen as luxury. Every other user would expect this as minimum safety.</font>
<br>
<br><font size=2 face="sans-serif">> So it is equally risky as calling
fdisk directly.</font>
<br>
<br><font size=2 face="sans-serif">The risk here is a completely other:
>From experience the parameters of fdisk are highly dependent on the Linux
version that you're using. So my first question was: Will the script work
properly on my system? But once again: Never you would expect to get devices
accessed that you never specified!!!</font>
<br>
<br><font size=2 face="sans-serif">>> Why "fsck.ext2"?
My QtMoko v55 and v57 SD cards had already been formatted with "fsck.ext4".
So even "fsck.ext3" would have been outdated.</font>
<br><font size=2 face="sans-serif">></font>
<br><font size=2 face="sans-serif">> No idea. The script only calls
fsck.ext3. Seems to be a bug in util-linux 2.27.1 when printing the error
message.</font>
<br>
<br><font size=2 face="sans-serif">A suggestion: Please provide a parameter
like -3 or -4. So that users are able to choose ext3 or ext4 by themselfes.
I for example prefer ext4.</font>
<br>
<br><font size=2 face="sans-serif">> Thanks for feedback about makesd.
It can only become better :)</font>
<br>
<br><font size=2 face="sans-serif">Indeed!!!</font>
<br>
<br><font size=2 face="sans-serif">I totally accept if you say that you're
providing tinkerer alpha versions and don't intend to serve them on silver
plates. But please understand that my intention is to be the one who would
be able to provide the GTA04 on silver plates to others. It's a hard job
because the reaction of de facto everyone who is just an interested smartphone
user looking for an alternative to Apple, Samsung etc. but is not a computer
freak, and who did only one short look at your internet pages was: What
a crap! But still I'm trying to find a way to get some acceptance for what
you're doing in the wider public.</font>
<br>
<br><font size=2 face="sans-serif">But never I would dare to provide the
current makesd script to others. Not on a silver plate, but even not on
pitchfork!</font>
<br>
<br><font size=2 face="sans-serif">Please tidy it up, thoroughly. Its too
basic and too essential to be left in the state as it currently is!</font>
<br>
<br><font size=2 face="sans-serif">Sorry, but will not continue testing
until this work has been done!</font>
<br>
<br>
<br><font size=2 face="sans-serif">By that opportunity one more well-intentioned
suggestion:</font>
<br>
<br><font size=2 face="sans-serif">The default way of using such a script
should not be to have a swiss army knife (German: "eierlegende Wollmilchsau").
For an ordinary user it's better to use such a script in several separated
but straightforward steps:</font>
<br>
<br><font size=2 face="sans-serif">1.) Download the big tarball manually,
either using "wget" or a browser. This isolates all the problems
that you can get with wrongly written URLs (e.g. whitespaces), network
problems (e.g. slow networks for such huge tarballs, including possible
timeouts), etc.</font>
<br>
<br><font size=2 face="sans-serif">2.) Don't call the script with the URL,
but with the filename of the tarball on your harddisc. This widely eliminates
the problems with wrongly written filenames, because you can use the tab
key for auto-completion. So the whole command needs much less keystrokes.
So problems like wrongly copy-and-pasted whitespaces can much more easily
be solved. And in case that the script failed for any reason, you don't
have to download the whole tarball again.</font>
<br>
<br><font size=2 face="sans-serif">3.) You wrote that the script automatically
adds a Linux kernel to QtMoko. Which kernel version? From which link? Currently
there's not any transparency for that. Better way would be if also for
the kernel there would be a parameter so that it can be downloaded and
provided from outside of the sript by the user.</font>
<br>
<br><font size=2 face="sans-serif">Best regards</font>
<br><font size=2 face="sans-serif">   Sven</font>
<br>
<br>