记录一次Manjaro系统的惊险修复
背景
这次真不是水
前几天五一假期中期之时， 因为跑一个React项目的缘故， 偶然间修改了根目录下/usr路径的权限。😇类似于:
1 | sudo chmod -R 777 /usr |
后续执行sudo xxx指令就报错/usr/bin/sudo 必须属于用户 ID 0(的用户)并且设置 setuid 位🤕
哎哎，自然是权限问题，因为Linux系统下的sudo权限必须交给root用户
(题外话说一下setuid, setuid位是一种特殊权限位，当设置在某个可执行文件上时，允许任何用户在执行该文件时拥有文件所有者的权限。对于sudo这样的命令，这是必要的，因为它允许非root用户临时提升权限执行管理任务)
现在sudo`也用不了，不能把权限给赋回去，好吧，开始救命
解决步骤
疯狂搜索
用这个报错信息一查，结果发现不止我一个傻春😝
靠前的搜索结果说的是重启进安全/紧急/单人模式，然后手动把权限改回去；或者直接当前状态下切到root用户，but这个方案似乎并没有起作用，su之后输密码重复试了很多次都还是不行，猜测也是/usr的改动导致的
问问拷打😎
抱着死马当作活马医的想法，就跑过去问GPT，特别提一下，是模型gpt-4-0125-preview，(另外，感谢@LHX的维护, 让我能够长期免费使用到GPT)给出的解决方案和搜索结果类似 :
当时电脑上浏览器开了不少窗口，同时又打算重启电脑，故用手机在问:)
正式开始
1. 进入单人模式
重启之后先进到Majaro启动的编辑界面(我这里是按E即进)， 然后定位到Linux开头那一行，加上single init=/bin/bash同时将ro改成rw， 以读写模式挂载
2. 指令修复
这里先把几个系统分区挂上
1 | lsblk # 查看分区 |
然后直接去修改权限
1 | chown root:root /usr/bin/sudo |
先修改文件目录所有者， 再该权限
解释4755:
第一位（4）表示特殊权限中的SetUID位（SUID）。当应用于可执行文件时，SUID允许任何用户在执行该文件时，暂时拥有文件所有者的权限。这对于需要普通用户以root或其他特权用户权限执行某些操作的情况非常有用，例如/usr/bin/passwd命令允许用户更改密码，就是利用了SUID权限。
接下来的三位（7）表示文件所有者的权限，拥有读（r=4）、写（w=2）、执行（x=1）权限，合起来就是7（4+2+1），即rwx。
再接下来的三位（5）表示与文件所有者同组的用户的权限，拥有读（r=4）和执行（x=1）权限，没有写权限，即rx。
最后的三位（5）表示其他用户的权限，同样拥有读和执行权限，没有写权限。总结来说，权限4755赋予了文件所有者全部权限，文件所属组用户和其他用户有读取和执行权限，并且由于设置了SUID位，任何用户执行该文件时都将暂时拥有文件所有者的权限。这种权限设置常见于需要提升权限执行的二进制程序上
3. 重启测试
重启之后sudo确实是好了，但是又出现了新问题😓
首先是zsh打开的时候就报错，大致意思是配置文件无法找到，补全失效
然后又有AppImage报错You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option. See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information
同时网络驱动貌似也死了
4. 修复新问题
所以我就去先修AppImage，这个地方我尝试着把所有分区重新挂载一遍貌似好了
网络问题，就只能USB连线使用手机共享网络
然后修zsh，卸载之后重装，还是不行，我以为是环境变量设置未生效，就打算重启看看
好么，重启结果卡住了，😡卡在启动界面进不去了卧槽，就靠着Ctrl+Alt+F3切换到tty模式，刚进去就看到提示No space left on device，用df -h查看磁盘占用情况，就发现/var分区20G全部占满，再使用sudo du -ahx /var | sort -rh | head -20查看目录下占用内存最大的文件，就看到有个/var/log/cups/error_log文件，大概有10多G,查阅之后知道这个日志是通用Unix打印系统(Common Unix Printing System)产生的，应该没啥用，就直接删除，但是因为命令提示行之前设置的是能够打印中文，所以很多提示都是方形的空白字符，根本看不清，删了几次才成功
不少次尝试后成功进入系统，我想要试试zsh配置重新设置之后能否生效，使用source ~/.zshrc，结果报错
1 | 警告：目录权限不一致 |
突然想到/usr之前被我修改权限了，但是只改回了/usr/bin/sudo，所以就打算手动把其他目录改回来，结果一个不小心，又把/usr/bin目录改了我是SB🤡，导致又要进单人模式，所幸有了之前的经验，这次改的很快，重启之后去查有没有比较方便修复文件系统权限的命令，果然有：
1 | yay -S pacman-fix-permissions |
先装好pacman-fix-permissions，然后去执行命令修复权限
我看命令执行情况，貌似是分析本机应用依赖包，然后全局扫描，测试权限，再改回来，大概跑了半个小时，重启之后系统修复，完好如初！😀
回顾总结
还好自己没有直接想着重装，而是尝试去修复(毕竟也不想再重装配环境了)
下次别在手贱不过脑子直接改权限了！🥲
其实之前用Linux的时候，也出过不少问题，
先是在一台主机上装了Ubuntu，第一次问题是不小心使用sudo rm -f /etc(当时是删别的某个路径，结果新开一个命令行忘切目录)把核心配置全删了，啥指令都不起作用，当时打算从别人那儿把/etv拷过来，结果挂载不上去，U盘调不出来，重装！
再有，是这个重装的Ubuntu系统，因为默认装的Gnome图形界面，非常不稳定，经常应用卡退，换成KDE，就直接红屏了；没办法，先改回去Gnome，然后看有人说输入法可能会造成应用闪退，卸掉，没起作用；修显卡驱动，重启，卡死了，文件系统崩溃，网络驱动也寄了，全挂了，直接重装Kubuntu了(这个系统用的倒是还好，没啥问题)
笔记本上的Manjaro，之前有一次分区不合理，想要合并分区来着，结果出了无法修复的问题，也重装过一次。有一说一，Manjaro是我用的最舒服的，日常没啥问题
哎哎，下次出问题继续修，反正是折腾😆