Contribute
Register

[Guide][New VoodooI2C] Asus Vivobook S15 X510UAR 10.13+

Need some advice!
Yesterday I performed NVRAM reset on my VivoBook S510UNR.
This VivoBook has dual boot - Windows 10 and Big Sur.
After reset only Windows 10 is loaded. All UEFI configurations have disappeared from the list of downloadable configurations in the BIOS. There are only two Windows bootloader configurations left (I have SSD and HDD, while both Windows 10 and Big Sur are installed on SSD, and the UEFI partition with SSD is simply copied to HDD). OpenCore does not start, even when I manually create the configuration using the BIOS (BOOTx64.efi and OpenCore.efi).
The long way I propose to solve this problem without reinstalling Windows and macOS is to defragment the HDD, allocate a 50 GB area on it and install the "new" BigSur there.
I think that after that both Windows and the "old" Big Sur will become available.
Dear colleagues, can you suggest an easier way? For example, it may be possible to somehow enter the appropriate boot configurations into NVRAM?
 
@bugsb: sorry for late late reply, had a family funeral
I only have this ssd, although you figured the problem out already

1641308133821.png


1641308107895.png
 
@mksim: if your w10 EFI broke, use the tools in bugsb's git to recreate it (I myself use Macrium Reflect)
leave opencore EFI on the HDD, then set the HDD as 1st boot in BIOS
1641309243665.png


thats how I got dual boot the easy way
 
Last edited:
@a29psx sorry to hear about your loss of a family member - I am expressing my condolences to you, and also hope you have found some peace and solace.


I also have separate ESPs (EFI System Partitions) for OC, Clover and Windows. My Data drive on HDD is exFAT for native r/w share Mac/ Windows.


Thank you for your screenshots. I was not aware until now that in Windows, drives that do connect via UASP appear as UAS under Storage in Device Manager; that's great to see and know!

Re. TRIM via UAS in macOS: guess what .. :thumbup:: there must have been a very recent change - it now suddenly DOES WORK, as several Mac detectives just found out no too long ago.

Do as follows:

1. in Terminal:
ioreg | grep UAS

there should not be any output

2. in Terminal:
sudo kextload /System/Library/Extensions/IOUSBAttachedSCSI.kext

3. connect your external SSD, wait till each volume on it is mounted

4. again, in Terminal:
ioreg | grep UAS

if indeed your USB drive is accessed via USB Attached SCSI, there now should be output! I do have the following output with my external M.2 enclosure and the hitherto/ beforehand internal 256GB internal Toshiba SSD:

IOUSBMassStorageUASDriver <class IOUSBMassStorageUASDriver, id 0x100003b4b, registered, matched, active, busy 0 (327 ms), retain 9>

5. Next let's check if TRIM is working not just for the internal SSD, but also for the UAS drive:

#below command queries TRIM attempts on today's date, but *only* on APFS volumes! "spaceman" = Space Manager, part of the AFPS sub-system
log show --predicate "processID == 0" --start `date "+%Y-%m-%d"` | grep spaceman

From journaldulapin-com:
Code:
kernel: (apfs) spaceman_scan_free_blocks:3153: disk4 scan took 4.544669 s, trims took 2.996066 s
kernel: (apfs) spaceman_scan_free_blocks:3155: disk4 100157466 blocks free in 4570 extents
kernel: (apfs) spaceman_scan_free_blocks:3163: disk4 100157466 blocks trimmed in 4570 extents (655 us/trim, 1525 trims/s)
kernel: (apfs) spaceman_scan_free_blocks:3166: disk4 trim distribution 1:815 2+:622 4+:809 16+:312 64+:174 256+:1838

If it doesn't support TRIM (be it case, SSD, HDD, etc.), you will have this instead:

Code:
kernel: (apfs) spaceman_metazone_init:191: disk4 metazone for device 0 of size 2693771 blocks (encrypted: 0-1346885 unencrypted: 1346885-2693771)
kernel: (apfs) spaceman_scan_free_blocks:3171: disk4 scan took 2.461839 s (no trims)

However, from the same French web page, translated into English:

Finally, I tested with Catalina (and it doesn't seem to work) and Guillaume helped me with Big Sur, and it doesn't seem to work either. So it is a priori a novelty of Monterey.
For further reading:
 
Last edited:
@a29psx sorry to hear about your loss of a family member - I am expressing my condolences to you, and also hope you have found some peace and solace.
thank you, best wishes for you and your family

My Data drive on HDD is exFAT for native r/w share Mac/ Windows.

I did try exFAT for data partition but got errors later, and it cannot be fixxed (forgot what the error is exactly)
So I have to move all my data to an ext HDD, reformat the internal HDD back to NTFS and using mounty on MACOS
the exFAT also cannot be resized by any partition manager, only delete and recreate

I think exFAT is really unreliable for important data storage
 
exFAT errors: I can confirm that my exFAT data partition on HDD appeared empty in Minitool Partition Wizard latest version a while ago, same as for you unfixable no matter what I tried, and also threw an error in GParted. Other than that it was working fine in both, macOS and Windows. But since I always have a 1:1 clone, I simply restored it to be on the safe side. It's not important data requiring encryption, so I opted for exFAT.

I'm observing now and would format it to HFS+ (+ HFS+ write support in Windows) in case I should get a similarly knotty error again.

exFAT resize: The tool Eassos DiskGenius (ex. PartitionGuru) is able to resize exFAT partitions. Even the free version can do it, and can also do a defrag if needed :)

To do a check and repair, perform a (small) resize.

See also this blog post @ Eassos.

On HDD it might be s l o w, however.

Mounty: I've been aware of it. A while ago I did a ton cross-comparing the different NTFS r/w solutions for macOS, both by reading and testing myself. Mounty uses macOS' built-in NTFS driver, which according to some people is inferior, which is why Paragon and the FUSE community developed their own r/w driver (there might be others I'm lacking right now out of the top of my head). I settled with Paragon, but also only toggle it into r/w on-demand.

TRIM via UAS in macOS: unless force-/pre-loading IOUSBAttachedSCSI via boot loader, sudo kextload /System/Library/Extensions/IOUSBAttachedSCSI.kext is necessary on Computers w/o Thunderbolt. On real Macs with TB (like my friend's MacBook Air), macOS detects TB and pre-loads that kext. Even though TB technically isn't USB per definition, Apple put that functionality even for TB into that kext. It's just the way it is.
 
I did try diskgenius last time after googling around
It claimed to work and it seemed to work at first. But when I hit apply button it just say it cannot
And the UI is horribly bad

my work is mostly on windows so I opt for NTFS + mounty for macOS (cause it s free :D)
 
Last edited:
Back
Top