@77ShiORi 这个是在开启无线桥接的情况下才能生效的，已经打算换小米路由器了，tplink 真是在退步，之前我用了好几年的老款 tplink 百兆路由器还支持单独关闭 dhcp ，新款居然不支持，真不知道他们产品经理是咋想的

@yanqiyu #24

dnf --installroot 应该是只需要 root 用户的，但是实测是不行的，不管是 fuse2fs -o fakeroot 还是普通的目录都报一样的错:

d@develop:~$ bwrap --dev-bind / / --unshare-user --uid 0 --gid 0 dnf --installroot=/home/d/.local/mnt/1/ --releasever=/ --config /etc/dnf/dnf.conf install vi
Last metadata expiration check: 0:05:21 ago on Sun 30 Jun 2024 05:57:21 PM CST.
Dependencies resolved.
===================================================================================================================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================================================================================================================
Installing:
vim-minimal x86_64 2:9.1.158-1.fc40 fedora 806 k
Installing dependencies:
vim-data noarch 2:9.1.158-1.fc40 fedora 23 k

Transaction Summary
===================================================================================================================================================================================================================
Install 2 Packages

Total size: 829 k
Installed size: 1.6 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] vim-data-9.1.158-1.fc40.noarch.rpm: Already downloaded
[SKIPPED] vim-minimal-9.1.158-1.fc40.x86_64.rpm: Already downloaded
Running transaction check
Transaction check succeeded.
Running transaction test
RPM: error: Unable to change root directory: Operation not permitted
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
Errors occurred during test transaction.

d@develop:~$

@guo4224 #21
@yanqiyu #22

刚才又试了一下不用 fuse2fs -o fakeroot 这种方式挂载的目录，就用普通的目录作为 rootfs 会怎样，结果还是不行：

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.6 MB/s | 11 MB 00:06
Fedora 40 - x86_64 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0xA15B79CC:
Userid : "Fedora (40) <[email protected]>"
Fingerprint: 115D F9AE F857 853E E844 5D0A 0727 707E A15B 79CC
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-40-x86_64
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
RPM: error: Unable to change root directory: Permission denied
[Errno 13] Permission denied: '/home/d/.local/mnt/2/var/lib/dnf/rpmdb_lock.pid'
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Failed to store expired repos cache: [Errno 13] Permission denied: '/home/d/.local'
[Errno 13] Permission denied: '/home/d/.local'
d@develop:~$

@guo4224 #21
@yanqiyu #22

实际上 setuid 是无法满足我的这个需求的，原因跟我 #8 楼说的一样，比如我给 python 设置了 s 标志:

chmod u+s /usr/bin/python3.12

然后执行 dnf:

d@develop:~$ dnf --installroot=/home/d/.local/mnt/0/ --releasever=/ --config /etc/dnf/dnf.conf install tar
Config error: [Errno 13] Permission denied: '/home/d/.local/mnt/0/var': '/home/d/.local/mnt/0/var'
d@develop:~$

@0o0O0o0O0o #19 用 podman 比 docker rootless 更好，主要有以下 2 点

1 ，podman 的安装比 docker rootless 更方便，一条 dnf 命令搞定
2 ，docker 貌似没有类似 podman 的 unshare 子命令，用 docker 的话我就必须再依赖一个 fedora 的 container ， 还要做个目录共享，例如：

docker run --name fedora4 -itd -p 2223:22 -v /home/d/.local/mnt/0/:/mnt/0 fedora:latest

然后用如下命令来实现：

docker exec -it fedora4 dnf --installroot=/mnt/0/ --releasever=/ --setopt=reposdir=/etc/yum.repos.d/ --setopt=cachedir=/var/cache/dnf --config /etc/dnf/dnf.conf install tar


如果用 bwrap 也能做到类似 podman unshare 的效果的话我也很乐意尝试一下，但暂时不打算研究了。

@yanqiyu 你的这种方法完美解决了我的问题：

podman unshare dnf --installroot=/home/d/.local/mnt/0/ --releasever=/ --config /etc/dnf/dnf.conf install tar

@sduoduo233 这个不提供 x86_64 架构下的安装包，而且我比较倾向于用 fedora 官方支持的工具来实现。

@0o0O0o0O0o fakeroot 的不是基于命名空间技术实现的，虽然可以用这个命令来骗过 dnf 命令， 让 dnf 命令不报那个需要特权用户的错，但执行到一半还是会报错：

d@develop:~$ fakeroot dnf --installroot=/home/d/.local/mnt/0 --releasever=/ --config /etc/dnf/dnf.conf install tcpdump
Last metadata expiration check: 0:04:10 ago on Sun 30 Jun 2024 02:58:04 PM CST.
Dependencies resolved.
===================================================================================================================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================================================================================================================
Installing:
tcpdump x86_64 14:4.99.4-6.fc40 fedora 501 k

Transaction Summary
===================================================================================================================================================================================================================
Install 1 Package

Total size: 501 k
Installed size: 1.2 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] tcpdump-4.99.4-6.fc40.x86_64.rpm: Already downloaded
Running transaction check
Transaction check succeeded.
Running transaction test
RPM: error: Unable to change root directory: Operation not permitted
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
Errors occurred during test transaction.

d@develop:~$

@dhb233 不行的，因为我是用

fuse2fs -o fakeroot ~/fedora.raw /path/to/fedora_rootfs

这种方式来挂载虚拟机的磁盘镜像的，这种方式就只能用普通用户来读写挂载目录的文件，用 root 用户反而没有读写的权限（所以用 sudo 肯定也不行）。

我觉得用基于命名空间的 root 用户是可以读写的，因为我把/path/to/fedora_rootfs 目录共享给 docker ，在 docker 内能用 root 用户读写这个目录，docker 的 root 用户就是通过命名空间技术映射到 host 的普通用户的。

@xscit 能具体一些吗？我就是想当伸手党才来问的，哈哈

@cccer 不是的，我用的 docker 是完全不需要 root 权限的：

https://docs.docker.com/engine/security/rootless/

docker 服务都是用普通用户来运行的：

d@develop:~$ systemctl --user start docker
d@develop:~$ systemctl --user status docker
● docker.service - Docker Application Container Engine (Rootless)
Loaded: loaded (/home/d/.config/systemd/user/docker.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/user/service.d
└─10-timeout-abort.conf
Active: active (running) since Sat 2024-06-29 18:44:10 CST; 19h ago
Docs: https://docs.docker.com/go/rootless/
Main PID: 5727 (rootlesskit)
Tasks: 170
Memory: 912.4M (peak: 1006.0M)
CPU: 1min 17.179s
CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/docker.service

@Features 有道理，但是人和电脑还是有区别，电脑是可以随便压榨的（只要别超频），但人压榨的太狠还是会反抗的。

@julyclyde 是的，所以我打算以后都用 lvm 了，昨天就遇到个 lvm 的问题，今天发帖问了一下，刚刚有位老哥帮我解决了：

https://v2ex.com/t/1052008

希望你以后能多给其他人提供有价值的回答。

@fugu37 你这个方法管用，多谢

@assiadamo #5 没人问你呀

@Ggmusic 确实巧了，问题完全一样，，

你是什么系统环境，之前有做什么不寻常的操作吗？

我是装了 fedora 40 双系统的，2 个 fedora 40 ，一个本来不是以 lvm 的分区方式安装的，是我手动把这个非 lvm 方式安装 的 fedora 转换成了 lvm 的分区方式，名为 vg 的 vg 就是我手动创建的，然后我又通过 fedora 安装程序安装了一个以 lvm 分区方式自动配置分区的 fedora ，就是 vg 名为 fedora 的这个。

2 个 fedora 都是可以启动的，奇怪的是我手动转换成 lvm 分区方式的那个 fedora 启动后识别不到名为 fedora 的卷组，但用 fedora 安装程序自动配置 lvm 的那个 fedora 启动后，2 个 vg 都能正常识别。

由于这 2 个 fedora 都是 fedora 40 ，所以内核版本是一样的，感觉最大的不同是 initramfs 以及 rootfs 上预先配置的一些 systemd 的服务， 我手动转换成 lvm 的那个 fedora 的 initramfs 是我通过 dracut 生成的，也不知道是不是跟一些 systemd 的配置有关。

@fitme

root@develop:/mnt/0# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
nvme1n1
├─nvme1n1p1 LVM2_member LVM2 001 We699H-iVEw-Hbkc-weAS-rovx-iX3U-xI9I5f
│ ├─vg-f40_root ext4 1.0 36df5d97-0c81-415e-baf0-88bde742f7bb 10.1G 30% /
│ └─vg-home ext4 1.0 e189760f-5df8-4ccc-9bfb-0a6c28628e9b 27.8G 22% /home
├─nvme1n1p2 vfat FAT16 4B64-9175 24.5M 51% /boot/efi
├─nvme1n1p3 ext4 1.0 4b7258eb-9478-4f7e-bf52-d83fdcf31147 653.2M 24% /boot
├─nvme1n1p4 ext4 1.0 86dbca85-a16b-46c4-9099-9c3fcac2e8c2
└─nvme1n1p5 LVM2_member LVM2 001 PCUuVc-rqiA-f7Wd-Qg0f-sfeJ-DC1R-SlspPV
└─fedora-root ext4 1.0 6ac9d777-70da-4ea2-8873-a00644e50934 11.4G 33% /mnt/0
root@develop:/mnt/0#
root@develop:/mnt/0# df .
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/fedora-root ext4 19G 6.2G 12G 35% /mnt/0
root@develop:/mnt/0#
root@develop:/mnt/0# date > test
root@develop:/mnt/0#
root@develop:/mnt/0# cat test
Mon Jun 24 12:21:53 PM CST 2024
root@develop:/mnt/0#

可以写入数据

@fitme

root@develop:~# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Jun 24 2024 36df5d97-0c81-415e-baf0-88bde742f7bb -> ../../dm-1
lrwxrwxrwx 1 root root 15 Jun 24 10:16 4B64-9175 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 15 Jun 24 10:16 4b7258eb-9478-4f7e-bf52-d83fdcf31147 -> ../../nvme1n1p3
lrwxrwxrwx 1 root root 10 Jun 24 2024 6ac9d777-70da-4ea2-8873-a00644e50934 -> ../../dm-0
lrwxrwxrwx 1 root root 15 Jun 24 10:16 86dbca85-a16b-46c4-9099-9c3fcac2e8c2 -> ../../nvme1n1p4
lrwxrwxrwx 1 root root 10 Jun 24 2024 e189760f-5df8-4ccc-9bfb-0a6c28628e9b -> ../../dm-2
root@develop:~#


lvm 的 pv 本来就不能用 /dev/disk/by-uuid/ 这种方式看到 uuid 吧？

正常的卷组所在的 pv 用 /dev/disk/by-uuid/ 这种方式也看不到

@fitme fedora 卷组只有一个物理卷，是在 /dev/nvme1n1p5 这个分区上，如下：

root@develop:/home/d#
root@develop:/home/d# gdisk -l /dev/nvme1n1
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme1n1: 976773168 sectors, 465.8 GiB
Model: WD_BLACK SN770 500GB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): C429264E-34FC-4E49-8B10-9120D21303DC
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2029 sectors (1014.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 2048 932732927 444.8 GiB 8E00
2 974675968 974778367 50.0 MiB EF00 EFI System Partition
3 974778368 976773119 974.0 MiB 8300
4 932732928 934830079 1024.0 MiB EA00
5 934830080 974675967 19.0 GiB 8E00
root@develop:/home/d#
root@develop:/home/d# mount /dev/nvme1n1p5 /mnt/0/
mount: /mnt/0: unknown filesystem type 'LVM2_member'.
dmesg(1) may have more information after failed mount system call.
root@develop:/home/d#