OK, it was just a thought.

The 4.14 kernel seems to be problematic.
There are quite a few references to problems on RPi forums as well as some on this forum, where
users went back to the 4.4 or 4.9.

On 31/12/18 08:17, Malte Schmidt wrote:
I changed fstab to contain UUID and uncommented uuid in uEnv.txt. I don't think this is it. 
Kernel boots with the commmandline containing the UUID for root. UUID set in fstab but still no improvement :-(

machinekit@beaglebone:~$ uname -a
Linux beaglebone 4.14.79-ti-rt-r84 #1 SMP PREEMPT RT Tue Nov 13 20:33:45 UTC 2018 armv7l GNU/Linux

machinekit@beaglebone:~$ cat /proc/cmdline
console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=UUID=94daacb3-de67-41a5-8087-c68a02c7e893 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet

machinekit@beaglebone:~$ cat /etc/fstab
UUID=94daacb3-de67-41a5-8087-c68a02c7e893 /  ext4  noatime,errors=remount-ro  0  1
debugfs  /sys/kernel/debug  debugfs  defaults  0  0

machinekit@beaglebone:~$ systemd-analyze blame
     1min 4.570s generic-board-startup.service
         20.171s dev-mmcblk0p1.device
          5.046s systemd-udev-trigger.service

machinekit@beaglebone:~$ blkid
/dev/mmcblk0p1: LABEL="rootfs" UUID="94daacb3-de67-41a5-8087-c68a02c7e893" TYPE="ext4" PARTUUID="e086444d-01"
/dev/mmcblk1p1: LABEL="rootfs" UUID="ab7cd6a9-12eb-434d-b05b-3a51654aec76" TYPE="ext4"



Am Sonntag, 30. Dezember 2018 22:46:23 UTC+1 schrieb Malte Schmidt:
Thanks all. I will give that a try

Am Samstag, 29. Dezember 2018 09:44:08 UTC+1 schrieb Bas de Bruijn:


On 29 Dec 2018, at 09:31, "[email protected]" <[email protected]> wrote:

I don't know if this is related  and know nothing specifically about BBB, but the line
1min 30.559s dev-mmcblk1p1.device
raises some suspicions.

The newer linux kernels are prone to hanging for 1min 30 secs where there are problems with a 'start job'
which usually relates to mounting a drive.

What usually happens is often related to the 'resume / suspend to disk' capability of the kernel, whether you use it or not.

Take this scenario:
You install a distro on a spare partition.
The Debian install program will format the partition you have chosen plus the swap partition.
However the reformatting of the swap partition also changes the UUID

Next boot of your original partition, the UUID in /etc/fstab for the swap partition is wrong and you
get a 90 sec wait with the 'A start job for dev-disk-by-uuid-xxx' message

I got the exact situation a few months ago when installing Buster along side Stretch on my laptop. When booting Stretch again it was looking for the ‘newer’ UUID of the swap partition.
Changed that uuid in fstab file and problem was solved.

So now you adjust your fstab file to point to the right UUID and reboot

On booting there is another wait whilst the kernel repeatedly tries to access the UUID it holds for Resume (which is the old swap partition UUID)

You then need to go to /etc/initramfs-tools/conf.d/resume and change the UUID in that file for the new one for the swap partition
Then you need to run 'makeinitramfs' for each bootable kernel, to create a new ram image which has the correct UUID for swap in it

THEN your original partition will boot quickly.

I would study the elements described above to make sure that the device designation matches the UUID held in fstab / initramfs-<kernel-version> etc etc

If you have introduced a new kernel whose initramfs is not matched to your system, that is a possible cause.

Either way, would be interested to hear the answer when you find it

regards


On 26/12/18 19:18, Malte Schmidt wrote:
Dear all,

this may be the wrong forum but my questions seem to fit neither perfectly the Machinekit nor Beaglebone forums

I've been following this manual to setup Machinekit with Preempt_RT on a BBB. 

Resulting in a Strech installation with preempt_rt kernel v4.4. With this kernel I'm getting long-long boot times of ~2-3 minutes. In the "default" installation this seems to be related to generic board startup service:
The output of systemd-analyze blame with 
         51.582s dev-mmcblk1p1.device
         47.793s generic-board-startup.service
          8.600s NetworkManager-wait-online.service
          4.290s systemd-udev-trigger.service
          ...

When I disable this serivce I'm getting thisd-analyze blame
    1min 30.559s dev-mmcblk1p1.device
          9.837s NetworkManager-wait-online.service
          4.739s systemd-udev-trigger.service
          ...

And I can't make something out of the critical path analysis which shows:
graphical.target @55.127s
└─multi-user.target @55.121s
  └─getty.target @54.807s
    └─[email protected] @54.785s
      └─dev-ttyGS0.device @54.762s


This issue does not seem to exist with v4.14 or v4.19 but for these kernels I'm not able to get the additional firmware images. i.e. 
(sudo apt install linux-firmware-image-`uname -r`)
fails. 
So I went back to v4.4

My var log messages shows this (excerpt, full messages attached)

Dec 26 18:43:30 beaglebone kernel: [    1.876960] of_cfs_init: OK
Dec 26 18:43:30 beaglebone kernel: [    1.882563]  remoteproc0: remote processor wkup_m3 is now up
Dec 26 18:43:30 beaglebone kernel: [    1.882629] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 0x193
Dec 26 18:43:30 beaglebone kernel: [    1.890647] Freeing unused kernel memory: 744K
Dec 26 18:43:30 beaglebone kernel: [    2.382866] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy ava
<snip - repeated a few times>
Dec 26 18:43:30 beaglebone kernel: [    2.409655] random: udevadm: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
Dec 26 18:43:30 beaglebone kernel: [   52.999288] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)
Dec 26 18:43:30 beaglebone kernel: [   53.569319] ip_tables: (C) 2000-2006 Netfilter Core Team
Dec 26 18:43:30 beaglebone kernel: [   55.098407] EXT4-fs (mmcblk1p1): re-mounted. Opts: errors=remount-ro
Dec 26 18:43:32 beaglebone kernel: [   62.508226] nf_conntrack version 0.5.0 (7787 buckets, 31148 max)
Dec 26 18:43:32 beaglebone kernel: [   62.766767] random: nonblocking pool is initialized

Which seems to be related to this: https://github.com/systemd/systemd/issues/4167
But I'm not sure if this is really the root cause.

I got three questions now. 

a) are there any hints / clues what to do regarding the boot time? Should I try and post this question to the Beagle Bone forum?
b) is trying to resolve the issues with linux-firmware-image and using kernel 4.14 or 4.19 the recommended approach
c) is using the preempt_rt kernel still the preferred / recommended way of setting up a new system on a BBB?

Any hints would be appreciated.

BR,
Malte
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to