Xfce switches to GitLab
GitLab is here!
Starting today, May 1, we’re switching from our cgit/gitolite setup to GitLab. Our old server, git.xfce.org, is now a ready-only in-sync mirror (so you can still pull code). Our new server is gitlab.xfce.org.
(The detailed version of this blog post can be read in my announcement on the Xfce Mailing List.)
For users nothing changes.
For distributors nothing changes (presuming you’re using the release tarballs and not Git tags).
For developers and contributors quite a few things change.
- Most importantly: The Git URL changed, so you need to update the remotes of your local repositories. Feel free to use our helper script.
- Fork repositories and use branches and merge requests!
- If you don’t have an account yet (we created quite a few for you regulars already) please sign up! We have opened registrations for GitLab accounts as well as allowing you to register with your GitHub account (if you have one).
Please poke us on IRC or the mailinglist if you’re lacking repository access or ownership. (By default new users cannot fork before being manually approved. Yes. We are afraid of the spambots.)
Have a nice GitLab!
Running a Modern Debian on the Netgear ReadyNAS NV+ v2
I have an old ReadyNAS NV+ v2 (not to be confused with the SPARC-based v1) that has been my workhorse home NAS for a good 7 years now (previously I had an older Netgear NAS that suffered a hardware failure and needed to be replaced). It’s a great piece of hardware, but the software hasn’t seen a major update in many years, and the OS is based on Debian squeeze, which is several releases behind current stable, and is no longer maintained.
I recently tried to visit the NAS’s admin web UI, only to see a recently-updated Firefox throw up a big scary security warning, telling me that TLS 1.0 and 1.1 are disabled in the browser, but the server I’m trying to connect to (the NAS) doesn’t support TLS 1.2 or newer. It allowed me to bypass the warning for now, but eventually I expect that older TLS versions (just like SSLv3 before it) will be removed entirely.
No problem, I thought, as I ssh’ed into the NAS. As I expected, the
issue was that Apache was linked against an old version of OpenSSL which
lacks TLS 1.2 support. To avoid disturbing the system itself too much,
I figured I’d use debootstrap to create a chroot with a more modern
Debian version, and run the webserver (or a proxy) from there.
But that didn’t work out. The glibc versions in Debian testing, buster, stretch, and even jessie all require a newer kernel than what’s running on the ReadyNAS (2.6.31.8). I looked at some other OSes, like Alpine (which uses musl and wouldn’t have the same issue) and nixOS (which I expected might just be more flexible), but neither of them support the armv5-based CPU in the NV+ v2.
After a bunch of dead ends, I finally ended up natively building a newer
version of OpenSSL, as well as HAProxy, on the NAS itself, and installed
it to a private prefix. That ended up working, but was largely
unsatisfying. Even before this, I’d lamented being unable to run newer
versions of some software (offlineimap, for one thing) on the NAS.
So I started poking around to see if anyone has done a large, unsupported upgrade on this hardware. I didn’t find any concrete instructions, but I did find some encouraging information. I found someone who had cataloged all the hardware of the device, and had upstreamed support for the board into the Linux kernel, and had noted that nearly all the hardware (save the front-panel LCD) is now supported by the upstream kernel. I found a reference on Debian’s ARM EABI port page that the ReadyNAS NV+ v2 is specifically supported by the upstream kernel.
WARNING
First off, a big disclaimer:
This is inherently risky, and you can very easily brick your NAS to the point where it will be incredibly difficult to recover it. I recommend you open it up and make sure you can get the serial console working before proceeding with any of these steps (there are instructions in one of the above links).
Also remember that, while it is possible to connect your NAS’s drives to a computer running Linux in order to assemble the RAID/LVM array to pull data off, you should have a backup of all data to be safe.
Kernel
The first step is to get a more modern kernel running on the box.
Unfortunately the ReadyNAS’s stock kernel is compiled without kexec
support, so we can’t experiment without overwiting the one-and-only copy
of the bootable kernel on the ReadyNAS’s flash chip.
TODO: see if the stock u-boot supports USB booting and how to get that to work.
The flash chip is partitioned like so:
The first partition contains the u-boot bootloader, with the second
holding environment variables that control u-boot’s operation. The
third (uImage) holds the kernel, and the fourth (minirootfs) holds a
small initial RAM disk that kicks off the boot process before turning
control over to the main rootfs. The fifth partition, jffs2, contains
- First back up all flash partitions on the NAS:
for i in /dev/mtd*; do sudo dd if=$i of=$(basename $i); doneBe sure to copy the resulting files off to another computer for safekeeping. apt install gcc-arm-linux-gnueabi u-boot-tools screen lrzsz- Grab kernel of your choice (I used 5.6.6; here’s .config), and build
with:
make zImage ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- - Make u-boot image for kernel:
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.6.6 -d /path/to/linux/arc/arm/boot/zImage kernel.img - Extract the initrd file system image (from the backup of
mtd3created earlier):dd if=mtd3 bs=64 skip=1 | gunzip -c | sudo cpio -i(Strip the 64-byte uImage header, unzip, extract). - Patch
initto not try to load Netgear’s proprietary kernel modules (which are no longer needed):sed -i -e 's/insmod/ls /g' init - Repackage the initrd:
find . -type f >name-list && sudo cpio -o <name-list | gzip -9 -c >initrd.gz && rm name-list - Make u-boot image for initrd:
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initrd -d initrd.gz initrd.img