grub-x86_64-efi still appears to be installed despite choosing to manage the bootloader independently.

adding the package dialog using the -p option with mklive.sh doesn't actually install dialog on the live image, wtf?

x86_64-efi musl

There's a bit of a problem with one of the file system setup dialogs in void-installer, namely that said dialog doesn't reflect the user's choice of file system for a given partition. I took some pictures to document the problem when I installed Void on a laptop recently and created a little photo story for your information. Note that the ext3 file system the installer does detect on /dev/sda1 existed on that partition before void-installer was run.

Initial state.

Selecting /dev/sda2 for setup.

Choosing to use that as swap space.

Letting the installer create a new swap space on /dev/sda2.

Newly created swap space on /dev/sda2 not recognized by the installer. Moving on to /dev/sda3.

Choosing to use that as an ext3 file system.

Setting the mount point.

Letting the installer create a new ext3 file system on /dev/sda3.

Newly created ext3 file system on /dev/sda3 not recognized by the installer.

Finding out the installer was acting dumb before and actually recognizes the file systems on those partitions.

Hello void folks,

Sorry if this is not a good area for issue discussion but I would still like to file it, if it is ok.

We can download voidlinux here:

https://voidlinux.org/download/

We have flavours such as:

Enlightenment
Cinnamon
LXDE
LXQT
MATE
XFCE

I would like to have a fat dvd, that is, a large .iso that I could just batch-install. If anyone knows the DVD of slackware, that is exactly what I would love to have. I don't care if parts of it become outdated and it does not have to be maintained a lot, e. g. one release of that per year would be perfectly fine, based on the other flavours.

Why would I want a fat DVD? Mostly due to convenience. I don't like post-installation routines that take long; I'd really love to just install what is useful and come back to the computer when this is all done. Saves me lots of time and problems lateron.

I am not sure how much work this would be; ideally the existing flavours could just be combined as-is, but I am not sure how simple that is. I guess the more important question here is whether voidlinux would even want to offer a big DVD but I'd think it would be for extra flexibility, for those who'd like it. On distrowatch, if you look around, most releases are quite large by now - voidlinux on the other hand does not have a large .iso right now.

Thank you for reading - feel free to close this issue at any moment in time.

This issue tracks progress towards a usable voidlinux image for the Pinebook Pro. Currently, we can already build a working image

• packaging
  • pinebookpro-kernel (void-linux/void-packages#19293)
  • pinebookpro-uboot (void-linux/void-packages#19196)
  • pinebookpro-base (void-linux/void-packages#19216)
  • pinebookpro-firmware (void-linux/void-packages#19197)
• add support to scripts in this repo (#109)
  • set_target_arch_from_platform in lib.sh.in
  • mkplatformfs
  • mkimage
• fix broken things in the scripts here
  • make sure /tmp is mounted correctly (#110)
  • fix post-install scripts on cross builds (#111)
• Images available on https://alpha.de.repo.voidlinux.org/live/

How to read the list: A checked box means that the work is done and merged, an unchecked box with a PR linked means that this is basically done, but not merged yet.

On line 353 of file mklive.sh.in you have this bashism:

[ -n "${INCLUDE_DIRECTORY}" ] && ((STEP_COUNT=STEP_COUNT+1))

Since shebang line states this script gets executed by /bin/sh, that math simply doesn't happen. Just change the line to this:

[ -n "${INCLUDE_DIRECTORY}" ] && STEP_COUNT=10

The docker images for the masterdirs used by travis are stale and updating the bootstrap causes a couple thousand lines of error messages, making it really a pain to read people's error logs. I made new images myself to test them and they worked fine at first glance.

Just to share my testing, I made 3 new images with the following method (and the patch from the PR to let alpine talk to our mirrors):

docker build --build-arg BASEPKG=base-chroot --build-arg ARCH=x86_64-musl .

And tested them on a branch on my repo:
https://travis-ci.org/bobertlo/void-packages/builds/601895748

Many people use gptfdisk when reparing or installing a Void Linux Installation. It is important that basic tools like these provided in gptfdisk, should be included in the base Live CD.

Pretty typical invocation led to an unusable install iso:

./mklive.sh -a x86_64-musl -l C -o ../install-wifi.iso -p "lvm2 cryptsetup wifi-firmware"

The function set_useraccount() in installer.sh.in presumes at least one group.

Currently when trying to boot the Live ISO components from an http/https endpoint you get back :

dracut: FATAL: Don't know how to handle 'root=live:http........

Basic /etc/dracut.conf to add this: (on top of your hooks)

add_dracutmodules+="dmsquash-live livenet nfs network base"
show_modules=yes
hostonly="no"

This is a stock module:
https://github.com/dracutdevs/dracut/tree/master/modules.d/90livenet

To also provide ssl support the host would need ca-certificates installed.

I am currently working through live distros to include in https://netboot.xyz/ menus.
Normally I would generate the vmlinuz/initrd combo in Docker, and maybe you could help me there. Due to the rolling nature of the distro I am not capable (I think) of installing the precise kernel version used in the already built Live CDs.

I am OK with maintaining a fork of the initrd/vmlinuz stuff, just figured I would ping you to see if this is something that could be added by default.

Just downloaded one of the new ISOs released in:
https://vm1.a-lej-de.m.voidlinux.org/live/20180921/

Unfortunately, we are victims of this nasty bug:
https://www.mail-archive.com/[email protected]/msg1629323.html

😠 can't boot from USB.

# lspci |grep USB
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)

# lsusb
Bus 002 Device 003: ID 0408:03f1 Quanta Computer, Inc. 
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsmod |grep ehci
ehci_pci               16384  0
ehci_hcd               86016  1 ehci_pci
usbcore               249856  4 ehci_pci,usb_storage,ehci_hcd,uas

I feel that the biggest thing missing from the void installation is full-disk encryption setup.

Right now you have to manually set it up outside of the installer, and you must do a network install. I like how Void has DE's setup by default on the live images and would prefer to have those installed over the network which only has a tty.

So is there any plans to include this as an option, or is there anyway to setup full-disk encryption and install the live image?

sudo ./mklive.sh -a x84_64-musl -k it

This build requires liblz4, the VirtualBox installation I have don't have this package installed by default.

Should liblz4 be added to the dependencies in the README.md?

I would like to start building docker images with this rather than alpine. Can we get a docker image of this so that users can run
"From void
..."

in a docker file? That would be sweet.

It seems that at least for some of the ISOs with desktop environment there is not enough free space, inodes, whatever to make build-live-images.sh create usable output.
Here's a screenshot of trying to boot a void-live-x86_64-20200404-gnome.iso in qemu.

Here's the last lines of /run/initramfs/rdsosreport.log:

Hi. Thanks for all the hard work of keeping the distro working.
Not sure where this ticket should go, please move if needed.

Currently, as far as I know, at least for a lxde-flavored live image, the sshd daemon is installed && up by default, which is true for an installed system too.

While I suspect some distros may have the same policy, I wonder what is the need behind of it? Possibly, installation over ssh?

I am opening the issue as it was pretty odd to me to find out that Void has it. Having a sshd sticking out into the network may be pretty dangerous, especially considering that Void doesn't promote itself as a server distro, but instead as a general-purpose OS, so the end-user may have no idea that sshd is up at all.

uname -a: Linux void-live 4.12.13_1 #1 SMP PREEMPT Thu Sep 14 13:15:00 URC 2017 x86_64 GNU/Linux

Affected program: void-installer 0.22 b4804a8

On the latest live image, the void-installer utility fails to connect to my local WPA2-encrypted Wi-Fi network. It works after restarting dhcpcd.

Steps to reproduce this issue

1. run sudo void-installer
2. select "Network"
3. select the Wi-Fi interface (wlp1s0)
4. enter the details (SSID = ..., encryption = "wpa", Password = ...)
5. the following error message is shown: "ERROR: DHCP request failed for wlp1s0. Check /dev/tty8 for errors."
6. check tty8, only message is: "sending commands to master dhcpcd process"
7. select "Exit"
8. run sudo sv restart dhcpcd
9. repeat steps 1–4
10. the following message is shown: "Network is working properly!"

Hello,

I just wanted to report that void-linux/void-installer#1 also applies to the installer in this repository.

The rpi2 image (didn't test the others) is missing the chrony user+group.
Had to create the user myself.

Alternatively I could just do

xbps-install -Su chrony

After setting the time manually

Currently shipping a new set of images requires a period of time where all builds can be stopped, and where everything can generally be assumed to be working. This is all for not a huge amount of gain. To ease this and to make it easier to release updated images on a more regular schedule, I'd like to reduce the number of images that are provided. The others will remain in the system, but won't be generated by default.

I propose removing the following images:

• All GCP Images
• All usbarmory filesystems
• The enlightenment images (all architectures)
• The LXQT images (all architectures)
• The MATE images (all architectures)
• All i686 images with the exception of the xfce4 image and the no-DE image.
• The x86_64 and i686 filesystems

Dropping the above images would reduce the number of images by 18, leaving 30 images. This still shows the versatility and adaptability of Void, but does so without impeding the release cadence for the ISOs.

I personally would also like to see the cubieboard2 and odroid-c2 images dropped from the provided set, which would bring us down to 26 provided images.

I intend to spin new images this coming weekend, so I'd like to get this resolved before then.

The mklive scripts are set to look for syslinux related files in /usr/share/syslinux but recently it appears that the syslinux package has changed to placing it's files in /usr/lib/syslinux.

This change causes the problem below:

[5/9] Generating isolinux support for PC-BIOS systems...
cp: cannot stat '/home/mollusk/git/butter/void-mklive/tmp.E78xFIo6BT/void-host/usr/share/syslinux/isolinux.bin': No such file or directory
cp: cannot stat '/home/mollusk/git/butter/void-mklive/tmp.E78xFIo6BT/void-host/usr/share/syslinux/ldlinux.c32': No such file or directory
cp: cannot stat '/home/mollusk/git/butter/void-mklive/tmp.E78xFIo6BT/void-host/usr/share/syslinux/libcom32.c32': No such file or directory
cp: cannot stat '/home/mollusk/git/butter/void-mklive/tmp.E78xFIo6BT/void-host/usr/share/syslinux/vesamenu.c32': No such file or directory
cp: cannot stat '/home/mollusk/git/butter/void-mklive/tmp.E78xFIo6BT/void-host/usr/share/syslinux/libutil.c32': No such file or directory
cp: cannot stat '/home/mollusk/git/butter/void-mklive/tmp.E78xFIo6BT/void-host/usr/share/syslinux/chain.c32': No such file or directory`

As a result, xorriso fails to complete and generates an error which in turn does not create the final image file.

I am trying to find where the $SYSLINUX_DATADIR is set which is a variable used in mklive.sh but that variable does not seem to be originally set in the same file it is used. If I can successfully locate this variable, I can change it and submit a pull request. Until then, if someone more familiar with the mklive scripts can sort this out quicker than I can, please do so as currently the system is broken.

EDIT: Found the SYSLINUX_DATADIR variable, it was in mklive.sh but closer to the bottom. Changed the variable and building a test image now.

EDIT2: The test image was successfully created. I am going to fork mklive and create a pull request.

Thanks

https://github.com/void-linux/void-mklive/blob/master/mklive.sh.in#L275

    "$VOIDHOSTDIR"/usr/bin/mksquashfs "$BUILDDIR/tmp" "$IMAGEDIR/LiveOS/squashfs.img" \
-comp "${SQUASHFS_COMPRESSION}" || die "Failed to generate squashfs image"

That command does not work. (Tested with Debian 9.7)
I got the error:

# ./mklive.sh
[...]
[5/9] Generating isolinux support for PC-BIOS systems...
[6/9] Generating GRUB support for EFI systems...
[7/9] Cleaning up rootfs...
[8/9] Generating squashfs image (xz) from rootfs...
./mklive.sh: 275: ./mklive.sh: /mnt/void-mklive/tmp.Er3cNzlFR7/void-host/usr/bin/mksquashfs: not found
ERROR: Failed to generate squashfs image

Regards.

Alpine's tar does not support the --posix flag which is used for packing.

@the-maldridge, I was refering to the installer on the November 2018 .iso images.
So what exactly do you mean with "not installed anywhere"?
To be honest, and as mentioned, it doesn't bother me. Just thought, you would like to know about it.
Have a good day and close this issue as fast as you can.

hello there,

I am trying to setup a docker container for testing purposes and I am getting this error

docker run --rm -it -t void-test /bin/bash
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/bin/bash\": stat /bin/bash: no such file or directory": unknown.

this is my Dockerfile (docker build -t void-test .)

FROM voidlinux/voidlinux-musl:latest
RUN xbps-install -Syu

does anyone know why?

Hi,
I've created an iso:
./mklive.sh -k de -p 'linux5.5'

Then I've booted the iso and tried to run the void-installer, but an error message said that dialog is missing. IMHO this should automatically be part of the iso.

excepted behavior: to be able to choose between Wayland and Xorg
current behavior: nothing
https://i.imgur.com/vROVlhs.png

Recently I noticed using my Void installation that I was able to run pkexec -u root without a password being required. After some digging in, I found out that void-live.rules is present in my system and not associated with any package. This means that, after installing Void (I don't remember how I did it, if I did so with the online or offline method, but if I had to bet it would be the latter), a file that allows unlimited full password-less root access for wheel accounts is silently left as part of the new system.

Here's a demonstration of how it looks like on my system:

mkplatformfs.sh has the following code for adding additional packages to an image:

if [ -z "$EXTRA_PKGS" ] ; then
    PKGS="$PKGS $EXTRA_PKGS"
fi

I believe the use of -z in the expression is wrong and results in packages never being added. The expression should instead use -n.

Hello,
I made an install using the new ISO, after which the installed system would not boot properly because the swap UUID was missing in fstab. Using the previous ISO from 2018 it works fine.

Title summarizes it, but the autoinstaller's default swapsize can cause sfdisk to fail when the target disk is smaller than the amount of memory. In particular, I ran into this when provisioning an R640 with an approximately 200gb root disk and 384gb of memory.

I need to work on a patch to set a reasonable upper bound on that (i.e., smaller than disk size) so that the installer doesn't croak. Until I have time for that and for any readers wondering, the solution is to just set your own swapsize.

Relevant line: https://github.com/void-linux/void-mklive/blob/master/dracut/autoinstaller/install.sh#L192

The "Settings" button in the Void Linux installer utility leads to a view of the chosen installation settings. I think the term "Settings" is misleading for this purpose (I was expecting a dialog with options to configure the installer). Please consider changing it to "Review settings" or something similar.

From what I understand, GPT disklabels do not use flags like MBR disks. The warning before partitioning in the installer states "For EFI systems GPT is mandatory and a FAT32 partition with at least 100MB must be created with the TOGGLE 'boot', this will be used as EFI System Partition. This partition must have mountpoint as '/boot/efi'."

Setting this "boot" flag on a GPT disk partition using cfdisk is not possible. Setting the partition type as EFI System in cfdisk establishes that this is the boot partition.

xbps-query -Rf sysprof prints:

/usr/''/sysprof2.service
/usr/bin/sysprof
/usr/bin/sysprof-cli
…

I think this is some systemd will-o'-wisp.

I know that the linux kernel has binary blobs loaded regardless if you need them, I wondered if it would be possible, to make an easy option in the linux kernel to disable them if you don't need them. I know you rejected another line of kernels, would you be willing to do this instead?
I only ask, because some computers can run without the binary blobs just fine and the binary blobs are a security risk.

I use RTL8188EE and MT7601 Wi-Fi adapters and I can't connect to Wi-Fi because both /usr/lib/firmware/rtlwifi/rtl8188efw.bin and /usr/lib/firmware/mt7601u.bin are missing. They both are provided by linux-firmware package and I don't know why you don't include it in the live system.

-> User installs live image
-> Boots into it. Tries to copy their previous backup from external hdd.
-> User cannot read/write from hdd.

During installation, the main repository URL is used to check network availability. The same URL is the only one for a network installation. However, in case of problems in the main repository, the network check fails and the network installation is not possible.

Suggestion: to test the availability of a network, use several third-party addresses (google.com, kernel.org, ntp.org ...); additionally specify several backup repositories in the xbps configuration.

Passing other extra packages with -p like grub-x86_64-efi or gptfdisk do not crash like this.

This package intel-ucode used to work before.

$ sudo ./mklive.sh -a x86_64-musl -r https://repo.voidlinux.eu/current/musl -p "void-repo-nonfree intel-ucode"
...
squashfs-tools-4.4_1: configuring ...
squashfs-tools-4.4_1: installed successfully.
bzip2-1.0.8_1: configuring ...
bzip2-1.0.8_1: installed successfully.
xorriso-1.5.3_1: configuring ...
xorriso-1.5.3_1: installed successfully.

37 downloaded, 37 installed, 0 updated, 37 configured, 0 removed.
[3/9] Installing void pkgs into the rootfs: base-system void-repo-nonfree intel-ucode ...
Package 'intel-ucode' not found in repository pool.
ERROR: Missing required binary packages, exiting...

Today I successfully cloned https://github.com/void-linux/void-mklive, did cd void-mklive, and then successfully issued make. No errors were reported.

I read the short help by issuing ./build-x86-images.sh -h

Then I tried to prepare a base live image thus:

./build-x86-images.sh -b base

But it got stuck at step [4/9]. It complains this way before dying: Cannot install a hook (/usr/lib/dracut/modules.d/01vmklive/copy-initramfs.sh) that does not exist.

The whole output can be seen here: https://pastebin.com/tWa2WBfW

Something's broken here I suppose?

This is not super important, especially since I know what modules to blacklist for my one laptop, but a lot of laptops rfkill wireless and are not configured by default to turn it on via hardware switches. Since wireless utilities are included I think this could be a candidate for the next release of liveimages.

I just thought I would formally suggest this. Thanks

void installer installs linux 5.3.18 instead of linux 5.4.5 and https://www.kernel.org/ says 5.3.18 is at its eol

There are issues with the current Void installer. Like the absence of LUKS on top of LLVM. Also, some users report trouble with partitioning.

There are alternatives that could be implemented.
One of them is ArchLabs installer. https://bitbucket.org/archlabslinux/installer/src/master/

It lacks any of the issues stated above, plus it is more advanced and looks better.

Please consider the switch. Thank you

Please provide a torrent to download the iso / img files. Thanks

I've been working on supporting the Pinephone. I can already build a working image.

Similarly to the PBP issue, this one exists to track my progress on this and to bring attention to it so that anyone else wishing to get voidlinux working on the pinephone can re-use my existing work.

• Voidlinux builds and runs
• Package templates
  • Uploaded to public repo *
  • Conform to contributing standards
  • Merged
• void-mklive
  • Uploaded to public repo *
  • Merged

* Note: I am going to push -f to these branches. Just so everyone is aware ahead of time.

I have some questions which I don't know the answers to:

• Where do I get the config file for the bluetooth firmware for the pinephone? The source for the firmware has a file for the pinebookpro but nothing for the pinephone.
• Does CC need to be exported for makefiles which rely on it? cc is not a symlink when I try to build which is odd to me. The pinebookpro u-boot package doesn't set CC and supposedly builds so I'm confused why my u-boot would need this.
• The pinebookpro u-boot package doesn't flash the u-boot either as a kernel config hook or as some kind of postinstall, how should this be handled?

  Flashing is done by mkimage when the image is built. u-boot images are installed to /boot, so they have to be flashed manually after upgrades. To make it easier, I think we should just provide some tool to flash them to correct place (analagous to grub-install) and document it's use. Updates to u-boot images are not very frequent anyway.

• The pinebookpro mkimage does an xbps-reconfigure in the chroot as part of the image making process to re-generate the u-boot boot.scr but it looks like this already happens in mkplatformfs.sh, is this necessary?

  Partition UUIDs are only known on mkimage step, so reconfigure is needed to update configuration with correct UUIDs.

Feel free to report issues to the issue trackers in the respective repositories and I'll have a look at them, or just post comments here.

Contributions are welcome but I'm not sure if they won't have to be squashed. If people have suggestions it would be easier to just tell me what I should do and I'll credit the person in the commit message.

Footnote: Bear with me, I don't know what I'm doing, I'm not a maintainer.

Hello, I want to have a void linux iso automatically install itself rather than going through the void-installer. I found https://github.com/void-linux/void-mklive/blob/master/dracut/autoinstaller/install.sh which looks like what I want. Is this something that can be run instead of void-installer? How can I enable it? Or do I just have to create my own void-installer.sh script instead?

Lots of discussion has been had about broken polkit in Void linux. I decided to try to get to the bottom of it and have found the issues. LXDM is currently used for GTK desktops, however, it does not correctly launch a ck-session for consolekit which causes shutdown/suspend buttons as well as other permission problems to occur. Lightdm-gtk3-greeter correctly launches the ck-session. I created a reddit thread https://www.reddit.com/r/voidlinux/comments/c7g1wt/ where another user already confirmed this is fixed. If the ck-session is launched correctly like lightdm does it, no custom polkit rules are necessary for shutdown/suspend or moutning disks etc.

https://forum.voidlinux.org/t/solved-void-installer-issue-chpasswd-cannot-determine-your-user-name/6866

at the end after ‘Executing post-install kernal hook: 20-dracut …’ I receive the following

chpasswd: Cannot determine your user name
useradd: group '100' does not exist
useradd: the GROUP~ configuration in /etc/default/useradd will be ignored
useradd: group 'wheel' does not exist
useradd: group 'floppy' does not exist
useradd: group 'audio' does not exist
useradd: group 'video' does not exist
useradd: group 'cdrom' does not exist
useradd: group 'optical' does not exist
useradd: group 'kvm' does not exist
useradd: group 'xbuilder' does not exist
chpasswd: Cannot determine your user name

I attempted a install just now using network as the source and it showed this issue that you are getting as well.
Thanks, installing from local worked perfectly!