I’ve seen the recommendations of software raid0. The answers are all technically correct.

Don’t do this. Especially with real hardware. If you lose one drive, you will lose both the drives.

Could you give us more info on how your other encrypted drive is mounted and meant to be used?

• It is possible to get the second encrypted drive to decrypt and mount automatically, without logging in.
• It’s possible to do it without leaving a key for your second drive on your primary hard drive using a TPM
• It is possible to get both drives to decrypt automatically and mount

It all depends how the encryption is being done, and where the mount points are.

Could you give us:

• The rough dimensions of the drive partitions (fdisk -l)
• Your current mount points after mounting the second drive (df -h)

Preinstalled OS is useable, though you’ll want to update it.

Installing the updated OS on an SD card is easy enough. I haven’t tried flashing it to disk yet. I’ve not felt hampered by major performance penalties.

The WiFi dongle workaround is that simple, yes. Pick one that’s supported in the mainline kernel, and you’re off to the races.

Be aware, you’ll need to pick one that’s USB C if you don’t want a second converter attached.

My preference would be to tether my phone I think - but my USB C 2.5G Ethernet adapter worked pretty well too.

Some more presient info from my investigation:

I got the latest Danctnix 20260630 running on it, and it’s working better now. Suspend is unmasked in that version, but it is not working all the time.

The WiFi driver is still unstable, but you can disconnect/reconnect quick enough when it drifts off.

Running phosh and sxmo/sway was a fair bit faster than full KDE.

The primary problem is hardware acceleration. For video, it’s just not there yet. You can make some video formats work, but this SoC is limited in what it can do in hardware, on its VPU. What little can be done, isn’t available without compiling your own ffmpeg.

This link shows what can be done with the 3566 hardware:

https://pine64.org/documentation/General/Mainline_Hardware_Decoding/

This link shows how it can be done:

https://clehaxze.tw/gemlog/2023/09-17-hardware-accelerated-playback-on-pinetab2.gmi

The bottom line is, without hardware acceleration for video decoding, it feels very underpowered.

I did bother to set it all up, and it’s a damn competent little tablet when you do - but all your effort won’t apply to streamed video unless you use MPV or something to play it, to take advantage of the ffmpeg. Straight up Firefox and chromium don’t offer selectors for YouTube etc to pick the right encoding format for your CPU, and they typically use more modern encoding formats. (e.g. VP9 over VP8)

Also, battery life is great! I’m sure not playing video helps…

Very much dependent on the particular hardware - here, the pinetab2 has some support. The danctnix mobile linux community maintains builds for it, so it’s a subset of Arch on Arm.

https://github.com/dreemurrs-embedded/danctnix-packages/tree/main/pine64/device-pine64-pinetab2

outside of that, there’s some limited support for postmarketOS and mobian

A good place to start understanding the challenges you’d face would be on the wiki:

https://wiki.pine64.org/wiki/PineTab2_Releases

I just bought one. The default KDE is a bit heavyweight for it, I’m thinking something lighter might be better.

I would say that they perfectly nailed the description, this is not a beginner device. You’ll not be distrohopping without knowing how to patch your own WiFi drivers and fix the auto rotate (90° clockwise further than it should be out of the box).

I love it, really cool. But not an easy in for beginners.

Feel free to ask me questions or check something, or send a picture of something!

I replaced an NVMe drive on a Windows 11 machine the other day. Cloned to new disk, booted up. After posting and entering the bootloaders, it said “BOOT DRIVE INACCESSIBLE”. The drive needed a driver to BOOT once Windows took over.

A Western Digital 850x black 2TB. This is not an uncommon drive, but I had to patch in the driver to the disk from a live CD.

I don’t see how people put up with this crap.

FYI, scrcpy can be an excellent tool for remote support, but you’d better trust the network the interface is on

I found a homemade Ubuntu 8.04 installer disk the other day, simpler times. It had it’s place.

I will never forgive the amazon partnership with the desktop search bar.

tl;dr:

If you think something is blocking DNS traffic, you could try configuring DNS-over-HTTPs or DNS- over- TLS and picking a reputable upstream. This should obfuscate the traffic somewhat and get past common DNS interference issues and tactics.

So building on what yourself and everyone else has said, it does seem to be a DNS issue.

I found that at select times my local ISP was up to shenanigans with DNS.

I live in a very small country and work in IT. The NOC for all three ISPs and I have met. It would surprise me if they were competent enough to do this intentionally for malicious purposes.

If you can get access out to the internet via ping, see if you can do other things - get on a VPS and test with tcpdump at both ends. There’s a few free ones or trials great for disposable purposes like this. Set it up in advance…

You won’t know what it is til you troubleshoot.

I’ve had huawei firewalls reaching some simultaneous connection limit and fail, reversing their ruleset - blocking everything except ICMP, tr069 and ssh (concerning) outbound…

I’ve had problems with specific DNS servers, through the ISP’s network.

I’ve seen regular BGP changes causing outages all over the place (the ISPs locally don’t peer with each other…)

Post your findings, would love to help/hear!

Do you subscribe to karakeep lists? Are they of infinite length?

I was about to say, I’ve only come across that particular issue since moving to KDE, but I know what you mean about the lack of options, but then I looked in the settings, and found this:

It’s getting there!

That’s exactly why. You can manage users no problem. Multiple machines was never the paradigm.

90% of the current development effort (containers, virtualization) is about copying the working machine and giving it a nice safe space to run in, where no outside forces can reach in and disturb its peace.

Did you just try to theme my app? We’re opinionated software, and that’s bigotry.

Also slimbook! They’re offering similar machines to tuxedo, but my Executive 14 13700 was slightly cheaper than the equivalent Tuxedo Infinity book pro (same clevo laptop base), and dropped the second nvme slot for a full 99Wh battery.

Additionally, I has no problems shipping from Spain to the US.

Oh, oh I know this one!

If your keyboard shortcut contains control characters, it will be interpreting the keypresses with the control characters you’re holding for the shortcut. Alt+a super+b etc.

Some keyboard shortcuts trigger on press, they can also trigger on release. This is why you need the sleep statement, to give you time to release the keys before it starts typing. You want the shortcuts to trigger after release.

I can set the difference in my window manager, but I’m not sure about doing it in (GNOME?) Ubuntu. Even assuming you can set the shortcut to only run on release, you still need to let go of all the keys instantly, so chaining with sleep is probably the best approach.

Chaining bash sleep and ydotool works for me in my window manager. Consider using “&&” instead of “;” to run the ydotool type command. Whatever is written after the “&&” only executes if the previous command (sleep 2) succeeds. The “;” might be interpreted by the keyboard shortcut system as an end of the statement:

sleep 2 && ydotool type abcde12345

Or perhaps the shortcut system is just executing the programs, not necessarily through a bash shell. In that case we would need to actually run bash to use its sleep function and the “;” or “&&” bit. Wrapping the lot in a bash command might look like this:

bash -c "sleep 2 && ydotool type abcde12345"

Assuming that doesn’t work, I see nothing wrong with running a script to do it. You just need to get past whatever in the shortcut system is cutting off the command after the sleep statement.

Running ydotoold at user level is preferred and recommended. It keeps it inside your user context, which is better for security.

They’ll just take the ick out of his name when he assumes his PR/Community manager role

Long live the Executive 14 99Wh - you’ll pry mine from my cold dead hands

I once had to edit and dump a Cisco config from a 10 switch stack over 9600 baud.

It took ages, and then I realised my fancy new terminal still had a default scrollback limit set, and had to do it again.

Actual torture.

So the package is a specific driver version, which will keep you on the 580 diver version through updates. This package would be installed to provide the drivers and requires the matched utils package.

You would install this, rather than just installing the meta-package from the official repositories. As shown in the AUR page:

Conflicts:	nvidia, NVIDIA-MODULE, nvidia-open-dkms
Provides:	nvidia, NVIDIA-MODULE

This is also a DKMS package. This will let it build against whatever kernel you’re running, so you can keep using the module through regular system qns kernel upgrades.

So, the idea would be, remove the nvidia drivers you have, install this one, and it’ll be like the upgrade and support drop never happened. You won’t get driver upgrades, but you wouldn’t anyway. It’s the mostly safe way to version pin the package without actually pinning it in pacman. That would count as a partial upgrade, which is unsupported

I’m using stow, and then git for versioning. The only question I’m currently facing is whether to keep my stow packages as individual got repos (so I can switch branches for radically different configs or new setups) or treat the whole lot as a big repo, and set the others up as subtrees.

I was trying to finalize a backup device to gift to my dad over Christmas. We’re planning to use each other for offsite backup, and save on the cloud costs, while providing a bridge to each other’s networks to get access to services we don’t want to advertise publicly.

It is a Beelink ME Mini running arch, btrfs on luks for the os on the emmc storage and the fTPM handling the decryption automatically.

I have built a few similar boxes since and migrated the build over to ansible, but this one was the proving ground and template for them. It was missing some of the other improvements I had built in to the deployed boxes, notably:

• zfs on luks on the NVMe drives
• the linux-lts kernel (zfs compatibility)
• UKI for the secureboot setup

I don’t know what possessed me, but I decided that the question marks and tasks I had in my original build documentation should be investigated as I did it up, I was hoping to export some more specific configuration to ansible to the other boxes once done. I was going to migrate manually to learn some lessons.

I wasn’t sure about bothering with UKI. I wanted zfs running, and that meant moving to the linux-lts kernel package for arch.

Given systemd-boot’s superior (at current time) support for owner keys, boot time unlocking and direct efi boot, I’ve been using that. However, it works differently if you use plain kernels, compared to if you use UKI. Plain kernels use a loader file to point to the correct locations for the initramfs and the kernel, which existed on this box.

I installed the linux-lts package, all good. I removed the linux kernel package, and something in the pacman hooks failed. The autosigning process for the secure-boot setup couldn’t find the old kernel files when it regenerated my initramfs, but happily signed the new lts ones. Cool, I thought, I’ll remove the old ones from the database, and re-enroll my os drive with systemd-cryotenroll after booting on the new kernel (the PCRs I’m using would be different on a new kernel, so auto-decrypt wouldn’t work anyway.)

So, just to be sure, I regenerated my initram and kernel with mkinitcpio -p linux-lts, everything worked fine, and rebooted. I was greeted with:

Reboot to firmware settings

as my only boot option. Sigh.

Still, I was determined to learn something from this. After a good long while of reading the arch wiki and mucking about with bootctl (PITA in a live CD booted system) I thought about checking my other machines. I was hoping to find a bootctl loader entry that matched the lts kernel I had on other machines, and copy it to this machine to at least prove to myself that I had sussed the problem.

After checking, I realised no other newer machine had a loader configuration actually specifying where the kernel and initram were. I was so lost. How the fuck is any of this working?

Well, it turns out, if you have UKI set up, as described, it bundles all the major bits together like the kernel, microcode, initram and boot config options in to one direct efi-bootable file. Which is automatically detected by bootctl when installed correctly. All my other machines had UKI set up and I’d forgotten. That was how it was working. Unfortunately, I had used archinstall for setting up UKI, and I had no idea how it was doing it. There was a line in my docs literally telling me to go check this out before it bit me in the ass…

…

• [x] figure out what makes uki from archinstall work ✅ 2025-09-19
• It was systemd-ukify

…

So, after that sidetrack, I did actually prove that the kernel could be described in that bootctl loader entry, then I was able to figure out how I’d done the UKI piece in the other machines, and applied it to this one, so it matched and updated my docs…

…

• IT WASN’T ukify

UKI configuration is in mkinitcpio default configs, but needs changing to make it work.

vim /etc/mkinitcpio.d/linux-lts.preset 

…

Turns out my Christmas wish came true, I learned I need to keep better notes.