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.
Hi
first of all thanks drmozes for the release, its awesomwe!
Just for info, as you said sdcards are unreliable, i can confirm that one of my two rpi4s broke three of them, while my other just did fine, so it seems to be a rpi4 hardware issue. I installed it with the other and everything went like charm.
I was able to boot the "damaged pi" with an sdcard i installed with the "good pi". The sdcards from the "damaged one" were unusable after my try to install Slackware, this means they were in a "frozen" state i couldn't change anything like partition table with gparted/fdisk/cfdisk, i even tried MS-Windows, a Android Phone and more.
Just to clarify it seems like a rpi4 related hardware issue not with the installer.
So i wanted to give a warninig if your pi does something like this dont try another sdcard.
Sunzu
When I was installing and at "Installing Slackware"
Power on the RockPro64, mine was on when I connected power, didn't have to Press the Power Button for approximately two seconds.
There was no "Found /extlinux/extlinux.conf" and all that.
I don't remember what the messages were, something about retrieving different files to boot from, I was going to try to take pictures, so I pressed power button while it was displaying the messages, instead of restarting it looked like it went into first boot, "Found /extlinux/extlinux.conf" and all that.
I got same output from all the steps. Now when I reboot, I see
I think (hope) I finally succeeded installing slackwareaarch64-current onto my Pinebook Pro!
Problems I ran into:
some strangeness about the willingness to boot depending on the charging port used (barrel-port => bad, usb-C => good.) Looks like hardware quirks.
I hoped to be able to keep the emmc enabled to use as storage. Alas warm reboot tries to boot off it so only cold boot is usable. I had to disable as per the tutorial.
having /home encrypted isn't practical as the password is prompted for in the UART console. I chose to keep UART active during installation and can't find how to change this now because
the uSD used as /boot isn't mountable. It boots fine but I can't mount it.
At least it seem to boot reliably, it's stable (had to rsync a lot, compile many things and it did all without a hiccup) and my Pinebook Pro has a purpose in life again!
Last edited by cycojesus; 04-09-2022 at 08:47 AM.
Reason: typos
Power on the RockPro64, mine was on when I connected power, didn't have to Press the Power Button for approximately two seconds.
Mine doesn't!
Quote:
I don't remember what the messages were, something about retrieving different files to boot from, I was going to try to take pictures, so I pressed power button while it was displaying the messages, instead of restarting it looked like it went into first boot, "Found /extlinux/extlinux.conf" and all that.
You'd have to provide output here. Not every line of text on the screen is mentioned in the documentation.
Quote:
not sure what this means, maybe related to "Installing Slackware" step?
I don't know why the message about bad CRC won't quote in the forum here but that's nothing to worry about - it'll always say that unless you save the u-boot environment. I'll fix it by default at some point but it requires some hacking, and it's a harmless warning.
Quote:
ALSO
not in the document I came across
(re missing step in docs)
Again, not sure why it won't quote your text but I wondered if anyone would notice that omission! I added in the firmware syncronisation 1 day before release. I'll add it to the docs some time.
I think (hope) I finally succeeded installing slackwareaarch64-current onto my Pinebook Pro!
Problems I ran into:[LIST][*]some strangeness about the willingness to boot depending on the charging port used (barrel-port => bad, usb-C => good.) Looks like hardware quirks.
I didn't know you *could* power it from the USB-C! Mine is powered from the barrel port.
Quote:
[*]I hoped to be able to keep the emmc enabled to use as storage. Alas warm reboot tries to boot off it so only cold boot is usable. I had to disable as per the tutorial.
Yep. The only fix for this would be to change the boot order in U-Boot to avoid booting off eMMC first - which involves patching it.
However to be frank, the eMMC is poor quality and I wouldn't store anything on it that I wanted to keep safe.
Quote:
[*]having /home encrypted isn't practical as the password is prompted for in the UART console. I chose to keep UART active during installation and can't find how to change this now because
Yes that is a known issue. I'm not sure how to address that yet although it probably can be.
Quote:
[*]the uSD used as /boot isn't mountable. It boots fine but I can't mount it.
I'm not sure what you mean here - if /boot cannot be mounted, the system isn't going to boot.
I didn't know you *could* power it from the USB-C! Mine is powered from the barrel port.
You can, I'm using a 15W rpi4 adapter through the pine dock now.
I must say I haven't understood the problem nor been able to have reproducible method but I've thought the pbpro dead several times until it booted many days later.
It wasn't booting this morning. I tried shorting the spi chip thinking trying tow-boot messed something, unplugged the battery and installed Slackware without it and with the bypass plugged. All that worked and with the help of the uart console I got to this stable stage where I removed the encrypted home (I think I read an article about installing OpenBSD mentioning the same issue about encryption password) and disabled the eMMC. https://tow-boot.org/ is really nice by the way, I don't think it's actually the source of my issues and it looks to be adopted by Manjaro and maybe other distributions.
Yep. The only fix for this would be to change the boot order in U-Boot to avoid booting off eMMC first - which involves patching it.
However to be frank, the eMMC is poor quality and I wouldn't store anything on it that I wanted to keep safe.
Yes that is a known issue. I'm not sure how to address that yet although it probably can be.
The uart console told me what was wrong there, the pbpro wasn't very talkative. I knew I was outside the "blessed path" anyway. I have a 1TB ssd in it so losing 64GB isn't such a big deal.
Quote:
Originally Posted by drmozes
I'm not sure what you mean here - if /boot cannot be mounted, the system isn't going to boot.
I'm as surprised as you are.
Here's the output of `mount`:
Code:
mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=32768k,mode=755)
devtmpfs on /dev type devtmpfs (rw,relatime,size=8192k,nr_inodes=457245,mode=755)
/dev/nvme0n1p3 on / type ext4 (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs (rw,relatime,size=8192k,mode=755)
cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
blkio on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
memory on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)
devices on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
perf_event on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
hugetlb on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)
pids on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids)
/dev/nvme0n1p2 on /home type ext4 (rw,relatime)
cgroup on /sys/fs/cgroup/elogind type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib64/elogind/elogind-cgroups-agent,name=elogind)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=396088k,nr_inodes=99022,mode=700)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=396088k,nr_inodes=99022,mode=700,uid=1000,gid=100)
and the `/etc/fstab`:
Code:
LABEL=SLKswap0 swap swap defaults 0 0
LABEL=SLKroot / ext4 defaults 1 1
/dev/nvme0n1p2 /home ext4 defaults 1 2
# This is the SD card that contains an ext4 file system, housing the
# Linux Kernel and Slackware OS InitRD (Operating System Initial RAM Disk).
LABEL=SLKboot /boot ext4 errors=remount-ro 0 1
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro,comment=x-gvfs-show 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs nosuid,nodev,noexec 0 0
`dmesg| grep mount`
Code:
[ 17.812584] EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Quota mode: none.
[ 22.374066] EXT4-fs (nvme0n1p3): re-mounted. Quota mode: none.
[ 23.483074] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Quota mode: none.
[ 23.958024] EXT4-fs (mmcblk1p1): mount failed
[ 27.810336] EXT4-fs (mmcblk1p1): mount failed
`sudo mount /boot`
Code:
mount: /boot: can't read superblock on /dev/mmcblk1p1.
dmesg(1) may have more information after failed mount system call.
and finally `fdisk -l /dev/mmcblk1`
Code:
Disk /dev/mmcblk1: 28.91 GiB, 31046238208 bytes, 60637184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xce6050cb
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 6144 60637183 60631040 28.9G 83 Linux
The last manual action I did to that card was dd'ing the installer on it. Then I (think I) told the installer to remove itself from it and extend the partition (something like that, I don't exactly remember.)
Maybe something's just wrong enough with the SD to make it not mountable yet bootable. I don't feel very confident in such a system, I'll have to make a backup of the card and make another one. Also I'll try to read it on different computer.
Therefore you are advised to manually label the file systems and modify the OS /etc/fstab accordingly.
Before adding additional drive using using pine pcie to dual sata-III card
SLKswap0 and SLKroot are identified as sda1, sda2 respectively and SLKboot is mmcblk1p1.
With additional storage /dev/sdb1 added as label sdb1, fstab adjusted accordingly
Quote:
LABEL=sdb1 /home/server/sdb1 xfs defaults 1 1
system comes up as
Quote:
/dev/mmcblk1p1 * 6144 125173759 125167616 59.7G 83 Linux
/dev/sdb1 2048 8390655 8388608 4G 82 Linux swap
/dev/sdb2 * 8390656 468862127 460471472 219.6G 83 Linux
Continuing with rockpro64 aarch64 install, applied all the updates the other day, all is well.
Quote:
The CPU fan speed is controlled statically during boot. By default it'll set the speed to '65' which is the lowest speed.
Side note, I'm looking into, following up, cpu fan seems to be last message before login prompt, fan kicks in high speed then settles down, that is, before I rearranged things, now the fan stops. I have the rockpro64 in an old desktop case, near a case fan, a little to help keep things cool maybe more so to keep dust from settling on critical stuffs.
I touched the heat sink and it's not even warm, so I guess the fans threshold to turn on hasn't been reached, 91F right now, load is dead still.
Side note, I'm looking into, following up, cpu fan seems to be last message before login prompt, fan kicks in high speed then settles down, that is, before I rearranged things, now the fan stops. I have the rockpro64 in an old desktop case, near a case fan, a little to help keep things cool maybe more so to keep dust from settling on critical stuffs.
I touched the heat sink and it's not even warm, so I guess the fans threshold to turn on hasn't been reached, 91F right now, load is dead still.
If you set /etc/rc.d/rc.platform.conf to CPU_FAN_MAX_SPEED=65, does the fan stay on? How about at 255? I've had mixed results. My fan seems to turn off if the max or the minimum fan speeds are replaced by any other speed. The /etc/rc.d/rc.platform.d/aarch64/rk3399 may be of interest for anyone else experiencing this issue.
In short, I noticed my fan speed is set to "0" if I do not set CPU_FAN_MAX_SPEED variable to max or min. Commenting out the variable yields a fan that slows to a halt shortly after the script exits.
I was able to reproduce this behavior by setting the speed to "80".
If you set /etc/rc.d/rc.platform.conf to CPU_FAN_MAX_SPEED=65, does the fan stay on? How about at 255? I've had mixed results. My fan seems to turn off if the max or the minimum fan speeds are replaced by any other speed. The /etc/rc.d/rc.platform.d/aarch64/rk3399 may be of interest for anyone else experiencing this issue.
In short, I noticed my fan speed is set to "0" if I do not set CPU_FAN_MAX_SPEED variable to max or min. Commenting out the variable yields a fan that slows to a halt shortly after the script exits.
I was able to reproduce this behavior by setting the speed to "80".
With my various RockPro64's the fans (despite them being supposedly the same) spin at different RPMs when the same values are set via the driver's interface, and one of them didn't respond at all until it the max speed was set a few times (hence why the fan control script works that way).
The fan stuff in the OS is all a bit hacky and should be replaced by something proper at some point.
Suggestion box is open ;-)
I touched the heat sink and it's not even warm, so I guess the fans threshold to turn on hasn't been reached, 91F right now, load is dead still.
The fan speed set via the driver's /proc interface is a hard coded value where I tried to strike the balance of an intrusive noise vs cooling the chip.
If the fan isn't spinning, it's probably stuck physically or just won't spin at the lower settings for whatever reason. Try setting the max (255?) and see if that starts it up.
I found that if I set my fan to 255 or 65 using the rc.platform script,then the fan stays running. If I try a different setting, such as 80, 100, 200, the fan will speed up then just turns off completely. So I settled for 65. The odd thing is that the rc.platform.conf must be configured to 65 and must be executed one more time after runlevel 3 drops to the login prompt.
I will have to turn down the music and leave the headphones off so I can keep an eye on it!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Pinebook Pro
