Problems with nand-sata-install

[tkaiser]

Just a quick list:

 

• It's named completely wrong since it doesn't install anything but transfers an already running installation from one media to another. Main focus on 'without breaking stuff' since transfering a booted/running system is challenging!
• It's named completely wrong since it's not about NAND and SATA any more (hello Cubieboards and Bananas back in 2014) but eMMC and USB these days (and yeah, SATA too)
• It's a blind alley: moving the installation from SD card to $somewhere will work. But nand-sata-install is still there, people might want to use it and will fail (though I think that will most probably never happen since once people are happy why should they try to move their installation from USB back to SD card for example)
• The code is a mess but that's understandable since from day 1 on only WiP and extended, extended, little bit cleaned up, extended, extended again

 

What about being honest and telling users

 

• Raw NAND on those horribly outdated Allwinner boards is crap, forget about it. Yeah, you paid for it but it's worse than SD cards and eMMC, it will fail anyway soon if you used it on your old board now many years, there's the incompatiblity between legacy and mainline NAND support and if you're really keen on using NAND these days.... get a CH.I.P. and stop using Armbian
• Think about what you're doing, eg. putting the rootfs on a HDD has serious drawbacks if users want the disk to spin-down when inactive (some more minimal documentation efforts I refuse to waste time on as long as the tool is named that weird)

 

If I haven't overlooked something that's it. And IMO it's necessary to clean-up the code base (or rewrite from the ground) since everytime I touch this it takes me an awful lot of time to get what this thing does. Then I think let's clean it up now, then I think 'where's my Cubietruck to test this useless NAND stuff', then I think 'ok, workaround mode again, fix it next time'. In summary just an insane waste of time and also dangerous (I believe I ran multiple times this year in nand-sata-install related issues where bootloader/initrd stuff has been updated on the wrong device).

 

If we can agree on dropping NAND support at all IMO it gets immediately easy since a lot of other groundwork we did already in the meantime (the UUID stuff for example or determining optimal mount options for various filesystems) can be combined with a few lines of code dealing in a clear way with the different situations we face with this tool.

 

No need to hurry, this is something for the release after next release. But I would love to get a direct feedback now about in which direction we want to move since my will to touch nand-sata-install in its current state will heavily depend on this

[tkaiser]

Great line for next release notes:

• Raw NAND support (old Allwinner boards) is deprecated now and will be removed with next release

[Tido]

It reminds me about another discussion we lately had.

• From To eMMC/SDcard
• From To USB/SDcard
• From To SATA/SDcard
• From To NAND/SDcard

Why not following the UNIX way, one tool per task?

[zador.blood.stained]

8 hours ago, tkaiser said:

• It's named completely wrong since it doesn't install anything but transfers an already running installation from one media to another. Main focus on 'without breaking stuff' since transfering a booted/running system is challenging!
• It's named completely wrong since it's not about NAND and SATA any more (hello Cubieboards and Bananas back in 2014) but eMMC and USB these days (and yeah, SATA too)

But we can't break backwards compatibility, so "nand-sata-install" should still launch this script by symlinking one of the scripts to the other one.

 

8 hours ago, tkaiser said:

What about being honest and telling users

 

• Raw NAND on those horribly outdated Allwinner boards is crap, forget about it.

Done already: https://github.com/armbian/build/commit/2a7ccaca1a8b04f633030f206231e8a08981cef9#diff-d9f1078e3fed3bc093787ab0a6240f14

 

8 hours ago, tkaiser said:

If we can agree on dropping NAND support at all IMO it gets immediately easy since a lot of other groundwork we did already in the meantime (the UUID stuff for example or determining optimal mount options for various filesystems) can be combined with a few lines of code dealing in a clear way with the different situations we face with this tool.

 

Agree - since there is no point of making new images with 3.4.x kernel the NAND use case becomes useless. The main concern is preventing upgrade of existing images so nand-sata-install is still available after apt upgrade.

[zador.blood.stained]

Just now, Tido said:

Why not following the UNIX way, one tool per task?

Because it is the same task - formatting some block devices and rsyncing some files. You don't make a "one tool per task" to write to CD-R, CD-RW, DVD-R, DVD-RW. Oh, you have DVD+R? Bad luck, nobody made that tool yet.

[Tido]

Yes and No.

If it means to copy a couple bytes and have an easy separation/trouble shooting, why not.

[tkaiser]

13 minutes ago, Tido said:

From To NAND/SDcard

 

C'mon, please read the threads you're jumping into. It's about dropping NAND support entirely since the structure of the tool's code is the main problem in maintaining it and solving any problems with it.

 

14 minutes ago, zador.blood.stained said:

we can't break backwards compatibility, so "nand-sata-install" should still launch this script by symlinking one of the scripts to the other one

 

Sure, but we need to change the official name since writing in documentation 'If you want to transfer your installation to eMMC then call nand-sata-install' is as bizarre as writing to 'call drill-hole-in-knee'. What about 'move-os' or 'move-armbian'?

 

18 minutes ago, zador.blood.stained said:

Agree - since there is no point of making new images with 3.4.x kernel the NAND use case becomes useless

 

@Igor: what's your opinion on this? Are you secretly working on mainline NAND support (and if yes why?) or can we simply drop the idea and clean-up the code base?

[Igor]

6 minutes ago, tkaiser said:

Are you secretly working on mainline NAND support

Absolutely not. We can start working on a new script, leave current as is and ultimately use it only for NAND install and block other ways when new tool become ready. Possible alternative. When booted Armbian on a board which has eMMC - at first login - "do you want to transfer system to internal memory". Yes -> dd to eMMC and power off with a note "remove SD card and press ENTER"? 

[Tido]

25 minutes ago, tkaiser said:

What about 'move-os' or 'move-armbian'?

isn't it a copy ?

Unix:

mv

cp

rm

Edited November 23, 2017 by Tido
added commands

[tkaiser]

35 minutes ago, Igor said:

We can start working on a new script, leave current as is and ultimately use it only for NAND install and block other ways when new tool become ready.

 

Hmm... yes, I like this even more than symlinking with a different name. This allows to develop a new tool in parallel, writing documentation (more a 'please think about what you're doing' reminder than real documentation) and once it's ready replace basic instructions and phase out support for nand-sata-install.

 

35 minutes ago, Igor said:

When booted Armbian on a board which has eMMC - at first login - "do you want to transfer system to internal memory". Yes -> dd to eMMC and power off with a note "remove SD card and press ENTER"?

 

Great idea though that would require that at this point some services (like resize2fs) weren't already running since we want to clone the original image as unmodified as possible to eMMC. Also 'first login' is possible via SSH too and then the whole system is already completely up and running (would be different if we were talking about an initrd scenario with keyboard/display). Let's think about this more but separate it from 'move-armbian' (or whatever it will be called later).

 

Edit: Pine folks for example shipped some time ago images that carried the real image inside and all this did at first boot was just that: overwriting the eMMC with the static image and asking for reboot. I heard few users being not that happy with a wiped out eMMC so such 'eMMC overwrite only images' are most probably also not a viable alternative  

 

Edit 2: minimal 'eMMC install' images could be possible, allowing to login, then choosing image to be burned to eMMC from a list, fetched via torrents and finalized. But better keep this whole idea separate from 'move-armbian'

[tkaiser]

3 minutes ago, Tido said:

isn't it a copy ?

No it's a file of course if you want to turn a discussion about improving Armbian into something that deals with Unix platitudes.

 

The tool we're talking about is something to move an installation from A to B technically doing a copy and adjusting references later. From a user perspective it's a move. And that's the only thing that matters.

[Tido]

You can tackle me about "Unix platitudes" but it doesn't change what I have said.

mv (engl. Abkürzung für move) ist ein Unix-Befehl, der eine oder mehrere Dateien oder Verzeichnisse von einem Ort zum anderen verschiebt.

 

If it is a move, the source is empty afterwards.

 

[tkaiser]

5 minutes ago, Tido said:

mv (engl. Abkürzung für move) ist ein Unix-Befehl, der eine oder mehrere Dateien oder Verzeichnisse von einem Ort zum anderen verschiebt.

 

Tido is totally right, we can't call a tool in a way a user would be able to understand what it does but we need to behave like primitive files (since in Unix just Everything is a file). So a better name would be partition-something-then-rsync-then-check-then-adjust-uuids-in-bootscript-and-fstab. That's great.

 

@Tido: it's really nice to get the difference explained between cp and mv especially so many decades after using Unix now. And of course it's a copy since we do not wipe out the source for obvious reasons (since if something went wrong the user can recover from this or delete the source on its own later after he decided to stay with the installation on the new media). And of course it's absolutely stupid when a dev tries to tell a moderator (who wants to deal with users obviously) the difference between the 'user perspective' and technical details (that do not matter here).

 

I'm out now.

[Tido]

@tkaiser, OMG there are humans smarter than you and even in this forum. I am very sure about that fact.

And all people in this forum know SSH/Putty and therefore  mv cp and rm is totally familiar to them.

And therefore is it 'not so smart' to name it move.

 

And your tackle: partition-something-then-rsync-then-check-then-adjust-uuids-in-bootscript-and-fstab. |  is nothing more than childish behavior.

[chwe]

OMG... if name is the only problem just call it ARMBIANto*whatever* or SDto*whatever" 

1 hour ago, Tido said:

And all people in this forum know SSH/Putty and therefore  mv cp and rm is totally familiar to them.

NO! If everyone would know the basics of 'working with console',  some support questions would never come up...  

 

To be philosophic, if I understood things right, the process is copying from SD-Card to *random other place* but in the end you remove  the SD-Card (otherwise it still boots from SD-Card instead of eMMC etc. and this means in the end, the system does not have a SD-card at all or for sure not with the stuff on it like before so it's a moved from there). 

 

But to keep it simple,  I think that *average Armbianuser* doesn't care about the name of the script, as long as it is described properly in the documentation. OK, anus, pardon *average Armbianuser*, doesn't read the docs at all, but there is a chance that this improves someday (there's also a chance that somewhere on earth we find someday a unicorn...  )

 

Disclaimer: There's some 'sort of humor' in my post. If someone feels upset by this post, please write me a PM, I don't think that we should flood this useful thread with reasons why you're upset about me. 

[Igor]

my 2 cents.

 

1. CLI. install-armbian or armbian-install

2. In armbian-config

"Install" "Install system to internal memory"

3. first run. "Do you want to install system to internal memory"

 

How to handle exceptions?

 

When SD card boot is needed, a warning pops out when hitting NEXT.

[chwe]

8 minutes ago, Igor said:

When SD card boot is needed, a warning pops out when hitting NEXT.

You mean when uboot has to be on SD card (e.g. when users wanna have armbian on an USB-Memorystick instead of the SD-Card on H3 boards)?

In this case, hitting <enter> should imho abort the script.  In python it would look like:  

var = input("Your installation still needs a SD-Card for the bootloader after installing to *random media* to boot, type: 'Yes, I understand' if you wanna continue")
if var == 'Yes, I understand'
	return
else:
	print ("Abort.")
	sys.exit(1)

Otherwise, support questions like 'armbian doesn't boot after armbian-install' will be the next major issue besides underpowering & shitty SD-Cards. 

[tkaiser]

My last 2 cents on the issue:

• the tool needs more sanity checks. That something like this can happen is just sad (or the user is not aware that from now on his external USB drive has to be present forever)
• An 'installation' is something completely different than transferring an already installed system from A to B
• That being said if this transfer is started prior to execution of check_first_login.sh (the 'eMMC detected and asking user whether to install to eMMC' use case) then and only then it's IMO OK to call the transfer of the fresly installed OS to another media 'installation'
• If I would call something armbian-install or install-armbian then it's an Installer for Armbian (eg. a branded Etcher 2.0 allowing users to choose OS images for their device from an online catalogue and thereby even checking download integrity. Flashing to eMMC directly is unfortunately unrealistic since too many board makers simply suck due to not easily allowing FEL mode with an already populated eMMC)
• I've no idea why/how external (USB) storage should be called 'internal memory'

But honestly I don't care any more, this thread is already screwed too much...