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.
>> https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/
>>
>> 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 [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.
>>
>>
--
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.
