Making XU4 Devuan Starting From Ubuntu Kernel

I’m doing a “do over” of making a working Devuan, but starting from Ubuntu for the boot loader, kernel, etc.

Why? Because I suspect that the use of a FAT file system /boot may be common between the two, where Armbian has a very different approach. I’m curious to see if the process is in any way ‘easier’.

Firxt, get a copy of Ubuntu from:

ems@XU4devuan2:/SG2/ext/XU4$ ls -l
-rw-r--r-- 1 root root 1303410760 Oct 13 16:57 ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img.xz

Uncompress it with the linux command “unxz”.

root@XU4devuan2:/SG2/ext/XU4# unxz ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img.xz 


ems@XU4devuan2:/SG2/ext/XU4$ ls -l
-rw-r--r-- 1 root root 6453985280 Oct 13 16:57 ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img

Yes, almost 6 1/2 GB of stuff. Ubuntu is Very Fat… Now, put that onto a uSD card (in a USB adapter) via dd. I’m very fond of using gparted at this point to display the partition structure of all mounted disks and cards just to assure I really really know what device is the target, since using “dd” will nuke anything on the target. The use of the gparted graphical partition editor on Linux is a very nice way to see all disks all partitions in one go, but often you need to install it first with “apt-get install gparted” on Debian / Devuan / Ubuntu etc. You can use the “file” command to look at partitions one by one and that is often enough. I’ve bolded some bits:

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 8388592, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0fae20edde20e9e4f; contains Microsoft Windows XP/VISTA bootloader BOOTMGR

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sda2
/dev/sda2: Linux/i386 swap file (new style), version 1 (4K pages), size 524287 pages, LABEL=SG2_swap, UUID=cbf6b665-c6a2-49cc-9d46-b3ed9e2e6ba0

I happen to know that disk /dev/sda always shows up first as my major scratch disk on this system. This is also where having certain naming standards or habits is helpful. I leave an NTFS partition at the front of new real rotating media disks where I leave whatever stuff the vendor included (often backup software for Micro$soft and / or boot sectors for them). I use gparted to shrink that down to something small and add other partitions for Linux use in almost all of the space. Typically, I’ll put a “swap” partition in number 2 position. This makes it easy to know what target to aim the “file” command at.

Notice /dev/sda2 is a swap partion with the LABEL I gave it of “SG2_swap”. Each of my disks I name with a clear short flag. This is my SeaGate 2 GB disk. So I can easily know that /dev/sda is just not a disk I want to mess with in the copy as it is my MAIN daily driver disk for home directory, swap space, etc. Note that I mount it on /SG2 and in my command prompt you see my working directory is /SG2/ext/XU4. I’m currently using that disk, but another partition, for this Ubuntu image handling.

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sda14
/dev/sda14: Linux rev 1.0 ext3 filesystem data, UUID=f0302962-76a5-4859-9bbf-e7a73214df44, volume name "SG2_ext3" (needs journal recovery) (large files)

Yeah, the 14th partition… Having 2 TB you can go a bit nuts on partitions ;-) But this is not the disk we want…

The next one is the last one plugged in. It has a Linux file system on it, but I know I was using this chip for a generic Armbian install from about 2019 that I no longer want. It is not mounted at present so no mount point shows up. Also note that the next slot after it, sdc, is empty and nothing shows up. So sdb is my target device.

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=9e93ad0d-7a3f-4fb0-97f8-66dcb548a6da (extents) (large files) (huge files)

root@XU4devuan2:/SG2/ext/XU4# file -s /dev/sdc1
/dev/sdc1: cannot open `/dev/sdc1' (No such file or directory)

Confirmation can be had to some degree from ‘df’:

ems@XU4devuan2:~$ df

Filesystem      1K-blocks      Used  Available Use% Mounted on
udev                10240         0      10240   0% /dev
tmpfs              204484       492     203992   1% /run
/dev/mmcblk1p5    4062912   3424048     429152  89% /
tmpfs                5120         4       5116   1% /run/lock
tmpfs             1247820     76660    1171160   7% /run/shm
/dev/mmcblk1p1    6160512   3281828    2796760  54% /SD/Devuan
tmpfs             2097152        16    2097136   1% /tmp
/dev/sda12      103081248  15599304   82239064  16% /SG2/home
/dev/sda14     1757578792 112005792 1556286448   7% /SG2/ext
/dev/sda15        8190392   2518584    5252432  33% /sq/sq
tmpfs             1022404         0    1022404   0% /sys/fs/cgroup
tmpfs              204480        12     204468   1% /run/user/1600

The /dev/mmcblk1px slices are the uSD card currently booted. My “multiboot multisystem” 32 GB card. Devuan 1.0 is in the /dev/mmcblk1p1 partition (mmc for mmc card, which it isn’t but they use the name anyway, blk for block device, 1 as the second one the 0 of first one being the real mmc mount below the board that I’m not using, and then p1 for partition one.). I have it mounted as /SD/Devuan. The running OS mounted on ‘/’ is /dev/mmcblk1p5 so the 5th partition on the card. It’s a Devuan 2.0 but using the /boot and kernel from the p1 partition to boot up.

We can also see several /dev/sda partitions mounted as /SG2/home /SG2/ext and /sq/sq (where I was playing with read-only squashfs filesystems for things like /usr and /lib and such)

No mounts for /dev/sdbx or higher. So, OK, pretty clear we can proceed to toss the image of Ubuntu onto that card. Being VERY careful to get the drive letters Just Right and remembering we are using the whole device /dev/sdb not any one partition like /dev/sdb1.

This is the copy command, but I put the “time” command in front of it to give us some timing data on how long it runs. Yes, dd does that itself, but in seconds and I’m being lazy and avoiding the conversion to minutes ;-) With writing 6 GB to a slow uSD card, this takes a while, so get get lunch… or something:

root@XU4devuan2:/SG2/ext/XU4# time dd bs=10M of=/dev/sdb if=ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img 

The 10M says to use 10 MB buffer size. I’ve tried other sizes and this seems to be a decent one for both speed and reliability. On some slow systems, using a buffer like 100M can cause instability in the uSD writing process. Shoving a bit much at some cheap cards means they can’t keep up ;-) In any case, it seems to be very reliable to use 10M.

After it completes the copy:

root@XU4devuan2:/SG2/ext/XU4# time dd bs=10M of=/dev/sdb if=ubuntu-20.04.1-5.4-mate-odroid-xu4-20200818.img 
615+1 records in
615+1 records out
6453985280 bytes (6.5 GB, 6.0 GiB) copied, 887.088 s, 7.3 MB/s

real	14m47.156s
user	0m0.001s
sys	0m48.725s

So about 15 minutes. I’d made a “backup” copy of my Devuan 2.0 standalone based on Armbian, but using a so-so Kodak uSD card and in a USB 3.0 adapter in the USB 3.0 port of the XU4, AND using 100M buffer size. It got about 16 MB/s write, 32 MB/s read. Then put “something else” on the card. When I tried restoring it, it was corrupted. So “something” in that set was ‘a problem’. Either the uSD card could not keep up with 100 MB at high speed, or the USB 3.0 adapter couldn’t take the speed or 100M buffer was just too big or “whatever”. I suspect it was the card at USB 3.0 speeds of 100MB size. Why? The copy on real disk was corrupted. That’s a read operation from the uSD card. It wasn’t limited by the peculiar write dynamics of uSD cards. At any rate, I’ve gone back to my old always reliable set of USB 2.0, Samsung or Sandisk uSD cards, and smaller buffer size for now. “Someday”, when I have nothing better to do, I’ll try the various parts individually and see what was the problem. But I figured if I’m making a new one, might as well try the Ubuntu starting point ;-)

FWIW I’ve used the Kodak card for various OS builds without issue before. But always using 10 MB buffer size in a USB 2.0 slot. I’ve also had “issues” with the USB 3.0 not working quite right on the XU4 in early OS releases (but fixed about a year+ ago). Finally, there’s also the point that I’m using a bastard mix of kernel, kernel modules, firmware, and Userland to do this work, so it’s possible one of them is just not up to the task. (BUT it did work fine at USB 2.0 / 10 MB …)

Now you can boot it up and let it do the new card file system expansion and such. At this point, you can also dd off a new copy of this uSD card to make restarting the process easier OR save it just as a working Ubuntu.

That’s what I’m going to do right now. So “back in a bit” as I only have one XU4 and can’t type this on it while I’m booting the chip ;-)

OK, after lunch and booting / shutting down the Ubuntu port. It worked and the card + image looks fine. In fact, it does put /boot on the first FAT partition (rather like the Devuan /etc/fstab expected. I went ahead and made a few more partitions (use the ‘move / shrink option of gparted to free up space at the end, then use the ‘new’ option to make some new partitions) on the uSD card.

Next up, we mount those partitions. Copy over the /boot /lib/modules and /lib/firmware from the Ubuntu partition to the save spaces. Then we can “blow away” the Ubuntu image, copy into that space the Devuan 2.0 tar files, and return the /boot /lib/modules and /lib/firmware bits to where they belong in the file system name space.

At that point, it ought to just boot and go. I’ll take ANOTHER dd image of the card anyway just to have a useful checkpoint / restart point and in case I want to try other things in the future without starting from scratch.

Here’s the spaces I made to mount things:

root@XU4devuan2:/# ls /SD
Armbian  Devuan2  Funtoo  Hyarm64  misc  slack	temp
Devuan	 ext	  Gentoo  Hyarmhf  ms	 sq	XU4
root@XU4devuan2:/# mkdir /SD/firmware
root@XU4devuan2:/# mkdir /SD/modules
root@XU4devuan2:/# mkdir /SD/boot
root@XU4devuan2:/# mkdir /SD/Ubuntu
root@XU4devuan2:/# mount /dev/sdb1 /SD/boot
root@XU4devuan2:/# mount /dev/sdb2 /SD/Ubuntu
root@XU4devuan2:/# mount /dev/sdb3 /SD/firmware
root@XU4devuan2:/# mount /dev/sdb5 /SD/modules
root@XU4devuan2:/# mount /dev/sdb6 /SD/temp

/SD is where I mount SD card file systems to work on them. Be they full sized SD cards or the small uSD. It tends to accumulate useful and meaningful mount point names over time ;-)

root@XU4devuan2:/# df

Filesystem      1K-blocks      Used  Available Use% Mounted on
udev                10240         0      10240   0% /dev
tmpfs              204484       592     203892   1% /run
/dev/mmcblk1p5    4062912   3424264     428936  89% /
tmpfs                5120         4       5116   1% /run/lock
tmpfs             1247820     63892    1183928   6% /run/shm
/dev/mmcblk1p1    6160512   3281828    2796760  54% /SD/Devuan
tmpfs             2097152         4    2097148   1% /tmp
/dev/sda12      103081248  15589936   82248432  16% /SG2/home
/dev/sda14     1757578792 142411428 1525880812   9% /SG2/ext
/dev/sda15        8190392   2518584    5252432  33% /sq/sq
tmpfs             1022404         0    1022404   0% /sys/fs/cgroup
tmpfs              204480        12     204468   1% /run/user/1600
/dev/sdb1          130798     16742     114056  13% /SD/boot
/dev/sdb2        25639236   4648024   20974828  19% /SD/Ubuntu
/dev/sdb3          999320      1320     945572   1% /SD/firmware
/dev/sdb5          999320      1320     945572   1% /SD/modules
/dev/sdb6         1014680      1304     961000   1% /SD/temp

So now I need to do a cd into the various directories, and copy their contents over to the mounted partitions where I’m going to save them. There are a dozen ways you could do this. For example, I could just ‘tar’ off the stuff into a tar file in /SG2/ext and have a saved copy, then restore it with “tar xvf FOO” into the new space. I often use a one line script to move things, of the form “(cd /FOO; tar cf – .) | (cd /BAR; tar xvf – ) as it does a good job with not following symbolic links and not screwing up ownership, permissions, and date stamps. HOWEVER, if you type “cd /BAR” wrong and the cd fails, it does the unpack wherever you are at the moment. This can have horrible effects… (Like if you are in /FOO at the time, overwriting the /FOO you are moving with partial blocks and screwing it all up so you get to start over…)

So I’m going to show the “safer” way of making a copy to a different disk, then doing the copy back.

root@XU4devuan2:/# mkdir /SG2/ext/Save_Ub
root@XU4devuan2:/# ls -ld /SG2/ext/Save_Ub/
drwxr-xr-x 2 root root 4096 Oct 13 21:03 /SG2/ext/Save_Ub/

Then the actual “make copies”.

root@XU4devuan2:/# cd /SD/boot
root@XU4devuan2:/SD/boot# ls
boot.ini		  exynos5422-odroidxu3-lite.dtb  uInitrd
config.ini		  exynos5422-odroidxu4.dtb	 zImage
exynos5422-odroidhc1.dtb  exynos5422-odroidxu4-kvm.dtb
exynos5422-odroidxu3.dtb  overlays
root@XU4devuan2:/SD/boot# tar cf /SG2/ext/Save_Ub/boot.tar .

Notice you didn’t get much feedback? Add the -v option for verbose feedback. Here’s a partial on the modules file system:

root@XU4devuan2:/SD/Ubuntu# cd /SD/Ubuntu/lib/modules/
root@XU4devuan2:/SD/Ubuntu/lib/modules# ls
root@XU4devuan2:/SD/Ubuntu/lib/modules# tar cvf /SG2/ext/Save_Ub/Modules.tar .

/lib/firmware has a lot in it too, so only a partial listing:

root@XU4devuan2:/SD/Ubuntu/lib/modules# cd ../firmware
root@XU4devuan2:/SD/Ubuntu/lib/firmware# ls
1a98-INTEL-EDK2-2-tplg.bin   iwlwifi-8265-36.ucode
3com			     iwlwifi-9000-pu-b0-jf-b0-33.ucode
a300_pfp.fw		     iwlwifi-9000-pu-b0-jf-b0-34.ucode
a300_pm4.fw		     iwlwifi-9000-pu-b0-jf-b0-38.ucode
acenic			     iwlwifi-9000-pu-b0-jf-b0-41.ucode
adaptec			     iwlwifi-9000-pu-b0-jf-b0-43.ucode
advansys		     iwlwifi-9000-pu-b0-jf-b0-46.ucode
agere_ap_fw.bin		     iwlwifi-9260-th-b0-jf-b0-33.ucode

Here’s the command:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# tar cvf /SG2/ext/Save_Ub/firmware.tar . 

Note that the trailing ‘.’ is vitally important. It says “copy from this, your current working directory”. You could get the same effect with an absolute path name like (scroll right to see the difference):

root@XU4devuan2:/SD/Ubuntu/lib/firmware# tar cvf /SG2/ext/Save_Ub/firmware.tar /SD/Ubuntu/lib/firmware

Useful if you do NOT “cd” into the target directory.

And now here’s the saved stuff:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# ls -l /SG2/ext/Save_Ub/
total 591768
-rw-r--r-- 1 root root  17141760 Oct 13 21:04 boot.tar
-rw-r--r-- 1 root root 535879680 Oct 13 21:12 firmware.tar
-rw-r--r-- 1 root root  52336640 Oct 13 21:08 Modules.tar

In Theory, I can just leave the /boot as it stands (not copy back the saved bits from /SD/boot) and I’m going to try that. But, should I want to do this to some other uSD card, I’ve saved a copy. Or if I fumble finger it and blow away /SD/boot…

Next we copy in the Devuan 2.0 tar ball, set aside those /lib/modules and /lib/firmware bits, and make a final check no /boot/boot.ini and another stuff that might need a tweek. I’m going to copy the firmware.tar and modules.tar stuff back into those small /SD partitions just so that I have copies on file system bits on the uSD card. I don’t need to do it this way. I could just stuff it into the existing Devuan image. But this lets me have more flexibility about when, using what workstation, etc. “It’s all on the SD card”… so easy to get to and use, or not. I can test just mounting the file system over what’s there vs ‘blow away and replace’, for example. This takes a while as writes to uSD are slow and Ubuntu has a LOT of firmware for all sorts of devices stuck in here (including stuff for the R.Pi M3 so clearly leaving stuff useless for this board in the build – essentially the ‘kitchen sink’ approach leaving in drivers for everything in the world even if you can’t use it with this hardware):

root@XU4devuan2:/SD/Ubuntu/lib/firmware# cd /SD/firmware/
root@XU4devuan2:/SD/firmware# ls
root@XU4devuan2:/SD/firmware# tar xvf /SG2/ext/Save_Ub/firmware.tar

Then kernel modules:

root@XU4devuan2:/SD/firmware# cd /SD/modules
root@XU4devuan2:/SD/modules# ls
root@XU4devuan2:/SD/modules# ls /SG2/ext/Save_Ub/
boot.tar  firmware.tar	Modules.tar
root@XU4devuan2:/SD/modules# tar xvf /SG2/ext/Save_Ub/Modules.tar

On to the “blow away the contents” of the / of Ubuntu. Since /boot is not mounted on that /SD/Ubuntu spot, I can just erase it all. BUT, remember that we have system file systems here that use Symbolic Links. “rm -rf” can follow symbolic links that might well point to parts of your running operating system via hard full path names (like, oh, /lib/whatever..) and break your system. For this reason, I prefer to use ‘gparted’ and just remake the file system. This will change the UUID (Universal Unit Identifier” and so the UUID in the boot partition will not be right, so you get to change that to something that will work.

So I’ll umount /SD/Ubuntu and use gparted to format that partition, then remount it and proceed to restore the Devuan tar tape file into it.

root@XU4devuan2:/SD/modules# umount /SD/Ubuntu/

Do the gparted format /dev/sdb2. I also labeled it “Ub_Devuan2”. Keep it ext4 as that’s what the boot loader / kernel expect to find.

root@XU4devuan2:/SD/modules# mount /dev/sdb2 /SD/Ubuntu
root@XU4devuan2:/SD/modules# df

Filesystem      1K-blocks      Used  Available Use% Mounted on
/dev/sdb2        25508076     45080   24144188   1% /SD/Ubuntu

So now you can see it is empty. I’d moved the tar image off to an Archive disk, /arc in the listing below. Wherever it is, you just need to un-tar it.

root@XU4devuan2:/SD/modules# ls /Arc/ext/UnpackWIP/XU4/
Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img	     devuan_ascii_2.0.0_armhf_odroidxu4.tar	     TEMP
Armbian_20.08.1_Odroidxu4_focal_legacy_4.14.195_desktop.img  NetBSD-9-earmv7hf-202009151800Z-odroid-xu3.img
devuan_ascii_2.0.0_armhf_odroidxu4.img			     stage3-armv7a_hardfp-20200509T210605Z.tar
root@XU4devuan2:/SD/modules# cd /SD/Ubuntu/
root@XU4devuan2:/SD/Ubuntu# ls
root@XU4devuan2:/SD/Ubuntu# tar xvf /Arc/ext/UnpackWIP/XU4/devuan_ascii_2.0.0_armhf_odroidxu4.tar 

Now in theory I can just make an /etc/fstab entry to mount my Ub_firmware and Ub_Modules partitions over the existing Devuan versions and be done. BUT, I don’t know for sure the order of “mount file systems” vs “load modules and firmware”. So initially I’m going to move the present Devuan /lib/modules to /lib/OLD_modules and move /lib/firmware to /lib/OLD_firmware; make new directories, and copy the tar file copies into them. Later I’ll try mounting the uSD files systems over those. Then eventually moving them to New_Modules and New_firmware and just mounting the uSD copy over the regular ones. This is not necessary to make this work, it is just me playing, learning, and finding the limits. All that’s really necessary is that copy off to a tar file, and then a tar extract into a new couple of /lib directories.

root@XU4devuan2:/SD/Ubuntu# ls
bin  boot  dev	etc  home  lib	lost+found  media  mnt	opt  proc  root  run  sbin  srv  sys  tmp  usr	var
root@XU4devuan2:/SD/Ubuntu# df

Filesystem      1K-blocks       Used  Available Use% Mounted on
/dev/sdb2        25508076     536100   23653168   3% /SD/Ubuntu

Note that it is presently about 500 MB.

Now I’m just going to set aside the old modules and firmware directories, make two new ones, and put the new stuff in them:

root@XU4devuan2:/SD/Ubuntu# cd lib/
root@XU4devuan2:/SD/Ubuntu/lib# ls
arm-linux-gnueabihf  ifupdown  lsb	 modules   systemd   udev
firmware	     init		     modprobe.d  startpar  terminfo
root@XU4devuan2:/SD/Ubuntu/lib# mv modules OLD_modules
root@XU4devuan2:/SD/Ubuntu/lib# mkdir modules
root@XU4devuan2:/SD/Ubuntu/lib# ls -ld modules OLD_modules/
drwxr-xr-x 2 root root 4096 Oct 13 21:52 modules
drwxr-xr-x 3 root root 4096 Jun  5  2018 OLD_modules/
root@XU4devuan2:/SD/Ubuntu/lib# mv firmware OLD_firmware
root@XU4devuan2:/SD/Ubuntu/lib# mkdir firmware
root@XU4devuan2:/SD/Ubuntu/lib# ls -ld firmware/ OLD_firmware/
drwxr-xr-x 2 root root 4096 Oct 13 21:53 firmware/
drwxr-xr-x 7 root root 4096 Jun  5  2018 OLD_firmware/
root@XU4devuan2:/SD/Ubuntu/lib# cd modules
root@XU4devuan2:/SD/Ubuntu/lib/modules# ls
root@XU4devuan2:/SD/Ubuntu/lib/modules# tar xf /SG2/ext/Save_Ub/Modules.tar 
root@XU4devuan2:/SD/Ubuntu/lib/modules# cd ../firmware/
root@XU4devuan2:/SD/Ubuntu/lib/firmware# tar xf /SG2/ext/Save_Ub/firmware.tar 

Clearly a lotof the size of Ubuntu is in all that firmwre for allthose devices you will never have on this board:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# df .

Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sdb2       25508076 1117004  23072264   5% /SD/Ubuntu


root@XU4devuan2:/SD/Ubuntu/lib/firmware# df /SD/firmware/

Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/sdb3         999320 531548    415344  57% /SD/firmware

Get the info needed for the boot files:

root@XU4devuan2:/SD/Ubuntu/lib/firmware# file -s /dev/sdb2
/dev/sdb2: Linux rev 1.0 ext4 filesystem data, UUID=32810fef-0978-42bd-83ec-c72f9782e091, volume name "Ub_Devuan2" (needs journal recovery) (extents) (64bit) (large files) (huge files)

Now you can either pass that UUID or that LABEL=”Ub_Devuan2″. Looking in /dev/sdb1 or /SD/boot/boot.ini:

# Boot Args
setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro net.ifnames=0 ${videoconfig} ${hdmi_phy_control} ${hid_quirks} smsc95xx.macaddr=${macaddr} ${external_watchdog}"

Either swap the new UUID for that one, or change it to “LABEL=” type.

Next, we check fstab:

root@XU4devuan2:/SD/Ubuntu/etc# cat fstab
## bootfs
/dev/mmcblk0p1    /boot         vfat   defaults                  0    1

Note that blk0 not blk1. It’s expecting a mmc card location. We’re on a uSD in blk1 position. so change that to a 1.

In theory, that’s it. Unless I missed something. So now I’m going to try booting it. BUT, just to add some fun, I’m going to publish this and THEN see if it works. Back “whenever” with the update!

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

5 Responses to Making XU4 Devuan Starting From Ubuntu Kernel

  1. E.M.Smith says:

    Golly! Worked first time!

    I’m posting this from my tablet as Devuan 2.0 install does not yet have a browser. Doing the “apt-get update”, “apt-get upgrade”, then the 700+ packages you get with an “apt-get install lxde” as the first thing added ;-)

  2. jim2 says:

    I truly wish I had time to read all of your linux adventures, much less do some of this stuff. I was lucky to get MX Linux running half-a$$ed on a full fledged desktop :) I still have work to do, but at least I have a computer running Linux.

  3. E.M.Smith says:


    I put my “adventures” up here mostly for 3 reasons:

    1) So that others can have somewhat less “adventure” should they choose to try what I do.
    2) So other folks can learn, whenever they are ready, how to do some of this stuff. And without the pain of doing it alone.
    3) So that a few years from now when I need to “do it again” I have a reminder / road map of where it says “Here there be dragons!” ;-)

    It just takes some time in the saddle doing things, adding one skill or technique at a time. Eventually you “get there”. Like watching me learning how Gentoo builds are done: Everybody has something they don’t know how to do.

    This is the Law Of Mutual Superiority.

    EVERYONE is superior to you on something.
    YOU are superior to them on something.

    So you just pick “some thing” and get good at it. YOU are now the local God Of That Something.

    FWIW, part of why so many folks are pissed about SystemD is that a whole lot of stuff that was learned over decades, where you became the local God Of Foo, were changed to some other crap. Mostly for no good reason. Often in a worse way or detrimental to operational stability.

    So I’ve chosen to avoid the new Crap-Foo and improve my skills with things like Slackware, Gentoo, and Devuan.

    Now, notice that it took me a good year+ to figure out why Devuan 2.0 was not installing for me. The final answer was “silly me – it wants the mmc card you don’t have in it”. After that, I was back on track to local superior skill (now documented above so ANYONE can get it in hours, not years…) BUT until that was accomplished, I was a Devuan 2.0 idiot NOOB who could not even install it.

    So recognize what this means:

    A few weeks ago, I was “stupider than you” on installing my chosen OS. YOU got yours (Linux MX) running and I had FAILED. YOU were the local superior expert.

    Today, I’ve got mine (Devuan 2.0) installed 3 different ways. At this moment, for that OS, on this hardware (and the Pi M3) I am the local expert and superior at that task. Yet next week, someone can read the above posting, add a trick, and THEY will be the superior expert. Don’t expect being The Best Local Expert to ever last longer than it takes for someone to read one page further in the manual than you have reached.

    We are ALL mutually superior. At something. Every Single Day.

    BTW: Posted this from my home directory on this new install, fully configured. It’s working fine, so far. Do need to make a backup of it…

  4. jim2 says:

    MX Linux doesn’t use SystemD. That’s why I picked it.

    However, the BIOS manual for may machine is over 70 pages. I have to get around to tweaking BIOS, then fiddle with some drivers/driver settings. It is working without sound at the moment.

  5. Pingback: SBC OS Choices & Opinions | Musings from the Chiefio

Comments are closed.