你可能会像我一样遇到这样的问题：有一台你无法控制的路由器使用相同的SSID同时发射2.4Ghz和5Ghz频率的WIFI信号，而你的操作系统默认优先使用信号强度更差的5Ghz，或更糟糕的时候在两个频率上来回跳跃；无论是哪种情况这都将导致你的互联网连接处于不稳定状态，如果你在玩网络延迟需求较高的网络游戏，这将会是一个噩梦。
别担心，其他Linux桌面环境常见的网络管理器诸如nm-connection-editor（NetworkManager）已经直接提供了简单明了的两个或三个频率的选项，你可以比KDE用户很容易的找到并调整他们。
在KDE系统设置中找到“连接”，选中你要调整的WIFI名称，注意控制面板右侧的BSSID选项，通常情况下我建议选择信号强度更好的那个。
如题，花了409购买了一块致态m.2 NVME. ITGZ硬盘盒花了69.
我的ThinkpadE14Gen3上有两个槽位,2230插着SN530 256G， 2280插着CUSO 250G
其中Windows10和Debian 的EFI文件都在SN530上，迁移时由于我的疏忽导致Debian的EFI文件丢失。
冗长的多次试错过程不再提及，只记录有参考价值的有效操作。
查清boot分区内的待启动的vmlinuz文件路径，由于我的整个发行版都处于同一分区，故路径为/boot/vmlinuz-5.18.xxxx
执行
linux /boot/vmlinuz-5.18.xxxx root=/dev/nvme1n1p2
务必给内核启动参数写明root路径，否则只能进入busybox
重装grub引导
sudo grub-install /dev/nvme1n1 #注意，此处为我的新硬盘设备顺序代号，不要填写具体的分区代号
如果提示/usr/xxxx缺少相关文件，执行 apt reinstall grub2
由于过去我使用SN530里的EFI分区，更换引导分区到新硬盘后应修改/etc/fstab里的/boot/efi分区对应UUID
9.生成新的grub.cfg
grub-mkconfig -o /boot/grub/grub.cfg
最后sudo update-grub更新grub配置。
双系统用户注意，如果输出内容没有看到你的WIndows引导，请自查是否启用os-prober.
参见：从Debian11 bullseye切换到Debian12 bookworm
cnblog有文章提到refind引导程序的使用，如有兴趣请自行查看。
一次修复linux的efi引导的集中方法总结记录
官方提到下载安装密钥的指令是：
sudo wget -nc -O /usr/share/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key
但是你apt update会得到这样的错误:
错误:5 https://dl.winehq.org/wine-builds/debian bookworm InRelease
由于没有公钥，无法验证下列签名： NO_PUBKEY 76F1A20FF987672F 正在读取软件包列表... 完成W: GPG
错误：https://dl.winehq.org/wine-builds/debian bookworm InRelease:
由于没有公钥，无法验证下列签名： NO_PUBKEY 76F1A20FF987672F E: 仓库“https://dl.winehq.org/wine-builds/debian bookworm InRelease”
没有数字签名。N: 无法安全地用该源进行更新，所以默认禁用该源。N: 参见 apt-secure(8)
手册以了解仓库创建和用户配置方面的细节。
最开始我没注意密钥路径不对，接着就习惯性
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 76F1A20FF987672F但是问题依旧，倒着往上查操作，在查看/etc/apt/sources.list.d/winehq-bookworm.sources的时候发现
最后一行分明写的是：Signed-By: /etc/apt/keyrings/winehq-archive.key
那你密钥干嘛让我装到/usr/share/keyrings/winehq-archive.key ???
所以先手动移动过去。
mv /usr/share/keyrings/winehq-archive.key /etc/apt/keyrings/winehq-archive.key
这个问题也被一些国内的镜像站点给抄过去了。比如清华的镜像源，不过截至发稿时间，清华源还没有同步Debian12的wine-build，可能得等到第二季度 Debian12正式发布以后了。
给管理员发了邮件申请改改wiki，目前尚未回复。
2023年11月27日：
看了看发现WineHQ依旧没改中文Wiki，清华源的也依然没变化。
我查看了https://wiki.winehq.org/Download_zhcn上面存在的维护者名字，中文写的维护者是无，所以我再次发了一封邮件，这次发给了一位非中文的维护者Rosanne DiMesio。如果收到回复我会继续在文章后面更新，或者有必要的话我尝试去申请一下作为Wiki的中文维护者。（话说上次发给web-admin@winehq.org的邮件都是三月份的事情了，现在都11月了也没人回我，真够无语的）
2023年12月30日：
评论区有网友提醒WineHQ WIki中文页面已经在10 December 2023, at 14:57修正了这个问题。
感谢 jkfloris提供的帮助，事实证明在Wine论坛发帖子比发邮件管用多了😀 
不过令人遗憾的是TUNA还没来得及改，也在邮件列表发了帖子，希望早点获得修正。
按照评论的提示，这个问题确实不会发生在清华的镜像站上。（前提是一开始就全程按照镜像站的提示操作）
我回忆了一下当初的操作，有相当多的人应该是先用了WineHQ官方的源发现下的很慢或者干脆直接被运营商阻断了连接再跑去用的镜像。但是镜像用的路径不是照着官方sources文件而是自己新建了个winehq.sources。
如果和我同样先用了官方的源再尝试用镜像，/etc/apt/sources.list.d路径下应该存在一个winehq-bookworm.sources
Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/wine-builds/debian/
Suites: bookworm
Components: main
Architectures: amd64 i386
Signed-By: /etc/apt/keyrings/winehq-archive.key
这里Signed-By的路径应当按照实际密钥下载的路径写，不管是/etc还是/usr下都无所谓，我个人倾向于下载到官方sources里的写的/etc/apt/keyrings/winehq-archive.key。
评论区说被清华坑了一道是不正确的，准确来说这是被WineHQ的中文旧文档坑了一道。
包括之前的2.1.1~,均无法在Debian12 KDE上运行，扫码后无反应，无法正常登录。
顺带一提，微信仍然会向/etc拉屎，特别明显的就是会修改：/etc/lsb-release为以下内容：
DISTRIB_ID=Kylin
DISTRIB_RELEASE=V10
DISTRIB_CODENAME=kylin
DISTRIB_DESCRIPTION="Kylin V10 SP1"
DISTRIB_KYLIN_RELEASE=V10
DISTRIB_VERSION_TYPE=enterprise
DISTRIB_VERSION_MODE=normal
看上去是银河麒麟的标识。
很无语，国内专有软件一般不会尊重用户。国外的也半斤八两，不过没国内这么嚣张罢了。
顺带一提，卸载的时候会出现缺少文件的错误，重装再卸载也不能解决问题。
sudo rm -rf /var/lib/dpkg/info/weixin
sudo rm -rf /usr/bin/weixin
sudo apt autoremove
即可.
没事别下载国产垃圾专有软件，省得给自己找事干。
xfox@ThinkPadE14Gen3:~$ cd /etc/apt/sources.list.d
xfox@ThinkPadE14Gen3:/etc/apt/sources.list.d$ ls
tailscale.list vscode.list vscode.list.save
xfox@ThinkPadE14Gen3:/etc/apt/sources.list.d$ rm tailscale.list
rm: 是否删除有写保护的普通文件 'tailscale.list'？y
rm: 无法删除 'tailscale.list': 权限不够xfox@ThinkPadE14Gen3:/etc/apt/sources.list.d$ sudo rm tailscale.list
[sudo] xfox 的密码：xfox@ThinkPadE14Gen3:/etc/apt/sources.list.d$
n2n使我快乐，而tailscale的PPA总是在更新apt cache的时候恶心我;)那就给我爬！
实际上Debian12尚未正式发布，但是似乎已经可用了。
参考文章：How to Upgrade from Debian 11 Bullseye to Debian 12 Bookworm
在此之前，你最好确保自己的其他软件处于bullseye的最新版本且工作正常。
sudo sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
sudo apt update && sudo apt full-upgrade
sudo reboot
升级完成后重启你的PC
GRUB里Windows10启动项没了，但是这不算太严重的问题，因为我确实打算全面切换到Linux，尤其是唯一困扰已久的休眠问题已久解决的情况下，FUCK YOU Microsoft！
不过，由于我的硬盘空间不足，我还是不得不至少在笔记本上启动一次Windows以便把必必需的数据无损迁移到Ext4分区。这还需要我去买一块硬盘;)大概得等到下个月发工资的时候了。
xfox@ThinkPadE14Gen3:~$ sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.18.0-0.deb11.4-amd64
Found initrd image: /boot/initrd.img-5.18.0-0.deb11.4-amd64
Found linux image: /boot/vmlinuz-5.10.0-20-amd64
Found initrd image: /boot/initrd.img-5.10.0-20-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done注意第八行提示，由于更新后的Grub软件包默认禁用os-prober，我们得手动编辑grub配置文件启用os-prober帮助grub扫描添加Windows启动项。
sudo nano /etc/default/grub
取消对GRUB_DISABLE_OS_PROBER=false的注释并保存
xfox@ThinkPadE14Gen3:~$ sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.18.0-0.deb11.4-amd64
Found initrd image: /boot/initrd.img-5.18.0-0.deb11.4-amd64
Found linux image: /boot/vmlinuz-5.10.0-20-amd64
Found initrd image: /boot/initrd.img-5.10.0-20-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done问题解决
看来一些人喜欢arch linux的滚动更新也并非没有道理，许多linux发行版的稳定版特别是LTS对新的桌面PC的支持都并不友好，但是这些新设备的支持往往已久被加入更新的软件版本了，对于因此对于自己手头常用的新PC产品并不应该过于执着稳定版，尚未发布的版本往往对新设备用户准备了惊喜/吓。
尽管休眠已经可用，我发现睡眠似乎还是出现睡眠后无法登录的问题，只能强制关机。
但是cat /sys/power/state发现返回值变成了freeze mem disk （在debian11的时候仅仅支持freeze和mem）
参见查看当前内核支持的休眠模式
经手动测试，freeze,mem，模式是正常可用的。
disk模式在测试时被发现电源指示灯闪烁后屏幕恢复休眠瞬间的界面并卡死。（但是我点击KDE休眠选项真的可以正常休眠和唤醒）
未完待续
反复检查，代码无任何问题。
直接使用python解释器也能正常启动，但是在vsc里用code runner插件运行就报错。
PS E:\PythonDevelopFiles\GUI-n2n> python -u "e:\PythonDevelopFiles\GUI-n2n\app.py"
Traceback (most recent call last):
File "e:\PythonDevelopFiles\GUI-n2n\app.py", line 3, in <module>
from tkinter import *
File "C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\python3.9\tkinter\__init__.py", line 37, in <module>
import _tkinter # If this fails your Python may not be configured for TkWindows的Python安装包默认是会安装tkinter的，接着我发现我居然有两个可选解释器
第二个貌似是不久前为了编译n2n安装choco包管理器后使用choco安装的，打开控制面板\程序\程序和功能，发现确实还有个
Python Launcher 3.9.7686.0，大概是两个注册环境产生冲突了。所以手动运行了其中一个的安装工具进行配置选择修复，果不其然发现tk/tcl是扫描到的修复项目。
接着发现问题没有解决，并且在windows目录下手动找到了一些乱七八糟的pyhton文件残留。
索性重新安装python3.8 （为了兼容Windows7）
接着问题依旧，连从外部运行也出现报错：文件名、目录名或卷标语法不正确。
我人麻了，Windows真的不适合开发。。。。配置开发环境可用性还要用户手动去保证，商店下的py3.8还这个德行。我不想在微软阿三的粪坑上浪费时间了，直接重启到Debian11
sudo apt install python3-tk #Debian11已经预装Python3了，但是没有预装tk。
Linux下Python的tkinter库是单独打包的。（因为非开发者通常不需要下载tk即可运行常见的的各类应用，即使某些有需要，其打包时也会写明对python3-tk的依赖。
VSC启动.....
[Running] python -u "/tmp/tempCodeRunnerFile.python"
/bin/sh: 1: python: not found
[Done] exited with code=127 in 0.008 seconds
好吧，Code Runner 默认用的是python这个命令调用的，手动建立个软链接就好了。
或者...sudo apt install python-is-python3 #我更喜欢使用包管理器，而不是让自己手动制造哪些我可能在未来忘记或产生疑问的非常规因素。
VScode 启动，右键 Run Code
窗口出现，继续开发。
尾声：祝愿不可靠的MS Windows早点从中国广大用户的PC里滚蛋，哪怕使用不被看好的国产Linux发行版也比这种屎山生态的不可控专有软件更有利于国家发展。
PS：今天早上把应用商店的Python3.8卸载掉，果断choco install python3安装了最新版，功能一切正常，问题解决。
偶然的重启了nas并且发现rdp无法连接，ssh登录后我发现我的nas里堆积了一些不好的文件导致，这些文件过去是我出于好奇加入到BT下载列表的，但是我现在不想看这些令人反感的文件，所以他们被删掉了。但是尽管空间占用问题解决，我依然无法启动我的rdp服务。我不太明白为什么......
~$ systemctl status xrdp.service
● xrdp.service - xrdp daemon
Loaded: loaded (/lib/systemd/system/xrdp.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2023-01-24 05:05:39 CST; 6s ago
Docs: man:xrdp(8)
man:xrdp.ini(5)
Process: 115063 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
Process: 115071 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=1/FAILURE)
CPU: 42ms
接着我看到了这个xrdp service fails to start after reboot
他们的报错与我似乎相同。