Installation Hurdles

[Tennodian]

This is not your typical issue report, so let me first express my gratitude for all that you have done so far regarding the Liteqube development.

I believe this is what the Qubes have always needed. It’s not perfect solution and there are some issues, however I’m quite happy how it turned out. It wasn’t a smooth ride to get it all working as described, but not all the problems were caused by the script.

I’m one of those users that also likes the mc file manager. Reminds me of old times from MS DOS era, when Norton Commander was the thing. It is a good tool, but in some cases can make some major headaches and unexpected problems.

I’ve used the mc to extract the zip and you can probably guess how that has ended. In short, problems with permissions, errors during and after install, lq-based scripts ending up without xterm...I was really tempted back then to come here and complain about it all, and then it hit me to check it one more time to be exactly sure if the problem was really with the main script (which supposedly had the newest fixes) or PEBKAC. Cause nobody else was complaining about these errors and issues, which means it’s either new or something on my end.

And it was the second. So, whoever is reading this, make sure to use unzip command.

Onward to the script itself. I’ve downloaded the version with the bug, which supposedly renders the OS useless. I didn’t encounter the same problem, probably because of the previous permissions issues, which has saved me in way, since I was doing the installation on two PC’s, one with a new Qubes install and second with existing installation. More luck then brains I guess.

With the correct extraction I had 0 issues on both machines with the Base install. Networking brought different problems, and in order to resolve them I’ve encountered several issues with the script.

I’ve picked the Mirage FW option, and encountered the same issues for Cannot Dynamically Attach. It was supposedly fixed in the main branch, so this got me really confused. I’ve tried then with regular Firewall, but my other PC had an issue with it and internet never worked. So I went back to Mirage.

I’ve added the following code after 456 line, since the sys-firewall, sys-net and fw-net were somehow stil running and messing up the rest of the script.

qvm-shutdown --quiet --wait --force "${SYS_FIREWALL}"
qvm-shutdown --quiet --wait --force "${SYS_NET}"
qvm-shutdown --quiet --wait --force "${VM_FW_NET}"
qvm-shutdown --quiet --wait --force "${VM_NET}"
sleep 3

This is where I found out a bug with Mirrage Firewall. Seems like you can’t set netvm property if it’s running. I’ve tested this out in the Qube Manager, and manager crashed upon the change. When Mirage is down, the change can be applied without such crash.

Of course, this wasn’t the end of my problems. I’ve encountered few more issues, mostly tied to specific hardware of my second PC.

The PC has the dreaded rtl8821ce wifi, and you can probably guess, it is a pain to configure. The firmware is only available with dkms module. In my case it meant one more uninstall and modification of the install script (firmware part) to add dkms, followed by the bc packet to the debain-core, in order to make the required module.

The module was successfully added to the debian-core and I finally had the wifi. But, here comes the unexpected part. Core-net crashed and refused the start. Logs indicated the kernel panic, which I found strange because for a moment wireless has worked, as I’ve connected when the script was toryfing the debian sources.

Apparently, it was the last part of the script with the memory adjustments, which lowered the core-net RAM from 512 to 208 MB. I’ve encountered similar issues since the change from 5.10 kernel to 5.15 and higher but wasn’t able to figure it out.

Now, thanks to your script I’ve found the cause. Probably the issue is in the rtl8821ce source code which doesn’t play nice with newer kernels, but I have no idea what to do there. I’ve used the only workaround available, to add more RAM for the core-net at the memory adjustments - line 517 of my modified script.

qvm-prefs --quiet --set "${VM_NET}" memory 640

Finally what was left to do is to add autoconnect feature to /etc/protect/template.core-net/config/rc.local in debian-core:

/usr/bin/nmcli con mod <wifi> connection.autoconnect yes

Liteqube, when it’s properly installed and configured, works like a charm. I’m so excited with it and I can’t wait for the addition of network and Tor applets, as they are the most important ones in my opinion. nmtui can work for Wifi network but I’m not sure what could be used for Tor.

My next adventure would be to try your awesomewm version, hopefully I would manage to figure it out.

Sorry for the long read and for the lack of TLDR.

[a-barinov]

Hey, many thanks for your feedback! A few random thoughts and notes:

Surprisingly, I also use mc as my primary file manager. I tried downloading 'liteqube-main.zip' archive and mc indeed strips files of the exeutale permissions. I normally use 7z but unzip will do the trick as well. Nevertheless this is fixed in today's commit.

'Cannot Dynamically Attach' was a painful problem that I was trying to trace down but never did, so you efforts are really appreciated. I tried adding slightly extended version of your code to the installer, hope this will help the users suffering from the problem. I have a super-slow computer where the problem was easy to reproduce, will try it over the weekend. Will also try to investigate non-working linux firewall. Most likely more memory needed under Qubes 4.1.

Speaking of core-net memory allocation, I never thought of the modules that might be more memory-hungry than intel's. I'd still prefer to keep memory usage as low as possible but:

1. I moved core-net memory to install options.
2. I added a note to the documentation suggesting to increase memory allocated to core-net if it crashes.

Interestingly, for some people network autoconnect is on by default and for some it's not. Once I get my hands on refactoring of network installer (which will happen after I refactor vpn and then tor installers), I'll make sure this is configurable.

My awesome config was never intended for public consumption but someone on github persuaded me to share it. Comes with no warranty, implicit or explicit. I'll not fix bugs or add features, but will sure accept commits and answer questions.

[Tennodian]

Hey, sorry for replying so late, I was very occupied with some of the real life issues. I'm still using liteqube, but it seems I've stumbled on few problems and they are both related to updates.

Apparently, the core-update qube is lacking enough storage space for larger updates in dom0. I've been testing few different kernels and due to insufficient space available for more than 700MB of packages, the update fails with messages how there is not enough space available (Failure writing output to destination). df in core-update shows 99 or 100% of storage is used at that moment. I assume the increase of system storage by 1GB or 2 would help in my case, but as core-update is based on core-dvm, I'm not sure how can I do this and I would really appreciate any suggestions.

Much smaller second problem is with torified repositories. They work really slow for me with speeds between 20 to 50KiB/s, so I've reverted back to default ones. I don't have a problem when the speeds are around 100 to 200KiB/s, but they never seems to happen in my case.

[arkenoi]

Why do we need persistent update storage at all? Let's make an option to allocate it dynamically to tmpfs!