好耶，是红帽系的openEuler

dnf groupinstall -y "Development Tools"

# 下载源代码
git clone https://github.com/ceph/ceph
cd ceph
git checkout quincy-release
git submodule update --init --recursive

# 编译前准备
# openEuler 22.03的源里没有这两个python包，需要改为手动下载
sed -i -E 's/(.*asyncssh$)/#\1/gm' ceph.spec.in
sed -i -E 's/(.*natsort$)/#\1/gm' ceph.spec.in

# 官方还没有加openEuler的选项，但大概率是兼容的
sed -i -e 's/centos|fedora/centos|openEuler|fedora/g' install-deps.sh

./install-deps.sh

# 装完依赖之后再装dnf里没有的两个包
pip3 install asyncssh natsort

dnf install -y xmlsec1 doxygen ninja-build python3-sphinx
dnf install -y libibverbs-devel openldap-devel lz4-devel expat-devel lttng-ust-devel libbabeltrace-devel libatomic librabbitmq-devel librdkafka-devel java-1.8.0-openjdk-devel

# cmake配置
./do_cmake.sh -DCMAKE_BUILD_TYPE=RelWithDebInfo

# 开始编译
ninja

打RPM包的过程有点曲折，openEuler的维护者不知道在干些什么，去维护ceph.spec而不是ceph.spec.in，搞得我不知道版本更新的时候到底该对着谁的spec改了。。

这里就不理openEuler自己公布的spec文件了，用点取巧的方法，伪装成CentOS试试。

# 制作RPM源码包
./make_srpm.sh

# 展开RPM源码包用于安装
# 注意默认是解压到家目录下的，所以在ceph目录下执行完可能发现没任何变化，回家目录检查下肯定有rpmbuild文件夹了
rpm -i ceph-17.2.5-0.g98318ae89f1.src.rpm

# 安装编译依赖
dnf builddep -y --define 'rhel 7' --spec ~/rpmbuild/SPECS/ceph.spec

# 华子的像素级抄袭功底还是在的，包管理器名字都给你改喽
# 说实话还整个大小写混用让人挺不舒服的。。
sed -i -e 's/^BuildRequires:  redhat-rpm-config$/BuildRequires:  (redhat-rpm-config or openEuler-rpm-config)/gm' ~/rpmbuild/SPECS/ceph.spec
sed -i -E 'N;s/(^%if 0%\{\?rhel} == 8$)(\n%py_byte_compile.*)/\1 || 0%{?openEuler}\2/gm' ~/rpmbuild/SPECS/ceph.spec

# RPM编译
# openEuler上的cmake可执行文件是python脚本，然而很怪，一用rpmbuild，python就会掉PYTHONPATH，找不到cmake
# 伪装成rhel7，走centos的编译流程，但是又绕过软件包版本限制
PYTHONPATH=/usr/local/lib64/python3.9/site-packages rpmbuild -ba ~/rpmbuild/SPECS/ceph.spec --define 'rhel 7'

将编译的ceph RPM包作为repo提供给其他机器使用，参考：https://blog.csdn.net/DeamonXiao/article/details/120879577

dnf install -y createrepo
cd ~/rpmbuild/RPMS
createrepo .

然后另外单独起个后台进程，直接用http提供服务；这里用7000端口，根据需要可以自己调。

python3 -m http.server 7000

至此，一个repo就建立好了。

然后配置服务器使用这个源：

cat << EOF > /etc/yum.repos.d/Ceph-dev.repo
[ceph-dev]
name=Ceph Dev
baseurl=http://<ip-address>:7000/
enabled=1
gpgcheck=0
EOF

# 更新缓存，测试源是否添加成功
dnf makecache

苦逼兼职运维的第六年，已经无力吐槽Ubuntu了= =

症状：在nmtui里激活网卡，提示Could not activate connection: XXX because device is strictly unmanaged.

懒人解决方案：

sudo su -c 'echo ",except:type:ethernet" >> /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf'
sudo service network-manager restart

原因大致是Ubuntu的NetworkManager默认将以太网卡设置为了不管理模式，因而无法通过nmtui对以太网卡进行开关操作，即使配置了网络设置也不管用。而上面这段except则是反向操作，告诉NetworkManager不要不管理以太网卡。

咕果上翻了半天没找到合适的解决方案，感谢这位知乎网友：https://zhuanlan.zhihu.com/p/514966896

为了玩玩最近很火的AI作画Stable Diffusion，不得不想办法把我在古台上囤了N多的陈年老数据转移到机械大house上。按照常规操作，较为合理的方法是做出共享文件夹，然后用robocopy来更新具体数据。

然而直接卡在了第一步= =

右键文件夹一看，那个熟悉的“共享”选项卡不见了，接在“常规”后面的就是“安全”。。。

马上某度，发现也有许多人遇到这个问题，大致情况可以归类为两种：

一是注册表损坏，用于展示共享文件夹的COM组件配置丢失，这个需要通过手动设置HKEY_CLASSES_ROOT\Directory\shellex\PropertySheetHandlers\Sharing表项的值为{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}来修复；

二是系统组件运行异常，主要关注Security Accounts Manager和Server两个服务的运行状态，确保它们处于正常运行状态才能正常显示选项卡。

然而经过确认，我电脑上这两个地方都没问题，重启多次仍然不见问题解决。而后在绝望之中碰巧看到了另一篇博客，发现竟然是三哥干的好事。。。

实际上，在注册表里，除了有启用COM组件的配置之外，还有禁用的配置，比如HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked注册表项。打开一看，上面Sharing的COM CLSID{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}赫然躺在里面。

WTF？？我用的好好的，结果你把他给我禁用了？当场删除了对应的注册表子项，甚至不用重启，许久不见的共享选项卡就回到了属性界面。

忽然想起某乎上的吐槽，阿三工程师的特点之一就是做事自在，指不定哪天心情好就把哪个feature给你改了，但是只要你不问他，他就绝不会跟你提到这个事。

这咖喱味的系统我是一秒也不想多用了.jpg

参考：

1. https://techcult.com/fix-sharing-tab-is-missing-in-folder-properties/
2. https://weblog.west-wind.com/posts/2020/Apr/13/Missing-Sharing-Tab-in-Windows-Explorer

需求是在gem5里跑SPEC程序。作为一个指令级模拟器，允许在不单独运行操作系统的情况下运行指定架构的程序本身就已经是一个巨大的工程了，而它所付出的代价则是运行效率低下和不支持动态链接（作者似乎说了在x86模式下支持加载动态库，但我没测试）。

于是对应的解决方案是，静态链接。

然而，在如今这个内外存充足、处理器足够快的时代，静态链接的用途可以说是已经被大幅削减了，如果要依赖外部程序的话，没有什么是附加一个动态库解决不了的。一定要说离不开静态链接的，可能也就只有在仍处于系统底层的内核了。对于只能识别汇编指令的处理器来说，它不知道该去哪里找对应的依赖实现，因而程序必须一字一句指导处理器执行。

好在仍然有部分C语言程序离不开静态编译，因而现有的操作系统还是提供了gcc的静态包。而fortran就不一样了，天生作为计算工具的语言往往在操作系统中执行，没必要搞静态链接，但凡一个库函数被调用了两次都是一种空间的浪费——或许是基于这种思想，几乎所有的Linux发行版都从安装源里删去了gfortran的静态依赖库，仿佛多的这几百KB的空间对服务器也是种累赘。

然而还是有人关注这个问题：在CentOS论坛中，有人解决方案。作为开源操作系统，保留源码可以说是一个非常好的文明了，而红帽系的系统甚至还提供了rpmbuild工具用来实现快捷的，从源码包到二进制包的编译功能，大致分为两步：

首先找到源码rpm包（这里推荐pkgs.org和rpmfind.net，格式工整，资料齐全）并解压：

rpm -i gcc-8.3.1-5.1.el8.src.rpm

然后用rpmbuild按照配置文件编译即可：

rpmbuild -bb ./rpmbuild/SPECS/gcc.spec

然后编译过程中可能会提示缺包缺文件，通过yum/dnf安装即可，缺失的文件也都是可以通过包管理器补上的。

以经典的/lib/libc.so.6和/usr/lib/libc.so为例，这两个文件是x86架构下的glibc库文件，在amd64系统上是默认不装的，但是因为rpmbuild需要，可以通过分别glibc.i686和glibc-devel.i686补上。

补完缺失的依赖之后就可以快乐泡茶等编译啦~

鸽了五年来填坑了

随着人年龄越来越大，逐渐对U盘的数量不再那么感兴趣，反而觉得一串串的U盘变成了随身携带的累赘，生怕一不小心就弄丢了。

几年前就试图给自己整个活，弄一个支持Windows+Linux+MacOS的三合一安装启动盘，无奈学识尚浅，花了几周都没搞定。

最近正好手头有装服务器的需求，心中的整活之魂又燃起来了，花了一下午时间总算把坑填好。

一 明确需求

由于通常情况下不论哪个系统都要求使用一个完整的U盘（尤其是MBR时期，刻盘是最方便的MBR更新方式），所以常规情况下换个系统就要重刻一张盘。

因而本项目的基本需求就是一个U盘能够在不修改引导的情况下完成三类系统的安装，且最好同时支持兼容（后文简称为MBR）+UEFI模式。

二 设计方案

三种不同的系统安装方法有所不同，虽然W/L/M三家都支持原装启动盘启动，但是Windows的官方启动盘功能实在是少得可怜，远比不上*nix两家的shell好用，所以大部分情况下会使用PE+WinNTSetup的方法，附加工具多，可定制化程度高。因而在整体方案上，使用PE工具建立Windows安装环境，Linux、MacOS则原盘启动安装。

好在MBR/UEFI的启动方式不同，一个是读扇区，一个是读文件系统，因而两者具有共存的余地——实际上现在的绝大部分启动盘都是同时支持两种模式的。

由于MacOS很早就抛弃了MBR启动，所以MBR启动不做MacOS支持（其实也不难，加个Chameleon iso引导就行）；其他方式能支持则尽可能支持：

三 大致步骤

由于MBR模式和UEFI模式在引导方式上有区别，因而要采用不同的方式对待。由于需要支持MBR模式，因而整体上U盘还是需要保持MBR格式的。

对于UEFI启动比较简单，首先到网上找一份efi shell，放到efi分区（也就是U盘物理地址上第一个分区）。然后启动进入efi shell之后，直接用命令行执行要uefi启动的系统引导即可。

由于只有MacOS本身可以正常操作其文件系统，通常要为MacOS的安装盘单独准备一个分区，然后在MacOS里用磁盘工具恢复分区。（对，手头需要先有一个能用的MacOS，不论是白的还是黑的）

MBR模式的稍微麻烦一点，我这里是基于大白菜魔改的。大白菜的多级菜单引导模式是基于grldr做的，也就是大名鼎鼎的grub4dos，因而需要通过修改菜单，让grub4dos来引导Linux系统的启动流程。

需要准备一个工具fbinsttool，用来读写大白菜的隐藏文件系统。大白菜专门预留了一个文件用来给我们制作自定义的启动菜单，在(ud)/IDBC/GRUB/DIY.LIST位置，在里面照抄现有启动项即可实现自定义启动项的添加。

以我配置的Rocky Linux 9为例：

title 【01】 Install Rocky Linux 9 Minimal 
# find只支持定位文件，不支持文件夹！
find --set-root --ignore-cd --ignore-floppies /RPM_GPG_KEY_ROCKY_9
kernel /ISOLINUX/VMLINUZ inst.stage2=hd:LABEL=Rocky_9_0-x86_64-dvd quiet
initrd /ISOLINUX/INITRD.IMG
boot

需要注意的是，这里最好用dd直接把光盘镜像的分区写入到U盘，不然后面的Anaconda安装可能找不到本地安装源。然后偷懒使用光盘内特有的文件来定位该分区（因为grub4dos不支持用分区名定位）。然后照常加载kernel和initrd即可完成启动。需要注意的是inst.stage2参数，该参数用于指导安装器Anaconda的加载，要是填错了或者没填会导致启动失败。（在光盘里这俩文件在不同位置出现了几次，估计是为了支持不同的启动方式吧）