(07-19-2016, 12:24 PM)montero65 Wrote: So, lots of comments, but not much help in fixing the problem. I was originally hoping I could get a quick answer of "you need to format the card with this sector size and it will be good" or something simple.
To be honest, I do keep forgetting to try the formatting that Don suggested when I get home, and never remember to bring a card to work to try out. Has anyone tried what Don suggested, using the SD formatter program? Did it work out?
I decided to write a copy of the latest non-rooted android image, and, this time, ran into the issue of a 32 gb SD not being big enough to hold the 32 gb image.
While SDFormatter is definitely the formatting tool that I would recommend using, I don't believe this is a formatting issue. I'm in agreement its an issue of the image size bumping up against the actual SD card size.
I will, as always, defer to higher levels of expertise, but would seem like the easiest fix is for the images to be re-sized to fall below worst case SD card capacities for each image size increment.
I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
(07-19-2016, 01:53 PM)Ghost Wrote: I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
I think the best solution is to use a 4GB ( as in 4,000,000,000 bytes) base image that will automatically resize the data partition to fill the rest of the card during the first boot procedures. This offers the least amount of hassle to end users and developers alike.
(07-20-2016, 08:30 AM)KPhillisJr Wrote: (07-19-2016, 01:53 PM)Ghost Wrote: I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
I think the best solution is to use a 4GB ( as in 4,000,000,000 bytes) base image that will automatically resize the data partition to fill the rest of the card during the first boot procedures. This offers the least amount of hassle to end users and developers alike.
That is exactly what the phoenixcard image does. Unfortunately the phoenixcard software is very unstable
(07-20-2016, 09:15 AM)Boring Wrote: (07-20-2016, 08:30 AM)KPhillisJr Wrote: (07-19-2016, 01:53 PM)Ghost Wrote: I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
I think the best solution is to use a 4GB ( as in 4,000,000,000 bytes) base image that will automatically resize the data partition to fill the rest of the card during the first boot procedures. This offers the least amount of hassle to end users and developers alike.
That is exactly what the phoenixcard image does. Unfortunately the phoenixcard software is very unstable
Then why doesn't someone release an image that mimics what the phoenixcard image does, but instead is meant to be used with Win32 Disk Imager. All it really takes is a disk image from a 4gb card since most users will have 8gb or larger memory cards.
(07-20-2016, 11:55 AM)KPhillisJr Wrote: (07-20-2016, 09:15 AM)Boring Wrote: (07-20-2016, 08:30 AM)KPhillisJr Wrote: (07-19-2016, 01:53 PM)Ghost Wrote: I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
I think the best solution is to use a 4GB ( as in 4,000,000,000 bytes) base image that will automatically resize the data partition to fill the rest of the card during the first boot procedures. This offers the least amount of hassle to end users and developers alike.
That is exactly what the phoenixcard image does. Unfortunately the phoenixcard software is very unstable
Then why doesn't someone release an image that mimics what the phoenixcard image does, but instead is meant to be used with Win32 Disk Imager. All it really takes is a disk image from a 4gb card since most users will have 8gb or larger memory cards.
I think if it were that easy to do, TL Lim and the team would have done that from the start, rather than make all these DD variations that can confuse some people and not work with xx% of cards. If it were simply a case of making the smallest possible OS image then having a script fill out the microSD capacity upon first boot, I'd like to think they'd considered it but it turned out not to be possible, for whatever reason.
It would definitely be preferable to have a single OS image though, rather than several that don't fit all microSD cards at the given capacities.
(07-21-2016, 09:08 PM)Ghost Wrote: (07-20-2016, 11:55 AM)KPhillisJr Wrote: (07-20-2016, 09:15 AM)Boring Wrote: (07-20-2016, 08:30 AM)KPhillisJr Wrote: (07-19-2016, 01:53 PM)Ghost Wrote: I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
I think the best solution is to use a 4GB ( as in 4,000,000,000 bytes) base image that will automatically resize the data partition to fill the rest of the card during the first boot procedures. This offers the least amount of hassle to end users and developers alike.
That is exactly what the phoenixcard image does. Unfortunately the phoenixcard software is very unstable
Then why doesn't someone release an image that mimics what the phoenixcard image does, but instead is meant to be used with Win32 Disk Imager. All it really takes is a disk image from a 4gb card since most users will have 8gb or larger memory cards.
I think if it were that easy to do, TL Lim and the team would have done that from the start, rather than make all these DD variations that can confuse some people and not work with xx% of cards. If it were simply a case of making the smallest possible OS image then having a script fill out the microSD capacity upon first boot, I'd like to think they'd considered it but it turned out not to be possible, for whatever reason.
It would definitely be preferable to have a single OS image though, rather than several that don't fit all microSD cards at the given capacities.
I believe that more than 80% of popular SDCards brands produced use the 1GB = 1 billion bytes ( 1,000,000,000 bytes) for sdcard sizes. A quick list of memory card vendors that generally use this definition for Memory Cards (Like SDCards, MicroSD Cards, etc) is as follows... - AData
- SanDisk
- Kingston
- Patriot Memory
- Samsung
- Silicon Power
I also believe other vendors follow this, but i have not gone through the trouble of identifying all makers. Instead I went with the makers that users are most likely going to find when they head to a local store to find a memory card for the Pine64.
This issue is really more complicated (more sophisticated) than has been discussed so far.
The SD card (I'm speaking of gnu+linux here) should be partitioned with multiple partitions and a part of the file system should be dedicated to each partition. This is done for security and also for technical integrity. These are the parts and the mount points:
1 /boot
2 / (root)
3 swap
4 (extended)
5 /usr
6 /var
7 /tmp
8 /usr/local
9 /opt
10 /home
The /home partition should be mounted nosuid and noexec .
If the SD card is going to get clobbered due to a power outage this will most likely happen to /var or /tmp, but may also happen to /home. There is no need to rebuild the entire card if only /var or /tmp is borked.
If you were going to run an external sdd or hdd on the Pine, then this scheme above should definitely be used; although, there are considerable advantages for doing the same to a standard SD card. Of course it takes some experience to know (for a given distro) the sizes for each of the partitions; particularly /usr and /opt. On a 32G card most of the card should be given over to /home. a 1G part for each of /var and /tmp should be fine. /opt and /usr will be sized based on the packages that are required for each filesystem.
/boot can be ext2 or ext3. All others besides swap should be ext4 journaled.
In any case IMHO 32G cards should be used , spanning the entire SD, regardless of 8G, 16G or whatever images. Everyone is making this too hard in the one direction... and not hard enough in the other (multiple partitions are the way to go).
marcushh777
(07-20-2016, 09:15 AM)Boring Wrote: (07-20-2016, 08:30 AM)KPhillisJr Wrote: (07-19-2016, 01:53 PM)Ghost Wrote: I know there was a plan afoot to make images that would fit all microSD cards in the given sizes (8GB, 16GB, 32GB, 64GB). Maybe TL Lim can weigh in on this, if he isn't too busy responding to shipping queries.
I think the best solution is to use a 4GB ( as in 4,000,000,000 bytes) base image that will automatically resize the data partition to fill the rest of the card during the first boot procedures. This offers the least amount of hassle to end users and developers alike.
That is exactly what the phoenixcard image does. Unfortunately the phoenixcard software is very unstable
The other issue with that is if you want to run a "rooted" version of Android, there is not a PhoenixCard version available. So you are stuck with the DD images that don't actually fit on the cards.
Kickstarter backer #5,864 -- SBC Noob -- SE Michigan, USA
Yesterday did I try to transfer the new Remix2.0 image to my 64GB SD card (Samsung Evo), but it was to small for the image. No formatting could help me. I did then download the Phoenix Card images and could without any problem generate a new images at my 64GB SD card (as I did with the Beta release) The first boot process was slow but completed without need for interactions.
I have got Kodi up and running but Youtube will not display any videos.
As default is there a new app at the desktop: Remix apps, but the app has no content. and by the way www.jide.com is down at the moment.
|
