i am currently looking for hints concerning the following topics:
1) Start datalogger application after boot:
The goal is to start the application after the file system is completely mounted. Since the datalogger application has a ram disk as temorary storage the rd has to be mounted before the application is started.
Q: Where to place/start the datalogger application (without login, headless system)
2) The watchdog service observes a special file located on the ram disk. I get a lot of log entries related to the unmounted ram disk.
Where can information about the complete boot process be found?
What i am searching for is the sequence of initialisation, staring of services and other things being performed before any login occurs and
-finally- when a user islogging in.
I try to find out where and how to place my own basic services for background processing. Some of them rely on other prerequisites such as mounted ramdisks etc.
Which logs are written by whom at which part of the boot process is also very interesting.
Where can information about the complete boot process be found?
What i am searching for is the sequence of initialisation, staring of services and other things being performed before any login occurs and
-finally- when a user islogging in.
I try to find out where and how to place my own basic services for background processing. Some of them rely on other prerequisites such as mounted ramdisks etc.
Which logs are written by whom at which part of the boot process is also very interesting.
On Thu, 29 Mar 2018 12:57:45 +0200, Newdo declaimed the following:
Do you mean:
between application of power and the transfer of control to Linux kernel
or
between the start of the kernel and the production of a login prompt on the system console
or between the start of the kernel and the production of a login prompt on a graphical environment
For the First, you may have to pay Broadcom -- as I recall, Broadcom provides a black-box blob to the R-Pi foundation which is loaded by the graphics processor, and which then sets up the hardware and loads the Linux kernel image into RAM before allowing the ARM processor to start execution. {Many other boards use a customized version of U-Boot which runs on the main processor and gets loaded by code in a small ROM in place of the initial load going to the graphics processor). Don't know if searching the ARM site would reveal generic documentation for configuring a processor boot system (remember: ARM sells processor /designs/, it is up to the chip designer to wrap the processor core with peripherals to provide booting capability).
Second and Third: Study Linux kernel configuration, device tree definitions, and whatever run-level control scheme is in use. Debian based OS have transitioned from Sys-V INIT to systemd (sys-V made sense to me; I glanced at some systemd stuff and was immediately lost -- it was as cryptic as the device tree). The main difference between 2 & 3 is that 2 stops with processes waiting for input on text consoles, while 3 has to load an X-Window environment and start the desktop login process waiting (if it isn't configured to automatically login as a default user).
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Have you looked at the Debian Reference documentation,
formatting link
If you need to know about stuff that happens after the Linux kernel is booted and controlling the startup process, this would be as as good a starting point as any, especially when combined with the systemd documentation. About the best documentation set I've found is here:
formatting link
The main problems with systemd are that Poettering and his crew seem unable to stop mucking around with it and are fairly careless about code quality, testing and documentation. However, that's old news which became obvious way back when they bollixed up Gnome 2 before getting bored and starting to work on Gnome 3 without tidying up unfinished business on Gnome 2.
Much more recently they managed to stuff up the logging daemon, which is now, apparently, part of systemd. A version got put live on the Fedora distro that screwed up mail system logging levels for Postfix and spamd:
24 hours after a reboot the log levels changed so that all message related mail info-level logging just stopped. Fortunately somebody kicked their goolies good and hard over that, because fixes appeared, but not in a very timely fashion.
I don't like this approach: the best part of the UNIX philosophy is that each program should do one thing and do it well, which also makes maintenance easier. We already have one giant all seeing, all dancing monolithic mishmash, the kernel, and don't need another.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.