Found the issue:
sudo hdparm -Tt /dev/mmcblk0
Timing cached reads: 240 MB in 2.00 seconds = 119.84 MB/sec
Timing buffered disk reads: 2 MB in 5.60 seconds = 365.82 kB/sec
<------ Wow !
Bad memory card ????
On Wed, Jan 24, 2018 at 1:39 PM, Duff, Bryan <bryan.duff1(a)abbott.com> wrote:
> Eh, I’ll give it a go… on F26 armhf7l. Keep in mind my repos may be
> different, so it might very the timing by maybe 30s?
> time sudo dnf install rygel –y
> Unfortunately it’s only 21 packages for me. And now that I look at it,
> would probably be better to “dnf download” first and time that separately.
> //start snip
> real 3m34.645s
> user 1m54.094s
> sys 1m19.396s
> # and
> sudo hdparm -Tt /dev/mmcblk0
> Timing cached reads: 834 MB in 2.00 seconds = 417.21 MB/sec
> Timing buffered disk reads: 68 MB in 3.06 seconds = 22.24 MB/sec
> //end snip
> *From:* linux guy [mailto:email@example.com]
> *Sent:* Wednesday, January 24, 2018 2:31 PM
> *To:* Richard Ryniker
> *Cc:* arm(a)lists.fedoraproject.org; marcin steć
> *Subject:* [fedora-arm] Re: Exactly how slow is Fedora 27 on an RP3 ? dnf
> update takes hours ?
> I just ran #time dnf install rygel on my fresh install. It required 56
> real 64m43.986s
> user 1m59.778s
> sys 0m25.893s
> This is on a console only machine, no GUI.
> Could someone run the same process on their RPi3 and see what they get ?
> This communication may contain information that is proprietary,
> confidential, or exempt from disclosure. If you are not the intended
> recipient, please note that any other dissemination, distribution, use or
> copying of this communication is strictly prohibited. Anyone who receives
> this message in error should notify the sender immediately by telephone or
> by return e-mail and delete it from his or her computer.
Thanks to the powers that be for getting Fedora onto the ARM platforms. I
really appreciate your work.
I'm wondering if Fedora 27 is really, really slow on a RPi3 or if I'm doing
something wrong or ???
I installed F27 Server Arm on an RPi3. The file I used was
Fedora-Server-armhfp-27-1.6-sda.raw.xz from https://arm.fedoraproject.org/
The installation was mostly straight forward.
Naturally the first thing I do is run #dnf update. Upon pressing return
the screen does nothing for 15 minutes. Eventually it comes back saying
~225 packages need updating, 2 need deleting and ~10 need installing. I
say yes to this. The package downloads go OK, takes probably 10 minutes.
But the Upgrading itself is horribly slow. Like 5 minutes per package, on
Is this normal or is there something wrong with my RPi3 ? I thought it
would be faster than this ?
The only thing I can think of is that I'm running it from a 2A power
adapter, rather than the 2.5A that is suggested. It seems to run fine
though, no errors, etc.
Is my power adapter the problem ?
Summary of Fedora on Odroid XU4
1. with Kernel 4.6.5-300.fc24 system boots without failure, but update
to newer kernel fails due dracut didn't build suitable intramfs
2. newer kernel works only with "cpuidle.off=1" inserted into the
"append" kernel line in the /boot/extlinux/extlinux.conf file, but all
USB3 Hosts failed, no onboard ethernet
3. To boot the system from the eMMC card:
A. The initramfs image file must be rebuilt. The simplest way is to:
a. Boot up using the MicroSD card;
b. Partition the eMMC card such that partition 1 begins on sector
(Default starting sector from fdisk is 2048). There should be
4 partitions created;
c. Mount the Fedora image desired to be installed on the eMMC
d. Copy all partition data from the mounted fedora image
partitions (there are 4 for Fedora 26 ARM images) to the appropriate
e. Update the UUID values on what will be the
/boot/extlinux/extlinux.conf file and /etc/fstab files of the eMMC card;
f. Assuming the eMMC partitions are mounted as such --
mount /dev/mmcblk1p4 /mnt
mount /dev/mmcblk1p2 /mnt/boot
then perform the following mounts --
mount -o bind /proc /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
B. Rebuild the eMMC card's initramfs by executing the following
chroot /mnt dracut --add-drivers='pwrseq_emmc mmc_block'
C. Flash the boot information in the header of the eMMC card;
C. Shutdown the system, then remove the MicroSD card;
D. Boot up using the eMMC card.
4. If the system is to be updated using "dnf update", a new initramfs
image must again be generated. This can be done using steps 1f - B.
above using the new initramfs and kernel images provided by the "dnf
Note to the developers/maintainers of dracut:
The kernel modules "pwrseq_emmc" and "mmc_block" should be included in
dracut for the Odroid-XU3 and Odroid-XU4 such that the user need not
have to execute this procedure each time and update to the system is
Is this correct and complete ?
last step on my Odroid-Xu4 is console output on the small display at the
Cloudshell (Cloudshell features a 2.2“ TFT LCD with a 320×240
resolution. The display is controlled by the well-known ILI9340
[root@myodroid ~]# uname -a
Linux myodroid 4.15.0-0.rc4.git3.1.fc28.armv7hl #1 SMP Sat Dec 23
22:10:52 UTC 2017 armv7l armv7l armv7l GNU/Linux (Running with Fedora
[root@myodroid ~]# fbset -fb /dev/dri/card0
geometry 0 -1225101404 -1225318544 1 0
timings 0 0 0 0 0 0 0
[root@myodroid ~]# fbi -d /dev /dri/card0 -i
using "DejaVu Sans Mono-16", pixelsize=16,67
ioctl VT_GETSTATE: Inappropriate ioctl for device (not a linux console?)
[root@myodroid ~]# lsmod | grep drm
tinydrm 24576 0
exynosdrm 163840 0
analogix_dp 32768 1 exynosdrm
drm_kms_helper 155648 3 tinydrm,exynosdrm,analogix_dp
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
drm 376832 5
cec 53248 2 exynosdrm,s5p_cec
Is there any howto to get this display working with tinydrm? I didn't
find anything beside https://github.com/notro/tinydrm/wiki/Tools