Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Two questions, the first is related to this thread, and the 5.7.6 kernel images, and the second is more general i/o question, but related to burning the kernel images to microsd.
The first time I used the 5.7.6 xfce-rootfs image, and it didn't take all day to burn to microsd...
I tested xfce, and the trackpad wasn't working, so my first question, is whether or not the trackpad is working for anyone else using the aforementioned xfce-rootfs image, or should the right kernel option be found and the kernel rebuilt so that the trackpad driver will be present either in the kernel or in a kernel module?
To continue, I buggered that card, by not blacklisting the kernels when I ran slackpkg to upgrade it to current, and mainly to get cryptsetup working, because that was missing.
Since I buggered it, I decided to wipe the filesystems, and redo, only this time with the base-rootfs image, because I am more concerned with encrypted setup combining luks and lvm on the internal mmc in the pinebook pro than I am with window manager, so figure I could do without xfce, and that the other image with just the basefs, should burn faster.
Noticing that the dd write speed, during this second burn, seems extremely slow (9.3 Kb/s) -- like a GB/24hourday--leads me to the second question: does anyone know any tricks to speed it up? Does that seem normal?
The cpu doing the work is described in /proc/cpu: AMD A12-9700P RADEON R7, 10 COMPUTE CORES 4C+6G, and there's 1.36 GB of ram. There are no cpu-intensive background processes. Doesn't 9.3 Kb/S seem too slow?
Noticing that the dd write speed, during this second burn, seems extremely slow (9.3 Kb/s) -- like a GB/24hourday--leads me to the second question: does anyone know any tricks to speed it up? Does that seem normal?
Writing to the SDcard on the boards themselves from 15Mb/s to 50Mb/s (depending on the SDcard). Here or with the card, there is a problem with the adapter.
Quote:
I tested xfce, and the trackpad wasn't working, so my first question, is whether or not the trackpad is working for anyone else using the aforementioned xfce-rootfs image, or should the right kernel option be found and the kernel rebuilt so that the trackpad driver will be present either in the kernel or in a kernel module?
You need to check which driver is used for this, and check the kernel configuration.
Here or with the card, there is a problem with the adapter
Sure enough: I got saved by the broken electric lawnmower, which tripped the breaker on the circuit that was powering my device, so I had to start over. When I did, I blew into the slot of the micro-sd card adapter, and on the sdcard before inserting it, resulting, during the subsequent attempt, in write speeds that were 24 times faster (1 gb per hour, instead of per day ) whew.
I got around to find some time to play around with my PBP.
After some attempts to run Slarm64 from the micro SD card, I decided to go ahead and install it on the internal MMC storage card.
I prepared and formatted the partitions the usual way, like I do on an x86_64 machine, and only noticed when running setup that it does not care about any pre-configured partitions or file systems, it will simply overwrite everything.
As far as I saw it created an ext4 root file system with everything on it.
I originally wanted to have my root on f2fs, which I hope is more friendlier on the eMMC than regular ext4.
I read here and there that the PBP can only load the kernel from an ext4 or fat32 filesystem, so I need a /boot that is either vfat or ext4.
I went ahead, created a GPT partition table and two partitions, the first with ext4, and the second with f2fs.
I copied everything from under /boot to the ext4 one, and put the rest on the f2fs one. After editing /etc/fstab, and the uEnv.txt under /boot, I rebooted, but the PBP did not boot from then on, until I restored the original content of the eMMC.
Now, what would I need to do to make this setup work?
After thinking a bit, these would be the steps I would take. Please correct me if I missed anything.
(I still have a tar file holding all files of the installed and customized Slarm64 installation.)
create a dos partition table
create a 256 MB first ext4 /boot partition
create a a second partition that takes up the rest of the free space, formatted to f2fs
put everything from underneath /boot in the tar file to the first partition
put the rest of the tar file's content on the second partition
edit /etc/fstab to automatically mount /boot, and also change the entry for / to point to the correct partition
edit the bootloader's config to point to the correct root device and file system
PROFIT
My second question would be how exactly could I change the boot loader config, and what should I change in it?
I would think that the kernel's cmdline should be changed as well.
As far as I have checked, there is no compiled in kernel cmdline, so whatever it gets must come from the boot loader.
The kernel also has built-in support for f2fs, so that shouldn't be a problem either.
What do you think sndwvs? What should I change in my process above?
I got around to find some time to play around with my PBP.
After some attempts to run Slarm64 from the micro SD card, I decided to go ahead and install it on the internal MMC storage card.
I prepared and formatted the partitions the usual way, like I do on an x86_64 machine, and only noticed when running setup that it does not care about any pre-configured partitions or file systems, it will simply overwrite everything.
As far as I saw it created an ext4 root file system with everything on it.
I originally wanted to have my root on f2fs, which I hope is more friendlier on the eMMC than regular ext4.
I read here and there that the PBP can only load the kernel from an ext4 or fat32 filesystem, so I need a /boot that is either vfat or ext4.
I went ahead, created a GPT partition table and two partitions, the first with ext4, and the second with f2fs.
I copied everything from under /boot to the ext4 one, and put the rest on the f2fs one. After editing /etc/fstab, and the uEnv.txt under /boot, I rebooted, but the PBP did not boot from then on, until I restored the original content of the eMMC.
Now, what would I need to do to make this setup work?
After thinking a bit, these would be the steps I would take. Please correct me if I missed anything.
(I still have a tar file holding all files of the installed and customized Slarm64 installation.)
create a dos partition table
create a 256 MB first ext4 /boot partition
create a a second partition that takes up the rest of the free space, formatted to f2fs
put everything from underneath /boot in the tar file to the first partition
put the rest of the tar file's content on the second partition
edit /etc/fstab to automatically mount /boot, and also change the entry for / to point to the correct partition
edit the bootloader's config to point to the correct root device and file system
PROFIT
My second question would be how exactly could I change the boot loader config, and what should I change in it?
I would think that the kernel's cmdline should be changed as well.
As far as I have checked, there is no compiled in kernel cmdline, so whatever it gets must come from the boot loader.
The kernel also has built-in support for f2fs, so that shouldn't be a problem either.
What do you think sndwvs? What should I change in my process above?
make 2 dos/gpt partitions, 1 partition must have offсeе 32768
1 partition to format ext4, 2 partition in f2fs
move /boot from the image to partition 1, the rest to partition 2
Thanks for your help sndwvs!
I managed to reconfigure my install based on your guidance.
The only things I needed to change was that the internal eMMC on the PBP is /dev/mmcblk2, so the partition names needed to be changed appropriately.
Also, f2fs doesn't like the errors=remount-ro mount option in fstab, so that had to go as well.
Apart from that I had a smooth experience, and now by root fs is f2fs!
Thanks again!
Last edited by wowbaggerHU; 12-13-2020 at 12:33 PM.
I tried installing a few of your custom packages, like chromium, vlc and libreoffice.
Chromium works on PBP, but unfortunately libreoffice and vlc doesn't seem to work, and are not overly helpful in their error messages:
Code:
janos@pinebook-pro:~$ libreoffice
LibreOffice 7.0 - Fatal Error: The application cannot be started.
component context fails to supply singleton com.sun.star.deployment.ExtensionManager of type com.sun.star.deployment.XExtensionManager /tmp/libreoffice/libreoffice-7.0.3.1/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/deployment/ExtensionManager.hpp:39
janos@pinebook-pro:~$ vlc
VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[0000000004623c60] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00000000046d8020] skins2 interface error: cannot instantiate dialogs provider
Remote control interface initialized. Type `help' for help.
[00000000046a90e0] main playlist: playlist is empty
^Cjanos@pinebook-pro:~
Is there anything I can do to easily fix these problems?
I tried installing a few of your custom packages, like chromium, vlc and libreoffice.
Chromium works on PBP, but unfortunately libreoffice and vlc doesn't seem to work, and are not overly helpful in their error messages:
Code:
janos@pinebook-pro:~$ libreoffice
LibreOffice 7.0 - Fatal Error: The application cannot be started.
component context fails to supply singleton com.sun.star.deployment.ExtensionManager of type com.sun.star.deployment.XExtensionManager /tmp/libreoffice/libreoffice-7.0.3.1/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/deployment/ExtensionManager.hpp:39
janos@pinebook-pro:~$ vlc
VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[0000000004623c60] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00000000046d8020] skins2 interface error: cannot instantiate dialogs provider
Remote control interface initialized. Type `help' for help.
[00000000046a90e0] main playlist: playlist is empty
^Cjanos@pinebook-pro:~
Is there anything I can do to easily fix these problems?
checked i have it runs with updated libraries.
look at the output for "not found"
All the dependencies seem to be installed, there were no "not found" library dependencies for either libreoffice or vlc.
In case of libreoffice the only problem I can think of is that I don't have java installed. Where should I get it from? Do you have a java package available?
I googled a bit, and found hints on the Arch Linux forum that in case of my error message the fix is to (re)install the clucene package.
I did exactly that and LibreOffice started up just okay.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.