Disabling SELinux (temporarily) with the following command (as root):
echo 0 > /sys/fs/selinux/enforce
it works for me.
My system: Linux fedora 6.0.12-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 16:58:47 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Ah and I'm using Podman and not Docker.
Not a great solution, but it could be a starting point to get a better solution.
@grimaldello commented on GitHub (Dec 11, 2022):
Disabling SELinux (temporarily) with the following command (as root):
`echo 0 > /sys/fs/selinux/enforce`
it works for me.
My system: `Linux fedora 6.0.12-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 16:58:47 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux`
Ah and I'm using Podman and not Docker.
Not a great solution, but it could be a starting point to get a better solution.
Just a note that @grimaldello’s solution didn’t work for me on Fedora Silverblue 37 (using podman). Still getting the same error as in the error report…
…
ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5703:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM default
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
even though
getenforce
Disabled
System details:
OS: Fedora Linux 37.20221222.0 (Silverblue) x86_64
Host: Gigabyte Technology Co., Ltd. B550I AORUS PRO AX
Kernel: 6.0.14-300.fc37.x86_64
Uptime: 12 mins
Packages: 1517 (rpm), 104 (flatpak)
Shell: fish 3.5.1
Resolution: 3840x2160
DE: GNOME 43.2 (Wayland)
WM: Mutter
WM Theme: Adwaita
Theme: Adwaita [GTK2/3]
Icons: Adwaita [GTK2/3]
Terminal: BlackBox
CPU: AMD Ryzen 7 5700G with Radeon Graphics (16) @ 4.673GHz
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series
Memory: 3882MiB / 63644MiB
@aral commented on GitHub (Dec 23, 2022):
Just a note that @grimaldello’s solution didn’t work for me on Fedora Silverblue 37 (using podman). Still getting the same error as in the error report…
```
…
ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5703:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM default
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
```
even though
```
getenforce
Disabled
```
System details:
```
OS: Fedora Linux 37.20221222.0 (Silverblue) x86_64
Host: Gigabyte Technology Co., Ltd. B550I AORUS PRO AX
Kernel: 6.0.14-300.fc37.x86_64
Uptime: 12 mins
Packages: 1517 (rpm), 104 (flatpak)
Shell: fish 3.5.1
Resolution: 3840x2160
DE: GNOME 43.2 (Wayland)
WM: Mutter
WM Theme: Adwaita
Theme: Adwaita [GTK2/3]
Icons: Adwaita [GTK2/3]
Terminal: BlackBox
CPU: AMD Ryzen 7 5700G with Radeon Graphics (16) @ 4.673GHz
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series
Memory: 3882MiB / 63644MiB
```
Right now I am installing Monterey, and I had the same error as you guys but adding --privileged after run in the command solved the issue. Fedora 37, Mate Desktop here, HP Z420, Intel Xeon E-1620, 40 Gb ECC RAM, AMD Radeon RX570 4 Gb GPU, Samsung EVO 500 Gb SSD, AOC 32" 2K monitor.
@crojack commented on GitHub (Dec 24, 2022):
Add
--privileged
after run. That will fix it.
The command should be:
sudo docker run --privileged -it \
--device /dev/kvm \
-p 50922:10022 \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-e "DISPLAY=${DISPLAY:-:0.0}" \
-e GENERATE_UNIQUE=true \
-e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \
sickcodes/docker-osx:monterey
Right now I am installing Monterey, and I had the same error as you guys but adding --privileged after run in the command solved the issue. Fedora 37, Mate Desktop here, HP Z420, Intel Xeon E-1620, 40 Gb ECC RAM, AMD Radeon RX570 4 Gb GPU, Samsung EVO 500 Gb SSD, AOC 32" 2K monitor.
+ exec qemu-system-x86_64 -m 4000 -cpu Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check, -machine q35,accel=kvm:tcg -smp 4,cores=4 -usb -device usb-kbd -device usb-tablet -device 'isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc' -drive if=pflash,format=raw,readonly=on,file=/home/arch/OSX-KVM/OVMF_CODE.fd -drive if=pflash,format=raw,file=/home/arch/OSX-KVM/OVMF_VARS-1024x768.fd -smbios type=2 -audiodev alsa,id=hda -device ich9-intel-hda -device hda-duplex,audiodev=hda -device ich9-ahci,id=sata -drive id=OpenCoreBoot,if=none,snapshot=on,format=qcow2,file=/home/arch/OSX-KVM/OpenCore/OpenCore.qcow2 -device ide-hd,bus=sata.2,drive=OpenCoreBoot -device ide-hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=/home/arch/OSX-KVM/BaseSystem.img,format=qcow2 -drive id=MacHDD,if=none,file=/home/arch/OSX-KVM/mac_hdd_ng.img,format=qcow2 -device ide-hd,bus=sata.4,drive=MacHDD -netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::5900-:5900, -device vmxnet3,netdev=net0,id=net0,mac=52:54:00:09:49:17 -monitor stdio -boot menu=on -vga vmware
Authorization required, but no authorization protocol specified
QEMU 7.1.0 monitor - type 'help' for more information
(qemu) ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `dac'
ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
Update: The very first issue I see in the output is a warning that might be relevant (since Fedora Silverblue is an immutable distribution):
supermin: warning: /usr/bin/augenrules: Permission denied (ignored)
Some distro files are not public readable, so supermin cannot copy them
into the appliance. This is a problem with your Linux distro. Please ask
your distro to stop doing pointless security by obscurity.
You can ignore these warnings. You *do not* need to use sudo.
supermin: warning: /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Permission denied (ignored)
supermin: warning: /usr/lib/ssh/ssh-keysign: Permission denied (ignored)
supermin: warning: /usr/share/factory/etc/crypttab: Permission denied (ignored)
supermin: warning: /usr/share/factory/etc/gshadow: Permission denied (ignored)
@aral commented on GitHub (Dec 24, 2022):
@crojack Thanks, but on Fedora Silverblue 37 with podman, at least, when I run:
```
sudo podman run --privileged -it \
--device /dev/kvm \
-p 50922:10022 \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-e "DISPLAY=${DISPLAY:-:0.0}" \
-e GENERATE_UNIQUE=true \
-e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' \
sickcodes/docker-osx:ventura
```
It still errors with:
```
+ exec qemu-system-x86_64 -m 4000 -cpu Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check, -machine q35,accel=kvm:tcg -smp 4,cores=4 -usb -device usb-kbd -device usb-tablet -device 'isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc' -drive if=pflash,format=raw,readonly=on,file=/home/arch/OSX-KVM/OVMF_CODE.fd -drive if=pflash,format=raw,file=/home/arch/OSX-KVM/OVMF_VARS-1024x768.fd -smbios type=2 -audiodev alsa,id=hda -device ich9-intel-hda -device hda-duplex,audiodev=hda -device ich9-ahci,id=sata -drive id=OpenCoreBoot,if=none,snapshot=on,format=qcow2,file=/home/arch/OSX-KVM/OpenCore/OpenCore.qcow2 -device ide-hd,bus=sata.2,drive=OpenCoreBoot -device ide-hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=/home/arch/OSX-KVM/BaseSystem.img,format=qcow2 -drive id=MacHDD,if=none,file=/home/arch/OSX-KVM/mac_hdd_ng.img,format=qcow2 -device ide-hd,bus=sata.4,drive=MacHDD -netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::5900-:5900, -device vmxnet3,netdev=net0,id=net0,mac=52:54:00:09:49:17 -monitor stdio -boot menu=on -vga vmware
Authorization required, but no authorization protocol specified
QEMU 7.1.0 monitor - type 'help' for more information
(qemu) ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `dac'
ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
```
Update: The very first issue I see in the output is a warning that might be relevant (since Fedora Silverblue is an immutable distribution):
```
supermin: warning: /usr/bin/augenrules: Permission denied (ignored)
Some distro files are not public readable, so supermin cannot copy them
into the appliance. This is a problem with your Linux distro. Please ask
your distro to stop doing pointless security by obscurity.
You can ignore these warnings. You *do not* need to use sudo.
supermin: warning: /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Permission denied (ignored)
supermin: warning: /usr/lib/ssh/ssh-keysign: Permission denied (ignored)
supermin: warning: /usr/share/factory/etc/crypttab: Permission denied (ignored)
supermin: warning: /usr/share/factory/etc/gshadow: Permission denied (ignored)
```
Right now I am installing Monterey, and I had the same error as you guys but adding --privileged after run in the command solved the issue. Fedora 37, Mate Desktop here, HP Z420, Intel Xeon E-1620, 40 Gb ECC RAM, AMD Radeon RX570 4 Gb GPU, Samsung EVO 500 Gb SSD, AOC 32" 2K monitor.
Running all as root is not a solution. Solution would be to identify what needs privileges and think about how to satisfy the need
@bphd commented on GitHub (Jan 15, 2023):
> Add
>
> --privileged
>
> after run. That will fix it.
>
> The command should be:
>
> sudo docker run --privileged -it --device /dev/kvm -p 50922:10022 -v /tmp/.X11-unix:/tmp/.X11-unix -e "DISPLAY=${DISPLAY:-:0.0}" -e GENERATE_UNIQUE=true -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist' sickcodes/docker-osx:monterey
>
> Right now I am installing Monterey, and I had the same error as you guys but adding --privileged after run in the command solved the issue. Fedora 37, Mate Desktop here, HP Z420, Intel Xeon E-1620, 40 Gb ECC RAM, AMD Radeon RX570 4 Gb GPU, Samsung EVO 500 Gb SSD, AOC 32" 2K monitor.
Running all as root is not a solution. Solution would be to identify what needs privileges and think about how to satisfy the need
Linux lenovo 6.1.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 14 Jan 2023 13:09:35 +0000 x86_64 GNU/Linux
@geakstr commented on GitHub (Jan 16, 2023):
Same for me on Arch
```
Linux lenovo 6.1.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 14 Jan 2023 13:09:35 +0000 x86_64 GNU/Linux
```
I was thinking about this project today and the fact that I wait since months to use this solution. But nobody want to come to my issue
@bphd commented on GitHub (Mar 12, 2023):
I was thinking about this project today and the fact that I wait since months to use this solution. But nobody want to come to my issue
Unauthorized System Access: Allowing any host or user to connect to the X server without authentication creates a significant vulnerability. Malicious individuals can exploit this access to gain unauthorized control over your system and execute malicious commands.
Malware Execution: Unrestricted access provides an avenue for the execution of malicious code or malware on your system. This can lead to unauthorized activities, data theft, system damage, or the spread of malware to other connected systems.
Data Breaches: Uncontrolled access to the X server exposes sensitive information displayed by X applications. This includes personal data, confidential business information, and any other data processed or displayed through graphical interfaces. Unauthorized data access can result in reputational damage, legal consequences, and financial losses.
To mitigate these security risks, follow these best practices for X server access control:
Identify and Whitelist Trusted Hosts: Take the time to identify the specific hosts that require access to your X server. Consider the purpose and requirements of each host in your network. This could include trusted workstations, servers, or other devices that need to run X applications or access the graphical interface. By carefully evaluating and identifying these hosts, you can create a list of authorized entities.
Whitelist Only Authorized Hosts: Once you have identified the trusted hosts, whitelist them by configuring the access control settings of the X server. Use commands such as "xhost +hostname" or "xhost +SI:localuser:username@hostname" to allow only these authorized hosts to connect to the X server. This effectively restricts access to the X server to the specified entities, preventing unauthorized connections.
@bphd commented on GitHub (Jun 28, 2023):
Unauthorized System Access: Allowing any host or user to connect to the X server without authentication creates a significant vulnerability. Malicious individuals can exploit this access to gain unauthorized control over your system and execute malicious commands.
Malware Execution: Unrestricted access provides an avenue for the execution of malicious code or malware on your system. This can lead to unauthorized activities, data theft, system damage, or the spread of malware to other connected systems.
Data Breaches: Uncontrolled access to the X server exposes sensitive information displayed by X applications. This includes personal data, confidential business information, and any other data processed or displayed through graphical interfaces. Unauthorized data access can result in reputational damage, legal consequences, and financial losses.
To mitigate these security risks, follow these best practices for X server access control:
Identify and Whitelist Trusted Hosts: Take the time to identify the specific hosts that require access to your X server. Consider the purpose and requirements of each host in your network. This could include trusted workstations, servers, or other devices that need to run X applications or access the graphical interface. By carefully evaluating and identifying these hosts, you can create a list of authorized entities.
Whitelist Only Authorized Hosts: Once you have identified the trusted hosts, whitelist them by configuring the access control settings of the X server. Use commands such as "xhost +hostname" or "xhost +SI:localuser:username@hostname" to allow only these authorized hosts to connect to the X server. This effectively restricts access to the X server to the specified entities, preventing unauthorized connections.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ghost on GitHub (Dec 10, 2022).
I'm sure you're tired of these by now!
Terminal output:
Command used:
Uname:
Linux fedora 6.0.11-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Dec 2 20:47:45 UTC 2022 x86_64 x86_64 x86_64 GNU/LinuxNeofetch:
Thanks in advance!
@dancvv commented on GitHub (Dec 11, 2022):
I have the same problem
@grimaldello commented on GitHub (Dec 11, 2022):
Disabling SELinux (temporarily) with the following command (as root):
echo 0 > /sys/fs/selinux/enforceit works for me.
My system:
Linux fedora 6.0.12-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 16:58:47 UTC 2022 x86_64 x86_64 x86_64 GNU/LinuxAh and I'm using Podman and not Docker.
Not a great solution, but it could be a starting point to get a better solution.
@nachovizzo commented on GitHub (Dec 14, 2022):
Same problem here! Ubuntu 22.04
@aral commented on GitHub (Dec 23, 2022):
Just a note that @grimaldello’s solution didn’t work for me on Fedora Silverblue 37 (using podman). Still getting the same error as in the error report…
even though
System details:
@crojack commented on GitHub (Dec 24, 2022):
Add
--privileged
after run. That will fix it.
The command should be:
sudo docker run --privileged -it
--device /dev/kvm
-p 50922:10022
-v /tmp/.X11-unix:/tmp/.X11-unix
-e "DISPLAY=${DISPLAY:-:0.0}"
-e GENERATE_UNIQUE=true
-e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist'
sickcodes/docker-osx:monterey
Right now I am installing Monterey, and I had the same error as you guys but adding --privileged after run in the command solved the issue. Fedora 37, Mate Desktop here, HP Z420, Intel Xeon E-1620, 40 Gb ECC RAM, AMD Radeon RX570 4 Gb GPU, Samsung EVO 500 Gb SSD, AOC 32" 2K monitor.
@aral commented on GitHub (Dec 24, 2022):
@crojack Thanks, but on Fedora Silverblue 37 with podman, at least, when I run:
It still errors with:
Update: The very first issue I see in the output is a warning that might be relevant (since Fedora Silverblue is an immutable distribution):
@aral commented on GitHub (Dec 24, 2022):
I’m able to get the QEMU window to launch on Fedora Silverblue 37 with
When I’ve also set permissions with:
But the initial launch still fails.
@liukliukliuk commented on GitHub (Jan 11, 2023):
same here with fedora 37
@bphd commented on GitHub (Jan 15, 2023):
Running all as root is not a solution. Solution would be to identify what needs privileges and think about how to satisfy the need
@geakstr commented on GitHub (Jan 16, 2023):
Same for me on Arch
@pfcdx commented on GitHub (Mar 12, 2023):
Same on Arch.
@bphd commented on GitHub (Mar 12, 2023):
I was thinking about this project today and the fact that I wait since months to use this solution. But nobody want to come to my issue
@elijah629 commented on GitHub (Jun 27, 2023):
Did anyone try?
xhost +@bphd commented on GitHub (Jun 28, 2023):
To mitigate these security risks, follow these best practices for X server access control:
Identify and Whitelist Trusted Hosts: Take the time to identify the specific hosts that require access to your X server. Consider the purpose and requirements of each host in your network. This could include trusted workstations, servers, or other devices that need to run X applications or access the graphical interface. By carefully evaluating and identifying these hosts, you can create a list of authorized entities.
Whitelist Only Authorized Hosts: Once you have identified the trusted hosts, whitelist them by configuring the access control settings of the X server. Use commands such as "xhost +hostname" or "xhost +SI:localuser:username@hostname" to allow only these authorized hosts to connect to the X server. This effectively restricts access to the X server to the specified entities, preventing unauthorized connections.