[arch-releng] archiso's (?) /dev/dm-* and /dev/loop devices and how to ignore them in AIF
So, in aif we switched approaches to list all possible block devices the user can install Arch to. at first, we listed blockdevices directly in /dev, by having some expressions like /dev/hd*, /dev/sd*, then later we needed to add /dev/vd*, /dev/xvd* and more to support all kinds of hardware and virtualisation solutions. This was a bit of a kludge, so we approached the problem from the other direction: Now we go over everything in /sys/block and filter _out_ the stuff we _don't_ want. (such as devices with size 0 - empty card readers - type 5 - cdrom drives) etc. see https://github.com/Dieterbe/aif/blob/develop/src/core/libs/lib-blockdevices-... This seems to work at least a tiny bit better, even though the problem is similar (we need to maintain filters to remove what we don't want..) I think the final filter we need to add is for the following devices: /dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/loop0 /dev/loop1 /dev/loop100 /dev/loop101 /dev/loop102 /dev/loop103 /dev/loop104 /dev/loop105 /dev/loop106 /dev/loop107 /dev/loop108 /dev/loop109 /dev/loop110 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5 /dev/loop6 /dev/loop7 are these all created by archiso? what exactly are they for? does anyone know what is the best way to ignore them? * some property in /sys/block/<dev>/ ? * how about just maintaining a list of exactly all these filenames .. or: * how about having archiso maintain a file called /var/aif-blockdevices or something? then aif can read that file and ignore blockdevices based on what it finds there. (just don't call it archiso-blockdevices or something, because AIF is supposed to be able to run in several environments)
Am 27.12.2011 19:08, schrieb Dieter Plaetinck:
/dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/loop0 /dev/loop1 /dev/loop100 /dev/loop101 /dev/loop102 /dev/loop103 /dev/loop104 /dev/loop105 /dev/loop106 /dev/loop107 /dev/loop108 /dev/loop109 /dev/loop110 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5 /dev/loop6 /dev/loop7
are these all created by archiso? what exactly are they for?
I'll try to figure this out: loop0-loop7 are loop devices allocated by default - this happens because old userspace can't use the new loop-control device and needs preallocated devices. The rest (on the image I just booted): /dev/loop100 is a block device for root-image.fs.sfs (squashfs, read-only), which is mounted. /dev/loop101 is a block device for the file root-image.fs, which is a (sparse) ext4 file system image (inside squashfs, read-only). /dev/loop102 is a block device for the sparse file /run/cowspace/root-image.cow (which is on tmpfs, read-write). The last two loop devices are put together into a device mapper snapshot device (dm-0), which is then mounted as /. The exact same thing happens for lib-modules.fs.sfs and usr-share.fs.sfs, creating loop103-loop108, dm-1 and dm-2. You booted a core image, so you have loop109 and loop110 as well, which are probably for the pkgs-$ARCH and pkgs-any squashfs. This block-based unioning/snapshotting is certainly not optimal, but it is stable and supported by unpatched kernels. We don't have a file-based solution that fulfills these criteria.
does anyone know what is the best way to ignore them? * some property in /sys/block/<dev>/ ? * how about just maintaining a list of exactly all these filenames .. or: * how about having archiso maintain a file called /var/aif-blockdevices or something? then aif can read that file and ignore blockdevices based on what it finds there. (just don't call it archiso-blockdevices or something, because AIF is supposed to be able to run in several environments)
Maybe not /var, but /run. Another way: use udevadm control --property=AIF_IGNORE=1 [...] This should work :)
On Fri, 30 Dec 2011 14:32:21 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
(.. lots of text..)
wow, thanks.
Maybe not /var, but /run. Another way: use udevadm control --property=AIF_IGNORE=1 [...] This should work :)
that looks interesting, but would require modifying at least archiso and mkinitcpio if i understand correctly. on one hand i dislike requiring other projects to modify their stuff in order to make aif work better, but OTOH I don't see a better way yet. Dieter
On Fri, 30 Dec 2011 14:48:50 +0100 Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Fri, 30 Dec 2011 14:32:21 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Maybe not /var, but /run. Another way: use udevadm control --property=AIF_IGNORE=1 [...] This should work :)
that looks interesting, but would require modifying at least archiso and mkinitcpio if i understand correctly. on one hand i dislike requiring other projects to modify their stuff in order to make aif work better, but OTOH I don't see a better way yet.
bump. this is something that we should resolve in order to be able to continue on the road to new images. (or: we go back to the old AIF behavior of matching device files with the risk of not matching enough of them) Dieter
participants (2)
-
Dieter Plaetinck
-
Thomas Bächler