Your WTFs and frustrations in Void


Then you use compiler flags, like -Werror, which makes gcc handle warnings as errors.


oh, ok. I wasn’t aware of such flag… maybe It can change my mind on gcc atleast. :slight_smile:


@Shampoo See my pull request #12516 :stuck_out_tongue:

(Mitchell) #262

This one took a little bit to figure out, connection refused when trying to sftp from one of my Void Linux boxes to another.

So, I ran sv stop sshd && /usr/bin/sshd -dD to see what was going on. Strange,

debug1: session_input_channel_req: session 0 req subsystem
debug1: subsystem: cannot stat /usr/lib/ssh/sftp-server: No such file or directory
debug1: subsystem: exec() /usr/lib/ssh/sftp-server

So I check the configuration between that of my two Void linux machines, sure enough
the path was different. It looks as if it’s changed to /usr/libexec/sftp-server

This is beyond frustrating to keep having little issues like this.

These are my own personal workstations which I rarely ssh into, infact I don’t even have
ssh set to start by default, let alone have I taken the time to change the config like I would
on a production server.

The next time I run into something non-trivial I’ll probably switch to Artix or Gentoo.


Is an awfully nice init system but I’m sorry the rest of the system is not only lacking polish but it’s downright unusable for anything but a hardcore developer’s workstation and the package manager is absolutely atrocious, specificying a remote repository has different syntax between query and install for instance? What is this madness.


And there was no configuration file ending with .${version}?
xbps doesn’t overwrite config files you you changed them and uses the versioned file instead.


(oliver) #264

I’m not a hardcore developer by any stretch of the imagination and I’ve been running void for on multiple boxes for at least two years.

(Mitchell) #265

On the machine with the problem:

mitch@sager /home/mitch $ ls -la /etc/ssh/ | grep sshd
-rw-r--r--  1 root root   3231 Mar 16 00:01 sshd_config
mitch@sager /home/mitch $

So I was wrong on this one I checked the man pages and both of them use --repository and work as expected.

(Gus Fun) #266

… aaahhhh…!!! :slight_smile:

(R.J.) #267

I requested a package around a month ago, someone made a template in less than a week but it hasen’t been pulled yet.

How long does it take, on average, to add a new package? Should I ask on freenode:#xbps?

(oliver) #268

This doesn’t answer your question but if you’re waiting for it, you can build it yourself pretty easily with xbps-src since you now have the template. Getting the template correct is the tricky part.


:peace_symbol: Merged 12 hours ago :tada:


just got the time to test your package, it seems that there is a dependency that is missing.

(it did however build in xbps-src), but it gets errors when trying to run the “default.lnk” if “imlib2” is not present :wink:

and thanks! :slight_smile:

(Timothy L Miller) #271

My main frustration was the Plasma 5 build. Plasma & Trinity are the only desktops I like to use. So I won’t use something that doesn’t have AT LEAST 1 of them available. Obviously very few OS’s have Trinity since it’s such a small project based on such an old technology, so Plasma for me is usually necessary. And due to the way the Plasma package is built, a lot of things simply don’t work correctly because the default dependencies on systemd functions aren’t fixed. It’s certainly possible to fix (see alien bobs plasma builds for Slackware), but they just aren’t. In the end, there were just too many little things that got annoying with having to work around in Plasma because it was trying to call systemd for everything that I gave up and went back to Debian and Arch as my OS’s of choice.

I will say there was a lot I liked about Void, but not enough to overcome my distaste of having to run a desktop other than Plasma to get a smooth running OS.


@Shampoo imlib2 is a runtime dependency of idesk , so… what are you complaining about?

See the build log for x86_64 and x86_64-musl for instance.

Moreover, if I do:

$ sudo xbps-remove imlib2
imlib2-1.5.1_1 (remove) breaks installed pkg `fluxbox-1.3.7_2'
imlib2-1.5.1_1 (remove) breaks installed pkg `giblib-1.2.4_7'
imlib2-1.5.1_1 (remove) breaks installed pkg `idesk-0.7.5_1'
imlib2-1.5.1_1 (remove) breaks installed pkg `scrot-0.8_6'
imlib2-1.5.1_1 (remove) breaks installed pkg `tint2-16.2_1'
Transaction aborted due to unresolved dependencies.

I have nothing more to say… :neutral_face:

(Gus Fun) #273

When I install void in a usb disk and ask it to install grub on that disk

grub-install /dev/sdb

it installs just fine but messes up the /dev/sda mbr. It doesn’t really install there, it just messes up the one that is there. So I have to go back to that other installation and tell it to

grub-install /dev/sda

Pain in the neck!


yeah, i noticed this afterwords… im not shure of why it wasn’t installed the first time i installed idesk… sorry for hasing you invain. :confused:

(Mitchell) #275

I’ve experienced similar pains with the way Void handles the boot process.

Granted my setup probably isn’t “supported” I can’t imagine too many people run ZFS as the root filesystem.

dracut is a constant pain for me, my issues making it work with ZFS aside, why do I need hostonly=yes and regenerate the image, why doesn’t it let me specifiy a encryption device on the command line!? ( A quick rundown of the scripts leads me to think this is actually possible, but I’m yet to make it work )

I just wish everything about Void was as simple as its init system. Void’s package management system is complex and large in the name of portability, at least from my end-user perspective, whilst distros such as Arch have PKGBUILDs that are simple to create and use on the base system without dragging any more than immediate dependancies. I’m xbps-src it does exactly what the creaters have intended it to do. Maybe it’s just not a good fit for me.

Getting the Nvidia drivers to work on my system was where I had enough of it on my laptop/mobile workstation. Despite having identical configuration to my Arch install for /etc/X11/xorg.conf ( Nvidia Optimus ) and similar files and the nvidia module being loaded I was unable to get any 3d acceleration under X. Strange enough, if I run the Void kernel under Arch or vise versa the state of the issue stays the same. Perhaps there’s something simple I’m missing here that someone knows about?

Either way I’ll probably keep Void on my chromebook because my requirements are simple and I have to compile a custom kernel for it anyway.

Having used FreeBSD extensively, what about taking some thoughts from their boot process to simplify that of Void’s? Maybe use syslinux, or syslinux+rEFInd by default, with a basic config, and basic boot/partition code and EFI filesystem images supplied in /boot?

For instance, to set up FreeBSD to boot on both BIOS and EFI systems, provided the partitions are in place it’s as simple as:

gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0
dd if=/boot/boot1.efifat of=/dev/ada0p2

I don’t see why this would be too hard to implement, it’s trivial to create a filesystem image with the proper EFI/boot/bootx64.efi file and place it in /boot Although a package to handle all of this might be a little bit more complex it’s much less complex overall when compared to something like GRUB.

The whole reason I liked Void in the first place is because some familiarity and functionality was traded for simplicity of implimentation, specifically with the runit init system, which I’ve found to be absolutely spectacular by the way!

Anyway, it’s just a thought for anyone reading.

(Edmond Dantes ) #276

Well Linux bootloaders work the same regardless of the distro: if you think about it, most distros do not develop much software on their own aside from package manager, everything else is 3rd party and further work essentially involves porting that same 3rd party stuff to that package manager; as a consequence distros following a comparable software-update schedule are almost equal, and Void example is rather a standard and less-prone to glitches one, since it uses a vanilla Linux kernel and a practically standard dracut-gnerated initramfs (obviously with systemd module omitted). The init is not implied in this, so the same problems experienced in Void should have been experienced on Arch, Fedora Rawhide, OpenSuSE Tumbleweed, Gentoo Unstable and what else. Personally I’ve used LILO, Grub and SysLinux so far on Void and never experienced a single booting issue.

Hi, indeed I’ve seen many, more than you’d expect: seems that OpenZFS is becoming everyday a more stable thing on Linux (pity, one more reason for Linuxists to say FreeBSD/illumos are nothing-worth), though zpool and zfs executable still lack all the features Illumos/FreeBSD provide. However, I’ve come to try ZFS only recently, after having bought a powerful desktop: despite being an awesome (perhapds the best new-gen, alongside APFS) FS, ZFS is avid on RAM and CPU and rather slows down limited-specs hardware. In particular I don’t see any reason in ZFS on non-amd64 PCs (I’ve seen people using it on i386 :face_with_raised_eyebrow: ) while under 4Gb RAM it looses part of its features and requires one to tune loader/sysctl values in order to make it stable.

Anyway, Linux community had its own new-gen FSs and strangely felt the need to port ZFS, instead of making those new FS more stable: Reiser4 looked very promising to me (and benchs confirmed my impressions), but Linux foundation and the various Linux-related projects (including bootloaders) seem to have no interest in investing resources on it (wondering why). Btrfs? used it for a while, a true mess…XFS for life

You don’t, usually it’s convenient, as it occupies less space and loads only what’s needed ( a host-only initramfs will most likely successfully bring the boot process to the login prompt only on the computer it’s been generated on). For example my host-only initramfs generated for my minimal zen-kernel occupies only ~9.1 MB; but nobody forces you to do so, and as far as I know, there’s no particular reason for a host-only image in Void. By the way, dracut is what most distros use nowadays, and in my opinion is probably the best.

why not? isn’t your kernel_cmdline dracut entry being applied? That’s very strange, perhaps needs some more attention and a dedicated thread; if you instead are wondering about how append kernel params to your about-to-generate initramfs, then you should edit either the dracut.conf file or touching an ad-hoc .conf file under/usr/lib/dracut/dracut.conf.d, specifying the kernel_cmdline=''.." param, as described inside dracut.conf(8). For example, you could use something like:

echo kernel_cmdline=\" root=/dev/mapper/<pool_name>-root cryptdevice=/dev/<partition1>:root cryptkey=/dev/<partition2>:<fstype>:<path> rd.luks=1 rd.luks.uuid=<UUID> \" > /usr/lib/dracut/dracut.conf.d/crypt.conf

Is GLX Xorg module loaded? /usr/lib/xorg/modules/extensions/ should be symlinked to some nvidia lib under /usr/include which come with the binary driver. Try install the glxinfo package and running glxinfo, and look up your Xorg.0.log to see if it’s loaded, or any problem has arisen while launching the X session

That would require changing a lot of things in the Linux boot process. For instances the EFI partittion and the /boot partition coincide on Linux and EFI code is stored there (usually a 500MB FAT32 partition), while on FreeBSD EFI code is stored as boot1.efi (indeed a symlink for ${ESP}/EFI/BOOT/BOOTX64.EFI) to on a non-mounted EFI partition (usually FAT12 200MB partition), while the rest of the boostrap code (stage 2: boot2 which provides the bootloader UI, stage3: the loader.efi, and kernel) is stored under /boot, which can be a folder of the root partition, or a partition on its own. Like you said, on FreeBSD an image of the ESP is stored under /boot as boot1.efifat, which de facto provides the stage1 without actually invoking or mounting the ESP (only read once by the UEFI firmware at boot), but this doesn’t change the fact that booting from UEFi and booting from BIOS remain two different and probably incompatible things.

I think you have some confusion here, the correct command on UEFI should have been in fact:

gpart bootcode -p /boot/boot1.efi -i 1 ada0

which embeds the boostrap code to the first sector of the GPT disk where the created ESP resides.

it’s true that, unlike Linux, FreeBSD doesn’t have any problem booting a GPT disk from BIOS, but BIOS stays Bios and UEFI UEFI: the gptboot (or gptzfsboot if root is on a freebsd-zfs partition) boostrap code you addressed, only functions as stage1 on BIOS-based computers (or CSM) with UFS root on a GPT labelled disk, see gptboot(8). It requires a freebsd-boot partition mounted under /boot, as described in gpart(8), #BOOTSTRAPPING section. gptboot calls loader, which in turn loads the kernel. freebsd-boot partition and gptboot are a typical GPT-on-BIOS thing: on UEFI a efi non mounted partition is typically followed by a freebsd-ufs partition, a freebsd BSD label, or a ZFS pool.

(Mitchell) #277

AFAIK Ubuntu, Debian, do not use dracut. They use initramfs-tools instead. Arch is also quite popular, and uses mkinitcpio. I guess it depends on how “most” is defined. Many more people use Ubuntu than Fedora, Arch, Debian, Void, Gentoo, etc.

Is there a quick way to drop to the shell from dracut? Why does it always leave me hanging for minutes at a time if there’s a problem with configuration? That I do not understand, nor have I taken the time to look at it indepth.

I spent some time messing with that very thing last night, glxinfo returned:

Xlib: extension "GLX" missing on display ":0".


mitch@sager /mnt/void $ ls -l /mnt/void/usr/lib/xorg/modules/extensions/
total 4210
lrwxrwxrwx 1 root root       16 Feb 21 16:30 ->*
-rwxr-xr-x 1 root root 14008936 Feb 21 16:30*
-rwxr-xr-x 1 root root   285896 Mar  5 09:24*
-rwxr-xr-x 1 root root   584384 Mar 15 07:10*


[  1297.655] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)

Modules exist and packages are installed

root@sager / $ xbps-query -l | grep nvidia
ii linux-firmware-nvidia-20180222_1          Binary firmware blobs for the Linux kernel NVIDIA GPU microcode
ii nvidia-390.25_1                           NVIDIA drivers for linux (long-lived series) - Libraries and Utilities
ii nvidia-dkms-390.25_1                      NVIDIA drivers for linux (long-lived series) - DKMS kernel module
ii nvidia-gtklibs-390.25_1                   NVIDIA drivers for linux (long-lived series) - GTK+ libraries
ii nvidia-libs-390.25_1                      NVIDIA drivers for linux (long-lived series) - common libraries
ii nvidia-opencl-390.25_1                    NVIDIA drivers for linux (long-lived series) - OpenCL implementation
root@sager / $ find /usr/lib/modules/4.14.26_1 -iname 'nvidia*'
root@sager / $

You should use boot1.efifat Otherwise they should both work, from FreeBSD’s uefi(8) man page:

               msdosfs(5) FAT file system image containing boot1.efi for
               use by bsdinstall(8) and the bootcode argument to gpart(8).

For example here’s the partition table as generated by bsdinstall

root@test:~ # gpart show
=>      40  20971440  vtbd0  GPT  (10G)
        40    409600      1  efi  (200M)
    409640      1024      2  freebsd-boot  (512K)
    410664       984         - free -  (492K)
    411648   4194304      3  freebsd-swap  (2.0G)
   4605952  16363520      4  freebsd-zfs  (7.8G)
  20969472      2008         - free -  (1.0M)

I could plug say a flash drive formatted in this manner into a machine capable of BIOS boot only and it’d start, I can plug it in my UEFI only chromebook and it’d start.

I’m not sure where that idea came from, I’ve been able to bios boot Linux from GPT formatted disks for years.

I’m also well aware of how the FreeBSD boot process is different from that of Linux’s, I was only offering a suggestion as to how we could simplify it from my experience with FreeBSD. :slight_smile:

(Edmond Dantes ) #278

Well, if you consider Gentoo, Void, RHEL, CentOS, OpenSuSE, Fedora, Solus, Sabayon (as well many Slackware users slowly preferring it to mkinitrd). On Debian it’s available since 9,Squeeze so, all things considered, it’s become quite popular. But probalby yes, you’re right, ‘most’ is too hyperbolic

Yes, you can use a couple of kernel params (see dracut.cmdline(7)):

  • will drop you dracut shell if mount_root fails

  • rd.break=[cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup] drops to dracut shell at defined breakpoint. Currently supported breakpoints can be listed with egrep 'rd.?break' /usr/lib/dracut/modules.d/99base/

Indeed this hanging isn’t normal and definitely merits attention. Again, see the dracut.cdmline in order to enhance its verbosity, and try to raise kernel’s loglevel too in your kernel command line

mmm, I’d try to force reinstall nvidia-libs, and make sure nouveau is blacklisted. Perhaps you’ve already done this, but make sure lspci -vk | grep nouveau and lsmod | grep nouveau (although a ‘bad’ virtual console resolution would already confirm nouveau is blacklisted). Also, try re-examining the Xorg.log, greping NOUVEAU, to confirm it’s not trying to load it instead. Make sure xf86-video-nouveo and xf86-video-modesetting are not installed, and that no xorg configuration file (like /usr/share/X11/xorg.conf.d/20-nouveau.conf) pointing to nouveau is present. Finally, try to install the nvidia-xconfig package and generate a xorg.conf file :wink:

You’re right, mea culpa, that was utterly wrong, I typed wrong while writin in haste; anyway boot1.efifat is absolutely the correct boostrap code (used it 3-4 times, so can confirm). Also, see UEFI on freebsd wiki

That’s because it has both the efi partition and the freebsd-boot partition; probably if looked under /boot, you’d find both boot1.efifat and gtpzsfboot, as well as loader.efi and zfsloader. This is like a more elegant way of installing a bootloader twice in Linux, one for BIOS and one for UEFI, repsectively on root and on ESP (which should work on Linux, I think distros installer ISO do it already), and to me sounds quite redundant.
Anyway, I’ve never used bsdinstall since UEFI went out, rahter I grew accostumed to manual CLI install: didn’t expect this to be a default setup and that’s quite interesting; probaly is the best, gonna try to implemnt somethign similar next time I install FreeBSD :slight_smile:

mmm, some years have passed since I tried (on a 32-bit UEFI machine, unsupported by Linux, which allowed lgacy boot) but I remember documentation discouraging it, as being quite unreliable, and I disn’t succeed trying with LILO

Fair, I think the way I replied sounded rude, so I apologize. To be honest I like your suggestion a lot, and whish it could be a reality, but I think it’s nowhere close to be ever taken into consideration, considering the spread of UEFI only machines, and hardcoded firmware, as well as the lack of interest by community in general and bootloader projects (which now have practically narrowed around bloated rEFInd and GRUB; hope SysLinux will improve its UEFI support any time soon). Perhaps what you were talking about coudl be realized with Coreboot/libreboot+ either a Bios-emulating or EFI-emulating Payload (ex. a system that boots either on Seabios or tianoCore)