As the title says, here's the video; I'll do a write up later since it's a long process.



This is not possible in windows 10 due to the GPT Hybrid MBR trickery used, the android image already does this when it writes the partition tables and etc.

Don't do this in windows nor attempt it, it's not going to happen unless there's something you can use to mess with partitions like I did, L4T-Ubuntu also won't work due to the partition stuff and etc, I'm currently making something to allow this without any complications, please be patient!

Watch the entire video and you'll understand more about this, if you make simple errors from not watching the video I will simply tell you to properly watch again and listen!
TOOL ETA: Don't ask, it's a complicated tool that needs a lot of maths, safety features and etc
TOOL SO FAR:

Tool functions: Android, Custom Android user data, 8GB Android install, Ubuntu, Ubuntu Swap, EmuMMC and Lakka dynamic setup.
Planned functions: Multi EmuMMC setup, EmuMMC Backup & restore(including Nintendo folder) + More unique management stuff!

UPDATE: I'm currently setting aside the tool until I finish making & releasing my new modchip

 

[jan2705]

I probably will give it a re format over the coming weekend then. Could you list the correct size for boot, recovery,dtb? Or is
Hos_data (varies)
Vendor 1084.9 MiB (1085 MiB?)
System 2216.9 MiB (2217 MiB?)
Boot 70 MiB
Recovery 70 MiB
Dtb 30 Mib
Userdata (varies)
Emummc 29856 MiB
Correct? Don't quote me on this guys

thats what worked for me:

part 2 | 1127MB
part 3 | 2253MB
part 4 | 70MB
part 5 | 70MB
part 6 | 30MB
part 7 | 8815MB
part 8 [emuMMC] 29856MB
part 9 [Ubuntu] 65536MB

 

[Deleted-172301]

yes, only losing space to make bigger partition definition than the real space used by the file system.
the partition table is mainly used by partition managers and OS to know where the start of the partition is located and where to put next one.
the first sector of that partition then contains the file system info (real usable size, sector number, cluster size, etc.)
it shouldn't create problems if your table has bigger area than actual usable partition's size. but don't quote me, I'm not 100% sure, it all depends how every apps are working and whether they check the size from the table or the file system itself.

Yea you can write an image to a bigger partition. Then you can reincorporate the remaining apace after its been written to.

 

[tabzer]

**Nothing to see here**

 

[TariqSoftDev]

@TariqSoftDev:

I think you made a mistake with the partition's size. some of which you already know.
you are aware about the userdata as you remade it to 8814.9MiB.

note that I use the size from the 16GB sd image, maybe they are different size in the other images, I don't know.
The vendor and system are wrong too, but it's not a big issue as you made them bigger.
Vendor exact size : 1 137 704 448 bytes
You : 1 126.4MiB
Actual: 1 084.9MiB

system exact size : 2 324 692 480 bytes
You: 2 252.8MiB
Actual: 2 216.9MiB


But I think the emuMMC is wrong and can be an issue because you made it smaller.
my MMC dump is 31 268 536 320 bytes
if I add boot0 and boot1 it is : 31 276 924 928 bytes, 29.1GB

you: 29 798.4MiB
actual: 29 828MiB

your MMC partition is smaller than the real MMC size.
it's not an issue if you end your SD card with the MMC, as the raw sectors will be written and read by emuMMC beyond the MBR's last LBA.
but if later you decide to add a new partition at the end (for L4T for example), it'll overwrite it. Or if you create L4T partition before dumping MMC, it'll overwrite L4T header.

I think adding 2 partitions (8GB and 2GB respectively? 7714MiB and 2217MiB exactly) for L4T and swap file can be a good idea for pentaboot.
the boot.scr for partition 9 is provided on first page.

Yeah I know I made them bigger, I have a bad habit of it but it's not by much so it's not a massive worry; as for the EmuMMC I'll make sure to comment that in although that's generally my go to size which I've had 0 issues with; most likely since I don't install anything to nand and etc, I wanted to refine this alot more but I'm pretty short on time (that day being the only day I realistically had time to rest during the month); thanks for the update anyways

When I do a write up I'll use the data given to provide a much more in detail accurate guide; I'm also looking at making a GUI based linux tool that will do this all in a couple of clicks for people.

 

[switchisfun]

@TariqSoftDev You're a hero, thanks for the excellent guide.

I'm including this boot.scr file to the thread that will boot L4T 1.3.1 from the 9th partition if anybody decides to do it the way I did it, though I have greater hopes for Tariq's solution whenever he decides to deliver it.

Thank you for this. I followed the video guide then used this solution for l4t. Everything boots properly, very happy to get this working!

 

[tabzer]

I think adding 2 partitions (8GB and 2GB respectively? 7714MiB and 2217MiB exactly) for L4T and swap file can be a good idea for pentaboot.

I decided to redo my SD card format following this advice, and I found that the base size for the L4T partition is way too small to have a meaningful experience with it. After doing updates and such, I wind up with very very little. So I became liberal and doubled the size of L4T. Also, 29828MiB was too small for Hekate to use to create emummc so I increased the size to 2956 MiB and it worked. This is about what I did:

Total Space avaialable 375623 MiB


1 hos_data 308266 MiB (calculated after the rest)
2 vendor 1085 MiB
3 system 2217 MiB
4 boot 70 MiB
5 recovery 70 MiB
6 dtb 30 MiB
7 userdata 8815 MiB -> 16384 MiB (7569 difference, resize after flashing android partitions)
8 emummc 29856 MiB (Make this after resizing userdata, then set flags for 1 EE and 8 E0, then create emummc )
9 L4T 7714 -> 15428 MiB (do in L4T so L4T can re-appropriate the space, do this after making emummc via hekate)
10 swap 2217 (do this in L4T)

Set EE flags for 1 (E0 for 8 is optional at this point.)

 

[lordelan]

I'm also looking at making a GUI based linux tool that will do this all in a couple of clicks for people.

Sounds very interesting! Although I'm fine doing things in GParted.

The start sector to an emuNAND created by SX OS is 0x2. So is there any way to get this into the party?

 

[Cyan]

. Could you list the correct size for boot, recovery,dtb? Or is

https://gbatemp.net/posts/8733850
I got exact bytes from the 16GB image.

here only the relevant part:
hos_data : 4194304 sectors : 2 147 483 648 bytes : ~2GB : 2048MiB : FAT32
vendor : 2222079 sectors : 1 137 704 448 bytes : ~1GB : ~1084.9MiB
system : 4540415 sectors : 2 324 692 480 bytes : ~2GB : ~2216.9MiB
boot : 143360 sectors : 73 400 320 bytes : ~73.4MB : 70MiB
recovery : 143360 sectors : 73 400 320 bytes : ~73.4MB : 70MiB
dtb : 61440 sectors : 31 457 280 bytes : ~31.4MB : 30MiB
userdata : 18053087 = 9 243 180 544 bytes : ~9GB : ~8814.9MiB

My hekate MMC dump : 31 268 536 320 bytes
if I add boot0 and boot1 it is : 61087744 sectors : 31 276 924 928 bytes : ~31.2GB : 29 828MiB
But apparently hekate will refuse this exact size, read tabzer's and bst's comment below.

Also, 29828MiB was too small for Hekate to use to create emummc so I increased the size to 2956 MiB and it worked.

ohh? that's really weird as it's the exact size I got when converting my MMC dump's bytes to MiB.
thanks for reporting hekate requires it to be bigger.
strange that Tariq didn't get the "too small" message while his partition was really smaller than MMC size. he made it bigger than the size from text file.

The start sector to an emuNAND created by SX OS is 0x2. So is there any way to get this into the party?

sector 2 is where the GPT table definition starts, so there's no way to do it. unless hekate (and android, and linux) could read from the backup GPT table at the end of the SD card. but it's very rarely looked at, it just assumes that GPT is absent if not on sector 1-63
if it was compatible, you'd have to create the MMC at the very end of the SD creation, because you need to let all tools generate the GPT+GPT backup properly, then overwrite GPT with SXOS emuMMC, where you'd have left enough space for it at the start of the SD.
it's a lot easier if SXOS just release a new version of their payload with alternative sector location (even hardcoded, like 64 or 2048), keeping old sector2 a valid location to boot from if found.

 

[tabzer]

https://gbatemp.net/posts/8733850

ohh? that's really weird as it's the exact size I got when converting my MMC dump's bytes to MiB.
thanks for reporting hekate requires it to be bigger.
strange that Tariq didn't get the "too small" message while his partition was really smaller than MMC size.


sector 2 is where the GPT table definition starts, so there's no way to do it.

Yeah, it seems that Hekate requires it to be bigger for some reason. I tried increasing the size little by little until it worked. Also in the video, Tariq formatted his FAT32 partition for emummc to 30823 MiB, which is like 950 MiB too big. I'm not quite sure where you got your reference from.

Also, it didn't say "too small" but something to the effect of "no suitable partition" found.

--------------------- MERGED ---------------------------

I see, you took the number from his text file he had on his desktop. What he actually used was much bigger.

 

[Cyan]

really? Sorry for the mistake.
I got it from the video. I rewatched it and you are right, he creates it with bigger value.

so, your value is the first accepted by hekate? good to know

 

[tabzer]

really? Sorry for the mistake.
I got it from the video. I rewatched it and you are right, he creates it with bigger value.

so, your value is the first accepted by hekate? good to know

Well, I didn't do it 1 by 1 MiB. It could be like 5-7 too big, lol (don't quote me!)

 

[Bst22322]

This is what I have gone off of, from the RetroNx Discord

 

[Cyan]

oh, right, if it has to be aligned that make sense
it also mean that writing it to arbitrary sector is not a good idea and hekate take care of that.
dumping nand to partition is therefore better than writing image to partition manually.

thank you for getting proper answer.

 

[TariqSoftDev]

Sounds very interesting! Although I'm fine doing things in GParted.

The start sector to an emuNAND created by SX OS is 0x2. So is there any way to get this into the party?

I'll see what I can do; most likely at first only a cmd line version will be ready.

 

[lordelan]

I'll see what I can do; most likely at first only a cmd line version will be ready.

Completely fine with that but it would be amazing if you could involve SX OS partition based emuMMC as well.

 

[Deleted-172301]

Excited for the tool! I’ve been putting off getting my SD setup just because of the time.

 

[jan2705]

I think I got OFW/CFW-Atmosphere/Lakka/Android/L4T working in a pentaboot situation.

I took what I learned from your guide, and at the end I created another unformated partition 9. I took the 1.img and dd'd it to partition 9. I couldn't resize it after... it gave me some sort of error. So I deleted it and recreated it using the rest of the space on the sd card.


Since L4T isn't going to be in its native location, we will have to edit the boot.scr file.

Change the partition reference in boot.scr by decrypt-> edit -> reencrypt

"dd if=boot.scr of=boot.txt bs=72 skip=1"
Decrypts

setenv bootargs 'root=/dev/mmcblk0p2 rw rootwait relative_sleep_states=1 access=m2 console=tty0 firmware_class.path=/lib/firmware/ fbcon=primary:1'

Change the partition reference to 9?

setenv bootargs 'root=/dev/mmcblk0p9 rw rootwait relative_sleep_states=1 access=m2 console=tty0 firmware_class.path=/lib/firmware/ fbcon=primary:1'

"mkimage -A arm -T script -O linux -d boot.txt boot.scr"
Encrypts

Also, when all was said and done, I needed to redo the flags for partition 1 and 8.

It seems to be working so far. I am testing it now. If you have any ideas for improvement, let us know!

hey, just seen that the lakka tread op says that dualboot with ubuntu wont work for now, did u needed to do additional steps to get it working alongside this setup or did just the fact that ubuntu is not installed to default location fix it?

 

[TariqSoftDev]

hey, just seen that the lakka tread op says that dualboot with ubuntu wont work for now, did u needed to do additional steps to get it working alongside this setup or did just the fact that ubuntu is not installed to default location fix it?

That's because of how the boot stuff was located before; just manually do it, don't use the boot stuff from the img but from the update then put Lakka on

 

[switchisfun]

hey, just seen that the lakka tread op says that dualboot with ubuntu wont work for now, did u needed to do additional steps to get it working alongside this setup or did just the fact that ubuntu is not installed to default location fix it?

Not the person you are replying to, but I did it as described and lakka boots alongside ubuntu with no issues. No extra steps or anything.

 

[jan2705]

That's because of how the boot stuff was located before; just manually do it, don't use the boot stuff from the img but from the update then put Lakka on

ah yes i remember in intial version boot.scr were located in sd root (hos_data in this case) thanks now i understand
btw do you think its theoretically possible to put ubuntu into an bootable image files on hos_data instead of an partition (like lakka)?