Thanks no i'm just trying to gather everything i'll need and get a plan together here.

I need to do more reading i'm getting a little confused.

So I should first install the Factory firmware K0711 in user defined mode

Then Factory V12 Maps in user defined mode OR the 6.24.0 from your VWVortex post after fixing the ini file with your script

Then Install your maps in user defined mode

I am reading not to use the user defined mode from the Green Menu? So i don't need the Green Menu afterall?

User defined mode means you drill into each folder that has an "N" in the 2nd column and check the application checkbox...once they are all checked you download?

Still reading here i'm probably missing some things no doubt

 

Your RNS850 has production P0735 (MU s/w 0881) -- DO NOT overwrite this !

Update K0711 is needed only for RNS850 main units imaged before 2013.

You should be able to install Lysy's repackaging of the Audi NAR 6.24.0 update directly.

Your description of User-defined mode is correct -- I don't claim to know under what conditions it's always needed, but I do know (after several Audi nav updates from production) the first update can be done with Standard mode successfully. After that, we need to patch the QNX O/S to unblock access to the navdb, which breaks Standard mode for subsequent navdb updates (the reason has to do with how the O/S is patched to allow access to the navdb -- an aside: a fellow from Lithuanian claims to have a solution for this in a modified MMI3GApplication binary, but offers no details on this method). In any case, I would set User-defined in the GEM anyway, and try running your navdb "update" as Standard. If no components are selected, it's easy enough to back up & reselect User-defined mode to proceed. --g

 

Your RNS850 has production P0735 (MU s/w 0881) -- DO NOT overwrite this !

Update K0711 is needed only for RNS850 main units imaged before 2013.

Arggggg! i just did this 😫

 

I think i'm going to have to abort I feel like i'm risking a brick when i really don't care about the NAV function anyway. The only reason i wanted to get it to work was to get my compass and altitude functions anyway 😆
I've read all i can read and i just don't understand what the correct process is for loading the maps. Nothing lines up with what i'm seeing. No matter if i select user defined or standard the only files that want to download are the navipersistance and Map styles......those are the only ones that ever get a Y next to them when proceeding with update. All the rest are N/A. The whole update process takes about 1 minute as it loads those files, then reboots and loads some more stuff for about 1 minute, then i hit cancel documentation and the RNS reboots and nothing has changed.

I'm going to clone my samsung spinner over to the SSD and hopefully that should "Just work" and i'm perfectly happy to leave it at that.

 

There is a huge threat on here, it's probably 30 pages, that has all kinds of map updates and whatnot but I'm not sure if that would be helpful

 

@UnXpectedError -- With regard to installing the navdb update, items listed as 'N' have the same version as installed; 'Y' means the update is newer than installed, and "N/A" means the iinstalled tem is not found in the update metainfo2.txt file. I assume you prepared a 32GB FAT32 SD card with Lysy's NAR 6.24.0 navdb update from here: https://www.clubtouareg.com/threads...50-north-america-region-maps-update-version-6-24-0-latest-one-2021-2022.300227/ --g

 

@UnXpectedError -- In cases like this, my advice is to run my MMI3G Information Reporting script at my GitHub repository: GitHub - DrGER2/MMI3G-Info: MMI3G Information Report Script
You are mostly interesting in the sections of the report log that describe the disk device attached to dev/hd0: partitions layout and available/mounted file systems. For example, the current NAR 6.24.0 navdb requires at least 25.1 GB. Based on my reading of the DOS "fdisk info" image, /mnt/nav will have enough space to accomodate the NAR navdb (28,676,455,936 bytes available), but not enough for ECE 6.36.0 (unless it is reformatted in the GEM). BTW, the paritioning of these drives looks like they came from Asian market cars, possibly later 2018 Q3s sold in JP, KR, and TW. This from an HN+_JP system being converted to HN+_EU:

Filesystem           1024-blocks      Used Available Capacity  Mounted on
/dev/hd0t77             28004332  12305964  15698368      44%  /mnt/nav/
/dev/hd0t78             20240368   5567993  14672375      28%  /mnt/mediadisk/
/dev/hd0t79              1069040    932277    136763      88%  /mnt/sss/
/dev/hd0t187             5245932   1191418   4054514      23%  /mnt/gracenode/
/dev/hd0t187.1            168940     11005    157935       7%  /mnt/mmebackup1/
/dev/hd0t187.2            177132     13387    163745       8%  /mnt/persistence
/dev/hd0t187.3           2137068     81409   2055659       4%  /mnt/img-cache/
/dev/hd0t187.4           1052652     40101   1012551       4%  /mnt/pv-cache/
/dev/hd0t187.5            354284     22019    332265       7%  /mnt/routestudy/
/dev/hd0t187.6            154604      9532    145072       7%  /mnt/vics/

--g

 

@UnXpectedError -- In cases like this, my advice is to run my MMI3G Information Reporting script at my GitHub repository: GitHub - DrGER2/MMI3G-Info: MMI3G Information Report Script
You are mostly interesting in the sections of the report log that describe the disk device attached to dev/hd0: partitions layout and available/mounted file systems. For example, the current NAR 6.24.0 navdb requires at least 25.1 GB. Based on my reading of the DOS "fdisk info" image, /mnt/nav will have enough space to accomodate the NAR navdb (28,676,455,936 bytes available), but not enough for ECE 6.36.0 (unless it is reformatted in the GEM). BTW, the paritioning of these drives looks like they came from Asian market cars, possibly later 2018 Q3s sold in JP, KR, and TW. This from an HN+_JP system being converted to HN+_EU:

Filesystem           1024-blocks      Used Available Capacity  Mounted on
/dev/hd0t77             28004332  12305964  15698368      44%  /mnt/nav/
/dev/hd0t78             20240368   5567993  14672375      28%  /mnt/mediadisk/
/dev/hd0t79              1069040    932277    136763      88%  /mnt/sss/
/dev/hd0t187             5245932   1191418   4054514      23%  /mnt/gracenode/
/dev/hd0t187.1            168940     11005    157935       7%  /mnt/mmebackup1/
/dev/hd0t187.2            177132     13387    163745       8%  /mnt/persistence
/dev/hd0t187.3           2137068     81409   2055659       4%  /mnt/img-cache/
/dev/hd0t187.4           1052652     40101   1012551       4%  /mnt/pv-cache/
/dev/hd0t187.5            354284     22019    332265       7%  /mnt/routestudy/
/dev/hd0t187.6            154604      9532    145072       7%  /mnt/vics/

--g

Attached is the output log file from your script.

This log is for the SSD running the image that was in my spinner which works except NAV.

I'll run your partition script on the other ssd and run the report again standby

 

Thanks guys I'll give it another go here today. Looks like i might have a bad block on my ssd:

 

So that's why he's selling them...

You have already this red mSATA PATA adapter. You can buy a cheap mSATA SSD and give it a go.

 

looks ok here .....is there a better scan i can run in the linux enviro?

Yes i got the red msata adapter in hand. Need a drive still but that will be easy.

 

Rather look at S.M.A.R.T. table and reallocated sector count number. Mind that disks have some additional blocks and in case of marking it as bad it's replaced by a spare.

Always You can try once again reformatting it with QNX and check if it's permanent.

 

@UnXpectedError -- Just run the mkmmi3ghdd2 script again. I've seen where "mount -e /dev/umass0" doesn't always enumerate the block devices (e.g., /dev/umass0t79) correctly -- had this happen recently on an old testing HDD; ran the script again and it finished OK. I'm thinking I'll put the "mount -e" in a while loop and have it try N=3 times before exiting the script with a warning message. --g

 

I actually bought 2 of these drives. Getting the same error at the same time with both drives. Script seems to execute just fine otherwise? Doesn't seem to matter how many times i run it i get the same error, but i have to delete the partitions each time in order to run it (Is that what we want?)

 

Just don't assemble covers for MU and the glovebox, plug the cables in and make a tryout with this drive.

 

For Sure
Could be my usb/ata adapter....vmware driver.....who knows

 

Can't seem to figure out how to get the box out of its bracket.......don't seem to remember this part

What do you mean by use 2 Volkswagen keys?

Edit aw man do I need special radio removal tool? Why do I not remember this.....I must be losing it lol

 

You can use two very flat nail files. Or any similiar item. While the spring inside mechanism is already pressed, use some force from the back to push the MU out.

 

Not liking the error counts.....guess i'll try loading maps anyway

 

It's downloading something and taking longer here.

Standard didn't work.
This time in user defined I went into a folder that had a ? Instead of an N or NA
Inside were a bunch of folders with an N which I selected all of them.

Hopefully this may work

 

Part of the problem with SMART here is that Harman-Becker added what looks like SMART support for SDD devices in the MMI3GApplication binary in the HN+R_P1001 release, built in Sep 2016. As best I can tell only some later A8s and MY2017+ Q3s got this. Your K0711 MMI3GApplication binary was built in Feb 2013, so take it for what it's worth. --g

 

Arg after 3+ hours of downloading DB files its now stuck in a continuous reboot cycle, Reading Metainfo Reboot, Reading Metainfo Reboot about 25 times now. Guess its time to shut er down,

 

Thought it was bricked for sure when I put the old spinner back in and the loading metainfo came up again.....thankfully it didn't reboot right away and let me cancel install

Earlier I took an image of the old Kijiji spinner and so I just restored that image onto the SSD and popped it in.....I'm up and running like I was before with everything working except NAV

The mp3 I was playing earlier on the spinner even resumed when I fired back up on the SSD

I know this is the 3rd time I've asked......but you guys are 100% sure a NAR image from somebody else's RNS won't "Just work" in mine? Assuming i found one with similar Hardware/software versions as mine?

Any ideas what I'm doing wrong with the install?

If I try again I might try the old spinner just to see.....maybe it wont have the i/o error which could have been the cause of my botched install

 

spinner:

 

When I started looking at working with the 2.5 inch IDE drive in our MMI3GP main units in the QNX VM a couple years ago, I had in my collection of older computer hardware a couple of USB2.0 notebook drive enclosures from projects 15+ years ago. The enclosure I use to test my mkmmi3gphdd2 script is powered, so I'm not relying on the Linux desktop USB port to power the notebook HDD in the enclosure. Given that the HDD & SDD appear to failing in the same way is an odd coincidence. The point of my intro here is that if the first IDE/USB adapter didn't play nice with the QNX VM, I had another to try. I'd look at the USB/IDE adapter next... --g

 

I had couple of problems with the USB PATA adapters as well. There was once faulty ribbon cable, I also had some power issues. When You do have a properly formatted drive, the upload should end up with success or failure, but not in boot cycles. Cloning a drive won't make a change.

I hope Your four thermopads are all in place, because overheating can cause such problems as well.

My conclusions are as they were before... Please check if the firmware was fully uploaded. If not, REPEAT the process until all sections will have status N, at the start of an update. It will mean all is up to date (in Your case down to date ). It's the first step to make things work. If You've aborted uploading a firmware or/and have some sections from one firmware (it's unclear to me what actually You've done), some from second, it will cause a mess.

Then please delete NAV partition via GM in this SSD drive. The only parition which had bad blocks was that with NAV. If it's adapters problem, formatting this section in the MU will delete it. Then install V12 maps in User defined mode ticking eveything to Y.

If it fails there's probability that You do have a faulty main unit, or the SSD drive is faulty.

If not, then we'll talk...

 

I hope Your four thermopads are all in place, because overheating can cause such problems as well.

Thanks for this. After reading this for the second time it finally clicked that the hard drive enclosure is acting as a heat sink for the below electronics.
It's entirely possible this is what happened during both my full install attempts since I had not been putting any screws in anything. Simply lodging things in there as gently as possible as I was switching out drives etc.

Contact with thermal pads was likely very poor. I'll make sure to button everything up better on my next full install attempt

 

Hey Guys thanks again for all the help and suggestions yes i agree my recent model Vantec ide adapter could be causing problems since we are getting errors on any drive it seems when partitioning using your script. In windows it seems to work fine and there are no complaints during bad block scans, image save and restore etc.

I tried the same procedure again with the samsung spinner except this time I deleted the NAV partition in green menu before proceeding and i got the exact same behavior as before.....wait 4 hours then nav get stuck in a reboot cycle.
I'm trying the same procedure again this time with the original Cloned image from Malaysia touareg and the SSD.

Took a video this time....maybe you'll see something i'm doing wrong.

Huge file this link might need some time:

New video by Rob E

photos.app.goo.gl

 

Got this error right away after the above video:

Tried retry but Had to hit skip twice then it rebooted and got NOK on all items

 

Got this error right away after the above video:

Tried retry but Had to hit skip twice then it rebooted and got NOK on all items

Error code 150 usually indicates that the Updater process (part of MMI3GApplication) cannot write to the destination device, either because "no space left" or device is mounted read-only. --g