Re: [gentoo-user] qemu / nbd
On 12/5/19 12:22 PM, n952162 wrote: But, since it's included in the package, and apparently (from the name) will use a NBD device, then I think the dependency is logical I disagree. QEMU itself does not use NBD. Thus QEMU does not need to depend on qemu-nbd. QEMU uses files on mounted file systems. qemu-nbd is a — perhaps questionably named — utility that allows QEMU disk images / files to be accessed as if they were NBDs. Not the other way around. qemu-nbd does not allow QEMU to use NBDs. As I understand it, nothing about /QEMU/ is dependent on any NBD support. -- Grant. . . . unix || die
Re: [gentoo-user] Re: To all IPv6-slackers among the Gentoo community
* Ian Zimmerman: > [OpenWrt] needs one crucial bit of configuration that's kind of hidden > (can't be done via the GUI), to let the router advertisements through. Glad to hear that you got things working. You have probably already filed a GUI enhancement request. ;-) -Ralph
Re: [gentoo-user] qemu / nbd
On 12/5/19 12:50 PM, Neil Bothwick wrote: No, but since it is provided by the ebuild, the ebuild should check that the target system is capable of supporting it. The qemu ebuild already spits out warnings about missing kernel options, not all of them essential, so why not this one too? I think a warning for missing NBD support is absolutely the correct way to go. I think blocking / failing the ebuild is the wrong thing to do. IMHO warning ≠ failure -- Grant. . . . unix || die -- Grant. . . . unix || die
Re: [gentoo-user] Help with IPv6, please
* gentoo-u...@c-14.de: > The easiest option is if you're using stateful DHCPv6. In this case > you just need to set up your dhcp server to notify your dns server of > any new leases. That's what you consider "the easiest option"? ;-) I usually ask the following of people starting with IPv6: Do you really need fixed names for all nodes, or is this more of a reflex? In my experience, home networks can usually run with only a few fixed addresses (or rather name-to-address mappings). An old printer might need a fixed address. A multimedia server will broadcast its services and often does not need a fixed address. Neither do various smart- phones. The router might need one, if it has a web UI. Something like this might be enough: # /etc/hosts fd67:1:2:3::1 router.local router fd67:1:2:3::2 printer.local printer fd67:1:2:3::/64 is a random ULA prefix, pretty much an equivalent of 10.0.0.0/8 but much larger. Just assign a fixed ULA address to nodes that *really* need it and share /etc/hosts across your nodes. That, to me, is an easier option than setting up DHCPv6 and a DNS server, both of which need to support dynamic DNS updates. Depending on your environment, "ping6 somename.local" might work without any manual configuration at all, as I mentioned in my previous message. -Ralph
Re: [gentoo-user] Help with IPv6, please
* Peter Humphrey: > $ ping6 vdsl > ping: vdsl: No address associated with hostname The outcome of ping depends on /etc/resolv.conf and /etc/hosts, and even on the OS of the IPv6 nodes involved. Apple devices will be available as somename.local, with "somename" being what the user configured as the device's name in Preferences->Sharing. I can for example ping my iPhone via "ping6 silver.local". > If I add the LAN address of the Bipac to /etc/hosts, ping finds it > okay, but what if the address changes if the Bipac reboots? Your Bipac will have multiple "LAN addresses", or rather addresses that are bound to the LAN-facing network interface. In your example, you were pinging the global scope address 2a02:x which may change over time, unless your provider assigns static networks (mine does not). However, the router should also have at least one link-local address and one unique local address (ULA): Global scope: 2a02:8010:x (may change or may not) Link local: fe80:y (may change with SLAAC privacy extensions) ULA: fd67:z (should be fixed) With my router, the ULA was set up once when I first picked a random ULA prefix, and has remained immutable since then. > I see my mobile phone has acquired an IPv6 address starting with > fe80::40be... and it doesn't look like its MAC address. That's not actually a bad thing. I mentioned SLAAC privacy extensions (RFC 4941) before; [1] offers some explanations. [1] https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/ -Ralph
Re: [gentoo-user] qemu / nbd
On Thu, 5 Dec 2019 12:01:33 -0700, Grant Taylor wrote: > qemu-nbd is a utility to act as a NBD server to allow the Linux kernel > to be an NBD client to access qcow(2) image files. > > qemu-nbd is not /needed/ for normal QEMU operation. No, but since it is provided by the ebuild, the ebuild should check that the target system is capable of supporting it. The qemu ebuild already spits out warnings about missing kernel options, not all of them essential, so why not this one too? -- Neil Bothwick I thought I saw the light at the end of the tunnel... but it was just some sod with a torch bringing me more work! pgpVuOYQ3Q4tR.pgp Description: OpenPGP digital signature
Re: [gentoo-user] nbd ebuild incomplete? [SOLVED]
On 12/05/19 20:01, Grant Taylor wrote: On 12/5/19 12:33 AM, n952162 wrote: The emerge should have checked for this and failed. I don't think it should fail. I've routinely seen emerge check for various kernel / network / other parameters and issue warnings about things not being the way that the ebuild wants. But the ebuild does successfully emerge. IMHO emerge / ebuild should not refuse to do what I tell it to do just because it doesn't like my custom kernel. The lack of kernel support is /my/ problem. The emerge / ebuild is capable of compiling perfectly fine without the kernel support. Perhaps I'm compiling on a fast machine that is running a different kernel and then copying the utilities to another system that does have the kernel support. Then you set the appropriate USE variable for that special situation. You could your argument for any dependency.
Re: [gentoo-user] qemu / nbd
Very informative explanation. On 12/05/19 20:01, Grant Taylor wrote: On 12/4/19 11:03 PM, Walter Dnes wrote: nbd is a "Network Block Device" driver along the lines of NFS, but it doesn't handle concurrency. https://nbd.sourceforge.io/ I think I'd liken NBD to iSCSI more so than NFS. Primarily because both NBD and iSCSI provide local block devices that are backed by something across the network. Conversely, NFS provides access to regular files from across the network. You can put a file system on an NBD / iSCSI block device if you want, but you don't have to. Conversely, NFS is a file system and doesn't require putting a file system on top of it. But it's generic, and can handle any *REGULAR* file system, not just NFS. NFS is not a file system in the /typical/ sense. There is no mkfs.nfs. NFS is a file system in the sense that it is mounted and provides access to files. QCOW2, or raw, or whatever, is a special QEMU format. So it requires QEMU libs (i.e. qemu-nbd) to decode QCOW2/RAW. Why doesn't qemu have a dependency on NFS? It doesn't, nor does it need to. Same answer; they're both remote network block device systems that most linux users don't need, NFS is not a block device. and they're both unrelated to the core functionality of QEMU. QEMU can use image files (qcow(2) or raw) on any mounted file system. NFS qualifies as a mounted file system, but that is completely outside of QEMU. Normal file systems can be put on NBD & iSCSI devices and mounted, but that is also completely outside of QEMU. QEMU proper will not use NBD devices (directly) itself. qemu-nbd is a utility to act as a NBD server to allow the Linux kernel to be an NBD client to access qcow(2) image files. qemu-nbd is not /needed/ for normal QEMU operation. But, since it's included in the package, and apparently (from the name) will use a NBD device, then I think the dependency is logical
Re: [gentoo-user] nbd ebuild incomplete? [SOLVED]
On 12/5/19 12:33 AM, n952162 wrote: The emerge should have checked for this and failed. I don't think it should fail. I've routinely seen emerge check for various kernel / network / other parameters and issue warnings about things not being the way that the ebuild wants. But the ebuild does successfully emerge. IMHO emerge / ebuild should not refuse to do what I tell it to do just because it doesn't like my custom kernel. The lack of kernel support is /my/ problem. The emerge / ebuild is capable of compiling perfectly fine without the kernel support. Perhaps I'm compiling on a fast machine that is running a different kernel and then copying the utilities to another system that does have the kernel support. -- Grant. . . . unix || die -- Grant. . . . unix || die
Re: [gentoo-user] qemu / nbd
On 12/4/19 11:03 PM, Walter Dnes wrote: nbd is a "Network Block Device" driver along the lines of NFS, but it doesn't handle concurrency. https://nbd.sourceforge.io/ I think I'd liken NBD to iSCSI more so than NFS. Primarily because both NBD and iSCSI provide local block devices that are backed by something across the network. Conversely, NFS provides access to regular files from across the network. You can put a file system on an NBD / iSCSI block device if you want, but you don't have to. Conversely, NFS is a file system and doesn't require putting a file system on top of it. But it's generic, and can handle any *REGULAR* file system, not just NFS. NFS is not a file system in the /typical/ sense. There is no mkfs.nfs. NFS is a file system in the sense that it is mounted and provides access to files. QCOW2, or raw, or whatever, is a special QEMU format. So it requires QEMU libs (i.e. qemu-nbd) to decode QCOW2/RAW. Why doesn't qemu have a dependency on NFS? It doesn't, nor does it need to. Same answer; they're both remote network block device systems that most linux users don't need, NFS is not a block device. and they're both unrelated to the core functionality of QEMU. QEMU can use image files (qcow(2) or raw) on any mounted file system. NFS qualifies as a mounted file system, but that is completely outside of QEMU. Normal file systems can be put on NBD & iSCSI devices and mounted, but that is also completely outside of QEMU. QEMU proper will not use NBD devices (directly) itself. qemu-nbd is a utility to act as a NBD server to allow the Linux kernel to be an NBD client to access qcow(2) image files. qemu-nbd is not /needed/ for normal QEMU operation. -- Grant. . . . unix || die -- Grant. . . . unix || die
[gentoo-user] Re: To all IPv6-slackers among the Gentoo community
On 2019-11-29 00:01, Ralph Seichter wrote: > > The first reason [...] was that my router does _not_ assign fe80::1 to > > itself, but rather some other arbitrary address in the fe80 prefix > > I found an article[1] that I first read years ago. "One method to make > things easier is to manually assign the link-local address to the > upstream router’s interfaces." That's one of the firmware-dependent > things, it may happen automatically. I know that my favourite data > center has its routers set up this way as well. One does not have to use > this method, of course. > > I did enable the router advertisement feature, and I checked that the > > daemon is running on the router. But I can see no output related to > > that when I run tcpdump on the desktop system. > > Anything that might be interfering with ICMPv6 ? That would prevent all > NDP, including router advertisement. > I only use a static IPv6 address for hosted machines, because I need DNS > records. The individual subnets are statically assigned by the data > center to each machine. > > At home, I don't configure clients with static IPv6, because it is not > necessary for me. In fact, I'm happy to have the lowest 64 address bits > scrambled (IPv6 Privacy Extensions) to make traffic analysis more > difficult. All local clients can use NDP to locate each other anyway. > > > https://openwrt.org/docs/guide-user/network/ipv6/start > > Sadly I have no practical experience with OpenWrt. Hopefully somebody > else here can help with that. I did make it work with DHCP6. The problems are all with my OpenWrt router. It is free software and I love it, but it has its bu^H^Hquirks. In particular it doesn't seem to be possible to force a particular link-local address on the internal interface. Apart from that, it needs one crucial bit of configuration that's kind of hidden (can't be done via the GUI), to let the router advertisements through. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Help with IPv6, please
> Hello list, Hi, > Having been inspired by the recent discussion of IPv6, I decided to try it, > starting with my ISP, my Billion Bipac vDSL modem-router and one host - this > one. Of course it isn't straightforward. > > Zen has allocated me a /64 ND prefix and a /48 PD prefix. I found a way to > tell the Bipac to set up IPv6, and rebooted it; it now tells me its LAN > address is 2a02:8010:663d:0:6203:47ff:fe2d:8eba/64. Nslookup on this host > says > the same, without the /64. But then this: > > $ ping6 vdsl > ping: vdsl: No address associated with hostname > $ ping6 2a02:8010:663d:0:6203:47ff:fe2d:8eba > PING 2a02:8010:663d:0:6203:47ff:fe2d:8eba(2a02:8010:663d:0:6203:47ff:fe2d: > 8eba) 56 data bytes > 64 bytes from 2a02:8010:663d:0:6203:47ff:fe2d:8eba: icmp_seq=1 ttl=64 > time=1.75 ms > ^C > > If I add the LAN address of the Bipac to /etc/hosts, ping finds it okay, but > what if the address changes if the Bipac reboots? I thought this kind of > address fixing was unnecessary in IPv6. > > And am I supposed to fix the IPv6 addresses of the other hosts on the LAN, or > just stick to IPv4 for local comms? And I haven't yet even thought about the > wireless devices served by the Bipac, though I see my mobile phone has > acquired an IPv6 address starting with fe80::40be... and it doesn't look like > its MAC address. It really depends how you're setting up IPv6 on your local network. The easiest option is if you're using stateful DHCPv6. In this case you just need to set up your dhcp server to notify your dns server of any new leases. If you're using static IPv6 addresses you can create a static mapping between hostnames and addresses either in /etc/hosts or your dns server. If you're using SLAAC, however, the only option I can think of is to use stateless DHCPv6 to notify the DHCP server of your client fqdn which should then sync the record with the DNS server. -- Simon Thelen
[gentoo-user] Help with IPv6, please
Hello list, Having been inspired by the recent discussion of IPv6, I decided to try it, starting with my ISP, my Billion Bipac vDSL modem-router and one host - this one. Of course it isn't straightforward. Zen has allocated me a /64 ND prefix and a /48 PD prefix. I found a way to tell the Bipac to set up IPv6, and rebooted it; it now tells me its LAN address is 2a02:8010:663d:0:6203:47ff:fe2d:8eba/64. Nslookup on this host says the same, without the /64. But then this: $ ping6 vdsl ping: vdsl: No address associated with hostname $ ping6 2a02:8010:663d:0:6203:47ff:fe2d:8eba PING 2a02:8010:663d:0:6203:47ff:fe2d:8eba(2a02:8010:663d:0:6203:47ff:fe2d: 8eba) 56 data bytes 64 bytes from 2a02:8010:663d:0:6203:47ff:fe2d:8eba: icmp_seq=1 ttl=64 time=1.75 ms ^C If I add the LAN address of the Bipac to /etc/hosts, ping finds it okay, but what if the address changes if the Bipac reboots? I thought this kind of address fixing was unnecessary in IPv6. And am I supposed to fix the IPv6 addresses of the other hosts on the LAN, or just stick to IPv4 for local comms? And I haven't yet even thought about the wireless devices served by the Bipac, though I see my mobile phone has acquired an IPv6 address starting with fe80::40be... and it doesn't look like its MAC address. -- Regards, Peter.
Re: [gentoo-user] nbd ebuild incomplete? [SOLVED]
On Thursday, 5 December 2019 12:52:41 GMT n952162 wrote: > where do I start? By not top-posting. > On 12/05/19 09:56, Neil Bothwick wrote: > > On Thu, 5 Dec 2019 08:33:08 +0100, n952162 wrote: > >> Okay, I see from /proc/config.gz that NBD probably needs to be > >> configured with the kernel > >> > >> # CONFIG_BLK_DEV_NBD is not set > >> > >> Bummer. At work, I could just do a apt-get install qemu-nbd (or > >> similar) without any more effort. > > > > That's because generic distro kernels already have BLK_DEV_NBD enabled. > > > >> The emerge should have checked for this and failed. > > > > Yes, it sounds like it. Have you filed a bug report? Have ready the output of 'emerge --info' in a file. Then go to bugs.gentoo.org, create an account and log in. Search for existing bugs against the ebuild you're interested in, including its version. If there is one, you could add yourself to its CC list (top right corner) to be notified of changes. Otherwise, create a new bug report, giving as much detail as you can. Attach your --info file to the bug. Job done. -- Regards, Peter.
Re: [gentoo-user] nbd ebuild incomplete? [SOLVED]
where do I start? On 12/05/19 09:56, Neil Bothwick wrote: On Thu, 5 Dec 2019 08:33:08 +0100, n952162 wrote: Okay, I see from /proc/config.gz that NBD probably needs to be configured with the kernel # CONFIG_BLK_DEV_NBD is not set Bummer. At work, I could just do a apt-get install qemu-nbd (or similar) without any more effort. That's because generic distro kernels already have BLK_DEV_NBD enabled. The emerge should have checked for this and failed. Yes, it sounds like it. Have you filed a bug report?
Re: [gentoo-user] nbd ebuild incomplete? [SOLVED]
On Thu, 5 Dec 2019 08:33:08 +0100, n952162 wrote: > Okay, I see from /proc/config.gz that NBD probably needs to be > configured with the kernel > > # CONFIG_BLK_DEV_NBD is not set > > Bummer. At work, I could just do a apt-get install qemu-nbd (or > similar) without any more effort. That's because generic distro kernels already have BLK_DEV_NBD enabled. > The emerge should have checked for this and failed. Yes, it sounds like it. Have you filed a bug report? -- Neil Bothwick Taglines are like cars - You get a good one, then someone nicks it. pgpFv_NDOpbcL.pgp Description: OpenPGP digital signature
Re: [gentoo-user] qemu / nbd
On Thu, 5 Dec 2019 08:05:46 +0100, n952162 wrote: > Or maybe the assumption is wrong - after emerging *nbd*, I still get > this when I try to modprobe nbd, which is required for running > *qemu-nbd*: > > modprobe: FATAL: Module ndb not found in directory > /lib/modules/4.19.72-gentoo The assumption is wrong, sys-block/nbd contains the userland stuff, to get the module you need CONFIG_BLK_DEV_NBD=m in yor kernel config. The qemu ebuild already checks kernel configs for required settings and it sounds like this should be added to the list. I'd suggest filing a bug report, if there isn't already one. -- Neil Bothwick Capt'n! The spellchecker kinna take this abuse! pgpLvZZErC2GK.pgp Description: OpenPGP digital signature
