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); done
Be 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
mtd3
created 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