解决办法
可能的解决办法之一是删除 ~/.emacs 文件,当然删除前先看看内容是否需要备份。
琅環笔记
有博学强记者,尝为鹅厂从事。游于洞宫,遇一人于途,问逍遥曰:“君读书几何?”遥曰:“吾之未读者,则二十年内书盖有之也,若二十年外,则吾固已尽读之矣。”其人论议超然,遥颇内服,相与欢甚。因共至一处,大石中忽然有门,引遥入数歩,则别是天地,宫室嵯峨。引入一室中,陈书满架,其人曰:“此PL史也。”又至一室,则曰:“OS志也。”毎室各有奇书,惟一室屋宇颇高,封识甚严,有二犬守之。遥问故,答曰:“此皆操作系统、编程语言、算法分析、生发正骨诸秘籍。”指二犬曰:“此龙也。”历观诸室书,皆Windows以前事,多所未闻者,如「BeOS」、「Solaris」、「FreeBSD」、「LISP」亦皆在焉。遥心乐之,欲赁住数十日,其人笑曰:“君痴矣。此岂可赁地耶?”即命小童送出,遥问地名,对曰:“琅嬛福地也。”
可能的解决办法之一是删除 ~/.emacs 文件,当然删除前先看看内容是否需要备份。
## 在类Unix系统上
类Unix:指 Linux macOS FreeBSD 等
环境配置文件:用来放置命令行的文件
比如在 bash,可以放在 ~/.profile,在 zsh,则是 .zshrc。
例如,以下命令用来添加GO环境变量
::bash
export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin
如果需要立刻生效,还需要执行 source 命令。
## 在 Windows 系统
可以在命令行运行::cmd
setx GOPATH $USERPROFILE%go setx path "%path%;%USERPROFILE%bin"
运行上述命令,然后关闭当前命令提示符窗口,重新打开一个新的,更改才会生效。
多用户登录模式,可读写全部文件。
单用户登录模式,只可操作根目录下的文件,只能读操作。常用来检查和修复文件系统。
当开机后,系统提示 "Cound not chdir to home directory /home/your_username No such file or directory"
此时,尝试执行 ls /home
会发现一无所获,表现为你的用户目录丢失了,非常惊悚。
黑客获得了你的系统权限,强制删除了你的用户目录。这一般是瞎扯的。
用户创建目录和 zfs 挂载的先后顺序问题。
详细来说,zfs 是一种高级文件系统,比如可以按需增加容量。
通常我们会将用户目录放到 zfs 的池中管理,挂载点的对应关系在 zfs 的 dataset 中保存。
此时,如果用户在 zfs 挂载 /usr/home 以前 (/home 是 /usr/home 的硬连接),在目录 /home 下创建了目录,再挂载 zfs 的目录时,会覆盖 /home 目录。
这里怎么理解?就好比目录和文件是对象,挂载点可以是层叠结构,后挂载的目录会指向同样的挂载点,而系统在挂载后,只会显示最后的挂载。
此时,先前的目录和文件并没有丢失,只是被遮蔽了。
进入单用户登录模式登录,尝试执行 ls /home
,一般会看到「丢失的」目录。
确认这一点后,可以重新进入多用户模式,先用 unmount 命令强制停止挂载 /home 目录
我在 https://forums.freebsd.org/threads/lost-home-directory.89382/ 看到,问题可能与 ZFS 有关,在没有思路时,我请教了 OpenAI 的 ChatGPT 3.5,效果好的可怕。
我的提示语如下:『你是协助我工作的精通FreeBSD系统的专家,此时我遇到一个问题向你请教。我的用户名是 xyz,当我从 multiple user mode 登录系统时,/home 和 /usr/home 下找不到 xyz 目录,但当我从 Single user mode 登录系统时,/home 和 /usr/home 下存在 xyz 目录,既存在 /home/xyz 和 /usr/home/xyz,请问现在如何做才可实现,当重启进入 multiple user mode 时依然看到 xyz 目录。我不清楚导致这个现象的原因是什么,可能是因为VPC异常关机,而我的 FreeBSD 是安装在 vpc 上的。』
结果 ChatGPT 给与了初步判断,并给了我处理步骤和命令提示,我继续执行它给的命令,并将结果告诉它,它便接着提示,大约通过十多轮对话,它帮我找到了 zfs 和 mount 的原因,也让我理解了为什么会出现这样的问题。
ChatGPT 真的可以,这里它做到了。
帮助我弥补专业知识不足;
教这些专业知识,让我理解;
就问题给出解答步骤,并可以交互式推进;
所以,我说它真的不错,至少在缺少领域知识的场景下,提高了问题解决的可能性,并缩短了问题解决的时间。
但,这里应看到的时,我们有一个共识:基于 FreeBSD 的存在和表现,它并不会出现无端丢失目录和文件的问题,如果你怀疑,就是在怀疑世界上聪明人的数量,及它们为热爱事物所付出的努力。
如果遇到 FreeBSD 的类似问题,你有此怀疑,这说明,你的思维方式不在正途,你不对劲。
在 /etc/hosts 文件中加入主机名,比如:
127.0.0.1 ubuntu.tt.com
浏览器地址打开 链接
如果是旧图,可以按 Ctrl+
须具有本地权限,通俗的说就是,需要肉身在服务器旁边。
启动服务器时按住 Shift 键,会进入 GNU GRUB version x.yz... 界面
在 GNU GRUB version x.yz... 界面下方至少会出现以下选项:
Ubuntu
*Advanced options for Ubuntu
选择 Advanced options for Ubuntu,按回车键;
出现新的选项:
Ubuntu, with Linux ...
*Ubuntu, with Linux ... (recovery mode)
选择带有 (recovery mode) 的一行,按回车键;
系统会显示一些输出并跳转到 Recovery Menu 菜单界面,选项如下:
resume
clean
dpkg
failsafeX
fsck
grub
network
root
system-summary
选择 root,按回车键
重新 mount 具有写权限的 root,运行命令::
mount -rw -o remount /
使用 ls /home
命令可以查看用户名,假设是 USER1,则使用如下命令重置密码:
passwd USER1
根据命令提示,你可以完成密码修改,然后退出到 Recovery Menu,选择 resume 重启,然后就可以使用上一步修改的新密码进入系统了。
Tips 之所以让人眼前一亮,那是因为这个 Tips 的结构不寻常。
大体上,是因为设计者没有想到,或者想到了,但没有设计好导致的。
比如下面这个:
SQLite 提示 "database disk image is malformed"
看起来很惊悚,说是数据库磁盘镜像畸形了。
第一感觉似乎是磁盘硬件坏道了?
当我在 PyCharm 中选中了项目的根目录后,在菜单 File -> File Properties -> Line Separators 的切换后,SQLite 数据库文件报错了;
我进行这个操作的主要原因是,每当我添加文件到 git 时,以 LF 为分隔符的 sitemap.xml 文件总是有一个 warning;
而这个报错的主要原因,被证明是一个 Python 2 的遗留问题导致的。
没有充分证实,但非常有可能是 LF 到 CRLF 的替换损坏了 SQLite 的数据库文件。
你想问问 PyCharm,你怎么这么蠢?
PyCharm 可能会说,怪我干什么,我只是个工具!
但我认为吧,PyCharm 确实有理由识别这是一个数据库文件吧,毕竟你是可以直接打开浏览和处理的。
好在此处,是之用到 SQLite 作为数据生成的本地缓存,且在 GitHub 上有备份,于是拿了一份下来本地覆盖既修复了。