rear
RFC: Do we still need COPY_AS_IS+=( /dev ... ) ?
-
ReaR version ("/usr/sbin/rear -V"): current master code
-
Description of the issue (ideally so that others can reproduce it):
See https://github.com/rear/rear/pull/3027#issuecomment-1641955414
We copy by default all in /dev/ into the recovery system because in current master code there is
COPY_AS_IS+=( /dev ...
in usr/share/rear/conf/GNU/Linux.conf https://github.com/rear/rear/blob/master/usr/share/rear/conf/GNU/Linux.conf#L231 without a comment why we copy all in /dev/ so I guess it was obvious why that is needed at the time when it was implemented.
It is there since the beginning (at least since Mar 15 2009) according to
# git log --follow -p usr/share/rear/conf/GNU/Linux.conf
so I guess copying all in /dev/ into the recovery system is from older times where things in /dev/ had been static.
Meanwhile /dev/ is a mountpoint in the running recovery system:
RESCUE localhost:~ # mountpoint /dev
/dev is a mountpoint
RESCUE localhost:~ # findmnt
TARGET SOURCE FSTYPE OPTIONS
/ none rootfs rw
|-/proc proc proc rw,nosuid,nodev,noexec,relatime
| `-/proc none proc rw,relatime
|-/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
| |-/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
| |-/sys/fs/cgroup tmpfs tmpfs ro,nosuid,nodev,noexec,size=4096k,nr_inodes=1024,mode=755,inode64
| | |-/sys/fs/cgroup/unified cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate
| | |-/sys/fs/cgroup/systemd cgroup cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd
| | |-/sys/fs/cgroup/pids cgroup cgroup rw,nosuid,nodev,noexec,relatime,pids
| | |-/sys/fs/cgroup/cpu,cpuacct cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
| | |-/sys/fs/cgroup/hugetlb cgroup cgroup rw,nosuid,nodev,noexec,relatime,hugetlb
| | |-/sys/fs/cgroup/rdma cgroup cgroup rw,nosuid,nodev,noexec,relatime,rdma
| | |-/sys/fs/cgroup/blkio cgroup cgroup rw,nosuid,nodev,noexec,relatime,blkio
| | |-/sys/fs/cgroup/cpuset cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpuset
| | |-/sys/fs/cgroup/devices cgroup cgroup rw,nosuid,nodev,noexec,relatime,devices
| | |-/sys/fs/cgroup/freezer cgroup cgroup rw,nosuid,nodev,noexec,relatime,freezer
| | |-/sys/fs/cgroup/memory cgroup cgroup rw,nosuid,nodev,noexec,relatime,memory
| | |-/sys/fs/cgroup/net_cls,net_prio cgroup cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio
| | |-/sys/fs/cgroup/misc cgroup cgroup rw,nosuid,nodev,noexec,relatime,misc
| | `-/sys/fs/cgroup/perf_event cgroup cgroup rw,nosuid,nodev,noexec,relatime,perf_event
| |-/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
| |-/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
| `-/sys/fs/bpf none bpf rw,nosuid,nodev,noexec,relatime,mode=700
|-/dev devtmpfs devtmpfs rw,nosuid,size=4096k,nr_inodes=1048576,mode=755,inode64
| |-/dev/shm tmpfs tmpfs rw,nosuid,nodev,inode64
| `-/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
| `-/dev/pts none devpts rw,relatime,gid=5,mode=620,ptmxmode=000
|-/run tmpfs tmpfs rw,nosuid,nodev,size=402384k,nr_inodes=819200,mode=755,inode64
`-/etc/machine-id tmpfs[/machine-id] tmpfs ro,size=402384k,nr_inodes=819200,mode=755,inode64
So what there was copied from the original system in /dev/ into the recovery system is hidden behind what is now mounted at /dev/ in the running recovery system.
For comparison:
On the original system:
# find /dev | wc -l
464
# find /var/tmp/rear.NCVRvE31DCUFZIa/rootfs/dev | wc -l
445
# find /dev/mqueue -ls
10194 0 drwxrwxrwt 2 root root 40 Jul 19 16:50 /dev/mqueue
# find /var/tmp/rear.NCVRvE31DCUFZIa/rootfs/dev/mqueue -ls
271020 4 drwxrwxrwt 2 root root 4096 Jul 19 16:50 /var/tmp/rear.NCVRvE31DCUFZIa/rootfs/dev/mqueue
# find /dev/watchdog -ls
385 0 crw------- 1 root root 10, 130 Jul 19 16:50 /dev/watchdog
# find /var/tmp/rear.NCVRvE31DCUFZIa/rootfs/dev/watchdog -ls
find: ‘/var/tmp/rear.NCVRvE31DCUFZIa/rootfs/dev/watchdog’: No such file or directory
In the running recovery system:
RESCUE localhost:~ # find /dev | wc -l
398
RESCUE localhost:~ # find /dev/mqueue -ls
find: '/dev/mqueue': No such file or directory
RESCUE localhost:~ # find /dev/watchdog -ls
289 0 crw------- 1 root root 10, 130 Jul 19 16:40 /dev/watchdog
Regarding '/dev/mqueue' see https://github.com/rear/rear/pull/3027
@pcahyna see my above https://github.com/rear/rear/issues/3028#issuecomment-1642266763 I have /dev/watchdog in the running recovery system regardless that it was not copied into the recovery system.
Nevertheless https://github.com/rear/rear/pull/2808 is right to not have /dev/watchdog in ReaR's build area.
With this issue here a generic solution could be to not have anything from /dev in ReaR's build area.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
FYI: in RHEL 6 /dev is already a mountpoint (devtmpfs). Even in RHEL 5 (which we do not care about anymore), it is a mountpoint (tmpfs). @jsmeix I suggest that you check the distributions that you care about.
In skel/default/etc/scripts/boot we have this:
udev_version=$(udevd --version)
if [[ "$udev_version" -gt 175 ]]; then
### udev > 175 needs devtmpfs
mountpoint /dev || mount -t devtmpfs none /dev
fi
so, for older udev versions than 176 we won't mount /dev in the recovery ssytem, despite being a mountpoint in the original system. I suppose it is not a problem though, if older udev can populate an empty /dev in the rescue ramdisk without it being a mountpoint.
The bigger issue is, is udev even started on systems that don't use systemd yet? (RHEL 6 is not.) I don't see udev being executed anywhere in the recovery system startup scripts.
On RHEL 7 there is no udevd anymore:
# udevd --version
bash: udevd: command not found
so, how does /dev get mounted in the recovery system, if at all, is a mystery for me.