Feature Complete Debian Desktop Release

[p1x3l3d]

Hi Luke and MrFixit,

Thank you very much for creating this desktop release. Fantastic to see this image appearing together with MrFixit's Debian minimal image! The RockPro64 is loving these and running really well on them

I thought to give this image a try and attempt to use the PCI-e SATA card to connect my two drives and setup software RAID(1), since I couldn't get my hardware RAID card up and running on MrFixit's Debian minimal image.

However, I soon found out that the required raid1 module is not build/compiled in the kernel of this image. Is there any way I can add the module or rebuild the kernel with it?

Again, thank you very much for all your efforts and hard work, and the fact that you're actively supporting the image by responding to our questions

[futurejones]

About the PCIe disks. Sounds like a permissions issue to me. I tested PCIe -> SATA some time back and had no issues, but didn't retest on the release. Anyways, let me know if this will solve your issue:

Code:

sudo chown -R -v rock:rock /media/rock    
sudo chmod -Rf 777 rock:rock /media/rock

[edit]
Can you switch tty when the build 'freezes up' ? if yes, you could check where it mounts and just chmod it I imagine (otherwise check from root):

Code:

sudo chmod 777 /dev/sdx

[edit 2]
If neither works, ssh into the board when its locked up and pastbin dmesg for us

Hi Luke,
None of the above work. "freezes up" is probably not the correct description. The device appears to power off. The white and red leds turn off as well as the green led on the pcie card.
At this point the machine is totally inaccessible including via ssh.
If you log in as "rock" without xserver running everything is fine. You can access and use the ssd. As soon as you run startx the device powers off.

[Luke]

About the PCIe disks. Sounds like a permissions issue to me. I tested PCIe -> SATA some time back and had no issues, but didn't retest on the release. Anyways, let me know if this will solve your issue:

Code:

sudo chown -R -v rock:rock /media/rock    
sudo chmod -Rf 777 rock:rock /media/rock

[edit]
Can you switch tty when the build 'freezes up' ? if yes, you could check where it mounts and just chmod it I imagine (otherwise check from root):

Code:

sudo chmod 777 /dev/sdx

[edit 2]
If neither works, ssh into the board when its locked up and pastbin dmesg for us

Hi Luke,
None of the above work. "freezes up" is probably not the correct description. The device appears to power off. The white and red leds turn off as well as the green led on the pcie card.
At this point the machine is totally inaccessible including via ssh.
If you log in as "rock" without xserver running everything is fine. You can access and use the ssd. As soon as you run startx the device powers off.

This is bizarre. Anyways, as I've already said earlier today we'll look into it - but its not at the top of the list at the moment. We'll get to it in time.
In the meantime, keep at it - perhaps you'll find a solution. Off the top of my head I cannot think of a reason why the board would lock up completely AND ONLY in DE as user and not root, with the SSD/HDDs connected via PCIe. Anything in xorg logs (look at .old)? check for clues, so we have something to go on when we get to it.

[dkryder]

Absolutely awesome work! This is without doubt the best performing and looking desktop available.
Thanks for all your hard work making this possible.
One problem - 
I have the PCIe m.2 adapter with a 250GB WD Black nvme ssd attached.
When I log in as root everything is working beautifully. Desktop is smooth and access to PCIe ssd works as expected. But....
When I try to log in as "rock" everything freezes and I have to restart the rockpro64.
This seems to be the same issue I have had with all other distro desktop installs I have tried except they won't boot even as root.
For now I am very happy just to be able to use as root.

try login as root and create new user and see if that user has same issues as user rock.

[futurejones]

I have been trying to install some .deb packages but I am getting this error - "package architecture (arm64) does not match system (armhf)"??

The RockPro64 is a 64bit system

Code:

root@rockpro64X:~# hostnamectl
   Static hostname: rockpro64X
         Icon name: computer
        Machine ID: **
           Boot ID: **
  Operating System: Debian GNU/Linux 9 (stretch)
            Kernel: Linux 4.4.171
      Architecture: arm64

but apt update is returning armhf packages.

Code:

chromium/stable 72.0.3626.122-1~deb9u1 armhf [upgradable from: 67.0.3396.87-1~deb9u1]
libbasicusageenvironment1/stable 2016.11.28-1+deb9u2 armhf [upgradable from: 2016.11.28-1+deb9u1]
libgroupsock8/stable 2016.11.28-1+deb9u2 armhf [upgradable from: 2016.11.28-1+deb9u1]
libldb1/stable 2:1.1.27-1+deb9u1 armhf [upgradable from: 2:1.1.27-1+b1]
liblivemedia57/stable 2016.11.28-1+deb9u2 armhf [upgradable from: 2016.11.28-1+deb9u1]
libopenjp2-7/stable 2.1.2-1.1+deb9u3 armhf [upgradable from: 2.1.2-1.1+deb9u2]
libssl1.0.2/stable 1.0.2r-1~deb9u1 armhf [upgradable from: 1.0.2q-1~deb9u1]
libusageenvironment3/stable 2016.11.28-1+deb9u2 armhf [upgradable from: 2016.11.28-1+deb9u1]
openssh-client/stable 1:7.4p1-10+deb9u6 armhf [upgradable from: 1:7.4p1-10+deb9u5]
openssh-server/stable 1:7.4p1-10+deb9u6 armhf [upgradable from: 1:7.4p1-10+deb9u5]
openssh-sftp-server/stable 1:7.4p1-10+deb9u6 armhf [upgradable from: 1:7.4p1-10+deb9u5]
python-ldb/stable 2:1.1.27-1+deb9u1 armhf [upgradable from: 2:1.1.27-1+b1]
ssh/stable 1:7.4p1-10+deb9u6 all [upgradable from: 1:7.4p1-10+deb9u5]

am I missing something?

---

Absolutely awesome work! This is without doubt the best performing and looking desktop available.
Thanks for all your hard work making this possible.
One problem - 
I have the PCIe m.2 adapter with a 250GB WD Black nvme ssd attached.
When I log in as root everything is working beautifully. Desktop is smooth and access to PCIe ssd works as expected. But....
When I try to log in as "rock" everything freezes and I have to restart the rockpro64.
This seems to be the same issue I have had with all other distro desktop installs I have tried except they won't boot even as root.
For now I am very happy just to be able to use as root.

try login as root and create new user and see if that user has same issues as user rock.

Thanks, but I have already tried that and get the same issues as with "rock"user.

[Luke]

Kernel is 64bit and userland is 32bit. So you want armhf .debs

[futurejones]

Kernel is 64bit and userland is 32bit. So you want armhf .debs

Thanks.
Will you be releasing a full 64bit version?

[Luke]

Kernel is 64bit and userland is 32bit. So you want armhf .debs

Thanks.
Will you be releasing a full 64bit version?

Well, 32bit desktop performs better, so unless something changes - no.

[hunderteins]

Well guys,

 you did setup your kernel like this:

CONFIG_EXTRA_FIRMWARE="dptx.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware/rockchip"

 if you really want to include the firmware-blob dptx.bin into your kernel, you should name it like how the driver looks for it:

cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2

so please change your .config to

CONFIG_EXTRA_FIRMWARE="rockchip/dptx.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware/"

TIA,
hunderteins

[Mrfixit2001]

I will be including RAID drivers in the kernel for the next releases.
I will also be including NFSD driver in the kernel for the next release.

Thank you for the feedback about the dptx firmware! I actually already have this configured in the kernel. I have tried both including the dptx.bin in the file system overlay, as well as actually adding the firmware as compiled into the kernel itself as embedded firmware. Sadly, neither solution seems to allow the kernel to load this file. Reviewing my setting, it does appear I didn't include the trailing "/", so I'll try again with that amended to see if it resolves. If so, you can expect it in the next release.

Will troubleshoot the PCIe at some point as well, but as Lukasz mentioned it's not at the top of the list. Since it works outside of the X environment, I am relatively confident that it's a software configuration, which means you are all able to help us in troubleshooting and resolution. It would be greatly helpful if someone could attached a UART console, edit /boot/extlinux/extlinux.conf so that output is verbose (remove: quiet logleve=3 vga=current), and then capture the output during a boot where the board freezes up so that we can see exactly what's happening.

Keep the feedback coming folks! It's only thru community testing and open communication that we can improve!