Download Pyra Debian OS (WIP)


@stevenc99

I will test it, have bought some sd card, so let's play :)

@aTc
I created a new sd card, replace only mmcblk0 with sda1 in "boot/extlinux/extlinux.conf" and now it boots directly to harddisk, thanks for help.

Running first boot wizard four times on weekend, well done, works flawless.

Thomas
 
At least i can replicate the perl thing here now.. it requires slightly more work than just doing and apt-get update/upgrade (had to do the --reinstall with libmodule-build-perl).
I did see it once before, but that was months ago, and just thought it was something to do with the packages on the debian repo not beeing fully updated yet, since it didn't happen when i rebuilt the image a short while later.

The second stage installer of multistrap is horribly undocumented (the one example in their docs doesn't even work, and the one it runs when ignorenativearch isn't set in the config doesn't work properly either), so it's not that surprising that not everything works flawlessly.
It might also have to do with me using apt instead of dpkg to finish he configuration stage.
We could always just move to debootstrap. (The current setup scrip already takes part of it from debootstraps second stage scripts)


And about the first run wizard, that's more a temporary hack until someone comes up with a proper wizard.
 
@aTc I came up with a workaround for this bug: https://github.com/stevenc99/pyraos-build/commit/c0ba1f400574aa71d1ed7671ef467038428ee931

If we pre-populate /var/lib/dpkg/diversions with whatever would have been put there by pre/postinst scripts - it prevents future apt-get installs/upgrades from trying to overwrite any diverted files (which fixes the problem we saw with libmodule-build-perl, perl and others).

We *probably* should reinstall the affected packages on the target device after setting up /var/lib/dpkg/diversions. But network access is needed to re-download the .debs, because multistrap has already cleaned them at that point (and I don't like making the stage1 -> stage2 part require network access).

By the way, using either apt or dpkg in /pyra-config.sh makes no difference, neither one will run preinst scripts for already-unpacked packages.
[doublepost=1465767104,1465763309][/doublepost]Here's my attempt at making rootfs tarballs. If anyone is able to test that would be great, as I could only test them as a separately mounted chroot on the OMAP3 devboard I have:
http://jenkins.kfreebsd.eu/jenkins/view/pyra/job/pyra_rootfs/ws/export/

* stage1 is a half-configured image; on first boot /pyra-config.sh takes something like an hour to finish configuring

* stage2 is the result of me running stage1 on my own armv7l board; you probably want to use this one

I'm working to make these build reproducibly; the idea is that someone should be able to reproduce stage1 by running multistrap with SOURCE_DATE_EPOCH=1465759684, and should get a byte-for-byte identical tarball. stage2 would take much more work to ever make it reproducible, which is why I offer stage1, so you can produce stage2 yourself on your own device if you don't trust mine.

I've produced a diff to show what happens between stage1 and stage2. A lot of the 'binary file' differences are just symlinks added by the /etc/alternatives system.

Known bugs in these images are:
* SSH host keys should be cleaned from my stage2 image, so that everyone's device generates their own
* my stage2 contains a machineid, that probably should be cleaned too
* some logs and things can be cleaned
* file capabilities are not being set, for /usr/bin/netstat etc. to be able to work as non-privileged user
* APT repository for security.debian.org is not enabled yet, so some packages (like firefox) are out-of-date

I think I've fixed the file conflict issue on APT upgrades though, which is the main thing.
 
Last edited:
I had quick check. Looks good, but there is no network configuration, i had to setup it manually. Added a static ip address to my eth0 interface, create resolv.conf with nameservers, and then, all works.

"apt-get update ; apt-get upgrade" has no packets to upgrades, xrdp / mc / joe installed without problems,

At moment, i found only one different in "apt-get update" process. In aTc rootfs many backports are included, in yours none.

The first run wizard works normally.

Something to check in detail?

Thomas
 
Last edited:
I had quick check. Looks good, but there is no network configuration, i had to setup it manually. Added a static ip address to my eth0 interface, create resolv.conf with nameservers, and then, all works.

Thanks very much!

Would automatic DHCP on eth0 be a sensible default for most users?

At moment, i found only one different in "apt-get update" process. In aTc rootfs many backports are included, in yours none.

It may just be that "apt-get update" information in my images is more recent and so doesn't need updating?

Or perhaps aTc added new packages to the images recently but hasn't updated git://git.openpandora.org/pyraos-build.git. When that happens, I'll update my own images to do the same. I'll also start building pyra-mate images at some point.

I think I fixed all the bugs I wanted to fix right now... I'll probably enable the security.debian.org APT repository, and then keep my images updated regularly, so that security patches are already applied at first boot.
 
Would automatic DHCP on eth0 be a sensible default for most users?

This was default in both aTC rootfs, normally we have later wlan on board, but for this, i don't know.

It may just be that "apt-get update" information in my images is more recent and so doesn't need updating?

You will be right, but sorry,i have no idea, :) (This could be my default response for future)


I had done some test on /dev/sda (500GB sata disc WD5002ABYS)

command to see buffered and cached disk read speed: hdparm -Tt /dev/sda
Timing cached reads: 1638 MB in 2.00 seconds = 819.94 MB/sec
Timing buffered disk reads: 338 MB in 3.00 seconds = 112.61 MB/sec

Writting one big file, command: dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 Datensätze ein
1+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 12,4442 s, 86,3 MB/s

Writting 1000 files with 512KB, command: dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 Datensätze ein
1000+0 Datensätze aus
512000 Bytes (512 kB) kopiert, 32,8706 s, 15,6 kB/s

Ok, random writes not so fast..

Next, i install a compiler and compiled a SDL game, bumprace, and running inside xrdp session, slow but playable. My hdmi display was to small for it, only 800x480.

I have done this in both rootfs and i see no big difference,so what next?

Thomas
[doublepost=1465834739,1465832979][/doublepost]I had run some gles test, glxgears runs with 150 FPS on my little display, MegaGlest is running, but very slow.

Thomas
 
Last edited:
Would automatic DHCP on eth0 be a sensible default for most users?
This was default in both aTC rootfs, normally we have later wlan on board, but for this, i don't know.

Yeah, from my knowledge playing with it in the past, It always has been the default in all the past rootfs images. Although this is on Ethernet only, the WLAN from my knowledge never worked on the OMAP5 EVM devboard.
 
Wow, that's mostly very fast. How quickly does it boot? What hardware are you testing on?
 
TI OMAP5432 board, 2 GB ram, boots from 4GB SD card with MLO/u-boot, but loads kernel from sata harddisk. I connect an usb hub for mouse and bluetooth adapter, founds my keyboard, but couldn't connect it.

It needs several seconds for scan attached devices, has timeout counter of 3 seconds, but pressing power button to login prompt, around 35 seconds.


Here a picture of my dev board
 

Attachments

  • IMAG0018.jpg
    IMAG0018.jpg
    1.2 MB · Views: 451
I just uploaded pyra-debian-jessie-xfce-rootfs-1465843129-stage2.tgz
where I've enabled the security.debian.org APT repository, so it already has patches applied for:
* DSA 3591-1 - ImageMagick vulnerabilities
* DSA 3600-1 - iceweasel upgraded to firefox-esr 45.2.0

I decided not to bundle APT package lists in this one, to make the stage1-stage2 diff smaller, make stage2 easier to reproduce, and the stage2 tarball a bit smaller.

There are no other changes of interest yet.
 
Last edited:
I should add that aTc did a fine job. A straightforward build system for the images, and a proper Debian repository and sources for all the added custom stuff.

The resulting image is very close to what an official Debian install would be. (Surprising how often vendors or derivative projects manage to screw this up, and then it's a nightmare to maintain).
 
@stevenc99
Image work, but no packets from security.debian.org applied, after "apt-get update ; apt-get upgrade", have you done this already?

Great work.

@aTc
Great job and thanks for helping me.

Thomas
 
Image aTc:

I tried to connect a bluetooth keyboard but this always fails, first with bluetoothctl, then with graphical manager on desktop. The device was visible, trusted, pair code was requested, and in bluetoothctl accepted, connected, but device couldn't added. I used two different bluetooth sticks and two different keyboards, changed my active usb hub, but nothing helps.

After searching, i changed in file /etc/bluetooth/input.conf

IdleTimeout=1200 (This is preventing keyboard lags, timeout was to low, so after 30 seconds, keyboard has to reconnect)

and

UserspaceHID=true

After restart i could add the keyboard with bluetoothctl and it is availabe on Desktop.

Thomas

After that, i tried to register a new keyboard with bluetooth graphical manager, the device is visible, a pin code for keyboard requested, but after typing on keyboard, i got message that connection is failed. With bluetoothctl as root on console it works and the new device is visible in graphical bluetooth manager. Maybe are user right problem?

Thomas
 
Last edited:
At least for me, bluetooth keyboards have always been a lot of trouble to get going.
I mostly tested the bluetooth stuff with various bluetooth speakers, and those work pretty much out of the box.
So at least that part of bluetooth works. It could be that input devices need more permissions, or that they can only be set up by root.
It doesn't help that the bluetooth stuff in debian is slightly outdated. Another possibility is missing bluetooth firmware, since i did have to manually install the firmware files for my bluetooth adapter to get it going properly.
(check dmesg, although for other adapters it will complain about missing firmware, but still work)

DHCP and any other network related stuff is handled by NetworkManager, so no other configuration should be needed there.
It has always brought up the network here without any messing about.

I've also written a new image building script, sort of as an alternative to multistrap.
It doesn't do a lot of checking at the moment, so make sure it can find all the programs it tries to run.
This one just uses debootstrap for everything, and then a systemd-nspawn to set everything up (tries to use qemu-arm-static to run on non-arm hardware, so that has to be installed and set up with binfmt to work)
It should be able to run pretty much everywhere, and i've been building test images on both my desktop machine running arch, and the devboard running debian.
http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/buildrootfs

Output of the script is an image that you can just dd to an sd card (or any other method, it's pretty much the same process as you'd use to install a rpi image), insert into the devboard, and it should boot.
Mate image available here : http://packages.pyra-handheld.com/images/extra/pyra-debian-jessie-mate.img.7z

It doesn't resize the partition on the first boot, and there's probably a few other issues, but it's more of a test to see if this stuff would work.
 
I will test it tonight, this makes creating a boot disk easily. On Windows i'm using win32diskimager, start as admin, write the image to SD card.

In extlinux.conf, timeout setting is ignored, it will start the image, set in default, immediately. Any hint for me?

Thomas
 
Last edited:
Sorry, but image didn't boot from SD card. In serial terminal i see uBoot is started and output is:

U-Boot SPL 2016.03-dirty (Jun 17 2016 - 23:17:24)
OMAP5432 ES2.0
Trying to boot from MMC
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!


U-Boot 2016.07-rc1-00026-g6b3943f-dirty (Jun 15 2016 - 02:10:21 +0200)

CPU : OMAP5432-GP ES2.0
Board: OMAP5432 uEVM
I2C: ready
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
** First descriptor is NOT a primary desc on 1:1 **
SCSI: SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net: No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found

USB device 0:
Device 0: device type unknown
... is now current device
** Bad device usb 0 **
** Bad device usb 0 **
scanning bus for devices...
Found 0 device(s).

Device 0: not available
** First descriptor is NOT a primary desc on 1:1 **
switch to partitions #0, OK
mmc1(part 0) is current device
** No partition table - mmc 1 **
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.0.93 (1459 ms)
Using sms0 device
TFTP from server 0.0.0.0; our IP address is 192.168.0.93; sending through gateway 192.168.0.1
Filename 'boot.scr.uimg'.
Load address: 0x90000000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Waiting for Ethernet connection... done.



The partition is on SD card, i can see it:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> mmc part

Partition Map for MMC device 0 -- Partition Type: DOS

Part Start Sector Num Sectors UUID Type
1 2048 6141952 00000000-01 83 Boot

=> ext4ls mmc 0:1
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 var
<DIR> 4096 usr
<DIR> 4096 bin
<DIR> 4096 lib
<DIR> 4096 etc
<DIR> 4096 tmp
<DIR> 4096 sys
<DIR> 4096 sbin
<DIR> 4096 run
<DIR> 4096 root
<DIR> 4096 proc
<DIR> 4096 home
<DIR> 4096 dev
<DIR> 4096 boot
<DIR> 4096 mnt
<DIR> 4096 srv
<DIR> 4096 opt
<DIR> 4096 media

=> ext4ls mmc 0:1 /boot
<DIR> 4096 .
<DIR> 4096 ..
2409741 System.map-4.6.0-letux-pyra+
129856 config-4.6.0-letux-pyra+
<DIR> 4096 extlinux
4542928 vmlinuz-4.6.0-letux-pyra+
3531112 initrd.img-4.6.0-letux-pyra+
=> ext4load mmc 0:1 0x80800000 /boot/vmlinuz-4.6.0-letux-pyra+
=> bootz 0x80800000
Kernel image @ 0x80800000 [ 0x000000 - 0x4551d0 ]

Starting kernel ...



Thats all, system hangs.

If i connect my harddisk, my previous images from you and stevenc99 is shown in boot manager, i can boot both.

Thomas
 
Looks like i mixed up the MLO and u-boot.img from different versions.
Another problem is that it seems to load MLO from the sd card, but then loads the u-boot from the emmc.
I'll wipe my emmc, rebuild u-boot, rebuild the image , and see if i can get something working.

It should also be trying to load omap5-uevm instead of the omap5-pyra.dtb it tries to load on your board.
[doublepost=1466541297,1466536213][/doublepost]i've updated http://packages.pyra-handheld.com/images/extra/pyra-debian-jessie-mate.img.7z .
MLO should report itself as U-Boot SPL 2016.03-dirty (Jun 17 2016 - 23:17:24) , u-boot as U-Boot 2016.03-dirty (Jun 17 2016 - 23:17:24 +0200)
As usual, it works fine here. I wiped the first 100mb of the emmc, just to be sure there's nothing on there that might interfere.
(dd if=/dev/zero bs=1M count=100 of=/dev/mmcblk0)
[doublepost=1466546115][/doublepost]
Will MATE be an official option for the Pyra then?

It will be an option, and most likely the default. It's slightly more polished than xfce, but still reasonably light weight.
 
Back
Top