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
_______________________________________________ Gta04-owner mailing list Gta04-owner@goldelico.com http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
