[Gta04-owner] Helldriving with basic and essential scripts

[Sven Dyroff]

Hello Nikolaus and Andreas,

> sudo does not pass the variables on (security reasons, you could do 
funny things).
> 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 
set.

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 
only!!!

> 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 
is.

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 
specified device.

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.

> 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 
specified!!!

>> 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 :)

Indeed!!!

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 
steps:

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.

Best regards
   Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20180302/1a3a6f06/attachment.html>