Logs

But why did they make this change? The old dhclient worked, didn't it?

There appears to be a tendency to replace old and trusted software from trusted developers by newfangled crap that more mimicks the behaviour and stability of Microsoft Windows, but why would "we" want to do that?

For example, with every package designed by Lennart Poettering I remove from a system, the system gains stability and improves in performance. (recently I again had that experience, this time with ifplugd, yet another completely useless program that only causes problems. just remove it!)

However, all the time we have to row against the flood of such packages introduced by the distributors. Is there a secret plot behind that?

Mostly, yes. I believe the isc-dchp-client that was used before had some issues with IPv6 addresses.

Using the new one is something to do with the choice of Wifi GUI tool. It works ok if all you want to do is use a standard DHCP setup.

I'm not keen on the idea of "That has been the standard method since forever - let's get rid of it!" that seems to be going around. Notwork Mangler was one example that I never got on with, but at least that made a show of acknowledging the interfaces file. This new dhcp daemon doesn't seem to even bother with that (I'm willing to believe that there might be a way to configure it to work "properly" though)

Ah... I do recognize that! We have some immediate requirement and replace the working system with a newly written untested program, and without looking into other requirements than the writer has on his own system...

Another one is the new idea of moving the entire system into the init program (then called systemd), and in the process modify many other things that "systemd cannot handle". (instead of implement changes into it to overcome those shortcomings)

Fortunately I still have a raspbian image from 2013 that I still use on all my new deployments, and from which things like ifplugd can still easily be removed.

Those are just log entries - did you search /etc and ~/ ?

It does not appear to be installed using the above.

Malcolm

Yes, it appeared to search /etc. I have now got the required result i.e. 192.168.1.90 in use by following a forum method given by Nat. Philosopher

The drawback is that WiFi Config does not appear to be used, that is it remains blank.

Malcolm

Tht is a general way with linux.

The raw behind the scenes way of doing things has been overlaid with windows like GUI tools, which have minds of their own and probably thrir own config files and work on the machine as a user level device.

For example, if I switch users on my desktop any USB drives already mounted are unavailable to the new user and give errors.

The sp0rt of rationale is that the machine is a single user desktop machine and therefore it ought to have everything that a user does vanish with that user.

However the other way of looking at a linux machine - as a multi-user server - has a completely different mind set associated with it,. You don't want ip addresses changing on a whim...

Op 05-08-15 om 00:33 schreef T M Smith:

What's with the endless difficult problems?!

Just go full dchp on all connected devices (ie. don't adjust anything from the standard install) and assign fixed addresses on the router, if you must have them.

so that they appear on random IP addresses? fine for clients, not fine for servers...

OK you CAN get around it if the router or DHCP server allows you to create a linkage between MAC addresses and IP addresses..

On Sun, 09 Aug 2015 16:02:03 +0100, The Natural Philosopher declaimed the following:

There are routers that don't offer that?

Manually Add Client Enter Client Name Assign IP Address To This MAC Address [ ] 192 . 168 . 2.[ ] [ ]

Or I can check a box for the clients already connected and lock them into their current IP assignments.

Probably works well but a complete unkown to me.

Malcolm

Log on to your router's admin web page, look for a way to assign a fixed (but effectively dhcp assigned) ip address for clients. Most routers can do that, I'm sure.

T M Smith wrote in news: snipped-for-privacy@tmsmith36.plus.com:

I was told early on that there was no log. It has something to do with the BOOT process starting in the GPU and there is a point where the filesystem is mounted such that it is too late to do any BOOT logging.

Pleae correct me here if this is wrong.

It does start in the GPU, but rapidly gets handed over to Linux ...

True: The early log entries can't be written *live* to a filesystem as no filesystems are mounted, same for most Linux. But ..

You don't need a filesystem to maintain a log. You keep it in memory.

Does "dmesg" shortly after boot provide you the information you need?

"dmesg: The program helps users to print out their bootup messages."

Note, the earlier entries will eventually be overwritten, so don't expect to go back to when you booted days ago :)

Have you looked at /var/log/boot.log?

I can't comment on whether you are right or wrong.

I understand the BIOS boot sequence might not be able to write to disk but surely the boot process needs access to the file system before booting Linux from the file system.

Mostly wrong.

The bootloader (the thing that does the coloured square) doesn't write to flash and doesn't log TTBOMK (apart from on the Pi 4 where using the serial port is an option).

But as soon as the Linux kernel is loaded it starts logging. To begin with it logs to a memory buffer. When the filesystem/init system comes up that buffer is written to disc and subsequent logging gets appended.

The memory buffer can be dumped via the 'dmesg' command or the /proc/kmsg device. The location of the log can vary by distro but /var/log/messages, kern.log and boot.log are good places to start.

The two stages of bootloader do know how to read SD card and more recently USB. However it's a lot simpler and less dangerous to read something than it is to write it.

Theo

Forgot to add, a lot of the messages that are displayed at boot aren't coming from the kernel, but from other services on the system. Those don't show up in dmesg, which is purely the kernel's log.

Other log mechanisms will show them, such as the 'journalctl' command, or looking in places like /var/log/syslog.

Theo

If I'm checking a system for problems, after boot up I do a

dmesg -H

This prints out the kernel logs from boots, in a paginated form so it doesn't just shoot paste. Look for any red lines which signify errors, you'll normally only get a couple from brcmfmac which can normally be ignored.

I then do a

systemctl --failed

Which will show any services which didn't start up. If any are shown, for each name to a

systemctl status -l

I then also use vim to look at /var/log/messages (vim uses syntax colouring to make spotting errors easier) to look for issues before and/or after the reboot. If there are problems, more information will be in /var/log/syslog You may need to look in /var/log/syslog.1 for information from before the reboot.

---druck