Package: qemu-utils
Version: 1:2.1+dfsg-12+deb8u6
Severity: normal
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829401
The report I sent this against package linux-image-4.5.0-2-grsec-amd64
breaks qemu-nbd's ability to work with max_part. Since the kernel team
is unwillingly to bother about it because they have to try commands with
"qemu-nbd", they are unwilling to look into it.
Here I've tried 4 kernels, the ones that are output with dpkg -l has
been tried. The excuse the kernel team gives about "grsec/non-grsec" is
a mere distration. The bug occurs whether the kernel has grsec built
into it or not, but it occurs against the kernel package it is report
against. They're just unwillingly to bother about it.
My observation is "qemu-nbd" (latest 1:2.5) or "1:2.1" both work fine
and exhibit the same "bug" for kernels above 4.3
"
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions.
"qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/<device>",
but kpartx is not needed at all after issuing qemu-nbd)
nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.
after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")
/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"
basically just a raw disk image containing one partition
dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin
any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
cfdisk 1.bin , and exit the partition tool
no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)
qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate
"qemu-nbd -c /dev/nbd0 1.bin"
there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
only expose partition I<num>"
it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd
Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.
... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices
some output for the report,
modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'
dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs
apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/ jessie-backports/main
amd64 Packages
*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64 Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1
latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail
"
