It was present before. The Pinebook Pro, does not have an RTC, so it relies on internet connection to get the correct time via NTP. So the time it shows you at startup is just a “guess” based on the last shutdown point. I think. 
Hey, an issue I can actually help with! What I did is here: forum.pine64DOTorg/showthread.php?tid=10173
Basically, run sudo hwclock -r to check the hardware clock, then run date to check what the OS considers the date (I guess?). To sync the two, just run sudo hwclock -w. That fixed the issue for me! In my experience, the fix is persistent as long as you don’t reinstall the OS or let the battery drain to zilch.
Let me know if that helps!
@Strit, had you seen this before?
Fantastic - thank you!
NetworkManager appears to be a required start-up target. So if you don’t have a network cable plugged in or haven’t configured your wireless settings [cause it’s your first boot]: you’ll get stuck waiting ~10 minutes [after the Bluetooth target appears] for the NetworkManager service to timeout. Once it times out, it will resume booting as normal.
Whomever, packages up the Manjaro releases should set lower timeouts in /etc/systemd/system.conf or remove NetworkManager as a start-up target requirement. [I’m testing Manjaro out for the first time; so don’t know community guidelines for feedback.]
You likely need to plug-in a network cable.
Check out my reply to ArcanHell for more details. [I would link to it, but apparently new forum members aren’t allowed to link to posts…]
We use the defaults from the Arch Linux ARM systemd package. So the issue should also be present on Arch Linux ARM, if this was the cause for it,
While that might be true.
Arch doesn’t come with NetworkManager; to get it, you first need to have a working networking setup to fetch the package. Then once it’s installed the end-user needs to configure systemd to enable and start the NetworkManager service [that does not happen automatically].
The issue here is: whomever configured the systemd NetworkManager service for Manjaro, did so in such a way as it’s a required start-up target and there isn’t a working networking setup [i.e. network cable not plugged in or wireless not configured].
[I’m a Arch Linux and Arch Linux ARM user, testing out Manjaro.]
The only “configuration” we have done, is to enable the NetworkManager service on editions using NetworkManager. We don’t configure it, so it is using the defaults from the packages.
Obviously, the defaults for some packages do not provide optimal results. [i.e. Manjaro makes amendments to the sudoers enabling the wheel group.] The intent from upstream is to provide sane suggestions for most users. But have users correctly choose their options before they enable or start things.
Anyways, this is one case were the defaults are not optimal and some users think their systems are not booting.
[I’m reading your replies, as if you’re implying that it is somehow Arch’s fault for not providing options that work better here.]
I do get your point.
The “problem” is that this issue has only come up recently. So some package, either networkmanager or systemd most likely, changed a default.
As far as I know, NetworkManager.service should not halt the system, when it does not have a connection, it should just continue going through the services to start up.
If we knew what changed, we might be able to “revert” the behavior.
Perhaps, NetworkManager-wait-online service changed/broke? I see some chatter on the Arch side as recently as May.
I will note that the timeout I noticed during boot was ~10 minutes, and not the 30 seconds as is configured in the NetworkManager-wait-online service file.
Yeah. I’m also seeing closer to 10 minutes.
We don’t enable NetworkManager-wait-online in our profiles though, but I see that it is being enabled on new images somehow. Will look into it.
NetworkManager-wait-online gets enable by NetworkManager just like systemd-networkd-wait-online.service does with systemd-networkd. I have pulled the plug on my network and it booted straight into the desktop with no lag so I am not seeing here a dependency. Strit is right that this issue has become more prevalent lately.
What I am seeing is systemd-networkd being enabled and NetworkManager fighting for control going back and forth. I have never liked systemd-networkd and NetworkManager being enabled at the same time and always disable systemd-networkd. I have had issues in the past with this. The NetworkManager and the systemd-networkd wiki’s both say to not have any other network service running when using one or the other.
Here is some lines showing (of many) systemd-networkd and NetworkManager fighting and taking control from each other. Sometimes on a first boot the wait would be a few seconds and other times it would be a long time. This is when it was a long time:
Sep 06 11:30:59 pi4 systemd-networkd[188]: wlan0: Link DOWN
Sep 06 11:30:59 pi4 NetworkManager[302]: <info> [1599409859.1435] device (wlan0): set-hw-addr: set MAC address to 26:D2:55:E5:AF:8D (scanning)
Sep 06 11:30:59 pi4 kernel: brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
Sep 06 11:30:59 pi4 systemd-networkd[188]: wlan0: Link UP
Sep 06 11:30:59 pi4 NetworkManager[302]: <info> [1599409859.1506] device (wlan0): supplicant interface state: disconnected -> interface_disabled
Sep 06 11:30:59 pi4 NetworkManager[302]: <info> [1599409859.1508] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> interface_disabled
Sep 06 11:30:59 pi4 NetworkManager[302]: <info> [1599409859.1528] device (wlan0): supplicant interface state: interface_disabled -> inactive
Sep 06 11:30:59 pi4 NetworkManager[302]: <info> [1599409859.1528] device (p2p-dev-wlan0): supplicant management interface state: interface_disabled -> inactive
Sep 06 11:33:00 pi4 dbus-daemon[639]: [session uid=1000 pid=639] Activating service name='ca.desrt.dconf' requested by ':1.68' (uid=1000 pid=931 comm="mousepad /home/ray/Desktop/New File ")
Sep 06 11:33:00 pi4 dbus-daemon[639]: [session uid=1000 pid=639] Successfully activated service 'ca.desrt.dconf'
Sep 06 11:37:54 pi4 systemd-networkd[188]: wlan0: Link DOWN
Sep 06 11:37:54 pi4 NetworkManager[302]: <info> [1599410274.0556] device (wlan0): set-hw-addr: set MAC address to 2A:67:68:2F:C9:3A (scanning)
Sep 06 11:37:54 pi4 systemd-networkd[188]: wlan0: Link UP
Sep 06 11:37:54 pi4 kernel: brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
Sep 06 11:37:54 pi4 NetworkManager[302]: <info> [1599410274.0615] device (wlan0): supplicant interface state: inactive -> interface_disabled
Sep 06 11:37:54 pi4 NetworkManager[302]: <info> [1599410274.0616] device (p2p-dev-wlan0): supplicant management interface state: inactive -> interface_disabled
Sep 06 11:37:54 pi4 NetworkManager[302]: <info> [1599410274.0628] device (wlan0): supplicant interface state: interface_disabled -> inactive
Sep 06 11:37:54 pi4 NetworkManager[302]: <info> [1599410274.0629] device (p2p-dev-wlan0): supplicant management interface state: interface_disabled -> inactive
I burned a fresh image and disabled systemd-networkd in /user/lib/system-preset/90-systemd.preset while the sdcard was still in my desktop. systemd-networkd is part of the systemd package and is a strange animal. It does not get enabled until the first boot so I had to disable it in the file that gets read. But after you first boot it can be disabled with systemctl:
disable systemd-networkd.service
disable systemd-resolved.service
I also stopped a stop-dmesg.service that we have to stop spam when the set up menu comes up and saw some more lines after the bluetooth where you do not see any and there were a few more lines being printed out about 1 a second setting thing up but no errors.
3 Likes
I have troubles installing Manjaro Sway on my newly shipped PineBook Pro.
What I did:
- Download Manjaro ARM 20.08 Sway, SHA1 is okay.
- Flashed the .img.xz to my SD card using Etcher.
2.b I also copied the .img.xz file into the home folder onto the SD card - Put SD card in Pinebook Pro, Power on, system is running from SD card.
- Installed manjaro-arm-flasher using pamac.
- Run manjaro-arm-flasher, using the .img.xz file I copied to the SD card earlier, flash it to the internal drive.
- Poweroff, remove SD card, power on:
Manjaro Logo with Spinning wheel for about 1 minute, then a black screen, occasionally showing the error message for a brief moment:
XDG_RUNTIME_DIR is not set in the environment. Aborting.
I tried to find help searching the web, but only found outdated GitHub issues.
Do you have any advice?
That’s wired. Could you pls boot from the working SD card and check the partitions on your eMMC… there should be a BOOT_MNJRO and a ROOT_MNJRO.
Haven’t used the manjaro arm flasher to set up my pbpro as I’m already using a nvme as root partition. So I also just did the usual restore to microSD for the 20.08 image without any issues…
$ lsblk -o +FSTYPE,LABEL
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT FSTYPE LABEL
mmcblk2 179:0 0 58,2G 0 disk
├─mmcblk2p1 179:1 0 213,6M 0 part vfat BOOT_MNJRO
└─mmcblk2p2 179:2 0 58G 0 part ext4 ROOT_MNJRO
mmcblk2boot0 179:32 0 4M 1 disk
mmcblk2boot1 179:64 0 4M 1 disk
mmcblk1 179:96 0 116G 0 disk
├─mmcblk1p1 179:97 0 213,6M 0 part /boot vfat BOOT_MNJRO
└─mmcblk1p2 179:98 0 115,8G 0 part / ext4 ROOT_MNJRO
zram0 252:0 0 5,6G 0 disk [SWAP]
It seems to be fine…
Japp looks good. Just to make sure the flashing was a ok could you please try it in another way…
- boot from microSD
- open up a terminal
- go to the folder holding your downloaded image file
- get root via
sudo su - - run
xzcat Manjaro-ARM-sway-pbpro-20.08.img.xz | dd of=/dev/mmcblk2 bs=1M status=progress conv=fsyncto flash it to eMMC - after it’s done reboot the pbpro and follow the initial setup wizard steps
1 Like
Awesome, this way it worked. Thank you 
2 Likes
My pleasure!