Just got my Pocket Reform! -- quick question

MNT Pocket Reform
1

Good morning!
I wanted to thank everyone involved at mntre (esp Plom) for getting me my order on time. I’m about to go (tomorrow) on a family trip to celebrate my daughter’s Med school graduation, and since we’re traveling light, this Pocket Reform was very much needed.

So, since I have so very little time left before leaving, I just wanted to make sure I don’t mess up the initial setup. I’m very familiar with UNIX, esp FreeBSD, but have just a little experience with Linux (mostly SuSE/ OpenSuSE). This will be my first time using and setting up Debian.

So my questions (after doing some research):

  1. After initial config (with GNOME), I assume the first steps should be to run, as root:
    apt update
    apt upgrade
    Correct? No need to do anything with the firmware? Is this step really necessary?
  2. Then, since the Pocket came with an nVME SSD, I should run, also as root:
    reform-setup-encrypted-disk – or maybe this step should be performed before (1) ?
  3. Then install a (real) editor, ie EMACS :slight_smile:
  4. I’m more familiar with KDE/Plasma than with gnome, although don’t mind giving gnome a try. Would it be too risky (since I’m about to travel) to install Plasma?
  5. I love the Debian concept of metapackages. So if I wanted to install Plasma, I would just need to
    apt install kde-full
    Correct?
  6. If I wanted to do a little C/C++ programming on the Pocket, the right metapackage is
    apt build-essential
    This will install gcc correct? So if I wanted clang, that would be a separate install? I already found the Lisp and the Julia I also use.
  7. The default fs on Debian appears to be ext4. I assume that given the hardware constraints of such a small platform, it would completely ridiculous to even try some other fs (ie, ZFS or even XFS)? Just want confirmation.

Thanks for reading, and sorry for taking your time with such basic questions! Any comments are more than welcome.

2 Likes
2

Connect to the internet and then run apt update && apt full-upgrade. Just running apt upgrade instead of apt full-upgrade will not upgrade everything but prevent upgrading packages which require removal of other packages to upgrade and it will not autoremove, for example (and most importantly) old kernel packages.

Depends on your firmware version. The quickest way to not only get your firmware version but also other information about your system status is to run sudo reform-check

This only matters if there were improvements to reform-setup-encrypted-disk recently and while there were some improvements, they probably do not affect you.

It would be more risky but it should work fine, especially since recent reform-tools installs the workaround for the cursor rendering.

I’m not sure, sorry. Though I thought the right meta package would be plasma-desktop.

The build-essential package gives you a C/C++ compiler (gcc), yes. But the package is intended as the absolute minimal requirements to build Debian packages, so you get a bit more than the compiler. You can also just install gcc to get a compiler only.

Yes.

I have not heard of somebody using ZFS on the Pocket but with RK3588 and 32 GB of RAM it might not be too terrible?

2 Likes
3

As you’re on a tight timeframe, and we just shipped this device to you, I’d recommend not to update anything except reform-tools at this point, to get reform-power-daemon which will help against brownouts.

As the device has 256GB fast eMMC you don’t need to migrate to encrypted NVMe right now, you can do it later when you’re not in a hurry.

For Plasma, I would strongly recommend against it in your situationn because there’s too much risk of messing up your system. Do this later when you have time and another computer for recovery and research of any small issues etc.

I would recommend to take a MicroSD card with a copy of a System Image from mnt.re/system-image dd’ed to it with you in case you run into some untested situation on the go (for example, trouble with the login manager, KDE plasma deciding to use an overlay plane for the cursor and crashing, etc), so you can boot and fix things from that if needed.

8 Likes
4

Hi @ricardo just checking in on you. Did things actually work out? Or did something break and would you appreciate help?

1 Like
5

My apologies @josch and @minute for not replying any sooner! Being the cautious (aka paranoid) person that I am, I eventually decided that I didn’t want to perform the setup with so little time before my travel. I ended taking up my un-configured Pocket, an external SSD with all my data, since my wife was taking her MacBook Air. That way, I thought I could configure my Pocket at my leisure, with not so much pressure.

Bottom line: I couldn’t be happier!!!
From the packing used (so nice!), the beautifully sculpted case, the very satisfying clicky keyboard to how clever its electronics design is – this is a beautifully engineered product. I wish I could have used something like this when I was teaching ECE classes.

I followed a combination of both the suggestions made by @josch and @minute – thank you both.

First thing I did was created the boot image on a MicroSD, just in case (as suggested by @minute). Then tested that I could boot from it.

Then I did

sudo apt update
sudo apt full-upgrade

rebooted, and

reform-setup-encrypted-disk

Everything worked perfectly.

I also realized how biased and prejudiced I can be sometimes :wink:

I have been a KDE / Plasma user since forever, and whatever desktop the Sun Solaris Sparcstaions used a long time ago. Decided to give gnome a try again (last time I tried it was perhaps 20 yrs ago). Not bad – at all!! I do enjoy its simplicity, esp for a small screen. So thus far, no need to install Plasma. As a matter of fact, I’m considering building my next app with GTK. Seems to be lighter and simpler than QT, but that’s just my very preliminary opinion.

The only minor “con” so far is that wireless performance can be a little spotty. Glad I’ve been doing all of the above with a wired connection.

Bottom line: I’m thinking about getting another Reform :slight_smile: That’s how happy I am.

Edit: I’m still getting used to the apt package manager. Thus far, I think I like pkg from FreeBSD and zypper from openSuSE just a tad better. But I’m just getting familiar with it.

7 Likes
6

There certainly are “quirks” when you come from elsewhere. If you have any questions, feel free to ask!

I’m glad that everything worked out for you in the end. :slight_smile:

1 Like
7

Thank you @josch for your kind words.
Just another quick question, if you don’t mind:

What is the best practice for people running Debian Sid (that’s how the unstable version is called, correct?), esp on a Pocket Reform, on running an apt full-upgrade on the system? Daily? Weekly? Monthly? I guess not having boot environments by default provides for a greater risk of messing up the system?

Thanks!

9

If you also want opinions from other ppl, let me burst in here :wink:

I update it regularly.. like every 1-2 weeks with a full upgrade. I’m used to rolling releases and kinda know which packages could mean trouble after updating. Also i like to have smaller jumps between upgrades, lesser package changes means easier spotting the problem ^^

With my old systems i had seldom real problems, like 1 or 2 times in the past 7 years where the system won’t boot anymore after an update.

Just one big recommendation (but you did that already great with your planned travel which you mentioned a few posts before). Never update the night before you wanna travel or don’t have time to fix stuff. I actually learned that the hard way a few years ago, where i spend half the night fixing my system before my travel next morning XD

1 Like
10

I don’t think I can give a very good recommendation here but maybe here are some things to consider: when running apt full-upgrade you will be presented with a list of release critical bugs in the versions of the packages that you are upgrading to and then are offered the chance to not perform the upgrade if you decide that one of the bugs could affect your system. But of course for those bugs to exist, somebody must’ve run into them before you and maybe you upgrade at a time where a package just got uploaded and then you are the first person running into the bug and thus nothing was reported yet. The instances where the system will not boot at all anymore are usually rare and often depend on specific system configurations. I’m not collecting any statistics about this but reform-specific problems are usually talked about in this forum and i’d suspect that problems of the “it will no longer boot” kind (in one way or another) are relatively rare and maybe happen once or twice a year? Just a gut feeling from reading this forum, maybe others have a different feeling or can even provide hard numbers. Maybe before you run a apt full-upgrade check the most recent forum threads if maybe somebody else has run into a problem recently. If you do encounter problems, either write a bug report to the Debian BTS if the bug is Debian specific and/or create a new post about the issue here. Having said all this: how often do you want to do this? If you do it very often you increase the chances that you are the first one to install a recently uploaded package version. If you do it too infrequently, you are going to run outdated software with security issues because Debian unstable does not receive security uploads in the same sense as they are done for Debian stable.

Yes. Maybe however often you do it (maybe every two weeks or so?) make sure you are able to set some time aside to first do a backup (which we all are performing regularly anyways, right? :upside_down_face: ) then check the forum, then perform the upgrade and investigate RC bugs that you are shown, finish the upgrade and if anything should’ve gone wrong, investigate what it is and report the problem so that it can get fixed and others don’t run into it.

Thanks! :heart:

3 Likes
11

I started with Debian in ‘97 and switched to NixOS in 2016. It is almost ten years ago that I had to worry about updates as NixOS has atomic updates and generations.

The atomic part means an update either succeeds and gets active, or it fails and nothing happens. No in between mix of a partly applied update.

The generation part means that if a successful upgrade contains a broken kernel (or a broken version of mesa on aarch64) I either rollback (atomic/instant) or boot into a previous generation.

These days I update all my servers/workstations/laptops unattended every 30 minutes and even auto-reboot some of my servers (including my router) when a new kernel or initrd is installed.

Other niceties are that everything is declared which means that one defines what software is installed and how it is configured, and that nixpkgs is the largest repository.

I appreciate how one is attached to their ways and that switching distributions (especially one as nice as Debian) is not to be taken lightly, but I had to respond to the above quote and share with the community that there are other ways.

1 Like
12

These days, reform-tools tries to be distro-agnostic. I welcome patches which improve reform-tools for NixOS users/packagers as well as bug reports for things that I can fix. :slight_smile:

1 Like
13

From https://source.mnt.re/reform/reform-tools:
It contains system utilities to manage your installation as well as configuration files for initramfs, flash-kernel, pulseaudio, alsa, u-boot-menu, udev and NetworkManager.

The things mentioned are all fundamentally managed by NixOS. I’m not sure it would make sense to create a nix package out of reform-tools. What would a Reform user miss if NixOS ran without reform-tools?

Btw, browsing the repository it looks like reform-tools is more about configuration than actual tools (like binaries) or am I overseeing something?

14

For example, have a look at reform-hw-setup. Each of the platforms requires a quirk or another to work properly. Without the environment variables reform-tools ships in /etc/profile.d various things on the desktop will not work right. The udev rule you mentioned allows imx8mq to wake up from suspend. Without the lpc module you don’t have battery status and you cannot properly shut down your unit. Without the systemd sleep service, imx8mq cannot enter suspend. Without the reform-power-daemon service, pocket reform will randomly shut off. Without the ucm profiles you’ll not be able to switch between headphones and speakers on pocket reform. Without the network manager config, your wifi will randomly drop. Without the sddm config, kde plasma cannot start. Without the dracut config, kernel modules required for display will be missing if you use dracut.

The tools are mostly about convenience scripts. Maybe in nixos there already exist utilities to migrate installations, set up partitions, flash u-boot, restore broken /boot partitions, move from one SoM to another, flash rescue images or change the boot order for u-boot. But at least in Debian we didn’t have things that can do the same yet. If NixOS has this maybe things can be shared?

Lastly, without the machine config file, there is no machine readable and declarative source of information like: what is the dtb path, what are system image names, is it even allowed to write to emmc, can the platform boot from emmc or only from sd-card, what is the device name for emmc, sd, usb and nvme, what are u-boot offsets, what are the u-boot ${bootargs}, what are the latest u-boot hashes and versions.

All of the above is part of a package because it is all specific to the MNT Reform platforms. Maybe the above is organized differently under NixOS and that’s why reform-tools is not needed? At least in Debian, things like this are organized on a per-package basis but maybe that is just a Debian specific convention?

1 Like
15

In NixOS most vendor specific configuration happens in nixos-hardware. I now see there already is nixos-hardware configuration for MNT Reform. I’m not sure how complete it is, but that would be the reform-tools equivalent.

I do not use nixos-hardware myself as I prefer to be a bit more in control. This means I have to configure kernel module loading, environment variables, udev rules and kernel configuration myself. I do not have a Reform yet, but I do have a Librem 5 (i.MX8MQ), a Raspberry Pi 4 (BCM2711) a NanoPi R6C and CM3588-NAS (RK3588S) and a T14s (X Elite) which all require a bit of extra configuration compared to x86_64.

Some snippets:

Module and kernel configuration (bit outdated) for Librem 5:

{
  boot = {
    initrd = {
      includeDefaultModules = false;
      kernelModules = [
        "bq25890_charger"
        "dwc3"
        "imx_dcss"
        "imx_sdma"
        "mtdblock"
        "ofpart"
        "phy_fsl_imx8mq_usb"
        "snvs_pwrkey"
        "spi_nor"
        "tps6598x"
        "xhci_hcd"
        "usbcore"
        "usb_storage"
        "uas"
        "xhci_plat_hcd"
      ];
      systemd.tpm2.enable = false;
    };
    kernelPackages =
      let
        kernel_pkg =
          { buildLinux, ... }@args:
          buildLinux (
            args
            // {
              defconfig = "librem5_defconfig";
              ignoreConfigErrors = true;
              version = "6.6.74-librem5";
              src = builtins.fetchGit {
                # git ls-remote https://source.puri.sm/Librem5/linux.git pureos/latest
                url = "https://source.puri.sm/Librem5/linux.git";
                ref = "latest";
                rev = "3449208c3c6bff93fe3b09862400e9e2b15fa607";
              };
            }
            // (args.argsOverride or { })
          );
        kernel = pkgs.callPackage kernel_pkg { };
      in
      pkgs.recurseIntoAttrs (pkgs.linuxPackagesFor kernel);
    kernelPatches = [
      {
        name = "librem5-extraconfig";
        patch = null;
         extraConfig = ''
          EFI y
          EFIVAR_FS m
        '';
      }
    ];
  };

  hardware = {
    deviceTree = {
      enable = true;
      name = "freescale/imx8mq-librem5-r4.dtb";
    };
  };

udev rules look like:

  services = {
    udev = {
      packages = [
        (pkgs.writeTextDir "lib/udev/rules.d/50-numworks-calculator.rules" ''
          SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="a291", TAG+="uaccess"
          SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="df11", TAG+="uaccess"
        '')
      ];
    };
  };

NetworkManager powersave would be configured with https://nixos.org/manual/nixos/stable/options#opt-networking.networkmanager.wifi.powersave

The reform-specific scripts could be good candidates to be nix-packaged. I’m not sure if there is a NixOS way of implementing these helpers.

One thing to consider is that an OS (Debian) shipped with a Reform is meant to work out of the box. If one installs a different OS, for reform-tools all bets are off.

16

Hrm… this sounds like things just have to be re-implemented for NixOS? This sounds like a whole lot of copypasta and a constant maintenance burden as somebody has to keep copying the things that change in reform-tools over to the NixOS config?

And so is the lpc dkms module. Without it, you do not see battery status nor can you properly shut down your machine.

How do you mean this?

17

Yes. This maintenance burden is a fact for any software.

Ah, yes, I assumed the module was part of the kernel and only needed to be loaded. The compilation and packaging of software is the core of the package manager nix.

reform-tools makes a lot of assumptions about the OS it gets deployed on. Paths to binaries and configuration, installed software, available kernel modules, the use of systemd, etc. It is not doable to expect reform-tools to run on all different combinations of Linux distributions out there.

18

Why not? Are not most free software packages made to run on different combinations of Linux distributions out there?

As a maintainer of packages in Debian I regularly communicate assumptions which Debian makes to upstream projects so that they can make their software work better on Debian. Is that not a normal thing to happen for any free software project that is getting packaged by distros?

19

Just a small data point about apt full-upgrade – I’m a compulsive upgrader. Like, daily. So far, in the … 10 months or so I’ve had access to MNT Reform hardware, I’ve run into “not booting”/”black screen” bugs about 3 or 4 times. In all cases, I could recover things by booting off an image on an SD card. YMMV.

1 Like
20

Because reform-tools depends on systemd for example, which not all distributions run. It depends on dpkg, dracut and plymouth, on /bin/sh being bash, on paths such as /bin, /usr/ and /etc/profile.d which all are not always available.

21

And if your distro does not support systemd, then I’ll welcome integration with other init systems.

That’s mainly reform-check. There is a merge request to make it work with the void linux package manager: Draft: Update reform-check to work with Void linux (!115) · Merge requests · Reform / MNT Reform Tools · GitLab If your distro does not use dpkg, then lets add support for your package manager.

It does not. The default initramfs generator in Debian is mkinitramfs. But either is optional. If you don’t use dracut, then the files it ships for dracut are installed but will just not be used.

It does not. Most reform users are not using plymouth.

If you find a script that makes such an assumption please report this as a bug. I’m using shellcheck in our tests to make sure that I only use POSIX shell constructs in the scripts. There is one script written in bash and that could be turned into POSIX shell if your distro does not have bash.

As does a lot of other software and still that software does work on NixOS, no?

Could we not instead be constructive about this and fix problems where they exist? I do not see how reform-tools as a software project is special here. Other upstream projects also start off with the main developer using distro X and they make assumptions accordingly. Then users of other distros find the software interesting, so they file bugs as appropriate and the software gets fixed.

Can you list a hard problem which cannot be solved by the usual process of how a lot of other software packages were already changed to work well with NixOS?