Red Hat Bugzilla – Bug 582948
mknod command doesn't make block, character or FIFO devices
Last modified: 2010-05-20 20:31:10 EDT
Description of problem: Currently there are four commands in guestfish to create device file: mknod, mknod-b, mknod-c and mkfifo, of which mknod-b, mknod-c and mkfifo are used to create block, char and fifo devices respectively. As for mknod, although manpage tells us that it can be used to create either device file(block, char and fifo devices), we can not create neither of them via this command. Version-Release number of selected component (if applicable): libguestfs-1.0.85-1.fc12.3.x86_64 How reproducible: Always Steps to Reproduce: 1.><fs> help mknod NAME mknod - make block, character or FIFO devices SYNOPSIS mknod mode devmajor devminor path DESCRIPTION This call creates block or character special devices, or named pipes (FIFOs). The "mode" parameter should be the mode, using the standard constants. "devmajor" and "devminor" are the device major and minor numbers, only used when creating block and character special devices. 2. Trying to create a block device file via mknod, and check the results: ><fs> mknod 0660 8 1 /block mknod 432 8 1 "/block" send_to_daemon: 0x25eb050 g->state = 3, n = 52 recv_from_daemon: 0x25eb050 g->state = 3, size_rtn = 0x7fffdb87b84c, buf_rtn = 0x7fffdb87b840 proc 133 (mknod) took 0.06 seconds ><fs> ll /block ll "/block" send_to_daemon: 0x25eb050 g->state = 3, n = 40 recv_from_daemon: 0x25eb050 g->state = 3, size_rtn = 0x7fffdb87b86c, buf_rtn = 0x7fffdb87b860 ls -la /sysroot/block proc 5 (ll) took 0.01 seconds -rw-r----- 1 root root 0 Apr 16 09:06 /sysroot/block ><fs> file /block file "/block" send_to_daemon: 0x25eb050 g->state = 3, n = 40 recv_from_daemon: 0x25eb050 g->state = 3, size_rtn = 0x7fffdb87b86c, buf_rtn = 0x7fffdb87b860 file -zbsL /sysroot/block proc 49 (file) took 0.00 seconds empty 3. Trying to create create a char device file via mknod, and check the results: ><fs> mknod 0660 5 1 /char mknod 432 5 1 "/char" send_to_daemon: 0x25eb050 g->state = 3, n = 52 recv_from_daemon: 0x25eb050 g->state = 3, size_rtn = 0x7fffdb87b84c, buf_rtn = 0x7fffdb87b840 proc 133 (mknod) took 0.03 seconds ><fs> ll /char ll "/char" send_to_daemon: 0x25eb050 g->state = 3, n = 40 recv_from_daemon: 0x25eb050 g->state = 3, size_rtn = 0x7fffdb87b86c, buf_rtn = 0x7fffdb87b860 ls -la /sysroot/char proc 5 (ll) took 0.01 seconds -rw-r----- 1 root root 0 Apr 16 09:09 /sysroot/char ><fs> file /char file "/char" send_to_daemon: 0x25eb050 g->state = 3, n = 40 recv_from_daemon: 0x25eb050 g->state = 3, size_rtn = 0x7fffdb87b86c, buf_rtn = 0x7fffdb87b860 file -zbsL /sysroot/char proc 49 (file) took 0.01 seconds empty 3. Trying to create a fifo: ><fs> mknod 0660 /fifp mknod should have 4 parameter(s) type 'help mknod' for help on mknod Actual results: Expected results: So I wonder why mknod still exists in guestfish, given that all its functionality has been provided by mknod-b, mknod-c and mkfifo. Additional info:
The issue as you may already know is you need to specify the correct flags in 'mode'. Since S_IFBLK is 060000, you can do: ><fs> mknod 060660 8 1 /block ><fs> ll / total 13 drwxr-xr-x 3 root root 1024 Apr 19 20:03 . dr-xr-xr-x 20 root root 0 Apr 17 20:09 .. brw-r----- 1 root root 8, 1 Apr 19 20:03 block drwx------ 2 root root 12288 Apr 19 20:03 lost+found Of course you might not "know" that S_IFBLK is 060000, but in that case you can use mknod-b which is exactly the same as mknod except that it or's S_IFBLK with the mode. Not sure if this is a bug since this is exactly how mknod(2) system call works, but I have changed the documentation for you to make this clearer: http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=42e43db927dac13da0afe6dba39708295eb06021
libguestfs-1.2.3-1.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/libguestfs-1.2.3-1.el5
libguestfs-1.2.3-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libguestfs-1.2.3-1.fc13
(In reply to comment #1) > The issue as you may already know is you need to specify > the correct flags in 'mode'. Since S_IFBLK is 060000, you > can do: > > ><fs> mknod 060660 8 1 /block > ><fs> ll / > total 13 > drwxr-xr-x 3 root root 1024 Apr 19 20:03 . > dr-xr-xr-x 20 root root 0 Apr 17 20:09 .. > brw-r----- 1 root root 8, 1 Apr 19 20:03 block > drwx------ 2 root root 12288 Apr 19 20:03 lost+found > > Of course you might not "know" that S_IFBLK is 060000, > but in that case you can use mknod-b which is exactly the > same as mknod except that it or's S_IFBLK with the mode. > > Not sure if this is a bug since this is exactly how mknod(2) > system call works, but I have changed the documentation > for you to make this clearer: > > http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=42e43db927dac13da0afe6dba39708295eb06021 Another question: Does it make sense to create fifo via mknod? For mknod only accepts 4 parameter(s), so we have to create fifo via mknod using such commands: ><fs> mknod 0010660 8 1 /fifo But it seems that "devmajor" and "devminor" are meaningless to fifo, but we have to give them them to mknod for it needs 4 parameters.
(In reply to comment #4) > Another question: > Does it make sense to create fifo via mknod? For mknod only accepts 4 > parameter(s), so we have to create fifo via mknod using such commands: > ><fs> mknod 0010660 8 1 /fifo > > But it seems that "devmajor" and "devminor" are meaningless to fifo, but we > have to give them them to mknod for it needs 4 parameters. Have a look at the mknod(2) system call: int mknod(const char *pathname, mode_t mode, dev_t dev); This is basically what the mknod command in libguestfs is implementing. devmajor and devminor correspond to the two parts of the 'dev' parameter to the underlying system call. The system call ignores the 'dev' parameter for certain types of node (eg. regular files, sockets and FIFOs). Anyway, we guarantee that the ABI stays unchanged, so even if we didn't like how 'mknod' works, we cannot change it or delete it, since some libguestfs users might be using it as it is now.
libguestfs-1.2.3-1.fc12.6 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libguestfs-1.2.3-1.fc12.6
libguestfs-1.2.3-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.