On most modern Linux systems, pretty much everything under /dev is put there by udev.
On my Debian machine, /dev/disk/by-label comes from several files under /lib/udev/rules.d For example, here is a rule from 60-persistent-storage.rules:
ENV{ID_FS_LABEL_ENC}=="?*", ENV{ID_FS_USAGE}=="filesystem|other", \
SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"
A few lines earlier is where ID_FS_LABEL_ENC comes from:
# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
You can run blkid yourself to see the data its passing to udev:
root@Zia:~# /sbin/blkid -o udev -p /dev/sda2
ID_FS_SEC_TYPE=msdos
ID_FS_LABEL=xfer1
ID_FS_LABEL_ENC=xfer1
ID_FS_UUID=B140-C934
ID_FS_UUID_ENC=B140-C934
ID_FS_VERSION=FAT16
ID_FS_TYPE=vfat
ID_FS_USAGE=filesystem
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_TYPE=0xc
ID_PART_ENTRY_NUMBER=2
ID_PART_ENTRY_OFFSET=257040
ID_PART_ENTRY_SIZE=257040
ID_PART_ENTRY_DISK=8:0
And indeed:
root@Zia:~# ls -l /dev/disk/by-label/xfer1
lrwxrwxrwx 1 root root 10 Nov 19 10:02 /dev/disk/by-label/xfer1 -> ../../sda2
You can put additional rules files in /etc/udev/rules.d/ if you'd like to make additional names for devices, change permissions, etc. E.g., here we have one that populates and sets the permissions on a /dev/disk/for-asm.
That part of the manpage is misleading. Generally you want a different ordering, as described in man 8 pivot_root.
cd new_root # chdir(new_root);
pivot_root . put_old # pivot_root(".", put_old);
exec chroot . # chroot(".");
This seems to be yet another subtle detail with pivot_root. Although the point of pivot_root is to rearrange the mount namespace, the kernel code seems to say that the root filesystem that it moves is determined by the per-process root, which is what chroot sets.
As a result, we hit the error "new_root or put_old are on the current root filesystem".
This subtle detail of pivot_root is necessary in order for it to work at all on modern Linux. If it was defined to work on the root mount of the mount namespace, it would try to move the special rootfs filesystem which you normally can't see. But this is not allowed, because rootfs must always be the root mount of the namespace.
We can confirm pivot_root works this way, by continuing the example as follows.
# unshare -m
# mount --bind / /mnt
# cd /mnt
# chroot /mnt
# pivot_root . mnt
pivot_root: failed to change root from `.' to `mnt': Device or resource busy
# exit # leave chroot
# mount --bind . mnt
# cd mnt
# mount --bind /proc proc
# findmnt | grep mnt
└─/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
└─/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
└─/mnt/proc proc proc rw,nosuid,nodev,noexec,relatime
# chroot /mnt # re-enter chroot
# cd /mnt
# pivot_root . mnt # this one works
# exit # leave chroot
# findmnt | grep mnt
└─/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
├─/mnt/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
└─/mnt/proc /dev/mapper/alan_dell_2016-fedora[/proc] ext4 rw,relatime,seclabel
The second pivot_root call works. But it didn't have any effect on the root of the mount namespace. Looking from outside the chroot, it swapped /mnt and /mnt/mnt.
Best Answer
You can use
dmsetupto create a device-mapper device using either theerrororflakeytargets to simulate failures.Where 123 is the length of the device, in sectors and /dev/loop0 is the original device that you want to simulate errors on. For error, you don't need the subsequent arguments as it always returns an error.