分类目录未定义

我的行车记录仪是乐驾的A8-plus，存储卡的容量是16GB，感觉空间不够用，在京东上下单买了个“金士顿行车记录仪&家庭监控摄像专用 TF（MicroSD）存储卡”，容量是128GB。

拿到新卡后，我把它插入到记录仪的卡槽里，然后开机，手指点击屏幕，出现操作选择界面，点录像按钮，发出“未插入SD卡”的提示音。我的心里满是疑惑，难道是卡的容量太大，记录仪不支持？还是别的什么原因？

我把新卡插到电脑上，看到卡的分区格式是exFAT格式。再看16GB的旧卡，则是FAT32格式。于是我决定把新卡重新格式化成FAT32格式，看看行不行。

但通过操作我发现Windows系统自带的磁盘管理工具根本无法格式化128GB的新卡为FAT32格式，于是百度查“如何格式化大容量fat32”，发现傲梅分区助手可以做这件事，于是下载安装了傲梅分区助手，通过傲梅微信公众号获得“使用码”，最终成功将128GB的新卡格式化为FAT32格式，操作如下：

将重新格式化的新卡再次插入到行车记录仪的卡槽内，开机点击屏幕选录像按钮，发出“开始录像”的提示音！128GB的新卡可以使用了！

最近发现当我使用谷歌Chrome浏览器会偶尔出现无法访问网络的情况，比如我在看新浪的新闻，一开始还都正常，用一会儿当点击某个新闻连接准备打开该新闻页面时出现的不是预期的正常页面，而是如下图所示的页面：

我电脑使用的是Windows11系统，通过小米无线路由器连接的网络。

网上搜了一下，找到了解决办法：

1. 打开chrome浏览器，在地址栏输入chrome://settings/security；

2. 找到“隐私设置和安全性”项，选“安全”项；

3. 找到“使用安全 DNS”项，选择“使用 自定义”，填写“https://dns.alidns.com/dns-query”，如下图：

使用Microsoft Edge浏览器也会遇到这个问题，解决方法类似。

2022年不知从何时起，每次使用Chrome浏览器都会在地址栏下方出现一行提示文字：“若要接收后续 Google Chrome 更新，您需使用 Windows 10 或更高版本。该计算机目前使用的是 Windows 7”，如下图：

不胜其烦，我多次尝试更改Chrome设置，希望关闭这个提示，未果。

一日我终于想到了万能的网络，直接搜索“若要接收后续 Google Chrome 更新，您需使用 Windows 10 或更高版本”，网络真是给力，没有丝毫的拖泥带水，问题很快解决，方法整理如下：

1. 新建一个文本文件，复制粘贴下面3行代码：

2. 保存文件为my.reg，注意扩展名一定是reg，不是txt；

3. 鼠标双击运行my.reg文件，在出现的“用户帐户控制”提示窗口中点“是”按钮：

4. 又出现一个提示窗口，点“是”按钮：

5. 出现注册表添加成功提示，点“确定”按钮：

6. 重启Chrome浏览器，烦人的提示消失了！

虚拟世界的MAC地址

先看一下真实世界的MAC地址是如何分配，如何保证没有重复的。

每块网卡都有一个MAC地址，MAC地址是一个6字节、也即48bit的数据。前3字节称为OUI ，是由IEEE组织注册给网络设备生产商的；每个厂商拥有一个或多个OUI，彼此不同。后三字节则是由网络设备生产商分配给自己生产的每一个拥有MAC地址的设备，互不重复。

在VM的世界中，每一台拥有虚拟NIC（网卡）的设备当然也拥有MAC地址。这虚拟网卡的MAC地址，当然也是按照规定，前三字节为OUI，后三字节逐一分配给每个设备。

由于虚拟网卡的”制造商“是VMware，XenSource，微软 等虚拟平台软件的生产商，OUI当然就分配给了他们。

VMware VM所使用的OUI

按照VMware ESX 3的[Server Configuration Guide ]的说法，VMware的使用下面的三个OUI作为VM的MAC地址：

00:0C:29 – 用于自动生成的MAC地址
00:50:56 – 用于手动设置的MAC地址
00:05:69 – 曾经用于旧版本的VM（大约是在ESX 1.5的时代），在ESX 3中已经不再使用

但是在实际应用上，我发现00:50:56这一MAC地址段并不是完全用于手动设置的MAC地址：

00:50:56:00:00:00 – 00:50:56:3F:FF:FF
这一段MAC地址可以用于手动设置的MAC地址

00:50:56:40:00:00 – 00:50:56:FF:FF:FF
这一段（我的推测，不一定准确），则是用于ESX 3上的自动生成的MAC地址（包括VM和Service Console）

MAC地址的生成

OUI有了，后三字节如何生成呢？要知道虚拟机是经常被创建和销毁的，这一点不像实体PC。网卡生产商可以计算每年生产多少块网卡，从而为每块网卡分配不同的MAC地址； VMware却不可能计算出每年有多少台VM、有多少块虚拟网卡被创建。

VMware ESX Server的算法是，使用散列算法，通过VM的UUID来生成MAC地址。VM的UUID是每一台VM特有的、128bit的ID，是由ESX Server硬件SMBIOS的UUID、加上VM的路径生成的。因此，一台虚拟机的虚拟网卡的MAC地址就与下面四个因素有关：

VMware的OUI
Host (ESX Server)的SMBIOS中的UUID
VM在服务器上的路径
网卡的实体名 (Entity Name)，用来确保同一VM上的不同网卡有不同的MAC地址

MAC地址冲突的检测与解决

MAC地址一旦生成，就不会再有变化，除非上面所述的四项因素发生改变（最可能发生的就是第三项，VM在服务器上的路径改变）。

尽管如此，由于散列算法本身的特征，还是有万一发生MAC地址冲突的可能（可能性极小，和年末ジャンボ中头彩的几率差不多）。ESX Server会不断跟踪和检测运行中和挂起(Suspend)的VM，以保证没有MAC地址冲突。但是已经关闭电源的VM是不在检查对象之内的。

因此，万一一台VM启动时ESX检测到MAC地址冲突，它会分配给VM的虚拟网卡一个新的MAC地址。所以从这个意义上说，VM的MAC地址是可能发生变化的——只是这个概率实在太小。

手动指定MAC地址

手动指定MAC地址仅用于一些极其特殊的情况，通常是进行P2V的时候。例如，某物理服务器上的软件，其License已经与该服务器的MAC地址绑定，如果MAC地址改变则软件无法运行；再如，某些底层网络软件以MAC地址来鉴别机器时，为了不做更改能够继续使用，在P2V的时候也要手动指定 MAC地址。
打开一个VM的.vmx文件，可以看到如下设置：（如果有多块NIC的话，那么就会有ethernet0、ethernet1、ethernet2……）

ethernet0.addressType = “generated”
ethernet0.generatedAddress = “00:0c:29:9b:fb:18”

这说明该NIC是自动生成的MAC地址。只需如下更改即可变为手动分配的MAC地址：

ethernet0.addressType = “static”
ethernet0.address = “00:50:56:00:00:01”

其中的00:50:56:00:00:01就是手动指定的MAC地址。

文章出处：https://www.cnblogs.com/Solomon-xm/articles/10253575.html