[OpenIndiana-discuss] Will OpenIndiana switch to SquashFS?
Most Linux distributions now employing SquashFS for their live system so they are blazing fast even though being run from a slow USB 2.0 stick. I'm posting this mail on one of such live system. I found OpenIndiana is using another technology: https://ptribble.blogspot.com/2012/10/those-strange-zlib-files.html Does this technology comparable to SquashFS? And if SquashFS is better, is there any plan to switch to SquashFS? I found when I dd-ed the .usb image into my usb, it only fills a small extent of my storage space. How could I extend it to fit to all of my storage space? Could I make a partition from the unused space to store data? Linux is too good at being a live system. The MX Live USB Creator handled all of this for me. I'm posting from a live MX Linux system. Nowadays, finding a live system not being a Linux distro is hard. So I really appreciate OpenIndiana. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Dual screen setup with intel DRM & VESA
OK, apparently I've jumped into conclusion here, since the Skylake GPU is actually not supported by illumos DRM right now, so this setup is probably impossible. I'll update this after I've come up with another idea. Thanks anyway. On 1/8/21 5:44 PM, Araragi Hokuto wrote: Hello everyone. I'm trying to setup an OI installation for my illumos dev tasks. My system has a i7-6700 CPU and RX480 graphics card, with a dual monitor setup. Since there is no AMDGPU driver avaliable for illumos (Correct me if I'm wrong, but https://www.illumos.org/issues/8069 does not seem to have a corresponding kernel module, and I couldn't get that working by simply installing the userland component, I'm assuming there is still no actual support at this moment?), I'm currently using VESA xorg driver, which works fine for me; but since it uses VESA BIOS for display, there is no dual screen support. But I noticed that there is intel DRM support on illumos, and I do have a intel GPU (the integrated GPU in my i7), so I'm thinking: is it possible to utilize both GPU for dual screen support? More specifically, these are what I'm trying to do: a) Use VESA driver for RX480, and connect the primary screen to its HDMI output, which is already working by default, and: b) Enable intel DRM on the integrated GPU, and connect the secondary monitor to the HDMI port provided by my motherboard. a) is working by default now, and enabling intel GPU while keep the AMD GPU working is certainly doable in my BIOS (verified under Linux with xrandr). But I'm not sure how to configure X server on illumos to make it aware of this setup. Therefore, is there anyone have ideas of what configure should I try, or some alternative way to setup dual screen with VESA/intel DRM? Unfortunately there is only one HDMI port on my motherboare, so I don't think connecting both monitor to intel GPU is an option (again, correct me if I'm wrong). Thanks in advance. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tasks to focus on
On Thu, Jan 7, 2021 at 10:57 PM Till Wegmueller wrote: > Hey Aurelian > > Nice to have you back! > > We had a Maintainer meetup yesterday aswell and I am still processing > the notes. And translating to English. (we where all German) > > But in short: > I will get myself a Physical host with Hetzner with a ton of RAM and CPU > so we can dedicate some zones and VM's to OpenIndiana building packages. > Olaf has been working on a revised Jenkins pipeline which fully > automates PR builds and allows to push them into seperate repos for > testing with others. So others can just use that repo for testing and > don't need to build. We will implement that Capability there. > Great initiative! > We also talked about making a rustup.mk which will use jmclulows rustup > work to bootstrap a rust compiler to build rust software and rust itself. > I worked on the updating the component months ago so my recipe has become obsolete since Joshua made illumos a first class rust citizen :) > > As we plan to eventually migrate our build and repository server onto > that Hetzner machine, we can also look into rebuild then, as we will > probably have to do one from scratch. > I will also set up a build zone on a file server which has fairly low workload now (2 x 20 cores, 192GB RAM) to resume the gcc-10 builds. There were only ~10 packages left to fix back then. > > PS. would you like to be invited to the Maintainer meetup? It's on the > thirst Wednesday every month 19:00 PM Berlin timezone. > Count me in :) Kind regards, Aurelien > > -Till > > > On 07.01.21 18:39, Aurélien Larcher wrote: > > Hi, > > since I have now more or less recovered from Covid I can be active to > some > > extent. > > > > Back in March I was working on: > > - building oi-userland with GCC-10 (everything was built except ~10 > > packages). > > - providing Python 3.8 and 3.9. > > - migrating pkg5 to Python 3.7. > > - updating Boost. > > - updating Clang. > > - updating Rust. > > - updating libdrm to 2.4.100. > > - bringing automated rebuild of oi-userland packages and dependencies in > > order. > > > > However priorities should be set as I cannot dedicate too much time... > > > > - What do you think should be prioritized? > > - Is anybody interested in picking up one of the tasks? I can assist and > > provide some guidance. > > > > Kind regards, > > > > Aurelien > > > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > -- --- Praise the Caffeine embeddings ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tasks to focus on -- firefox
Am 08.01.21 um 10:55 schrieb Carsten Grzemba via openindiana-discuss: Am 08.01.21 10:25 schrieb "Joshua M. Clulow" : On Thu, 7 Jan 2021 at 23:34, Carsten Grzemba via openindiana-discuss wrote: On 07.01.21 23:47, Joshua M. Clulow via openindiana-discuss wrote: If you hit any trouble with Rust, I'd love to hear about it! We have a good relationship with the Rust project itself, so we should be able to get things fixed as they arise, without needing to float additional patches. I try to build firefox 78esr for openindiana. The problems with Rust are much smaller than a while ago. I took a spin at building Firefox last year, and while I didn't get a complete build finished (ran out of time) it was honestly easier to get master to build than ESR. The main branch usually uses updated crates, and thus tends to have _better_ support for illumos than the older ESR branches. But I stopped to use the rustc installed with rustup because this use a toolchain naming like x86_64-unknown-illumos. For that the rustc sources build instruction have to extent for target_os "solaris" to target_os "illumos", which is an additional effort. So I updated the oi-userland build reciept for rust to provide an newer version (1.41.1) where the target tripple x86_64-sun-solaris is used. So there are no patching of lib.rs and others is necessary. Or it is possible with rustup to get the target toolchain x86_64-sun-solaris also? The old "sun-solaris" targets are not really being maintained by the illumos community at this point -- either in the Rust toolchain itself, or in the crates in the Rust ecosystem at large. I would recommend using the illumos target and getting any build issues fixed upstream in whatever crates have remaining platform-specific issues. I and some other folks have been doing that sort of thing a lot throughout 2019-2020. Most or all of our patches and testing are for the illumos target, even if the Solaris targets sometimes also come along for the ride. I think it'd be best if OI ships an illumos target toolchain for Rust, rather than the increasingly obsolete solaris target. Then we're all testing and working on the same bits! Cheers. -- Joshua M. Clulow http://blog.sysmgr.org Some other findings related buld FF on OI - update ICU, if we want use system ICU - update mozilla-nss, if we want system-nss - update rust - if we use system-sqlite3, in sqlite3 libsqlite-3 2 symbols not exported because these missing in mapfile these all are already in my repository on github - readelf (2.34) of our binutil package is unable to read the libxul.so, readelf (2.33) of Solaris 11.4 can it read. updated readelf (2.35.2) reports less errors but fails also. I deceide to use GCC9 because the trouble to compile with clang was bigger, GCC7 stopped with a suspicouse memory allocation error. Carsten ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss It's good to see that people try to build things. But I want to ask you all to do that more openly and work together. We have our Github repositories for PR's, discussion groups and mailing lists. If everybody tries to work together the burden for the maintainers will be lesser and the advancements for OI better. I have the impression that a lot of necessary updates would have already been possible with a little bit more cooperation. Andreas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Virtualbox and USB webcam
Hey Tony Here in the EU I always get myself a USB Gaming Headset for my Audio needs. They are Cheap(ish) and you can get yourself a Wireless Headset that has a dedicated receiver that needs no special driver, other than Audio. You might also get away by simply using the Mic, Headset on the host and using Virtuablox Audio. And thanks for that Note that may be why I was unsuccessful in the past with certain pass through combinations. -Till On 08.01.21 05:09, Tony Brian Albers wrote: Hi Till, Thanks a lot for your reply. Well, it wasn't a kernel driver hogging the device. I could modunload the usbvc driver easily, but when I tried to attach the device in vbox, the kernel loaded the usbvc driver automagically again. But you did actually point me in the right direction, this post helped: https://forums.virtualbox.org/viewtopic.php?t=87398#p475462 ### THE IMPORTANT PART ### It seems that you need to make sure that the USB device goes into a USB port that matches the device's type (USB 2, 3 etc.) and then make sure that your USB controller type configuration of the VM matches the physical port you're trying to pass through. ### END OF THE IMPORTANT PART" So when I attached the webcam to a USB 2.0 port, there was a bit more stuff logged in /var/adm/messages. Then I selected "USB 2.0 (OHCI + EHCI) Controller" in vbox settings(USB for the VM), and suddenly it works! Next challenge is to get the mic working. And since I don't have an external mic that might prove a bit difficult :) And of course my old(ish) PC doesn't have a headset port, but separate headphones/mic ports. /tony On 01/07/21 10:30 PM, Till Wegmueller wrote: Hey Tony That sounds to me like the a kernel driver is attaching to the device and thus Virtualbox cannot do that anymore. There is a blacklisting capability but I have never done that or know how exactly that works, or if it helps in this situation. It should be comparable to bhyve passthrough setups where a Host OS driver already attaches. And I know there are guides there for that. but you might ask best on IRC about specifically Virtualbox passthrough. As we have new facilities to achieve such a passthrough. I also remember this issue being solved once before. So you may also want to search the archives. -Till On 07.01.21 11:53, Tony Brian Albers wrote: Hi guys, I'm trying to get my webcam to work in a vbox guest (to use zoom), but even though it seems to be present in the VM, cheese, zoom and qv4l2 only shows a blank screen. The video device is there though. On the host I see: messages:Jan 7 15:46:00 emu usba: [ID 691482 kern.warning] WARNING: /pci@0,0/pci1028,546@14 (xhci0): usb_mid2 cannot be reset due to other applications are using it, please first close these applications, then disconnect and reconnectthe device. In /var/adm/messages. I'm using virtualbox 6.1.16 r140961 with the extension pack of the same version and guest additions. I use the webcam passthrough option under "Devices". The guest is SolydX64 (debian respin) Does anyone have any ideas? I haven't been able to find any info about this specific issue. TIA /tony ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tasks to focus on
On 08.01.21 01:15, Chris wrote: You might also be interested in what Oregon State University is offering (free to opren source && includes IPv6) https://osuosl.org/services/hosting/ That might actually be a good idea simply to have a IPS mirror outside the EU. Thanks for the tip. -Till ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tasks to focus on -- firefox
Am 08.01.21 10:25 schrieb "Joshua M. Clulow" : > > On Thu, 7 Jan 2021 at 23:34, Carsten Grzemba via openindiana-discuss > wrote: > > > >On 07.01.21 23:47, Joshua M. Clulow via openindiana-discuss wrote: > > > >>If you hit any trouble with Rust, I'd love to hear about it! We have > > > >>a good relationship with the Rust project itself, so we should be able > > > >>to get things fixed as they arise, without needing to float additional > > > >>patches. > > I try to build firefox 78esr for openindiana. The problems with Rust are > > much smaller than a while ago. > > I took a spin at building Firefox last year, and while I didn't get a > complete build finished (ran out of time) it was honestly easier to > get master to build than ESR. The main branch usually uses updated > crates, and thus tends to have _better_ support for illumos than the > older ESR branches. > > > But I stopped to use the rustc installed with rustup because this use a > > toolchain naming like x86_64-unknown-illumos. > > > > For that the rustc sources build instruction have to extent for target_os > > "solaris" to target_os "illumos", which is an additional effort. > > > > So I updated the oi-userland build reciept for rust to provide an newer > > version (1.41.1) where the target tripple x86_64-sun-solaris is used. > > So there are no patching of lib.rs and others is necessary. > > Or it is possible with rustup to get the target toolchain > > x86_64-sun-solaris also? > > The old "sun-solaris" targets are not really being maintained by the > illumos community at this point -- either in the Rust toolchain > itself, or in the crates in the Rust ecosystem at large. I would > recommend using the illumos target and getting any build issues fixed > upstream in whatever crates have remaining platform-specific issues. > > I and some other folks have been doing that sort of thing a lot > throughout 2019-2020. Most or all of our patches and testing are for > the illumos target, even if the Solaris targets sometimes also come > along for the ride. > > I think it'd be best if OI ships an illumos target toolchain for Rust, > rather than the increasingly obsolete solaris target. Then we're all > testing and working on the same bits! > > > Cheers. > > -- > Joshua M. Clulow > http://blog.sysmgr.org > Some other findings related buld FF on OI - update ICU, if we want use system ICU - update mozilla-nss, if we want system-nss - update rust - if we use system-sqlite3, in sqlite3 libsqlite-3 2 symbols not exported because these missing in mapfile these all are already in my repository on github - readelf (2.34) of our binutil package is unable to read the libxul.so, readelf (2.33) of Solaris 11.4 can it read. updated readelf (2.35.2) reports less errors but fails also. I deceide to use GCC9 because the trouble to compile with clang was bigger, GCC7 stopped with a suspicouse memory allocation error. Carsten ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Dual screen setup with intel DRM & VESA
Hello everyone. I'm trying to setup an OI installation for my illumos dev tasks. My system has a i7-6700 CPU and RX480 graphics card, with a dual monitor setup. Since there is no AMDGPU driver avaliable for illumos (Correct me if I'm wrong, but https://www.illumos.org/issues/8069 does not seem to have a corresponding kernel module, and I couldn't get that working by simply installing the userland component, I'm assuming there is still no actual support at this moment?), I'm currently using VESA xorg driver, which works fine for me; but since it uses VESA BIOS for display, there is no dual screen support. But I noticed that there is intel DRM support on illumos, and I do have a intel GPU (the integrated GPU in my i7), so I'm thinking: is it possible to utilize both GPU for dual screen support? More specifically, these are what I'm trying to do: a) Use VESA driver for RX480, and connect the primary screen to its HDMI output, which is already working by default, and: b) Enable intel DRM on the integrated GPU, and connect the secondary monitor to the HDMI port provided by my motherboard. a) is working by default now, and enabling intel GPU while keep the AMD GPU working is certainly doable in my BIOS (verified under Linux with xrandr). But I'm not sure how to configure X server on illumos to make it aware of this setup. Therefore, is there anyone have ideas of what configure should I try, or some alternative way to setup dual screen with VESA/intel DRM? Unfortunately there is only one HDMI port on my motherboare, so I don't think connecting both monitor to intel GPU is an option (again, correct me if I'm wrong). Thanks in advance. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tasks to focus on
On Thu, 7 Jan 2021 at 23:34, Carsten Grzemba via openindiana-discuss wrote: > > >On 07.01.21 23:47, Joshua M. Clulow via openindiana-discuss wrote: > > >>If you hit any trouble with Rust, I'd love to hear about it! We have > > >>a good relationship with the Rust project itself, so we should be able > > >>to get things fixed as they arise, without needing to float additional > > >>patches. > I try to build firefox 78esr for openindiana. The problems with Rust are much > smaller than a while ago. I took a spin at building Firefox last year, and while I didn't get a complete build finished (ran out of time) it was honestly easier to get master to build than ESR. The main branch usually uses updated crates, and thus tends to have _better_ support for illumos than the older ESR branches. > But I stopped to use the rustc installed with rustup because this use a > toolchain naming like x86_64-unknown-illumos. > > For that the rustc sources build instruction have to extent for target_os > "solaris" to target_os "illumos", which is an additional effort. > > So I updated the oi-userland build reciept for rust to provide an newer > version (1.41.1) where the target tripple x86_64-sun-solaris is used. > So there are no patching of lib.rs and others is necessary. > Or it is possible with rustup to get the target toolchain x86_64-sun-solaris > also? The old "sun-solaris" targets are not really being maintained by the illumos community at this point -- either in the Rust toolchain itself, or in the crates in the Rust ecosystem at large. I would recommend using the illumos target and getting any build issues fixed upstream in whatever crates have remaining platform-specific issues. I and some other folks have been doing that sort of thing a lot throughout 2019-2020. Most or all of our patches and testing are for the illumos target, even if the Solaris targets sometimes also come along for the ride. I think it'd be best if OI ships an illumos target toolchain for Rust, rather than the increasingly obsolete solaris target. Then we're all testing and working on the same bits! Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Merging OI + OmniOS? (And OpenZFS vs ZFS)
On January 8, 2021 1:27:34 AM UTC, Chris wrote: >On 2021-01-07 13:50, Guenther Alka wrote: >> In the end I do not think in these categories. >> >> A few years ago all my own servers were OpenIndiana and maybe 40% of >my >> users on >> Solaris. Now I am 100% on OmniOS beside a OI evaluation machine (and >miss OI >> features and use cases) and maybe 10% of my users are left on Solaris >with >> OI near >> to not relevant now. >> >> OmniOS and OI are OpenSource. Why not take over this from OmniOS to >keep >> them more in sync? >> On Linux Debian and Ubuntu are big enough to be independent while >very >> similar. On >> Illumos everyone may be too small alone in the long run. >IMHO No that RHEL is in bed with IBM, and as a result; RHEL, and CentOS > >taking >quite a different path. OI is likely to see a greater influx of users. >A >quick >look on the CentOS mailinglists/forums indicates thier userbase is >LIVID >about >the changes. The was not one single positive note about the change. >tl;dr >A lot of CentOS, and as a result, RHEL users; are abandoning ship. >They'll >all >be going *somewhere*. Maybe it's to OI. :-) > >--Chris >> >> Gea >> >>> >>> What you want is to make a OmniOS extra respoitory (git) with GUi >packages. >>> That would factually mean abandoning OI and the Goal of a General >Purpose >>> OS. That would be an acquisition not a merger. >>> >>> -Till >>> >>> ___ >>> openindiana-discuss mailing list >>> openindiana-discuss@openindiana.org >>> https://openindiana.org/mailman/listinfo/openindiana-discuss >> >> ___ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> https://openindiana.org/mailman/listinfo/openindiana-discuss > >___ >openindiana-discuss mailing list >openindiana-discuss@openindiana.org >https://openindiana.org/mailman/listinfo/openindiana-discuss Alas, I'd not be too enthusiastic about people leaving CentOS because of rolling-release model coming to OI because it is the primary model for OI Hipster too (with half-yearly snapshots). Maybe OmniOS LTS would be a better fit for them in fact - but still, if that debacle provides an influx to illumos ecosystem, that's good :) Elsewhere, it was assumed that omnios is "close to" illumos-gate. In fact, it is not, and in a way stages the improvements that take time or have other hiccups to get into the requirements for common upstream codebase changes. There are several facets to this. One is getting those fixes into illumos-gate - that is hard for the same reasons those commits are not upstreamed yet. Another is people who missed features like lx, bhyve, overlays, etc. that are/were absent in OI and present in OO. It might be alleviated by building and installing a gate (and additional packages for features) made from OO codebase. Tribblix has a flavor like that. Such work would probably need some integration effort, but probably is not prohibitively hard. It may oppose current goals of Hipster as a distro made on top of vanilla illumos-gate however, so there is a question of who'd make it and keep it working. Yet another aspect is that build systems and packaging approaches and layout into package publishers (repos) are way too different. It may be possible to emulate one build system by another in terms of making recipes for equivalent result, but scrap that other in case of distro-merging. IMHO from sheer size and integrated magic for dependency checks and build rituals, the oi-userland would survive such merge, but not sure how kindly the OmniOS community and maintainers would take to that. After all, by goal and design OO is a minimal-footprint distro for people who custom-build their application software (with OO style of recipes or somehow else); similar to Gentoo if I were to draw parallels. Initially I was among those who proposed such a merger when OmniTI stepped down, but no longer push for that. Not objected if that "just happens to converge", but forcing that to happen either. As tools with their certain purposes, the distros are too different to easily mash and still meet all existing use-cases. As communities of real people with different goals for their different works and projects, they often share the same pool of talent. And it is nice to have different points of view and ways of solving problems, just like shadow compilations expose different bugs to let us make more robust code. Possibly a facet project where full OI userland builds on top of omnios-gate (plus code for packaged tools of the new features) instead of illumos-gate might solve the practical user woes. IMHO as far as OI is concerned, someone outside maintains some *-gate content and quality, so it should not be too relevant *which* third-party code is used for this or that variant build. Jim -- Typos courtesy of K-9 Mail on my Android
Re: [OpenIndiana-discuss] Virtualbox and USB webcam
Hi Till, Thanks a lot for your reply. Well, it wasn't a kernel driver hogging the device. I could modunload the usbvc driver easily, but when I tried to attach the device in vbox, the kernel loaded the usbvc driver automagically again. But you did actually point me in the right direction, this post helped: https://forums.virtualbox.org/viewtopic.php?t=87398#p475462 ### THE IMPORTANT PART ### It seems that you need to make sure that the USB device goes into a USB port that matches the device's type (USB 2, 3 etc.) and then make sure that your USB controller type configuration of the VM matches the physical port you're trying to pass through. ### END OF THE IMPORTANT PART" So when I attached the webcam to a USB 2.0 port, there was a bit more stuff logged in /var/adm/messages. Then I selected "USB 2.0 (OHCI + EHCI) Controller" in vbox settings(USB for the VM), and suddenly it works! Next challenge is to get the mic working. And since I don't have an external mic that might prove a bit difficult :) And of course my old(ish) PC doesn't have a headset port, but separate headphones/mic ports. /tony On 01/07/21 10:30 PM, Till Wegmueller wrote: > Hey Tony > > That sounds to me like the a kernel driver is attaching to the device > and thus Virtualbox cannot do that anymore. > > There is a blacklisting capability but I have never done that or know > how exactly that works, or if it helps in this situation. > > It should be comparable to bhyve passthrough setups where a Host OS > driver already attaches. And I know there are guides there for that. but > you might ask best on IRC about specifically Virtualbox passthrough. As > we have new facilities to achieve such a passthrough. > > I also remember this issue being solved once before. So you may also > want to search the archives. > > -Till > > On 07.01.21 11:53, Tony Brian Albers wrote: >> Hi guys, >> >> I'm trying to get my webcam to work in a vbox guest (to use zoom), but >> even though it seems to be present in the VM, cheese, zoom and qv4l2 >> only shows a blank screen. The video device is there though. >> >> On the host I see: >> >> messages:Jan 7 15:46:00 emu usba: [ID 691482 kern.warning] WARNING: >> /pci@0,0/pci1028,546@14 (xhci0): usb_mid2 cannot be reset due to other >> applications are using it, please first close these applications, then >> disconnect and reconnectthe device. >> >> In /var/adm/messages. >> >> I'm using virtualbox 6.1.16 r140961 with the extension pack of the same >> version and guest additions. I use the webcam passthrough option under >> "Devices". >> >> The guest is SolydX64 (debian respin) >> >> Does anyone have any ideas? I haven't been able to find any info about >> this specific issue. >> >> TIA >> >> /tony >> >> > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss -- Tony Albers - Systems Architect - IT Development Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
