On 1/24/26 07:33, Greg Wooledge wrote:
On Sat, Jan 24, 2026 at 16:09:12 +0500, Alexander V. Makartsev wrote:
"cp -r /dev/ /tmp/RFS/dev/" is wrong! Don't do that.
Think about it, "cp" command will copy block devices such as /dev/sda like
files into /tmp/RFS, basically into itself until it runs out of free space.
I remember, a number of years ago, getting caught by exactly this, I believe on
an earlier version of Debian.
Considering that things might have changed since then, I tried it, with the
following results:
root@dyson:~# mkdir /mnt/test
root@dyson:~# cp /dev/sda1 /mnt/test
root@dyson:~# du /mnt/test
173870 /mnt/test
root@dyson:~# ll /mnt/test
total 173861
-rw-r----- 1 root root 535822336 Jan 24 18:22 sda1
root@dyson:~# ll /mnt/test/sda1
-rw-r----- 1 root root 535822336 Jan 24 18:22 /mnt/test/sda1
#(/dev/sda contains /boot from a presently inactive Debian installation)#
root@dyson:~# ll /dev/sda*
brw-rw---- 1 root disk 8, 0 Jan 23 18:00 /dev/sda
brw-rw---- 1 root disk 8, 1 Jan 23 18:00 /dev/sda1
brw-rw---- 1 root disk 8, 2 Jan 23 18:00 /dev/sda2
brw-rw---- 1 root disk 8, 3 Jan 23 18:00 /dev/sda3
brw-rw---- 1 root disk 8, 4 Jan 23 18:00 /dev/sda4
root@dyson:~# fdisk -l /dev/sda
Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SAMSUNG MZ7PD256
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F6190B20-EBBF-420E-BF13-1F526D8C3F0B
Device Start End Sectors Size Type
/dev/sda1 2048 1048575 1046528 511M Linux filesystem
/dev/sda2 1048576 458737663 457689088 218.2G Linux filesystem
/dev/sda3 458737664 495908863 37171200 17.7G Microsoft basic data
/dev/sda4 495908864 500101119 4192256 2G Microsoft basic data
Having done that, I conclude that cp -r /dev/ probably would have done the same
thing, and a lot more, just as my error of long ago.
Interestingly, the resulting file, /mnt/test/sday can be mounted and looks
entirely normal:
root@dyson:~# mkdir /mnt2
root@dyson:~# mount /mnt/test/sda1 /mnt2
root@dyson:~# ll /mnt2
total 122205
-rw-r--r-- 1 root root 206212 Aug 7 2019 config-4.19.0-5-amd64
-rw-r--r-- 1 root root 206361 Nov 10 2019 config-4.19.0-6-amd64
drwxr-xr-x 5 root root 1024 Nov 14 2019 grub
-rw-r--r-- 1 root root 53325177 Aug 10 2019 initrd.img-4.19.0-5-amd64
-rw-r--r-- 1 root root 54107425 Jan 9 2020 initrd.img-4.19.0-6-amd64
drwx------ 2 root root 12288 Jul 17 2014 lost+found
-rw-r----- 1 root root 4096 Aug 27 2014 luks_head
-rw-r--r-- 1 root root 3370904 Aug 7 2019 System.map-4.19.0-5-amd64
-rw-r--r-- 1 root root 3410671 Nov 10 2019 System.map-4.19.0-6-amd64
drwxr-xr-x 4 root root 1024 Mar 10 2020 'System Volume Information'
-rw-r--r-- 1 root root 5217520 Aug 7 2019 vmlinuz-4.19.0-5-amd64
-rw-r--r-- 1 root root 5270768 Nov 10 2019 vmlinuz-4.19.0-6-amd64
As I also expected based on experience in the early 1990s when I used to make
image backups of several systems by running gzip on the entire disk or on
partitions of interest. And, of course, the reverse process is widely used,
now, to plant .iso installer images to DVDs or USB keys.
mount -bind /dev is the way I would do chroot setup, and I would expect nothing
good from cp -r /dev
Regards,
Tom Dial
A reasonable guess, but it's not correct.
hobbit:~$ mkdir d1
hobbit:~$ mkfifo d1/pipe
hobbit:~$ cp -r d1 d2
hobbit:~$ ls -l d1 d2
d1:
total 0
prw-rw-r-- 1 greg greg 0 Jan 24 09:25 pipe|
d2:
total 0
prw-rw-r-- 1 greg greg 0 Jan 24 09:25 pipe|
=============================
hobbit:~$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Jan 14 18:21 /dev/null
hobbit:~$ sudo mknod d1/null c 1 3
[sudo] password for greg:
hobbit:~$ sudo rm -rf d2
hobbit:~$ sudo cp -r d1 d2
hobbit:~$ ls -l d1 d2
d1:
total 0
crw-r--r-- 1 root root 1, 3 Jan 24 09:27 null
prw-rw-r-- 1 greg greg 0 Jan 24 09:25 pipe|
d2:
total 0
crw-r--r-- 1 root root 1, 3 Jan 24 09:27 null
prw-r--r-- 1 root root 0 Jan 24 09:27 pipe|
=============================
Of course, the bind mount solution is better than the cp solution in
this case. But the cp solution isn't as wrong as you believed. One
would probably want to use -a instead of -r, though, to copy the
permissions and ownerships.
