[arch-general] virtualbox-host-dkms
Hi :)
dkms can't rebuild deleted vbox modules for the linux kernel
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
Module vboxhost/4.2.8 already installed on kernel 3.7.10-1-ARCH/x86_64
# ls /usr/lib/modules/extramodules-3.7-ARCH/
version
and for linux-rt I get the same error
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
Module vboxhost/4.2.8 already installed on kernel 3.6.11-rt30-1-rt/x86_64
but there never were modules installed for the kernel-rt.
Regards,
Ralf
Re: [arch-general] virtualbox-host-dkms
On Fri, 2013-03-08 at 13:34 +0100, Ralf Mardorf wrote:
Hi :)
dkms can't rebuild deleted vbox modules for the linux kernel
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
Module vboxhost/4.2.8 already installed on kernel 3.7.10-1-ARCH/x86_64
# ls /usr/lib/modules/extramodules-3.7-ARCH/
version
and for linux-rt I get the same error
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
Module vboxhost/4.2.8 already installed on kernel 3.6.11-rt30-1-rt/x86_64
but there never were modules installed for the kernel-rt.
Regards,
Ralf
Try 'dkms remove vboxhost/4.2.8 --all' and attempt to build again ('dkms
autoinstall' should do the trick for this).
--
Maxime
signature.asc
Description: This is a digitally signed message part
Re: [arch-general] virtualbox-host-dkms
On Fri, 2013-03-08 at 13:34 +0100, Ralf Mardorf wrote:
Hi :)
dkms can't rebuild deleted vbox modules for the linux kernel
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
Module vboxhost/4.2.8 already installed on kernel 3.7.10-1-ARCH/x86_64
# ls /usr/lib/modules/extramodules-3.7-ARCH/
version
and for linux-rt I get the same error
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
Module vboxhost/4.2.8 already installed on kernel 3.6.11-rt30-1-rt/x86_64
but there never were modules installed for the kernel-rt.
Regards,
Ralf
Also, modules are not in extramodules anymore, they are in
'/usr/lib/modules/your kernel/kernel/misc/' now.
--
Maxime
signature.asc
Description: This is a digitally signed message part
Re: [arch-general] [wpa_actiond 1.4] slow disconnects
On Wed, 06 Mar 2013 19:19:16 +0100 Thomas Bächler tho...@archlinux.org wrote: Am 05.03.2013 16:44, schrieb Pali Rohár: Hello, On Tuesday 05 March 2013 10:23:24 Thomas Bächler wrote: Am 04.03.2013 21:26, schrieb Leonid Isaev: Hi, With testing/wpa_actiond-1.4 I am having a minor problem when shutting down net-auto-wireless.service: 'systemctl stop net-auto-wireless.service' pauses for ~10sec before finally disconnecting. Of course, this also occurs on normal system poweroff (which is usually ~5sec). The wifi network is WPA enterprise (important entries in wpa_supplicant.conf: key_mgmt=WPA-EAP; eap=PEAP; phase1=peaplabel=0; phase2=auth=MSCHAPV2), and piece of daemon.log after the above delay has elapsed: I've seen this too, but I didn't determine yet that is was wpa_actiond's fault. There are several issues here: 1) I am unsure what exactly terminates wpa_actiond. Before my patches wpa_actiond could be terminated only by KILL/TERM signals or correct terminate event from wpa_supplicant. wpa_supplicant sending terminate event only if wpa_supplcant is stopped regulary (when wpa_supplicant is killed by KILL no terminate event is sent!). With my patches wpa_actiond is also terminated when wpa_supplicant is KILLed. 2) net-auto-wireless.service is Type=forking, but has no proper MainPID detected, so systemd doesn't know what exactly to kill. This change however seems to be related to Pali's changed, so I'm CC'ing him to see if he knows what this might be about. You can always stop wpa_actiond with KILL or TERM signals. I did not removed any code which handling stopping wpa_actiond. I only added another check if wpa_actiond should exit. So my patches should not change behaviour of stopping wpa_actiond. Problem is maybe in blackbox which starting and stoppping wpa_actiond. I'm not using that systemd and this is another reason against it. Not easy to understand and debug this problem. I tested my patches on my system without systemd and wpa_actiond working without problem. Really I cannot help you with blackbox which I not using... This may even be related to the way netcfg stops wpa_actiond (it doesn't - it only stops wpa_supplicant). One can probably debug this easily by making wpa_actiond more verbose. Turns out you were right. What probably happens is that wpa_supplicant dies, ctrl sockets in /run/wpa_supplicant disappear and wpa_actiond dies after some timeout (our network has a grid of APs with varying signal strength/capabilities, so delays slightly depended on the AP). If wpa_ctrl part in wpa_actiond is copied from wpa_supplicant/hostapd, this must be a new thing in 2.0. For me, sending a -term signal to wpa_actiond in netctl-auto stop (kill -term $($PIDFILE)) makes stops/restarts almost instantaneous. In any case, one should probably stop wpa_actiond before wpa_supplicant regardless of any possible issues. I'll send an email regarding netctl to arch-projects, but this should also be fixed in netcfg... Thanks, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] UEFI madness
Hi On Fri, Mar 1, 2013 at 10:44 PM, David Benfell benf...@parts-unknown.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, So far, my attempt to install Arch Linux on a UEFI system is a total facepalm moment. The problem is in booting post-install. So, first, does anyone have actual--and successful--experience installing Arch on a UEFI system? Yes, I went to the Arch Wiki, which initially pointed me at GummiBoot. There are actually two sets of instructions, one given where I looked first, for the UEFI entry, and another under the entry for GummiBoot. Neither succeeds, but I wound up following the latter set of instructions (and cleaning up extra entries with efibootmgr, which fortunately makes this relatively easy). GummiBoot says it can't find /vmlinuz-linux. I tried modifying the configuration to say /boot/vmlinuz-linux, but no joy. Apparently, I'm really supposed to copy this file and the initrd image to the EFI partition, but nobody says where in the EFI partition, so I have no idea. I also tried following the instructions for grub-efi. I'm just mystified. I managed to install the right package, but from there I just wasn't understanding a thing. I've been using linux since 1999 so this shouldn't be so completely mystifying. I tried installing rEFInd (from sourceforge). As near as I can tell, it does indeed detect all the possible boot options on the system. But when I try booting the Arch installation, it says it can't find the root partition. It also detects the GummiBoot option, but that leads the same place as before. Finally, it detects the Windows option, which I hope still works (unfortunately I do need this). I guess getting something that just works--like it did with BIOS systems--is not in the cards. What do I do now? I installed Arch on my new home server several days ago and I had similar experience with UEFI that you had. I decided to go with gummiboot as it sounds simpler, and installation instructions [1] are cleaner than for other UEFI bootloaders. efibootmgr did not work for me so I started from copy it to the 'default' location $esp/EFI/boot/bootx64.efi for x86_64 systems. (see [1]). I was hoping that my ASRock H61M/U3S3 will recognize gummiboot bootloader. But no. It shown me cryptic error something No device found. I reformatted UEFI system partition, upgraded motherboard UEFI, but nothing helped. So I renamed gummiboot.efi to $ESP/shellx64.efi and then booted default shell from matherboard UEFI graphical UI. Only then I was able to run efibootmgr and set path to gummiboot binaries. Resume: my motherboard does not recognize $esp/EFI/boot/bootx64.efi as a default shell. I mounted $ESP to /boot, copied kernel there, setup systemd hook for gummiboot binaries and everything works like charm now. Additionally I use multiple-devises btrfs [2] for root fs so I had to add btrfs hook to mkinitcpio.conf. [1] https://wiki.archlinux.org/index.php/Gummiboot [2] https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices PS: UEFI works great with Arch, but some Arch UEFI documentation cleanup is required.
[arch-general] makechrootpkg vs. namcap
Hi, I was building a package using makechrootpkg, and the build was failing because a mandatory dependency was missing. But when I add the dependency, namcap complains that it is not needed. I was wondering how namcap checks dependencies, and what the particular shortcommings are of namcap when detecting dependencies. I was also wondering if there could be a possibility that namcap is right, and that something else goes wrong while doing the chroot-build. I would be grateful if somebody could enlighten me a little in this... Greetings, lieven
Re: [arch-general] virtualbox-host-dkms
Thank you Maxime :)
you solved my problem, resp. there never was a problem.
On Fri, 2013-03-08 at 14:53 +0100, Maxime Gauduin wrote:
Also, modules are not in extramodules anymore, they are in
'/usr/lib/modules/your kernel/kernel/misc/' now.
Indeed in /lib/modules/3.7.10-1-ARCH/kernel/misc/
and /lib/modules/3.6.11-rt30-1-rt/kernel/misc/ there are already the
vbox kernel modules, but I deleted modules in /extramodules, so I guess
I had modules in /misc and /extramodules. This might cause issues, but I
didn't run VBox by Arch until now, I also didn't enable the mkinitcpio
hook until now.
The package virtualbox-host-modules put the modules into /extramodules.
$ pacman -Qi virtualbox
Depends On : virtualbox-host-modules
$ pacman -Ql virtualbox-host-modules
virtualbox-host-modules /usr/lib/modules/extramodules-3.7-ARCH/vboxdrv.ko.gz
virtualbox-host-modules /usr/lib/modules/extramodules-3.7-ARCH/vboxnetadp.ko.gz
virtualbox-host-modules /usr/lib/modules/extramodules-3.7-ARCH/vboxnetflt.ko.gz
virtualbox-host-modules /usr/lib/modules/extramodules-3.7-ARCH/vboxpci.ko.gz
On Fri, 2013-03-08 at 14:48 +0100, Maxime Gauduin wrote:
Try 'dkms remove vboxhost/4.2.8 --all' and attempt to build
again('dkms autoinstall' should do the trick for this).
# dkms remove vboxhost/4.2.8 --all
Removed the modules from /kernel/misc/ :).
# dkms autoinstall
Didn't work.
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
Rebuild the modules. So there never was something broken, I just wasn't aware
that the modules now are in /misc.
Regards,
Ralf
PS: On Ubuntu they are in different places too, I found them in
/run/media/rocketmouse/q/lib/modules/3.6.5-rt14/updates/dkms/
for an installed kernel and in
/run/media/rocketmouse/q/lib/modules/3.5.0-23-generic/misc/
for a kernel that is removed, but they're missing for
/run/media/rocketmouse/q/lib/modules/3.5.0-18-lowlatency
another installed kernel.
Re: [arch-general] virtualbox-host-dkms
On 03/08/13 18:04, Ralf Mardorf wrote:
Hi :)
dkms can't rebuild deleted vbox modules for the linux kernel
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
Module vboxhost/4.2.8 already installed on kernel 3.7.10-1-ARCH/x86_64
# ls /usr/lib/modules/extramodules-3.7-ARCH/
version
and for linux-rt I get the same error
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
Module vboxhost/4.2.8 already installed on kernel 3.6.11-rt30-1-rt/x86_64
but there never were modules installed for the kernel-rt.
Regards,
Ralf
I don't know if this is because of I'm using a custom kernel, but on my
system Virtualbox modules are located under /var/lib/dkms/vboxhost/
In you case they should be:
/var/lib/dkms/vboxhost/4.2.8/3.7.10-1-ARCH/x86_64/module/
or
/var/lib/dkms/vboxhost/4.2.8/3.6.11-rt30-1-rt/x86_64/module/
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] makechrootpkg vs. namcap
Just put the dep in makedepends, namcap only checks for runtime deps, can't detect build dep AFAIK. -- Maxime On Mar 9, 2013 12:28 AM, Lieven Moors lievenmo...@gmail.com wrote: Hi, I was building a package using makechrootpkg, and the build was failing because a mandatory dependency was missing. But when I add the dependency, namcap complains that it is not needed. I was wondering how namcap checks dependencies, and what the particular shortcommings are of namcap when detecting dependencies. I was also wondering if there could be a possibility that namcap is right, and that something else goes wrong while doing the chroot-build. I would be grateful if somebody could enlighten me a little in this... Greetings, lieven
Re: [arch-general] makechrootpkg vs. namcap
On Mar 9, 2013 1:16 AM, Maxime GAUDUIN aluc...@gmail.com wrote: Just put the dep in makedepends, namcap only checks for runtime deps, can't detect build dep AFAIK. -- Maxime On Mar 9, 2013 12:28 AM, Lieven Moors lievenmo...@gmail.com wrote: Hi, I was building a package using makechrootpkg, and the build was failing because a mandatory dependency was missing. But when I add the dependency, namcap complains that it is not needed. I was wondering how namcap checks dependencies, and what the particular shortcommings are of namcap when detecting dependencies. I was also wondering if there could be a possibility that namcap is right, and that something else goes wrong while doing the chroot-build. I would be grateful if somebody could enlighten me a little in this... Greetings, lieven Sorry I answered above, still getting used to android :P -- Maxime
[arch-general] Virtualbox guest additions on custom kernel
Hello all, I compiled my own custom kernel on a virtual machine and then I need to provide at my system the additions in order to have a compelete system. I tried to follow the https://wiki.archlinux.org/index.php/VirtualBox#Install_the_Guest_Additions but I catch an error on # modprobe -a vboxguest vboxsf vboxvideo FATAL: module vboxdrv not found And under /lib/modules/mykernel/ or /lib/modules/extra-mykernel I can't find the modules, do I compile by hands the module, any suggestions ? Hope this is the right place where ask, thanks in advance, Pietro
Re: [arch-general] Virtualbox guest additions on custom kernel
I suspect you're missing an optional dependency.
$ pacman -Si virtualbox-guest-utils | grep non-stock
Optional Deps : virtualbox-guest-dkms: Guest kernel source modules for
non-stock kernels
It's likely that it will work as it does work for the host,
https://wiki.archlinux.org/index.php/VirtualBox#Hosts_running_a_custom_kernel ,
IOW I guess you need to install virtualbox-guest-dkms, then run
# dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed
's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
and after that to load the modules.
[arch-general] Realtek wifi won't come up
Hey everyone, I'm trying to install Arch. The first time I tried installing everything worked fine, even the wifi, which usually doesn't work with linux. However, my laptop battery died in the middle of downloading packages because I was careless and hadn't plugged it in. Now, when I enter ip link set wlp2s0f0 up, it doesn't set the interface up. Strangely, when I reboot, the interface is renamed to wlan0 (that's what it was when the wifi worked), even though the wiki says it shouldn't. Running modprobe -r rtl8192ce modprobe rtl8192ce changes the interface name to wlp2s0f0. ip link gives me (besides the lo interface) 3: wlp2s0f0: BROADCAST, MULTICAST mtu 1500 qdisc nook state DOWN mode DEFAULT qlen 1000 link/ether 00:e0:4c:81:92:53 brd ff:ff:ff:ff:ff:ff Before, it gave me: 2: wlan0: NO-CARRIER, BROADCAST, MULTICAST, UP mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000 link/ether 24:ec:99:4c:60:1f brd ff:ff:ff:ff:ff:ff What else can I try? Lspci and dmesg show that the firmware has been loaded and that the card has been recognized. Thanks! Josh
