Scribbles for my bad memory

我前两天在Facebook Market上又捡了一台电子垃圾：$50买了一台 Dell Chromebook 11 3120，配置是 2GB 内存，16GB硬盘。卖家之前已刷了Sea BIOS，安装了CloudReady系统，但没有搞定声卡驱动，所以没有声音，也因此他才愿意便宜出售。

我喜欢ChromeOS的流畅，但讨厌不能自由安装软件。那有没有可能在Chromebook上安装Linux并让它跑得几乎与ChromeOS一样快呢？我没有把握，也知道可能性并不大，但我还是想试试。

我在这台Chromebook 上安装了Debian 11系统，目前没有遇到大的问题，声音，蓝牙，wifi，hdmi都能正常工作，除了觉得有点慢，以及从suspend状态复原时系统变得极度缓慢，几乎没有响应。

我在这台Chromebook上目前已经做了以下尝试：

1. 禁用Wayland
2. 删除SWAP分区
3. 升级到最新内核

今天打算再设置下 ZRAM内存压缩。没想到极其简单，有ZRAM Tools加持，一分钟就设置好了。照抄的例子，给ZRAM分配了60%的物理内存。Reference 那就看后续使用效果了，我会过两天再更新这个文章。

「25-05-2023更新」 我卸掉了gnome3，装上了xfce4。这是我在移情gnome之前最喜欢的桌面环境。2G内存毕竟太少了，而gnome太贪心，它吃掉了太多的内存。为了更好的性能，我转向了xfce4，而它也确实没有让我失望。这台小机器现在能做很多事，并且跑得很流畅。我很开心啦！

English Version (Thanks ChatGPT)

I picked up another piece of electronic junk on Facebook Marketplace a couple of days ago: a Dell Chromebook 11 3120 for $50. It came with 2GB of RAM and a 16GB hard drive. The seller had previously flashed Sea BIOS and installed CloudReady, but couldn't get the sound card driver working, so there was no audio. That's why he was willing to sell it cheap.

I like the smoothness of ChromeOS but dislike the limitations when it comes to installing software. So, I wondered if it would be possible to install Linux on the Chromebook and have it run almost as fast as ChromeOS. I wasn't sure and knew it was unlikely, but I wanted to give it a try anyway.

I installed Debian 11 on this Chromebook, and so far, I haven't encountered any major issues. The sound, Bluetooth, Wi-Fi, and HDMI all work fine. The only drawbacks are that it feels a bit slow, and the system becomes extremely sluggish when resuming from suspend, almost unresponsive.

Here are the things I've tried on this Chromebook so far:

• Disable Wayland in /etc/gdm3/daemon.conf
• Removing the SWAP partition
• Upgrading to the latest kernel

Today, I'm planning to set up ZRAM memory compression. Surprisingly, it was incredibly simple with the help of ZRAM Tools. I allocated 60% of the physical memory to ZRAM, following an example I found at Debian Wiki. We'll see how it performs in practice, and I'll update this article in a couple of days.

Update on 25-05-2023: I have uninstalled GNOME 3 and installed XFCE4. This is my favorite desktop environment before switching to GNOME. With only 2GB of memory, it was just too little, and GNOME was too resource-intensive, consuming a significant amount of memory. In order to improve performance, I turned to XFCE4, and it has not let me down. This little machine can now handle many tasks and runs smoothly. I am very happy!"

tl;dr

The root cause is that the default route was not set to the router's IP address.

My journey to resolve the issue:

The issue is that port mapping can work with my raspberry pi while it couldn't work with a virtual machine in the same LAN. I firstly think it must be a bug from the router. I upgrade the router to its latest firmware, but it still doesn't work. I google back and forth, I learned much from all kinds of answers, but they were just not my case. I almost decided to give up.

Then I found the following answer from E. van Putten, he answered this question and nobody gave his answer a "Like"!!!

In case you landed on this page because you can't reach a server running inside a Xen Guest from the internet (but can connect locally), then read on...

1. The fritzbox can get confused by different OS'es appearing from the same MAC-address etc. (could happen while you are setting up / experimenting with Xen)
2. The fritzbox has seemingly duplicate entries in the list, but with different settings, you need to delete the portmap from the incorrect entry, cleanup the list and reapply the portmap settings.
3. It might be that your guest OS has no default gateway IP-address set. You'd expect a default gateway set to the local IP-address of your fritzbox.

The symptoms of a missing default gateway is that your LAN PCs can access the server running inside the guest just fine, but external users from the internet cannot connect.

He gave three possible causes, and my case is the third one! here's my solution

opts = {
    :name => "yt-gateway",
    :ip => "192.168.178.173",
    :mem => "1024",
    :cpu => "1"
}
Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-20.04"
  config.vm.hostname = opts[:name]
  config.vm.network :public_network, ip: opts[:ip], bridge: "eno1"
  config.vm.provision "shell", run: "always", inline: "route add default gw 192.168.178.1 || true"
  config.vm.provider "virtualbox" do |v|
    v.name = opts[:name]
    v.customize ["modifyvm", :id, "--memory", opts[:mem]]
    v.customize ["modifyvm", :id, "--cpus", opts[:cpu]]
    v.customize ["modifyvm", :id, "--name", opts[:name]]
  end
end

I love you E. van!

Sometimes we need to run shopt -s dotglob nullglob before moving files including dotfiles. So there's another question, do we need to set it back afterward? The most correct answer is

It's usually not clear if either dotglob or nullglob were already set before running shopt -s to set them. Thus, blindly un-setting them may not be the proper reset to do. Setting them in a subshell would leave the current shell's settings unchanged:

( shopt -s dotglob nullglob; mv /public/* /public_html/ )

Reference: Jeff Schaller's answer under this question

Cause:

This morning, I change to the /backup directory and found I cannot write in it. So I rapidly typed sudo chown -R david:david .. then press Enter. You know what happened! All the files in / directory were changing the owner to me! I realized this by seeing an error message like "You cannot change the owner of xxx file to david".

Damn, how silly I was! Unfortunately, that was not the end of my bad luck. When I try to revert it by typing sudo chown -R root:root /, I got another error message: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. Then I tried su - root but it seems that I haven't set a root password.

How can I recover my pop! OS?

1. reboot it into single-user mode, edit the boot menu, add systemd.unit=rescue.target at the end of the boot line.
2. In the boot console, chown -R root:root /usr; chmod 4755 /usr/bin/{sudo,dpkg,pkexec,crontab}; reboot

Rather easy, right? It did cost me over 10mins! PS. I met many issues later after recovering from the accident. One of them is that the crontab command did not work as usual. I have to run the instruction below to fix it.

sudo apt reinstall cron

Linux is also fragile, please don't be such silly thing next time. I told myself. PS: This time I also set a root password as well, so next time I could run su - root directly instead of going to the single user mode.