With the iPhone 17 Pro, Apple is sourcing OLED panels from different manufacturers. It’s a bit of a lottery — some phones end up with Samsung panels (considered the best), while others come with LG or BOE panels. The catch? A few non-Samsung screens show a noticeable blue tint.

The easiest way to check? Use 3uTools.

• Runs on both Windows and Mac
• Works perfectly on iOS 26 (as of Sept 25, 2025)
• Doesn’t need a jailbreak
• Spits out your hardware info in seconds, including the display’s serial prefix

Look for G9P, G9N, or G9Q in the serial number — that means you’ve got a Samsung panel.

Apple used to let us pull this info by digging into sysdiagnose logs, but they shut that down in iOS 26. Thankfully, 3uTools makes it super easy. I haven’t had the time to play with all its extra features yet, but for this one purpose alone it’s worth grabbing.

Big shoutout to the developers for keeping it free!

You would think this would be pretty easy, a few clicks and done? That wasn’t my experience on Azure and setting this up isn’t easy nor straightforward. Below is how to get it done, if this helps you – you can buy me a coffee or beer.

Updates

June 2021: Reader “Ben R” contacted me about this article and shared some noteworthy information for folks using older VM images or installations. DHCPv6 may be disabled and must be manually enabled. See this article for enabling DHCPv6 on Azure.

The problem with creating a directory for something before is mounted is that when zfs-mount.service runs and attempts to mount the zfs mount points you will get these kind of errors:

root@pve:~# systemctl status zfs-mount.service
● zfs-mount.service - Mount ZFS filesystems
Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2017-06-30 18:10:21 PDT; 21s ago
Process: 6590 ExecStart=/sbin/zfs mount -a (code=exited, status=1/FAILURE)
Main PID: 6590 (code=exited, status=1/FAILURE)

Jun 30 18:10:19 pve systemd[1]: Starting Mount ZFS filesystems...
Jun 30 18:10:20 pve zfs[6590]: cannot mount '/gdata/pve/subvol-102-disk-1': directory is not empty
Jun 30 18:10:20 pve zfs[6590]: cannot mount '/gdata/pve/subvol-106-disk-1': directory is not empty
Jun 30 18:10:20 pve zfs[6590]: cannot mount '/gdata/pve/subvol-109-disk-1': directory is not empty
Jun 30 18:10:21 pve systemd[1]: zfs-mount.service: Main process exited, code=exited, status=1/FAILURE
Jun 30 18:10:21 pve systemd[1]: Failed to start Mount ZFS filesystems.
Jun 30 18:10:21 pve systemd[1]: zfs-mount.service: Unit entered failed state.
Jun 30 18:10:21 pve systemd[1]: zfs-mount.service: Failed with result 'exit-code'.

Fixing the root of the problem: change how proxmox deals with mounts by editing /etc/pve/storage.cfg – you need to add “mkdir 0” and “is_mountpoint” to the directory mount. Example:

dir: gdata-dump
path /gdata/vz
content iso,vztmpl,backup
maxfiles 0
shared 0
mkdir 0
is_mountpoint 1

Now we need to do some system cleanup before we reboot and confirm the problem is fixed.

Let’s check which mount points have failed:
root@pve:~# zfs list -r -o name,mountpoint,mounted

Now let’s umount all zfs mount points (except rpool of course – assuming the rootfs is zfs)

# zfs umount -a

After making sure ZFS mount points are unmounted, now we can delete the empty folders. Recall the failed mount points that the zfs list command gave you and one by one delete them like so:

# rm -rf /gdata/pve/subvol-102-disk-1

Do this for each folder that showed issues mounting. You have a choice to remount everything with zfs mount -O -a — or better… reboot the system and check its fixed. I like the later better. So reboot.

After it boots back up check that service was able to mount zfs without issues:

# systemctl status zfs-mount.service
# zfs list -r -o name,mountpoint,mounted

That’s all folks… if you made the edit to storage.cfg and added the two variables this should not occur again. This was an annoying bug to deal with but good to have found a better solution than a startup script doing some dirty tricks!

I have a pair of Samsung 840 Pro 256GB SSDs that I wanted to use for my new homelab that I am currently building (moving from vmware to proxmox). You may be wondering why I want to install the operating system on a partition instead of an entire disk. Several reasons:

1. Proxmox (ZFS-on-Linux) does not yet support SSD TRIM, FreeBSD does support it so migrating from FreeNAS into Proxmox I should be aware of it.
2. Data redundancy for the root filesystem does not need to be large. Even if I do RAID1 with my two SSDs I won’t be storing my critical data or VMs in the rpool – I want a smaller sized root pool that has fault-tolerance (RAID1). A partition of 60GB mirrored in two SSDs should fit the bill here.
3. ZIL Intent Log experimentation, I also want to experiment by using the same two SSDs to speed up my ZFS writes. I want a small partition in a stripe (RAID0) for performance, 45GB total (22.5gb per ssd) is plenty for this.
4. The left over unused space will be left untouched so that the SSD will have more available blocks during the controller’s built-in garbage collection (not the same as TRIM)

I don’t have enough time to go into a lot of details (it’s past 4am), so I will get to how to do it. If you are trying to follow my same steps, you will need at least 3 hard drives.

1. On a hard drive or device you don’t care to use in the final outcome, install Proxmox as you would normally. Wipe the entire partition table and let it install RAID0 on the whole disk.
2. Boot into your new installation, have the two new disks you want to keep attached to the system and ensure linux sees them fdisk should help with this.
3. You will now need to create the partitions on the new disks (not rpool):

You will need to know how to calculate hard disk sectors and multiply by your block size. I don’t have time to go over it but I will do a quick TL;DR example to give you an idea:

We want 25GB slice so that is around 25000000000 bytes / 512 (block size) = 48828125 total sectors to allocate this storage amount.

Take a look at the partition table to make sure you create something similar, fdisk -l /dev/sd$ (your rpool disk). We will leave 8MB disk at the end of the partition, Proxmox by default creates 3 partitions: GRUB_BOOT, ZFS data, Solaris 8MB.

This command creates the partitions for my new array, I’ve described them for you by the -c command. It should be self-explanatory.

# sgdisk -z /dev/sdb
# sgdisk -a1 -n1:34:2047 -t1:EF02 -c1:”BIOS boot” -n2:2048:156252048 -t2:BF01 -c2:”mirror” -n3:156252049:205080174 -t3:BF01 -c3:”stripe” -n4:205080175:205096559 -t4:BF0 /dev/sda

# sgdisk -a1 -n1:34:2047 -t1:EF02 -c1:”BIOS boot” -n2:2048:156252048 -t2:BF01 -c2:”mirror” -n3:156252049:205080174 -t3:BF01 -c3:”stripe” -n4:205080175:205096559 -t4:BF0 /dev/sdc
# zpool create -f stripe -o ashift=13 /dev/sda3 /dev/sdc3
# zpool create -f newroot -o ashift=13 mirror /dev/sda2 /dev/sdc2
# grub-install /dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1ATNSADB46090M
# grub-install /dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S12RNEACC59063B

Backup & moving stuff.
# zfs snapshot -r rpool@fullbackup
# zfs list -t snapshot
# zfs send -R rpool@fullbackup | zfs recv -vFd newroot
root@pve:/# zpool get bootfs
NAME PROPERTY VALUE SOURCE
newroot bootfs – default
rpool bootfs rpool/ROOT/pve-1 local
stripe bootfs – default
root@pve:/# zpool set bootfs=newroot/ROOT/pve-1 newroot
zpool export newroot
zpool import -o altroot=/mnt newroot
— rebooted with freenas live cd, enter shell, import newroot with new name rpool. rebooted
— boot into proxmox recovery — once it boots, do recovery
grub-install /dev/sdb
grub-install /dev/sda
update-grub2
update-initramfs -u

#zpool set bootfs=newroot rpool could also work without renaming via FreeNAS but didn’t try.

My needs for more CPU power and memory is driven by the idea of hyperconvergence. Which means I use a single machine to be my router/firewall, VPN gateway, network storage as well as virtual machine host.

Those themes have been part of my home network design since 2010 or so, today’s hot technologies are focusing on containers (LXC), Docker, etc. So I need a more powerful server in order to be able to expand my playground into those technologies. The 32gb maximum on my old server is simply not enough when you have 5 different VMs that consume almost all your memory resources (windows 10 VM, OSX one and my FreeNAS one being the top users of 75%+).

On my new machine I have decided to move towards the Xeon E5 v4 CPU series and DDR4 which has lower memory consumption than my current LPDDR3 (1.2v vs 1.35v per ram stick).

The components of choice is a Supermicro X10SRL-F with remote management (IPKVM), and 64gb DDR4 to start.

For server chassis I’ll be reusing my Lenovo TS440, but first I’ll assemble and test my new server on a different chassis as to not impact my home router/network design.

Since I will most likely be moving away from VMware ESXi into Proxmox or another open source alternative this means that there will be a steep learning curve as I try to do the initial configuration of the network to run on a single node (hyperconverged). I will have to learn OpenVswitch with is a virtual switch that runs on unix.

However, if you open the command line and you attempt to run “chrome.exe” it will complain that the executable is not found in the %PATH%

This is because Control+R also looks up the registry values within HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\

Which include all apps ever installed such as Chrome.exe, Firefox.exe, Excel.exe, Illustrator.exe, etc.

So if you are ever writing a program in your programming language of choice, using a Windows Registry check of the location (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths) for whatever.exe will be the perfect solution when that program is not in the System Environment variable %PATH%

The disk actually is a Seagate ST32000644NS that HP calls it its own model MB2000EAMZF. Once the disks arrived and I was ready to test them I noticed a fatal flaw. Their firmware was very out of date and HP made a critical update that is mandatory for these drives to avoid them from failing due to 24/7 usage.

To my surprise although these drives are Seagate and the internals are exactly the same they run different firmwares, and Seagate’s tools or utilities will not flash or work on HP branded drives thus forcing you to grab the firmware updates from HP.

Seagate makes these firmware updates available for free and HP does as well but with one gotcha – you must run the firmware update tool in Hewlett Packard hardware or the firmware will not flash and there seems to be no workaround. Thumbs down to HP for locking down a critical firmware update to only run on HP Proliant server hardware (I have Dell but a SATA hard drive is recognized as a normal hdd on any brand computer thanks to computing standards).

The problem I recently encountered was trying to find the executable PATH of the git-bash.exe so that I can configure my Webstorm IDE to use it. All the documentation on the internet seems to point to C:/Program Files/Git folder but Github may have changed this as in the latest release I downloaded (v 3.3.3.0) the files reside elsewhere and I will share where to find them.

To find your git-bash.exe path try the following:

1. Open File Explorer and put %AppData% in the address bar, hit enter.
2. It should redirect to something like:  C:\Users\Giovanni\AppData\Roaming
3. Now change folders from Roaming to Local
4. You should now be at: C:\Users\Giovanni\AppData\Local 
5. Find the Github folder, enter it.
6. You should see a list of files and folders, we care about “PortableGit” it has a longer name that just PortableGit, so enter it.
7. You will see git-bash.exe in there.
8. Go back into Webstorm > Settings > Terminal
9. Set your terminal to this new path, in my case: “C:\Users\Giovanni\AppData\Local\GitHub\PortableGit_d7effa1a4a322478cd29c826b52a0c118ad3db11\git-bash.exe”

You’re all set! Webstorm should now be able to launch Github Desktop’s git-bash.exe as the terminal, no additional software required.

There is a gotcha: the terminal window will open separate from Webstorm window, if you want a tab under your code then I suggest to download and install git for windows in addition to Github Desktop.https://git-for-windows.github.io/

I have run into a few issues on Google Compute Engine, it looks like every time the instance gets a DHCP offer the hostname of the machine will get reset to the internal hostname, overriding whatever setting you may have set… this is bad news for a server that needs to respond to DNS settings.

After a few hours of digging and testing out different approaches, including trying to setup a DHCP hook to run the “hostname” linux command I came across documentation from Google talking about “custom metadata”.

What is Google Compute Engine?

Google Compute Engine (or “GCE”) is Google’s answer to Amazon’s AWS, it basically offers you the ability to deploy Virtual Machines (VMs) at Google’s datacenters. In the most simplistics of setups you would use a single VM or “compute instance” and if you wanted to have a more complex setup you could deploy multiple instances in different geographic locations spread across different datacenters in the United States to achieve a more redundant setup or to provide you with better capacity for large traffic workflows.

It all depends on what your goals are, myself I am just starting out with a simple requirement. I would like to use a single compute instance running CentOS linux that runs cPanel DNSonly (proprietary control panel/dns clustering solution for cPanel servers).

The goal is not to host websites or any critical services on this instance, but rather only keep a copy of my DNS zones. If my experiment fails or my instance goes down or gets destroyed there won’t be any losses or damages for this experiment as my primary server is still running on Proxmox PVE.

The limitations of GCE… What I learned so far

GCE instances run behind Google’s firewalls and depending on the datacenter you decide to host your instance your VM will have an internal IP within that datacenters network scope/range (for example: us-central1 datacenter zone has a 10.128.0.0/20 range for all VMs).

This means that assigning a IPv4 public static IP, which is needed to allow anyone to query the DNS server we’ll be hosting inside this instance will actually have to forward packets to the instances internal network. Not really a big deal unless your application can’t be behind a NAT firewall like it is the case here.

For our intensive use and purposes it is fine. One important issue that I found is that doing any kind of e-mail server related activities on GCE is prohibited (source). You won’t be able to use SMTP (Simple Mail Transfer Protocol) port 25, 465 or 587 to send or receive email.

Now for a DNS server that will not be a mailserver this is not a blocker, but it is really a pain in the ass. Why? because monitoring scripts running on the server need to email the administrator to notify me of issues or errors so they can be investigated.

Continued on the next page.