Config directories don't mount inside VM #45
Comments
|
Additional info: wifibox-core-0.11.0: wifibox-alpine-20230213: Intel(R) Wireless-AC 9560 160MHz, REV=0x318 |
|
Hi @iron-udjin, thanks for the report! I could not yet reproduce this on 12.4-RELEASE but I have not yet given it up... Based on the log, everything goes as expected. Could you please include the VM's logs as well? You can find this at Regarding the AP sample configuration, I am not sure this is the responsibility of Wifibox. Similarly to Of course, I can include here the |
This directory is empty:
Generic config could be something like https://wiki.gentoo.org/wiki/Hostapd: |
|
Looks like the VirtFS/9P mounts do not work at all, although the messages in the log do not indicate any related problems. |
|
Is not there anything unusual present the |
|
|
|
Thanks! No indication of any mount errors in either of the logs, though -- that is even stranger. I should really try to reproduce this locally. By the way, does |
No, it doesn't work. The same problem with config direstories mount. |
|
Where is VirtFS functionality is located? Possibly there is some module missing or something like that... Here is my kernel config: https://pastebin.com/A4B401Wy |
|
Here is my |
|
If I recall correctly, the implementation of VirtFS/9p does not require any special support from the side of the kernel and the base system. It is a shipped as a library ( However, something else might be broken that affects the |
|
I'm afraid it could be bug in |
|
Unfortunately I do not have any direct experience with tracking down issues like that one. It might be a good idea to report this problem in the FreeBSD Project right away (given the timing) where developers will tell you what to do or even quickly realize what to revert. |
|
Ok, thank you. Let's close this issue as the problem is not within |
|
What about posting the link to the upstream bug report and leave it open until resolved? This may help others to learn about the problem. We have done something similar in the past. |
pgj
added
base system
|
Ok, let's leave it as is. |
|
To track the issue with |
|
I tried to reproduce the problem with |
|
I tried to rebuild kernel with GENERIC config or even deploy kernel image from here - still have no luck. It seems the problem somewhere inside |
|
Here is how you can investigate the behavior of the # cd /usr/src/usr.sbin/bhyve
# make DEBUG_FLAGS="-O0 -g"
# make installIn result, debug symbols for # file /usr/lib/debug/usr/sbin/bhyve.debug
/usr/lib/debug/usr/sbin/bhyve.debug: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), no program header, for FreeBSD 12.4, FreeBSD-style, with debug_info, not strippedThen create a dummy # /usr/local/sbin/grub-bhyve -S -M 64M -r host -d /usr/local/share/wifibox testAnd then it becomes possible to start # lldb -- /usr/sbin/bhyve -c 1 -m 64M -AHP -u -S -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/usr/local/share/wifibox/disk.img -s 4:1,virtio-9p,config=/usr/local/etc/wifibox/appliance,ro -s 4:2,virtio-9p,var=/var/run/wifibox/appliance -s 4:3,virtio-9p,app_config=/usr/local/etc/wifibox/wpa_supplicant test
(lldb) target create "/usr/sbin/bhyve"
Current executable set to '/usr/sbin/bhyve' (x86_64).
(lldb) settings set -- target.run-args "-c" "1" "-m" "64M" "-AHP" "-u" "-S" "-s" "0,hostbridge" "-s" "31,lpc" "-s" "4:0,virtio-blk,/usr/local/share/wifibox/disk.img" "-s" "4:1,virtio-9p,config=/usr/local/etc/wifibox/appliance,ro" "-s" "4:2,virtio-9p,var=/var/run/wifibox/appliance" "-s" "4:3,virtio-9p,app_config=/usr/local/etc/wifibox/wpa_supplicant" "test"Use Once the breakpoint is set, start the application, which should immediately be stopped in response to that: The execution of the function can be stepped by the That way, for example, it can be tracked how the Ideally, this should give us some ideas about why the things are not going right. After finished working with # bhyvectl --destroy --vm=test |
|
Can you try it with freebsd 13.1-RELEASE ? it always worked great 4 me. Now
Im using 13.2-BETA and it still works.
Il dom 26 feb 2023, 23:34 PÁLI Gábor János ***@***.***> ha
scritto:
… Here is how you can investigate the behavior of the virtio-9p backend in
bhyve. First create and install a version of the bhyve binary that
includes debug symbols and not optimized.
# cd /usr/src/usr.sbin/bhyve
# make DEBUG_FLAGS="-O0 -g"
# make install
In result, debug symbols for bhyve will be installed as
/usr/lib/debug/sbin/bhyve.debug, along with an updated version of
/usr/sbin/bhyve (this is for 12.4-RELEASE but it should be the same on
other major versions):
# file /usr/lib/debug/usr/sbin/bhyve.debug/usr/lib/debug/usr/sbin/bhyve.debug: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), no program header, for FreeBSD 12.4, FreeBSD-style, with debug_info, not stripped
Then create a dummy bhyve VM, which will be called test here, that mimics
the execution of wifibox. Start with preparing the launch by grub-bhyve:
# /usr/local/sbin/grub-bhyve -S -M 64M -r host -d /usr/local/share/wifibox test
And then it becomes possible to start bhyve through lldb, the system
debugger:
# lldb -- /usr/sbin/bhyve -c 1 -m 64M -AHP -u -S -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/usr/local/share/wifibox/disk.img -s 4:1,virtio-9p,config=/usr/local/etc/wifibox/appliance,ro -s 4:2,virtio-9p,var=/var/run/wifibox/appliance -s 4:3,virtio-9p,app_config=/usr/local/etc/wifibox/wpa_supplicant test(lldb) target create "/usr/sbin/bhyve"Current executable set to '/usr/sbin/bhyve' (x86_64).(lldb) settings set -- target.run-args "-c" "1" "-m" "64M" "-AHP" "-u" "-S" "-s" "0,hostbridge" "-s" "31,lpc" "-s" "4:0,virtio-blk,/usr/local/share/wifibox/disk.img" "-s" "4:1,virtio-9p,config=/usr/local/etc/wifibox/appliance,ro" "-s" "4:2,virtio-9p,var=/var/run/wifibox/appliance" "-s" "4:3,virtio-9p,app_config=/usr/local/etc/wifibox/wpa_supplicant" "test"
Use lldb commands to check how the arguments of the pci_vt9p_init
<https://cgit.freebsd.org/src/tree/usr.sbin/bhyve/pci_virtio_9p.c?h=stable/13#n251>
function are flowing through. This C function is responsible for making the
9P protocol work.
(lldb) b pci_vt9p_init
Breakpoint 1: where = bhyve`pci_vt9p_init + 35 at pci_virtio_9p.c:242:11, address = 0x000000000023e663
Once the breakpoint is set, start the application, which should
immediately be stopped in response to that:
(lldb) r
Process 19852 launched: '/usr/sbin/bhyve' (x86_64)
Process 19852 stopped
* thread #1, name = 'bhyve', stop reason = breakpoint 1.1
frame #0: 0x000000000023e663 bhyve`pci_vt9p_init(ctx=0x000000080029c180, pi=0x0000000800b2c500, opts="config=/usr/local/etc/wifibox/appliance,ro") at pci_virtio_9p.c:242:11
239 bool ro = false;
240 cap_rights_t rootcap;
241
-> 242 if (opts == NULL) {
243 printf("virtio-9p: share name and path required\n");
244 return (1);
245 }
The execution of the function can be stepped by the s (step) command and
the state of the variables in scope can be investigated by the var
command:
(lldb) var
(vmctx *) ctx = 0x000000080029c180
(pci_devinst *) pi = 0x0000000800b2c500
(char *) opts = 0x000000080029c10e "config=/usr/local/etc/wifibox/appliance,ro"
(cap_rights_t) rootcap = {
cr_rights = ([0] = 140737488347616, [1] = 0)
}
(bool) ro = false
(char *) rootpath = 0x0000000000000000
(char *) sharename = 0x0000000000000000
(char *) opt = <variable not available>
(int) rootfd = <variable not available>
(pci_vt9p_softc *) sc = <variable not available>
That way, for example, it can be tracked how the sharename variable gets
its value:
[..]
(lldb) s
Process 19852 stopped
* thread #1, name = 'bhyve', stop reason = step in
frame #0: 0x000000000023e6db bhyve`pci_vt9p_init(ctx=<unavailable>, pi=0x0000000800b2c500, opts="ro") at pci_virtio_9p.c:255:15
252 }
253
254 sharename = strsep(&opt, "=");
-> 255 rootpath = opt;
256 continue;
257 }
258
(lldb) p sharename
(char *) $0 = 0x000000080029c10e "config"
Ideally, this should give us some ideas about why the things are not going
right.
—
Reply to this email directly, view it on GitHub
<#45 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFYNC4IH5YCX733GMPB5ZTWZPLAJANCNFSM6AAAAAAVEDR5EM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Oh... thanks for such detailed instructions! Using debugger I found that the problem is in lack of CAPSUIM support. I've rebuilded world + kernel and everything works as expected: That's really weird that Thanks a lot for your help! |
|
I am glad that finally we could find the root cause. I have posted the conclusion to the FreeBSD ticket in case folks do not want to read through the comments here. I may even submit a patch for |
Hello,
I'm trying to configure
wifiboxas AP. I addedpassthrudevice and startedwifibox:service wireguard startwifibox console:
As you see, VM doesn't mount config directories. And as a result, doesn't bringing up network interfaces.
Debug logs:
Don't have any idea where should I dig to solve this problem. Could you please advise me?
Also please add sample configuration about creating AP.
man 8 wifiboxhas nice samples but nothing regarding hostapd config or setup AP in general. It would be great to havehostapd/hostapd.confwith commented sample configuration. Users could just uncomment sample config and edit it according to their needs instead of readingman hostapd.Thank you!
The text was updated successfully, but these errors were encountered: