09-20-2016, 07:37 AM
(This post was last modified: 09-20-2016, 07:38 AM by MarkHaysHarris777.)
(09-20-2016, 07:23 AM)clarkss12 Wrote: Right now, I tried twice to install Armbian_5.20_Pine64_Ubuntu_xenial_3.10.102 on my MicroSD card, using the Win32diskimager and Rufus. Neither method will boot. Is there something I need to do rather than just install the img file??
There is no magic; it either works or it doesn't. Depending on the condition of your SD card, and the condition of the SD card from which the image was taken, the write may or may not work. Try it again. Use another card, try DD from a mac or a linux machine.
It either works, or it doesn't ; reseat the card... try try again. 
(09-20-2016, 07:37 AM)MarkHaysHarris777 Wrote: (09-20-2016, 07:23 AM)clarkss12 Wrote: Right now, I tried twice to install Armbian_5.20_Pine64_Ubuntu_xenial_3.10.102 on my MicroSD card, using the Win32diskimager and Rufus. Neither method will boot. Is there something I need to do rather than just install the img file??
There is no magic; it either works or it doesn't. Depending on the condition of your SD card, and the condition of the SD card from which the image was taken, the write may or may not work. Try it again. Use another card, try DD from a mac or a linux machine.
It either works, or it doesn't ; reseat the card... try try again.
PS ( I have never had a dd write to an SD card fail... why why why do so many people struggle with this )
marcushh777 
please join us for a chat @ irc.pine64.xyz:6667 or ssl irc.pine64.xyz:6697
( I regret that I am not able to respond to personal messages; let's meet on irc! )
Burned this version and worked first time, Armbian_5.20_Pine64_Debian_jessie_3.10.102.
(09-20-2016, 07:23 AM)clarkss12 Wrote: Right now, I tried twice to install Armbian_5.20_Pine64_Ubuntu_xenial_3.10.102 on my MicroSD card, using the Win32diskimager and Rufus. Neither method will boot. Is there something I need to do rather than just install the img file??
Nope, just follow the basic instructions: http://docs.armbian.com/User-Guide_Getting-Started/
I would never ever use Win32diskimager but only Rufus or Etcher (since they're able to verify the burning process) and in case you run in boot troubles please also read what's recommended above (this does not apply to Armbian only but to any kind of OS image that has to be transferred to flash media). Will now stop wasting time here, Armbian support happens in Armbian forum if needed. But most if not all problems are related to insufficient power supply or crappy SD cards or unreliable burning process (or a combination).
My problem now, and very frustrating since I don't know chit about Linux, it keeps asking me to change password, but won't take anything I type in. Speaking of typing, the keyboards (tried 3) keep double punching. LLLiikkee this.
Better revert back to longsleep's Xenial image (I really don't want to copy&paste the Armbian documentation bit by bit into this forum since why?)
Done, going back to xenial-pine64-bspkernel-20160716.
(09-20-2016, 08:25 AM)clarkss12 Wrote: My problem now, and very frustrating since I don't know chit about Linux, it keeps asking me to change password, but won't take anything I type in. Speaking of typing, the keyboards (tried 3) keep double punching. LLLiikkee this.
1) I always use Win32DiskImager, no issues, even though it doesn't verify. Rufus is nice, but for ease of use, Win32 is cool.
2) I think I know what you're doing. Before you enter the new password you have to enter the CURRENT password, then the new one twice - so essentially you have to enter three passwords. I did the same thing.
(09-20-2016, 03:22 PM)amc2012 Wrote: 1) I always use Win32DiskImager, no issues, even though it doesn't verify. Rufus is nice, but for ease of use, Win32 is cool.
Nope, so many issues here in the forum (and everywhere else where SD cards are used) are related to 2 problems:
- crappy SD cards
- crappy card readers (writers)
It's such an insane waste of time to skip the verification process given that so many constellations exist where OS images are silently corrupted while being written to the card (I look at this from a different point of view since I deal on a regular basis with user complaints telling 'Armbian does not work' -- in over 95 percent related to crappy SD card, broken burn process or power supply -- or 'Armbian is slow' -- in 101 percent related to crappy SD cards)
I know it's absolutely useless since people will use Win32Diskimager the next 500 years even if it's outdated and still called 'Beta' and will also moronically waste their time with "SD Formatter" which is absolutely useless on any device that is not a Raspberry Pi.
But only burning processes that are followed by a verify are good ones:
Etcher is available for all platforms and direct result of all these absolutely useless burning troubles people around the world constantly run into. Why not just starting to use it? It's free and it's better than the alternatives. The whole problem again is that in this community documentation/instructions so horribly suck (and that's those careless peoples fault mainting the wiki and 'FAQs')
I don't like some arrogant SOB talking down to me either.
(09-20-2016, 04:57 PM)clarkss12 Wrote: I don't like some arrogant SOB talking down to me either.
Do you know how many harsh comments/posting were needed to force Pine64 folks to start at least putting together a lame list like this: http://wiki.pine64.org/index.php/Main_Pa...t_Guide.5D
Maybe 50 or so back in March and April. The forums were flooded by always the same questions and issues, every single issue was already well known but not properly documented (Ghost did a great job back then starting to re-organise some of the forum's contents but a real 'quick start guide' is all what's really needed. Still does not exist).
It's known that crappy / counterfeit cards exist, it's known that the burning process itself can cause corrupted installs (card readers overheat, USB front ports connected through tiny wires corrupt data and so on). So why even allow this? It's so easy, only recommend and use tools that allow a verify of the burning process. Even better only recommend and use tools that force this verify.
That's what Etcher is about. The tool's development has been driven by another community that suffers from the very same problems this community has. And what happens here? Nothing, still the same recommendations that waste time on user's and supporter's side since broken burning processes aren't ruled out. It's just insane to recommend this Win32 thingie these days (was great years ago but isn't any more)
|
