01-15-2020, 09:31 AM
(This post was last modified: 01-15-2020, 10:08 AM by danielt.)
(01-14-2020, 09:14 PM)ab1jx Wrote: This is fun, I like it because it uses debootstrap and you potentially end up with a cutting-edge system. But I wonder if it's possible to toughen it so it drops breadcrumbs and checks for those as it goes along. For those of us with unreliable networks where everything isn't likely to get done at once. I got up to choosing software, lxde, web server, etc, then everything went dead. Restarted and it went back and partitioned the SD again, got up to about the same place and died again. My new SD boots to a very basic system with no network. Since I think I can muddle through by doing dpkg -i downloaded debs on usb devices until I get network I'll probably continue.
But if it could recognize waypoints from a partial install like make does it would save time for those of us with imperfect networks. Could these use make?
I decided to give it one more shot and it got through the downloads without stopping, now it's installing. A newer than I've ever seen Debian on my first ever new laptop, always bought fixer-uppers before. 50% done, unpacking.
There's nothing automatic but there is some support in the script for taking things a step at a time so it might be worth taking a look the internal functions.
Each of the functions starting with do_ can be run on its own by putting it on the command line (do_all is just the default). For example if the installer failed during the installation of the GUI desktop then I think you can do something like: ./install-debian BLKDEV=... do_mount do_tasksel do_umount (and I think will preserve the cache of any binaries fetched during the previous task selection).
Naturally the other trick is to simply not select any additional software and then run tasksel by hand from within the newly install distro.
(01-14-2020, 06:50 PM)ThatGeoGuy Wrote: I'm trying to figure out what the rough edges would be, but not having encryption support on a laptop is a pretty big one for me.I assume by default most of the inputs work, and WiFi / Bluetooth is in good shape? If so, it doesn't seem too limited in comparison to default debian, so I'll take your word for it. My plan is to avoid most DEs anyways, and probably stick to awesomewm/sway/i3 anyways. So assuming the basics are working, I don't think my needs are too complex 
WiFi works but I'm not using (nor testing) bluetooth at the moment. I have seen some people have had difficulty making it work (check out the mainline kernel thread for clues... IIRC there was something about manually supplying a MAC address).
To be clear I am using a distro built by (a very old version) of the installer as my only OS on the PBP. It's robust and I'm now using PBP to build it's own kernel and bootloaders.
Having said that I'm not spending quite as much time on PBP as I might like... because I have a PineTime too ;-) .
Hi, thanks for the installer script, that makes installing a nearly pure Debian much easier!
I was trying to build my own kernel based on the posts in this thread, but when cloning https://gitlab.manjaro.org/tsys/linux-pinebook-pro and then running
Code: make ARCH=arm64 pinebook_pro_defconfig
make KBUILD_IMAGE=arch/arm64/boot/Image bindeb-pkg
there are still a lot of unset kernel options and the config script goes through all of them.
Did you first base the config on the config of the system you built the kernel on and then used the `pinebook_pro_defconfig`?
Hi Daniel,
Thanks a lot for your installer. It is much more polished and efficient than what I was doing manually.
I have an issue with libva (video decoding acceleration). VLC is crashing when I launch a video and I can see the same error as in the vainfo command:
Code: antoine@frisbee:~$ vainfo
libva info: VA-API version 1.6.0
libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/rockchip_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
In fact, looking at the kernel output I can see multiple failures to load the firmware:
Code: antoine@frisbee:~$ dmesg |grep dptx
[ 4.428843] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 5.511231] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 7.591180] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 11.671246] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
The firmware is present in /lib/firmware/rockchip and initramfs-update has been ran.
I am a bit frustrated not being able to run vlc. Is there anybody who has had the same problems?
Antoine
(01-15-2020, 12:01 PM)bisco Wrote: Hi, thanks for the installer script, that makes installing a nearly pure Debian much easier!
I was trying to build my own kernel based on the posts in this thread, but when cloning https://gitlab.manjaro.org/tsys/linux-pinebook-pro and then running
Code: make ARCH=arm64 pinebook_pro_defconfig
make KBUILD_IMAGE=arch/arm64/boot/Image bindeb-pkg
Did you first base the config on the config of the system you built the kernel on and then used the `pinebook_pro_defconfig`?
Currently I do the following to configure:
Code: make pinebook_pro_defconfig
scripts/config --set-str LOCALVERSION -1-pinebookpro-arm64
scripts/config --enable COMPAT
scripts/config --disable MODULE_COMPRESS
scripts/config --enable PREEMPT
scripts/config --disable HARDEN_EL2_VECTORS
scripts/config --enable RTC_DRV_RK808
make olddefconfig
I think after changes on Thomas' side some of the above will be redundant but I haven't cleaned it up yet. However disabling MODULE_COMPRESS is mandatory for Debian and disabling HARDEN_EL2_VECTORS is needed for the maxcpus=4 boot time workaround to work correctly.
Once configured I build as follows (I adjust KVER by hand at present... but it would script quite easily).
Code: KVER=5.4.2-1-pinebookpro-arm64
PVER=`git describe | sed -e 's/\(v[0-9]*[.][0-9]*\)-/\1.0-/' -e 's/^v//'-1`
chrt -i 0 make -j nproc \
KERNELRELEASE=KVER KDEB_PKGVERSION=PVER \
KBUILD_IMAGE=arch/arm64/boot/Image \
deb-pkg
Note that the KVER/PVER stuff is mostly there to ensure the packages can be parallel installed (e.g. if you apt update from my repo it doesn't clobber your existing kernel).
PS I'm happy to point you at my exact kernel sources if you have problems getting something working but, to be honest, putting focus on my kernel is just splitting the development community. Using the Manjaro kernel for your work is, IMHO, better for everyone for now... and you can switch to "real" mainline as soon as Thomas' lands the remaining patches.
(01-16-2020, 04:47 AM)danielt Wrote: Currently I do the following to configure:
Code: make pinebook_pro_defconfig
scripts/config --set-str LOCALVERSION -1-pinebookpro-arm64
scripts/config --enable COMPAT
scripts/config --disable MODULE_COMPRESS
scripts/config --enable PREEMPT
scripts/config --disable HARDEN_EL2_VECTORS
scripts/config --enable RTC_DRV_RK808
make olddefconfig
Thanks, that was exactly what I was looking for! I'm cross compiling the kernel right now!
Quote:PS I'm happy to point you at my exact kernel sources if you have problems getting something working but, to be honest, putting focus on my kernel is just splitting the development community. Using the Manjaro kernel for your work is, IMHO, better for everyone for now... and you can switch to "real" mainline as soon as Thomas' lands the remaining patches.
Yeah, I agree- and maybe we can then also use the arm64 kernel package directly from Debian 
(01-15-2020, 05:28 PM)Antoine Wrote: Code: antoine@frisbee:~$ vainfo
libva info: VA-API version 1.6.0
libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/rockchip_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
I have found the missing driver on github : https://github.com/hizukiayaka/rockchip-video-driver
I am able to compile the master branch and use this driver to launch vlc (using the environment variable LIBVA_DRIVERS_PATH). The video is smooth even at quite high resolution but the colors seem a bit odd. I can compile the devel branch but there is a linking error at runtime.
Where is a good place to keep track of bugs related to the Bullseye image? Maybe on the installer github project? It's easy for issues to get lost on the forum, but filing directly with Debian or upstream makes it hard for Pinebook community members to see the status of thing.
Issues I've noticed so far (Gnome Desktop):
- Issues waking from suspend (~30 seconds for the screen to come back on...or never).
- Screen brightness keys don't work.
- Packaged Firefox crashes (upstream builds work but are tier-2 and don't update themselves).
I was going to ask if the script could be run from x64, then saw all the mount --bind, and thought 'better not'
Quite a slick script, completed OK, but, but
after struggling for 4-5 hours, I would say debian arm64 is not ready for prime time
It felt like I had entered a time warp, back to slackware 3 or so...
I quickly black-screened plasma, then noticed the only browser that worked,
epipany and nv3 were.... lacking(mostly white screen,,crash after few minutes)
firefox (illegal instruction, nothing else), konqueror , falkon (dbind error)
then after a shut off, a hour trying to get connected, (there was no connection applet in
lxqt, icewm, mate, enlightenment, gnome),,, nmcli (I have used before)
refused my CORRECT password! A black screen plasma got me connected,,
(there was a 1 second flash that I could see connection circle)
But cups worked!! and picked up config from eMMC (mrfixits ver did not work,,airprint)
with nv3, but it quickly crashed. Lots of init 3;init 5 (with the black plasma)
Maybe when debian is more mature
Hi Daniel,
Many thanks for sharing your debian-install script, it worked really well for me. I used it to perform a minimal install of Debian bullseye/sid onto a microSD card, then once booted into bullseye used the normal apt commands to install the other packages I wanted.
I have 1 comment on the script's default block device and 1 question regarding firmware.
"install-debian"'s default block device.
With my PBP running the default Debian 9.11 / Mint
Linux Debian-Desktop 4.4.207 #2 SMP Sat Dec 21 22:42:47 EST 2019 aarch64 GNU/Linux
The block device names are as follows:
mmcblk1 = internal eMMC device
mmcblk0 = microSDXC card
However, once booted into Debian bullseye/sid, those devices have different names
mmcblk2 = internal eMMC device
mmcblk1 = microSDXC card
Note how mmcblk1 can either be the internal eMMC or the MicroSD card.
Caution is needed here as if one is running from the default OS on the eMMC and intends to install to micoSD card the default device used by install-debian script looks like it would overwrite the internal eMMC rather than installing to the microSD slot. This might catch people out, maybe the script have no default value for the block device and insist it is specified.
(If anyone reading this post wants to install the SD and is now concerned about which device name to use for; one way to double check which device has been given which name is by running the blkdev command with the SD slot empty then again with an SD card inserted. The 2nd run of blkdev should show an additional device, this will be the SD card. Now without rebooting use this device name and BLKDEV argument of the install-debian script. ./install-debian BLKDEV=/dev/???? )
Firmware dptx:
I see the same firmware issue with dptx as Antoine reported in #73
Code: root@Debian-Desktop:~# dpkg -S /lib/firmware/rockchip/dptx.bin
firmware-misc-nonfree: /lib/firmware/rockchip/dptx.bin
root@Debian-Desktop:~# md5sum /lib/firmware/rockchip/dptx.bin
cb5347ba640a3f091816d21f19b7cae4 /lib/firmware/rockchip/dptx.bin
root@Debian-Desktop:~# dmesg | grep dptx -B 2 -A 2
[ 4.471977] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4.471979] [drm] No driver support for vblank timestamp query.
[ 4.472968] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 4.514911] panfrost ff9a0000.gpu: clock rate = 500000000
[ 4.515246] panfrost ff9a0000.gpu: mali-t860 id 0x860 major 0x2 minor 0x0 status 0x0
--
[ 5.195658] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 5.195667] cfg80211: failed to load regulatory.db
[ 5.511177] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 6.232603] random: plymouthd: uninitialized urandom read (8 bytes read)
[ 6.233032] random: plymouthd: uninitialized urandom read (8 bytes read)
root@Debian-Desktop:~#
Does anyone have dptx.bin loading ? How ?
(01-16-2020, 09:40 PM)rillian Wrote: Where is a good place to keep track of bugs related to the Bullseye image? Maybe on the installer github project? It's easy for issues to get lost on the forum, but filing directly with Debian or upstream makes it hard for Pinebook community members to see the status of thing.
Issues on github is fine but I'll probably close anything that isn't caused by a bug in the installer or the kernel. IMHO upstream bugs belong in upstream bug trackers.
I'm also of the view that bug trackers aren't the best way to see the overall status of things. They focus exclusively on what doesn't work, which can be pretty misleading.
Better IMHO to create a wiki page for the release and create tables of what is and isn't work plus perhaps some free form notes to transient upstream issues (such as the firefox problems). Not only is that more useful for users but it can also be curated by anyone in the community who interested in compiling and maintaining such information! If someone does put together such a page I'd be happy to link to it from the first post.
|
