Debian on Devterm R-01

I got my Devterm R-01 last week and I am loving it!

I’ve managed to get Debian running on it, it’s still work in progress, but I’ve done a write up here: Debian on Devterm R-01 | TomsWeb

Kind Regards
Tom

5 Likes

Thanks for sharing! Hopefully as we pool together more information, we can get to a more optimised build / distribution. You’ve inspired me to write up my own notes.

You might also want to share this on the ClockworkPi subreddit? There are a few R01 posts over there already.

Cool, I would be really interested in see others peoples notes, do post them!

Good idea re reddit, will do that now. :slight_smile:

1 Like

Why move discussions to another place? Why not keep them here where people might look first?

I’m not trying to move the discussion :slight_smile: people are already also talking about the DevTerm R01 on Reddit, so I thought that might give more visibility to that blog post. Discussions are going to happen in several places, anyway.

1 Like

I am in both and am all the happier for it

Spreading my dependencies

Finally getting to trying to do the same thing here, with the hope of being able to dig more into the kernel stuff once I’ve got my own image.

In general I’ve been able to follow your notes, with minor deviations (I’m building on Ubuntu 21.10 22.04 which is what I have handy on a laptop, but that’s Debian-ish enough for the most part…). There are a few notes I could add, specifically as noted here, the python2.7 dependency is ridiculous and can be ignored anyway (the code can be modded to use Python 3 in both devterm-audio-patch and devterm-fan-control-cpi), and there are a few typos to watch out for, but this is otherwise a great guide! Thank you for sharing this!

I’m falling over at the point of trying to get the disk image built and copied to an SD card. I’ll focus just on the bits that touch the disk image…

:heavy_check_mark: Everything under Create new disk image file, partition and make filesystems works

:heavy_check_mark: Skipping on, the next part where we touch the image is under Compile bootloader and again, those dd commands work without particular concern (barring the fact that dd is dangerous in itself… :slightly_smiling_face: )

:heavy_check_mark: So then we build the base Debian setup and everything is looking happy until…

:bangbang: … I get to Copy rootfs to disk image and sd card and this is where I’ve hit an issue. Basically trying to mount the separate partitions in the disk image is failing…

$ d=$(sudo losetup --show -f -P disk.img)
$ sudo mount ${d}p2 disk.img.d
mount: /home/andy/devterm/disk.img.d: special device /dev/loop1p2 does not exist.
$ sudo mount $d tmp/fs/folder
NTFS signature is missing.
Failed to mount '/dev/loop1': Invalid argument
The device '/dev/loop1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
$ fdisk -l disk.img
Disk disk.img: 17 MiB, 17822720 bytes, 34810 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0b473fe1

Device     Boot  Start     End Sectors  Size Id Type
disk.img1        65536  270335  204800  100M 83 Linux
disk.img2       270336 8388607 8118272  3.9G 83 Linux

So it looks like the disk image does contain the two partitions but I can’t mount them to copy data in…

I’m confused by the NTFS reference as well.

Any chance you might have an inkling what I’ve missed here, @thomasdstewart ? :pray:

ICYMI, my own notes and explorations, on the default Ubuntu installation so far, are here :arrow_down:

Looking at the syslog when I get to trying to mount the loopback device the second time around, it looks like something is getting broken when the bootloader is added to the disk image. I’m not an expert when it comes to partition tables etc so I’m not sure what I’m doing wrong… also, comparing with the wiki page from ClockworkPi, that appears to create more partitions than this, so I’m not sure if something is missing.

[ 5226.771488] loop49: detected capacity change from 0 to 8388608
[ 5226.771815]  loop49: p1 p2
[ 5226.793578]  loop49: p1 p2
[ 5268.715383] EXT4-fs (loop49p2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 5303.524224] EXT4-fs (loop49p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 5454.327225] loop49: detected capacity change from 0 to 34810
[ 5454.327595]  loop49: p1 p2
[ 5454.327632] loop49: p1 start 65536 is beyond EOD, truncated
[ 5454.327642] loop49: p2 start 270336 is beyond EOD, truncated
[ 5454.353229]  loop49: p1 p2

Hi,

I was originally going to suggest adding the max_parts=63 option to the loop kernel module, like this:

$ cat /etc/modprobe.d/loop.conf 
options loop max_part=63

However your dmesg indicates it’s done that “loop49: p1 p2”. However loop49 sounds like there are loads of loop devices loaded, did you umount and losetup -d each or them?

I would umount and detach all the existing loops, make sure the max_part is set, and start the image creation again. When you get to the “d=$(sudo losetup --show -f -P disk.img)” setup, afterwards run sudo losetup, echo $d and lsblk. I’ve just repeated my steps, and it looked like this for me:

$ sudo losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE             DIO LOG-SEC
/dev/loop0         0      0         0  0 /home/thomas/disk.img   0     512
$
$ echo $d
/dev/loop0
$
$ lsblk
NAME                            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                             7:0    0     4G  0 loop  
├─loop0p1                         7:1    0   100M  0 part  
└─loop0p2                         7:2    0   3.9G  0 part  
$

Hope that helps
Tom

Thanks for this.

The huge number of loop mounts is the delight (!) of snapd… so yes, there are a lot of them, but I can just about find the one I want in the mess.

So I’m getting to the second round of losetup as described, after writing the uboot loader to the front of the disk image, and what I’m seeing is this (with the noise removed):

$ d=$(sudo losetup --show -f -P disk.img)
$ sudo losetup
NAME        SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                              DIO LOG-SEC
[...]
/dev/loop38         0      0         0  0 /home/andy/devterm/disk.img                              0     512
$ echo $d
/dev/loop38
$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0 133.2M  1 loop /snap/1password/74
[...]
loop38        7:38   0    17M  0 loop
loop39        7:39   0 105.6M  1 loop /snap/slack/62
[...]

So, after the bootloader is added, the disk image no longer loads partitions on loop (it did to that beforehand; I double-checked before I ran the dd commands). The only thing I’ve not tried is to forcibly set the max_part (I think loop is built-in to the kernel, and there’s no similar module config file on my system). I guess an alternative might be to do all of this, at least the building of the disk.img file, inside of a Debian VM…

I can also try rsync’ing the partition content, and then going back and doing the dd of the bootloader…

Something is wrong, why is the loop 17 megabytes. How big is the underlying file?

Mine looks like:

NAME                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                 7:0    0     4G  0 loop  
├─loop0p1           259:6    0   100M  0 part  
└─loop0p2           259:7    0   3.9G  0 part