04-28-2016, 05:51 AM
(This post was last modified: 04-28-2016, 05:52 AM by EricL.)
Hi all.
So, I've been tearing my hair out trying to get RemixOS to behave on the PINE A64. I tried downloading the latest image from here, which has changed in the past day or so and thankfully doesn't require PhoenixCard anymore. However, it seems geared to 8GB MicroSD cards and I can't for the life of me figure out how to expand it. Both Parted and GParted complain of overlapping partitions, so a simple resize of the filesystem doesn't work. What's more, removing and re-creating the partition doesn't work, because the first block is actually overlapping with the last block of the extended partition. This thing has the most bizarre partition table I've ever seen. Short of hacking away at the partition table with a hex editor, is there any way I can clear the overlapping partition problem?
(04-28-2016, 05:51 AM)EricL Wrote: Hi all.
So, I've been tearing my hair out trying to get RemixOS to behave on the PINE A64. I tried downloading the latest image from here, which has changed in the past day or so and thankfully doesn't require PhoenixCard anymore. However, it seems geared to 8GB MicroSD cards and I can't for the life of me figure out how to expand it. Both Parted and GParted complain of overlapping partitions, so a simple resize of the filesystem doesn't work. What's more, removing and re-creating the partition doesn't work, because the first block is actually overlapping with the last block of the extended partition. This thing has the most bizarre partition table I've ever seen. Short of hacking away at the partition table with a hex editor, is there any way I can clear the overlapping partition problem?
It is hard to expend on Android and Remix build. For DD image method, we will need to create different size image (8, 16, 32, and 64).
(04-28-2016, 05:51 AM)EricL Wrote: Hi all.
So, I've been tearing my hair out trying to get RemixOS to behave on the PINE A64. I tried downloading the latest image from here, which has changed in the past day or so and thankfully doesn't require PhoenixCard anymore. However, it seems geared to 8GB MicroSD cards and I can't for the life of me figure out how to expand it. Both Parted and GParted complain of overlapping partitions, so a simple resize of the filesystem doesn't work. What's more, removing and re-creating the partition doesn't work, because the first block is actually overlapping with the last block of the extended partition. This thing has the most bizarre partition table I've ever seen. Short of hacking away at the partition table with a hex editor, is there any way I can clear the overlapping partition problem?
I just received my board in the mail and have been trying to install Remix and expand it with the same issues you've had. Seems to work fine with the stock image on its own using win32 disk imager but it only gives like 4 GB of usable space on my 32 GB card. I also tried to use GParted and various other tools but got the same error, overlapping partitions. Hoping you guys can come up with a way for us to build our own images or something so we can choose arbitrary image sizes or possibly fix the overlapping images so a simple resize could do it!
(04-29-2016, 01:12 AM)Gunsmithy Wrote: I also tried to use GParted and various other tools but got the same error, overlapping partitions.
Step 1: Check your new SD card with either H2testw or F3. If this succeeds then you're ready for the next step
Step 2: Grab the Phoenix Card image (not the DD version), grab Phoenix Card and follow exactly these instructions: Start the software as admin, use ' format to normal' first and then burn in startup mode. Phoenix Card will partition the card itself and you can use the whole capacity afterwards.
Step 3: Disconnect Ethernet on 1st boot (otherwise boot will stuck on Pine64 logo), use a PSU that is known to provide 5.1V @ 2A and be patient (1st boot might take up to 10 minutes, next boots are faster)
Yeah, the PhoenixCard image will work, if I sit there and retry it some 30 times. Got to be hell on the flash memory doing that. It also errors out at random parts of the process, so it's definitely not a capacity issue as it should fail at exactly the same point each time. It's also very doubtful that it's an SD card reader issue, since I've used 3 completely different readers and got similar results (one USB, and two integrated in laptops). None of these show any sort of corruption issues when burning to win32diskimager, and I've burned a LOT of flash memory with them.
However, I think there's a bigger question here. Why does an Android/Remix boot somehow require an invalid partition table? This seems like a bug to me.
In the meantime, I think I'll experiment with sfdisk to rewrite the partition table from scratch and try to work it out that way.
(04-29-2016, 10:42 PM)EricL Wrote: Yeah, the PhoenixCard image will work, if I sit there and retry it some 30 times. Got to be hell on the flash memory doing that. It also errors out at random parts of the process, so it's definitely not a capacity issue as it should fail at exactly the same point each time. It's also very doubtful that it's an SD card reader issue, since I've used 3 completely different readers and got similar results (one USB, and two integrated in laptops). None of these show any sort of corruption issues when burning to win32diskimager, and I've burned a LOT of flash memory with them.
However, I think there's a bigger question here. Why does an Android/Remix boot somehow require an invalid partition table? This seems like a bug to me.
In the meantime, I think I'll experiment with sfdisk to rewrite the partition table from scratch and try to work it out that way.
I will upload 16, 32, and 64GB Remix DD image on this weekend. Very time consuming, create a 64GB DD image takes about 4 hours (including zip time)
Very much appreciated. I've downloaded some of them and taken a look. They seem pretty decent. The only problem is that I end up having to use an image size smaller than the card, because my card is literally a few blocks smaller than the image. (Did the counterfeit check, it's fine. There is just some variation in card size due to things like overprovisioning for wear leveling.) I'd thought about using DD and just blind blasting the image on anyway, but I figure that would probably result in the same problem as a counterfeit card. I still wish there was a way to properly resize these things without using PhoenixCard, as it seems to be really unstable.
I did some looking into why this partition table is so weird, and the answers I found were really unfortunate. Basically, these images were originally designed to be flashed to eMMC and the partition table wasn't meant to be useful outside of the operating system installed. With that in mind, I'm genuinely surprised it has something that looks like a "real" partition table at all, as it could have just as easily been a block at the beginning with a bunch of smashed-together binary data. I could hope that the people over at Jide could sort that out somehow, but I don't know how much control they really have over the kernel.
Back to these DD images, there wouldn't happen to be some reserved space at the end of the image to account for slight card variations, would there? Might it actually be safe to just blast the image blind on to the card with DD?
(04-30-2016, 09:49 PM)EricL Wrote: Very much appreciated. I've downloaded some of them and taken a look. They seem pretty decent. The only problem is that I end up having to use an image size smaller than the card, because my card is literally a few blocks smaller than the image. (Did the counterfeit check, it's fine. There is just some variation in card size due to things like overprovisioning for wear leveling.) I'd thought about using DD and just blind blasting the image on anyway, but I figure that would probably result in the same problem as a counterfeit card. I still wish there was a way to properly resize these things without using PhoenixCard, as it seems to be really unstable.
I did some looking into why this partition table is so weird, and the answers I found were really unfortunate. Basically, these images were originally designed to be flashed to eMMC and the partition table wasn't meant to be useful outside of the operating system installed. With that in mind, I'm genuinely surprised it has something that looks like a "real" partition table at all, as it could have just as easily been a block at the beginning with a bunch of smashed-together binary data. I could hope that the people over at Jide could sort that out somehow, but I don't know how much control they really have over the kernel.
Back to these DD images, there wouldn't happen to be some reserved space at the end of the image to account for slight card variations, would there? Might it actually be safe to just blast the image blind on to the card with DD?
This is the major issue about DD image, the image cannot be larger than the card size. In general, I try to look for the microSD card that has "smaller" capacity on it class and make the image. I need to know your 64GB mircoSD card actually capacity and explore whether able to make on smaller for it. However, I also don't want to make one that too small and wasting everybody microSD card capacity.
|
