Marcus, I purchased one of the Samsung Evo+ cards, the 64GB version, and have had the exact same problem that I had with my SanDisk Ultra cards. I have yet to find a company that sells flash storage that uses 1024. Both my Samsung and SanDisk cards even state on the packaging (in very small letters) that they use 1000. Knowing that is the case, I would agree with Stiansen (as well as many others that have made the same point in numerous threads) that the images should be sized with this in mind. So telling someone to go buy a better quality SD card is not really a fix.
As mentioned in this thread, there are those of us who do not have a linux system or know anything about setting one up, myself included. So we don't know how to deal with changing partitions.
I don't understand why the image files aren't just made a little smaller, as that would solve this problem once and for all. From all the threads I've read on this same issue, it sounds like part of the image is actually just open space that can be used for storage. Why not just make that a little smaller so it fits on the cards? They aren't oversized by much, and I imagine dropping a small amount of the storage space would be the way to go. Besides, having a 32GB image on a 64GB card means there's a ton of storage I'm missing out on, so if the storage available in the image was dropped by 1 or 2 GB, it would be an improvement because I could use the rest of the space on my larger card.
So make the images a little smaller, make everyone happy, and those of us that don't know how to resize partitions can still make full use of the cards we buy. It seems much easier for the provider of the images to resize rather than asking every user to resize the image on their own.
Kickstarter backer #5,864 -- SBC Noob -- SE Michigan, USA
08-05-2016, 08:50 AM
(This post was last modified: 08-05-2016, 08:53 AM by MarkHaysHarris777.)
hi Montero65,
On the gnu+linux images that we control we are doing precisely as you suggest, now. In fact the gnu+linux images must be expanded in order to take full advantage of the space available on the full SD card.
The problem arises with the images that we do not control.
I will pass this on to the developers in our own think tank, and see what we can do to influence the people who are building the proprietary images for Android &c. If I controlled it this would be fixed this afternoon. If TL Lim controlled it, it would have been fixed weeks ago.
The most important thing to do is to make sure that your SD card really has the capacity that it is supposed to have. There are several on-line tests for this purpose. If you have a bad or fraudulent card (maybe even a fake) there is no amount of programming that will fix that.
Another thing we can do is have a builld and test group of volunteers who will verify that each image will actually work with X number of SD card vendors and size. This is not fully in place, and we are going to have to discuss it some more. In the mean time, the best i can suggest atm is to purchase quality cards which are having the capacity they advertise.
NOTE: The 'K' problem is universal. Please don't shoot the messenger. developers *all* use K=1024... SD card vendors all ALL use K=1000. This is clearly an error, but none of use who are developers are going to start using K=1000 !! (NOT GOING TO HAPPEN) The reason of course is that K is about binary, not about decimal; and the even binary number closest to 1000 is 1024.... so, what's the 16Gb equivalent of this idea... ?
17,179,869,184
Do you see the problem ? By the place value that we are talking about billions of bytes (16 Billion bytes) is actually well over seventeen billion bytes !!
The manufacture of these cards is in the hands of engineers who have NDAs and contracts with multiple Corporations... and our hands are tied. Its not so simple as tell someone to make the image smaller... we get the image the way its given to us... this problem can be pushed back a bit... but it is going to take some time, politics, understanding, and patience.
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! )
Hi Marcus, I am well aware of the fact that all the SD card suppliers do it, and the reasoning of the binary vs. decimal. That has bothered me for years, was not mad at you for it. And I wouldn't expect you or any other developers to adopt it, as it doesn't make sense to do so. In another thread, I even mentioned the math that at the absolute maximum, any SD card is only going to have about 93% of the advertised storage ((1000/1024)^3). My SanDisks were actually closer to about 90% though (although they checked out as not fake or faulty).
Up until now, I was under the impression that the images for Android were put together by the Pine team, but it sounds like that is not actually the case. I thought it was something that TL did have control of, so that he could adjust the images before they were posted to the website, but I guess not. I was actually surprised he hadn't fixed it, but if it is not something he can control, that makes more sense. This is the first time in all these threads on the topic that that information has been provided though. If the Pine team is not in control of the images, who is? Is someone from Allwinner doing the images? As I thought these builds were specific to the Pine, I thought it would be easy to request this change.
Kickstarter backer #5,864 -- SBC Noob -- SE Michigan, USA
08-05-2016, 09:46 AM
(This post was last modified: 08-05-2016, 10:51 AM by MarkHaysHarris777.)
(08-05-2016, 09:06 AM)montero65 Wrote: This is the first time in all these threads on the topic that that information has been provided though. If the Pine team is not in control of the images, who is? Is someone from Allwinner doing the images? As I thought these builds were specific to the Pine, I thought it would be easy to request this change.
hi montero65, Allwinner has NDA(s) with ARM and Syllology<sp> as far as I know. I actually do not know who builds the images specifically; I can tell you that making suggestions and providing bug reports is (at this time) an internal affair that even tllim has mentioned should not be brought forward yet for public access. Like I said before, and I'm just trying to be honest and forthright, in good faith, the images are not being built by the gnu+linux team, and they are not being built by the Pine team (and we are just as frustrated about that as you are).
I have a stack of notes on my desk for bug reports... and another stack for suggestions for improvement... and I myself am struggling a bit to get them to the right people in a sensitive way. This is nothing unlike other things that any other startup has had to deal with... NDA(s) are a PITA, but a fact of life. Also, proprietary codes are also a PITA, but when that stuff is out of ones hands, one deals with what one CAN control--- its just abetter use of time and resources.
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! )
I think just the knowledge that it is something not in the control of Pine is actually good knowledge. It keeps us from being frustrated with the Pine team for something they cannot fix right now. It doesn't tell us who to aim our frustration at, exactly, but at least it can prevent it being aimed at the wrong people. Thanks for the info on that.
Kickstarter backer #5,864 -- SBC Noob -- SE Michigan, USA
(08-05-2016, 08:20 AM)montero65 Wrote: Marcus, I purchased one of the Samsung Evo+ cards, the 64GB version, and have had the exact same problem that I had with my SanDisk Ultra cards. I have yet to find a company that sells flash storage that uses 1024. Both my Samsung and SanDisk cards even state on the packaging (in very small letters) that they use 1000. Knowing that is the case, I would agree with Stiansen (as well as many others that have made the same point in numerous threads) that the images should be sized with this in mind. So telling someone to go buy a better quality SD card is not really a fix.
As mentioned in this thread, there are those of us who do not have a linux system or know anything about setting one up, myself included. So we don't know how to deal with changing partitions.
I don't understand why the image files aren't just made a little smaller, as that would solve this problem once and for all. From all the threads I've read on this same issue, it sounds like part of the image is actually just open space that can be used for storage. Why not just make that a little smaller so it fits on the cards? They aren't oversized by much, and I imagine dropping a small amount of the storage space would be the way to go. Besides, having a 32GB image on a 64GB card means there's a ton of storage I'm missing out on, so if the storage available in the image was dropped by 1 or 2 GB, it would be an improvement because I could use the rest of the space on my larger card.
So make the images a little smaller, make everyone happy, and those of us that don't know how to resize partitions can still make full use of the cards we buy. It seems much easier for the provider of the images to resize rather than asking every user to resize the image on their own. I plan to make the build image smaller for sub sequence build. Currently, I am collecting the physical capacity size of microSD card in market to determine the build size. I also don't want to be too small and waste capacity.
08-05-2016, 01:43 PM
(This post was last modified: 08-05-2016, 01:43 PM by DonFL.)
(08-05-2016, 12:27 PM)tllim Wrote: (08-05-2016, 08:20 AM)montero65 Wrote: Marcus, I purchased one of the Samsung Evo+ cards, the 64GB version, and have had the exact same problem that I had with my SanDisk Ultra cards. I have yet to find a company that sells flash storage that uses 1024. Both my Samsung and SanDisk cards even state on the packaging (in very small letters) that they use 1000. Knowing that is the case, I would agree with Stiansen (as well as many others that have made the same point in numerous threads) that the images should be sized with this in mind. So telling someone to go buy a better quality SD card is not really a fix.
As mentioned in this thread, there are those of us who do not have a linux system or know anything about setting one up, myself included. So we don't know how to deal with changing partitions.
I don't understand why the image files aren't just made a little smaller, as that would solve this problem once and for all. From all the threads I've read on this same issue, it sounds like part of the image is actually just open space that can be used for storage. Why not just make that a little smaller so it fits on the cards? They aren't oversized by much, and I imagine dropping a small amount of the storage space would be the way to go. Besides, having a 32GB image on a 64GB card means there's a ton of storage I'm missing out on, so if the storage available in the image was dropped by 1 or 2 GB, it would be an improvement because I could use the rest of the space on my larger card.
So make the images a little smaller, make everyone happy, and those of us that don't know how to resize partitions can still make full use of the cards we buy. It seems much easier for the provider of the images to resize rather than asking every user to resize the image on their own. I plan to make the build image smaller for sub sequence build. Currently, I am collecting the physical capacity size of microSD card in market to determine the build size. I also don't want to be too small and waste capacity.
Interesting. So it sounds like the Pine folks ARE part of the process and can help resolve.
Thanks for the accurate information and insight.
Thanks TL, good to know. Like I said before, if the current situation is that we have to use a bigger card for the image (ie, 64GB card for 32GB image), then reducing the capacity in order for it to fit on the card should not actually be an issue, because instead of not having access to the other roughly half of the card as is the case right now, we would have that access. So instead of wasting say 30GB of capacity as I am now, I would get access to all of that. I'll double check my cards tonight, but I'm pretty sure my SanDisk ultra 32GB cards were about 90% of advertised, so a little lower than the 93% from the 1000/1024 issue. Thanks.
Kickstarter backer #5,864 -- SBC Noob -- SE Michigan, USA
(08-05-2016, 02:03 PM)montero65 Wrote: Thanks TL, good to know. Like I said before, if the current situation is that we have to use a bigger card for the image (ie, 64GB card for 32GB image), then reducing the capacity in order for it to fit on the card should not actually be an issue, because instead of not having access to the other roughly half of the card as is the case right now, we would have that access. So instead of wasting say 30GB of capacity as I am now, I would get access to all of that. I'll double check my cards tonight, but I'm pretty sure my SanDisk ultra 32GB cards were about 90% of advertised, so a little lower than the 93% from the 1000/1024 issue. Thanks.
Sorry on the size issue and concern. I am currently on the final step on finalize the build size. Using SanDisk Ultra 32GB as example, there are actually two size, the one has UHS-I logo is 29.7GB but the one has class 10 logo is only 28.7GB. This means I need to set the 32GB build size down to 28.7GB :-( Most 32GB microSD capacity size around 29.5-30.0GB
Hello,
there is the same problem with 64GB images too - for Android and Remix OS.
|
