[Gta04-owner] Helldriving with basic and essential scripts
S.Dyroff at phytec.de
Fri Mar 2 13:53:06 CET 2018
Hello Nikolaus and Andreas,
> sudo does not pass the variables on (security reasons, you could do
> So makesd did not know about your DEV=/dev/sdg
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!
> makesd should simply have no default for DEV and not do anything if not
To tell it in clear words: NEVER NEVER NEVER a script should access any
path that the user never had provided by himself except "." !!!
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!!!
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!!!
> do not automatically use /dev/sdc if no device is specified
> instead print usage and an error message.
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!
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!
> Well, it has to have some default because if you make 20 sd cards
> per day, every keystroke counts. And in 19 times you type
> /dev/sdg correctly and then you mistype /dev/sdh + Enter.
> So it needs some default you do not have to think about too much.
Ok, I understand. But then I strongly suggest a parameter like "--hell"
for activating such hardcoded values that are valid on your machine
> There is already a secondary default which reads the file ~/.makesd.conf
> to set such a default. And the /dev/sdc is only used if that file
> does not exist or is empty.
> I have already updated the documentation page because that
> feature is available for a while.
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!
> 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
Exactly because of that a script never should dare to fool you!!!
> I usually use an SD card reader of some SBC where I did ssh root access
to so I never thought
> about needing sudo.
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!
> Maybe we should add a check that you really have write access to the
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
> There is at least one protection: you can't overwrite /dev/sda.
Under Linux indeed this can already be seen as luxury. Every other user
would expect this as minimum safety.
> So it is equally risky as calling fdisk directly.
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
>> 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.
> No idea. The script only calls fsck.ext3. Seems to be a bug in
util-linux 2.27.1 when printing the error message.
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.
> Thanks for feedback about makesd. It can only become better :)
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.
But never I would dare to provide the current makesd script to others. Not
on a silver plate, but even not on pitchfork!
Please tidy it up, thoroughly. Its too basic and too essential to be left
in the state as it currently is!
Sorry, but will not continue testing until this work has been done!
By that opportunity one more well-intentioned suggestion:
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
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gta04-owner