Download Pyra Debian OS (WIP)


Touchscreen "Should" work out of the box, the nubs you need to manually set them up as mouse/button mode, basically what the script typically does on the Pandora.
The Pyra OS doesn't really have all the Pandora features loaded by default, so it needs a bit of tweaking. with a bit of effort, I've got just about everything except overclocking working.
 
Your EVM is also kaput ?
Well Wally has the IGEP OMAP5 board, not the Ti OMAP5 EVM board. If you're talking about my board, yeah it seems that way... I think Wally's issue seems to be related to the SDRAM, mine I don't get any kind of serial prompt to indicate what may be the issue. Using a scope I can see some clocks still running, I need to do some deep debug work on it.
 
Yeah my IGEP board went kaput. I get a uboot screen but that's about it, it' just goes on about how the SDram size is 0 and is expecting 200000.

RIP
 
Did you press the button while booting a SD with a new uboot ?
Because it's the way to do to change memory settings.
 
Which button?
[doublepost=1464085549,1464085351][/doublepost]Getting nubs and touch screen working is done by

Getting to terminal and typing sudo depmod -a then reboot

Nubs are set to absolute so you need to change the mode to mouse and mbuttons respectively
 
True, but haven't some prototypes been sent out already?

I would love to see a news blurb on how many went to people working on X, Y and Z and how it's progressing.

I suspect, though, that the actual number of prototype Pyra handhelds in existence so far might be able to be counted on one hand by someone who flunked school wood shop.
 
Here's a quick tour of the Pyra OS image at the moment. The pre-configured APT repositories:
Code:
root@pyra:~# aptitude update
Hit http://ftp.nl.debian.org jessie-backports InRelease
Ign http://ftp.nl.debian.org jessie InRelease
Hit http://packages.pyra-handheld.com jessie-pyra InRelease
Hit http://ftp.nl.debian.org jessie Release.gpg
Hit http://ftp.nl.debian.org jessie Release
Get: 1 http://ftp.nl.debian.org jessie-backports/main Sources/DiffIndex [27.8 kB]
Hit http://packages.pyra-handheld.com jessie-pyra/main Sources
Get: 2 http://ftp.nl.debian.org jessie-backports/main armhf Packages/DiffIndex [27.8 kB]
Get: 3 http://ftp.nl.debian.org jessie-backports/main Translation-en/DiffIndex [27.8 kB]
Hit http://packages.pyra-handheld.com jessie-pyra/main armhf Packages
Hit http://ftp.nl.debian.org jessie/main Sources
Hit http://ftp.nl.debian.org jessie/contrib Sources
Hit http://ftp.nl.debian.org jessie/non-free Sources
Hit http://ftp.nl.debian.org jessie/main armhf Packages
Hit http://ftp.nl.debian.org jessie/contrib armhf Packages
Hit http://ftp.nl.debian.org jessie/non-free armhf Packages
Hit http://ftp.nl.debian.org jessie/contrib Translation-en
Hit http://ftp.nl.debian.org jessie/main Translation-en
Ign http://packages.pyra-handheld.com jessie-pyra/main Translation-en_US
Hit http://ftp.nl.debian.org jessie/non-free Translation-en
Ign http://packages.pyra-handheld.com jessie-pyra/main Translation-en

Some things that are missing:
* update with new packages from the Debian 8.5 point release, from last week has been done now, thanks!
* enable security updates from security.debian.org? (https://github.com/stevenc99/pyraos-build/commit/59836cb758377edd522d665e212950fad8fd8080)
* the newest iceweasel security update, where Debian has actually switched to firefox-esr (restoring the original Firefox name and branding)
* a newer kernel (the latest released by Nikolaus is letux-4.7-rc2)

Also noticed:
* could be using httpredir.debian.org instead of ftp.nl? (https://github.com/stevenc99/pyraos-build/commit/16ca2ca2fa2d67e46ac271c29151d0996be2f7f9)
* some files in /var/log could be removed before creating the image

These are the extra pre-installed packages, besides official Debian ones:
Code:
root@pyra:~# aptitude search '~S ~i !~ODebian'
i   dbp                              - DragonBox Package system
i   led-config                       - Configure LED triggers for /sys/class/leds/
i   led-config-pyra                  - led-config file for Pyra handheld
i A linux-image-4.4.0-letux-pyra     - Linux kernel, version 4.4.0-letux-pyra
i   linux-image-4.4.0-rc4-letux-pyra - Linux kernel, version 4.4.0-rc4-letux-pyra
i   linux-image-pyra                 - Linux for Pyra handheld (meta-package)
i A linux-libc-dev                   - Linux support headers for userspace development
i   pyra-archive-keyring             - GnuPG archive keys of the Pyra package archive
i   pyra-config-desktop              - Pyra default desktop environment settings.
i   pyra-config-modprobe             - Pyra default modprobe options
i   pyra-config-udev                 - Pyra default udev options
i   pyra-config-xorg                 - Pyra default config, xorg
i   pyra-first-run                   - Pyra first run scripts
i   pyra-meta-base                   - minimal requirements for the pyra firmware (metapackage)
i   pyra-meta-desktop-base           - minimal requirements for a graphical pyra firmware (metapackage)
i   pyra-meta-extra                  - useful, but not essential extra packages for pyra (metapackage)
i   pyra-meta-xfce                   - XFCE desktop for pyra (metapackage)
i   pyra-scripts                     - Support scripts for Pyra handheld
i   pyra-slim-theme                  - Pyra theme for slim
i   pyra-themes                      - Meta pacakge for all pyra themes
i   pyra-wallpapers                  - Pyra Handheld wallpapers
i   xserver-xorg-video-fbturbo       - X.Org X server -- fbturbo display driver

The installed non-free packages:
Code:
root@pyra:~# aptitude search '~i ?section(non-free)'
i   firmware-linux         - Binary firmware for various drivers in the Linux kernel (meta-package)
i   firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel

The first-run configuration script:
http://dev.pyra-handheld.com/index.php/p/pyra-first-run/source/tree/master/pyra-first-run.sh
 
Last edited:
I have installed the image "http://packages.pyra-handheld.com/rootfs/pyra-debian-jessie-xfce-rootfs.tgz" on my TI-OMAP5432-EVM board and have some hints
  • in install script "install.sh" the rootfs is extract with "tar zxf ../$IMAGE -C rootfs", i called it with "./install.sh /dev/mmcblk0 pyra-debian-jessie-xfce-rootfs.tgz" and it fail. Adding "../" to tar command was unexpected for me :)
  • the user pyra doesn't exists, with root/root i got into the system
  • after booting, login with root, i did a "apt-get update" "apt-get upgrade" and run into an error, that "perl-base_5.20.2-3+deb8u5_armhf.deb" is in conflict with libmodule-build-perl, this one needs "perl_5.20.2-3+deb8u4_armhf.deb". Solution is simple, removing libmodule-build-perl with "dpkg -r libmodule-build-perl" and "apt-get upgrade" runs without errors.
Has anybody installing the image on hardisk and booting from them?

Thomas
 
I have installed the image "http://packages.pyra-handheld.com/rootfs/pyra-debian-jessie-xfce-rootfs.tgz" on my TI-OMAP5432-EVM board and have some hints
  • in install script "install.sh" the rootfs is extract with "tar zxf ../$IMAGE -C rootfs", i called it with "./install.sh /dev/mmcblk0 pyra-debian-jessie-xfce-rootfs.tgz" and it fail. Adding "../" to tar command was unexpected for me :)
  • the user pyra doesn't exists, with root/root i got into the system
  • after booting, login with root, i did a "apt-get update" "apt-get upgrade" and run into an error, that "perl-base_5.20.2-3+deb8u5_armhf.deb" is in conflict with libmodule-build-perl, this one needs "perl_5.20.2-3+deb8u4_armhf.deb". Solution is simple, removing libmodule-build-perl with "dpkg -r libmodule-build-perl" and "apt-get upgrade" runs without errors.
Has anybody installing the image on hardisk and booting from them?

Thomas

I think @aTc has had it boot from the hard-disk before. I've always just used an SD card for convenience. aTc hasn't been doing much on updating lately my guess waiting for actual development units show. Also mostly because no one has been giving him feed back of anything that needs to be done, My devboard died a few months ago.



The installer I remember doing a bit of dancing to make it work properly, so yeah that need to change.
 
[*]after booting, login with root, i did a "apt-get update" "apt-get upgrade" and run into an error, that "perl-base_5.20.2-3+deb8u5_armhf.deb" is in conflict with libmodule-build-perl, this one needs "perl_5.20.2-3+deb8u4_armhf.deb".

Oh dear, this is a critical bug, as it will break package upgrades. When this happened to me I thought I must have done something to it, but it seems the image itself is broken. This affects many other packages too.

/var/lib/dpkg/info/libmodule-build-perl.preinst uses dpkg-divert for /usr/bin/config_data

/var/lib/dpkg/info/gnupg-curl.preinst uses dpkg-divert for /usr/lib/gnupg/gpgkeys_curl and /usr/lib/gnupg/gpgkeys_hkp

/var/lib/dpkg/info/libgtk-3-bin.preinst uses dpkg-divert for /usr/sbin/update-icon-caches and /usr/share/man/man8/update-icon-caches.8.gz

/var/lib/dpkg/diversions should contain many more entries than it actually does in the image.

This seems to be a limitation of multistrap, not running the pre/postinst scripts at all, which could have other consequences too: https://bugs.debian.org/627068
[doublepost=1465675154,1465673083][/doublepost]Oh, I see what's missing:
http://dev.pyra-handheld.com/index....ce/tree/master/multistrap/pyra/pyra-config.sh

That script needs to run, otherwise packages are only half-installed. Either on first boot, or before publishing the rootfs image. I can't find a copy of that script inside the published rootfs.
 
multistrap is designed for cross-architecture image creation, e.g. you can produce images for an armhf device, on a much faster amd64 build server. Its major limitation is that it can't run the installed programs, or even the post-install configuration scripts. So the packages are really only half-installed...

This script:
https://github.com/stevenc99/pyraos...multistrap/pyra/hooks/completion_00_nspawn.sh

is intended to 'boot into' (systemd-nspawn inside chroot) the new image and do some extra configuration (see pyra-config.sh mentioned above). That would create the "pyra" user account and it would finish installing the half-installed packages, and that would have prevented the file conflict issues seen above.

However, it can only do that when the image is being built on an armv7l (armhf) system. Otherwise, it is expected that pyra-config.sh will run on first boot... but I think that's not working either (that file isn't even in the rootfs tarball).

If it did that, the first boot might also be very slow. I do have some suggestions/requests:

* continue building rootfs as it's done currently, but call those "stage1"
* I have some patches that allow this part to be byte-for-byte reproducible as a bonus (https://github.com/stevenc99/pyraos-build/commit/4198dc40c983f97abbe5fe22e0723b3e13057597, https://github.com/stevenc99/pyraos-build/commit/d60b077ed10609aa7507372296ef144957288b3f)
* periodically download stage1 images to any suitable armv7l device (Pyra or devboard) boot stage1 in a Qemu VM, runs the pyra-config.sh inside it and upload the result, which can be called "stage2" - that's the finished image, able to boot quickly, to the pyra-first-run.sh user config / welcome thing
* anyone should be able to download stage1 and produce their own stage2 from it, so they don't have to trust the published ones
 
Last edited:
I've been mostly messing about with the pyra-mate image, the xfce stuff is a bit behind.
I've also been a bit lazy about pushing stuff to the git repo and the site, a lot of stuff has been fixed already.

It doesn't help that with all the dead devboards around i've been getting no feedback whatsoever for the last few months.
And of course everything always works perfectly on my end :)

I've also got a multistrap setup that works with qemu-arm-static to run the arm nspawn on am64 hardware.
It runs as a very slow arm cpu, but since it's mostly io that's going on it doesn't matter that much.
The reason you don't see the pyra-config.sh in the rootfs is because it's removed after it has been run.
The images are normally built on the evm5432 devboard, with a sata hd attached to speed things up.
I also don't test the resulting images that much, it's mostly add new feature, make image, write to sd, boot sd, check if feature works, boot back into my full dev setup on the sata hd.
 
Yay, that's all good news. If you could please push to git://git.openpandora.org/pyraos-build.git I can keep testing and sending patches. There doesn't seem to be a multistrap/pyra-mate.conf yet, so I can only build xfce images at the moment.

I managed to do all the above testing with just an old OMAP3 board. I have my own auto-builder for running multistrap now, and a way to automate deployment of the rootfs to that board.
 
Last edited:
Back
Top