Your message dated Wed, 19 May 2021 12:44:58 -0700 (PDT) with message-id <[email protected]> and subject line Closing this bug (BTS maintenance for src:linux bugs) has caused the Debian Bug report #829530, regarding linux-image-4.6.0-0.bpo.1-amd64: breaks qemu-nbd to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 829530: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829530 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: linux-image-4.6.0-0.bpo.1-amd64 Version: 4.6.1-1~bpo8+1 Severity: normal 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
--- End Message ---
--- Begin Message ---Hi This bug was filed for a very old kernel or the bug is old itself without resolution. If you can reproduce it with - the current version in unstable/testing - the latest kernel from backports please reopen the bug, see https://www.debian.org/Bugs/server-control for details. Regards, Salvatore
--- End Message ---
