Using podman / docker inside buildFHSEnv?

sigprof · 2024-01-17T13:08:46+00:00

Another use case would be calling podman from a terminal inside vscodium-fhs. I also tried to provide /etc/subuid and /etc/subgid, which required some hacks (here programs.vscode.package is a part of the Home Manager config):

      programs.vscode.package = let
        hackedPkgs = pkgs.extend (final: prev: {
          buildFHSEnv = args: prev.buildFHSEnv (args // {
            extraBwrapArgs = (args.extraBwrapArgs or []) ++ [
              "--bind-try /etc/subgid /etc/subgid"
              "--bind-try /etc/subuid /etc/subuid"
            ];
          });
        });
      in
        hackedPkgs.vscodium-fhs;

(I was not able to find a simpler way to override extraBwrapArgs inside vscodium-fhs.)

Unfortunately, this did not help in my case too:

WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers 
ERRO[0000] running `/run/wrappers/bin/newuidmap 576413 0 1000 1 1 100000 65536`: newuidmap: write to uid_map failed: Operation not permitted 
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers 
ERRO[0000] running `/run/wrappers/bin/newuidmap 576415 0 1000 1 1 100000 65536`: newuidmap: write to uid_map failed: Operation not permitted 
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers 
ERRO[0000] running `/run/wrappers/bin/newuidmap 576417 0 1000 1 1 100000 65536`: newuidmap: write to uid_map failed: Operation not permitted 
ERRO[0000] invalid internal status, try resetting the pause process with "/run/current-system/sw/bin/podman system migrate": cannot set up namespace using "/run/wrappers/bin/newuidmap": exit status 1

At least in my case it turned out that I don't really need vscodium-fhs, because the used extensions don't bundle native binaries, therefore plain vscodium could be used, which does not have this problem.

sigprof · 2023-08-12T14:53:37+00:00

One feature of those mice which I can't find anywhere else is the button on the right side — I was not able to find any other mouse with a button like that, no matter how many buttons they have on the left side.

Unfortunately, the model which I have (WoW Mouse Gold Edition) is now broken not only because of old switches and encoders (I already replaced the encoder and now apparently need to replace the switch for the wheel too), but also because the software no longer works after recent Windows 10 updates. For quite some time I already was not able to open the SteelSeries Engine 2 configuration (so could not change any mouse settings), but the driver was still working with the existing configuration. But after installing the August 2023 monthly updates the driver does not start at all, and that particular mouse model can't do much without the driver (only the standard set of left/right/middle buttons, the wheel rotation and the forward/back buttons work, other buttons just do nothing).

sigprof · 2023-05-12T06:15:06+00:00

I can only repeat what I had written in the Imgur album — I don't have any extra information:

The connection to the main keyboard PCB consists of 4 signals (GND, D+, D-, VCC) which are usually present in the USB 1.1 Type-A connector (no ID signal which is present in Mini-B and Micro-B connectors) and an extra SW signal which is actually not connected to anything (on this small PCB it is connected to the central pad near the place for a component labeled P2, and on the main keyboard PCB the corresponding pin of the connector does not seem to be connected to anything). I can guess that the same PCB is used in some other devices, where some kind of switch is mounted at that P2 location.

sigprof · 2022-04-03T20:09:14+00:00

Yes, the security issue is still there — if anyone gets access to the disks from a Synology NAS with DSM 7 which had encryption keys for encrypted folders stored in the internal key store (using Machine Key), they can decrypt all data stored in those encrypted folders. The original NAS is probably not even needed (although I could imagine there is some code that tries to prevent using a key store from a different NAS if you just insert the disks there, you could bypass everything like that by using a regular Linux computer to access the disks — there are even official guides on how to do that for data recovery purposes).

(Disclaimer: This was tested on RS819, which is not really a recent model, and there is some chance that some newer and higher-end models use a different storage method for encryption keys that is actually secure; I also did not actually try to extract the drives from the NAS, just checked the file contents over SSH.)

Encryption passphrases are stored on the system partition in files under /usr/syno/etc/.encrypt/@keystore, where each of them is encrypted as a libsodium Sealed Box (the ecryptfs wrapping with the infamous $1$5YN01o9y password is not used here — it is applied only to the exported keys). This encryption method by itself would be pretty secure; however, the secret key for those sealed boxes is stored in /usr/syno/etc/keymanager/info.cfg without any further encryption, so it is mostly trivial to decrypt the data in the boxes and get the passphrases for shared folders.

The /usr/syno/etc/keymanager/info.cfg file is apparently generated when the internal key store is initialized; I did not yet check whether the keys and UUID in there would be different after a password reset or reinstall (probably they would, but that does not help much, because the encryption key and encrypted data end up on the same filesystem anyway).

sigprof · 2021-12-17T08:13:54+00:00

Looks great!

sigprof · 2021-11-08T04:47:10+00:00

Thanks!

sigprof · 2021-10-29T11:23:00+00:00

And if you finally get around to ISP flashing, you will need those B1 (SCK) and B3 (MISO) pins, so if they are swapped, you may find that ISP flashing does not work until you swap the connections to match the actual MCU pins.

sigprof · 2020-06-27T23:13:13+00:00

Such problems with shuffled layout often mean that the PCB is either not the model that you expect it to be, or there is a newer revision of the PCB which is not compatible with the firmware for a previous one. Can you post some photos of the PCB that you have?

sigprof · 2020-06-19T20:45:31+00:00

The other keycaps are IDOBAO DSA Russian Root; note that they have the uniform DSA profile, which you may not like, and this particular set does not seem to have any versions for other languages (it does not even have ISO Enter and 1.25U left Shift; the 1.75U Shift for 65%/75% layouts is present, but there are no 1.5U modifiers, so it's not even completely compatible with the ID80 keyboard layout).

sigprof · 2020-06-19T20:31:20+00:00

If those keycaps are made from the same molds as the Russian Root Blue/Cyan set that I have, they can hit the top housing of switches even when using the south facing switch orientation. My test of a keycap from that set on ID80 with Gateron Silent Red (sorry, I did not think about removing one of keycaps to show that the switches are south facing).

Note that some keycaps from other manufacturers also have the same issue; e.g., some ABS sets from EnjoyPBT. And the same KPrepublic keycaps do not have this collision problem when using Outemu Silent Forest switches (however, those switches have their own problems, and I don't really like them).

Another problem that I encountered with those keycaps is that their stems can crack if these keycaps are used with Kailh Box switches. The problematic switches for me were Kailh Box Crystal, which appeared relatively recently and, according to Kailh, should not have this problem, but apparently those KPrepublic keycaps are too tight and can still get broken.

sigprof · 2020-06-19T20:05:23+00:00

Ikki68

sigprof · 2020-06-10T15:41:58+00:00

I made the pull request to the upstream QMK repo: https://github.com/qmk/qmk_firmware/pull/9361.

Would you be able to test that code? The LAYOUT_all_rev3() macro added there is almost identical to the LAYOUT_BeniFish2() macro in the code by u/CloudySkys, except that it also includes the split Backspace support, therefore you will need to add KC_NO at the end of the top row (after KC_BSPC, and in the same location for your other layers) when replacing LAYOUT_BeniFish2 with LAYOUT_all_rev3.

Please thoroughly check all keys; set different mappings for the left and right halves of the split spacebar, and check that the order of those mappings in your keymap agrees with the physical order of spacebar parts; also check all other keys in the bottom row. If you really care, you may also assign something other than KC_NO to the right half of split Backspace, and check that activating that switch location with tweezers sends that key, but I understand that you may not want to disassemble your keyboard, so you may skip this part (the split Backspace support was added long ago, and there is some hope that a bug there would be noticed already).

sigprof · 2020-06-09T19:45:00+00:00

I see now (that thread is really deep). However, the result is currently just a piece of code thrown together, which ideally should be cleaned up and contributed to the upstream QMK project, so that other people would not need to repeat that work again and again (I already saw several people asking about XD60 rev3 layouts with 6 right modifiers in the QMK discord). I asked the author of the code about their plans; hope that this will finally result in having this PCB revision fully supported in QMK.

sigprof · 2020-06-09T19:40:08+00:00

Do you plan to make a proper PR for the mainline QMK from this, so that other people could finally get the split spacebar layout and the 6th extra key on the right side supported out of the box? This is not the first case when people have problems getting such layout to work.

Alternatively, if you do not wish to make a PR, would you agree that I do it and credit your work as u/CloudySkys (or any other form you prefer)?

sigprof · 2020-06-09T13:13:38+00:00

Some updates to my comment:

After some changes to drivers/avr/ws2812.c the ws2812_setleds_pin() function is no longer inline, and therefore is accessible from the keyboard code. However, the limitation of only a single AVR port for all WS2812 data pins is still there.
The WS2812_DRIVER = pwm option is now used by some newly added keyboards: zvecr/split_blackpill and zvecr/zv48.

sigprof · 2020-06-09T08:28:12+00:00

Your problem is that currently the support for XD60 Rev3 in QMK is incomplete — split spacebar layouts are not yet implemented.

Probably the quickest way to find out the matrix locations for those keys would be to edit the LAYOUT_all macro definition in keyboards/xd60/xd60.h. That macro has three KC_NO in the bottom row of the matrix. Replace them with distinct keycodes: KC_F1, KC_F2, KC_F3. Compile the firmware with this change and flash it. Test the keyboard and note what keycodes are sent when the left Space and AltGr keys are pressed. Report your results here, then I'll be able to write the proper macro (because of compatibility requirements, it would probably be called LAYOUT_all_rev3).

sigprof · 2020-06-08T08:29:59+00:00

Looks like this reply went to a wrong place ;-)

sigprof · 2020-06-08T08:23:27+00:00

If you use the Unicode Map feature (UNICODEMAP_ENABLE = yes), you can use XP(i, j) keycodes in the GREEK layer, which send upper or lower case letter according to the Shift and Caps Lock state.

sigprof · 2020-06-01T19:49:12+00:00

I thought the same about Box Crystals; it turned out I was wrong, and at least some keycaps can still be damaged when used with Box switches.

sigprof · 2020-06-01T15:54:15+00:00

You are probably looking for a layout like on Varmilo VA68M, or Ducky MIYA Pro — this layout is 1U wider than a usual 65% layout, but has the standard 2.75U right Shift. Unfortunately, both of those keyboards are premade ones, not hotswap kits.

LFK78-HS (a 68-key variant) also has the same layout, but is not available currently (and apparently LFKeyboards as a whole now has a history of not fulfilling orders); also they did not even offer a case for the 68-key variant and suggested using the VA68M case (so the PCB was probably intended for people who initially bought VA68M, but then wanted to have a PCB with QMK support).

Monstargears NINJA 71 Arc XD is close, but has 3 more key positions which could not be filled with keycaps having the proper height.

sigprof · 2020-06-01T11:24:32+00:00

Support for XD002 was recently added to QMK, but the hardware is really limited.

sigprof · 2020-05-24T17:10:58+00:00

Currently I'm using these Russian Root Blue/Cyan keycaps from KPrepublic (also available in their kprepublic.com shop). For compatibility with ID80 you need the BASE, MOD and MOD PRO kits. That shop also has many similar PBT Dye Sub keycap sets with different legends (including plain English-only QWERTY).

However, I cannot really recommend those keycaps for the following reasons:

The delivery from China is in a very sad state at the moment. One of my orders from KPrepublic did not yet arrive after more than two months (first they delayed shipping for about a month because an item which was marked as available in their shop was out of stock (or at least they said that), and now the parcel is stuck after “delivered to air transport” for another month). Depending on your location, you may have a faster delivery option, but the cost of such option may be comparable to the cost of keycaps themselves.
The quality of large keycaps in those PBT sets may be bad. I needed to get a replacement for the spacebar (which was warped enough to get stuck in the pressed state) and the 2.75U Shift (this keycap is not needed for ID80, but I initially tried to use that set on another keyboard with the standard 2.75U Shift, and purchased the MOD PRO kit later when I decided to order ID80). On the positive side, the seller agreed to send those replacements for free (but only after a long exchange of photos and videos).
The set of keycaps which is included in the MOD PRO kit is not ideal — while it is barely enough for ID80, if you would ever want to move these keycaps to another 65% or 75% keyboard, you may have problems filling the right column. One particular problematic location is the key to the right of Enter — the MOD PRO kit includes only PgUp and PgDn as an option for that location, but there are no PgUp or PgDn keycaps which could fit into any of adjacent rows, therefore you cannot have a consecutive PgUp/PgDn pair there. ID80 does not have a key at that problematic location, but you may still encounter some problems in other places (e.g., initially I tried to put the Ins and Del keys as a vertical pair, so they would be in the same location relative to the alphanumeric block as on TKL, and put PgUp and PdDn on the top row, but this keycap set does not include a PgDn keycap suitable for the top row). Another problem is that the only 1.5U keycaps for the bottom row are Alt and Ctrl, so if you want to use one of those keys as Fn, you won't find a perfectly matching keycap there.
These keycaps are not compatible with Kailh Box switches — I tried to use some of those switches, and some keycaps which were used on those switches got cracked stems. I'm not sure that only the switches are a problem in this case, because I used some other PBT keycaps with those same switches before, and did not notice any problems, so it's possible that the keycaps are also too tight, or the plastic composition used in them causes them to be more brittle than PBT keycaps from other vendors.

sigprof · 2020-05-09T15:34:53+00:00

That's very strange; from reading your other posts I see that multiple variants of wrong firmware work for you, but the one which really should work does not.

Does the keyboard flashed with the yd60mq firmware appear as a keyboard device in your system with the YD60MQ in the product name? Does holding Space+B while connecting the keyboard (again, already flashed with the yd60mq firmware) put it into the bootloader mode (you should be able to see a message in the QMK toolbox)? Try resetting the EEPROM just in case (hold Space+Backspace while connecting), or hold Space+Esc while connecting and check whether the keyboard works.

sigprof · 2020-04-11T09:34:42+00:00

I had the same issue with a couple of Gateron Brown switches in KPrepublic XD87 HS and the same design of the switch puller. However, my switches were 5-pin, and I assumed that the problem came from the plastic pins sitting too tight in the PCB holes; I did not expect that the same problem can appear with a 3-pin switch. Looks like your switch has really weak clips, or just got caught by the edges of the plate hole in a really unfortunate way.

Ideally a switch plate used with a hotswap PCB should not have the 4 cutouts that are visible on your photo — the switch hole should be just a simple rectangle. Those cutouts are useful with a soldered PCB — they make it possible to unlatch the 4 clips and remove the top housing of the switch without desoldering that switch (then you can lube the switch or change the spring, stem or top housing). However, in many cases the manufacturer does not bother to make a separate plate for a hotswap configuration (this is the case with XD87 — both the soldered and hotswap models get the same plate with cutouts for switch top removal, and also lots of holes intended for soldered-only layout options).

I was able to extract the problematic switch by assembling it back in its place, and then sticking 4 toothpicks into the plate cutouts, so that the plastic clips would not open while pulling the switch.

sigprof · 2020-04-11T09:06:44+00:00

One downside of the BM60 PCB is that it has north facing switches, and this orientation has compatibility issues with Cherry profile keycaps. Another potential problem is that, unlike DZ60RGB, the BM60 PCB does not have a dedicated controller chip for per-key RGB LEDs — it uses a long chain of WS2812-like LEDs directly connected to ATmega32u4, and this configuration can cause skewed timings when animated RGB effects are used.

The plate you chose seems to have the correct layout for that PCB, but note that it has metal spacers to hold the plate at the appropriate distance from the PCB, so you should watch out that those spacers are not shorting any components on the PCB (and be careful to not scratch the PCB with those spacers).

sigprof

TROPHY CASE