Logs

The search has now produced the following:- Aug 7 19-30 raspberry avahi-daemon[2377] Joining mdns multicast group on interface wlan0. ipv4 with address 192.168.1.95 "" etc"" Registering new address for 192.168.1.95 on wlan0. ipv4 "" etc"" Listening normally on 3 wlan0 192.168.1.95 UDP 123
Can anyone make any sense of this ?
Malcolm
--
T M Smith 
Using an ARMX6 and RISC OS 5.21 in the North Riding of Yorkshire
Reply to
T M Smith
Loading thread data ...
Hi Malcolm, ok, maybe you don't have it installed, but it is standard on the latest Raspbian images and bloddy annoying if you want to set a static address.
dhcpcd5 is a DHCP client deamon. It handles the DHCP on your network interfaces. Unlike previous clients it ignores the settings in /etc/network/interfaces and just does its own thing. So if you set a manual address in /etc/network/interfaces you get two addresses - one from interfaces and one set by dhcp.
To check if you have it installed:
dpkg -l dhcpcd5
If it comes up with a line starting with "ii dhcpcd5", then it is installed.
To remove it:
sudo apt-get remove dhcpcd5
Reply to
Dom
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?
Reply to
Rob
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)
Reply to
Dom
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.
Reply to
Rob
Those are just log entries - did you search /etc and ~/ ?
Reply to
Rob Morley
It does not appear to be installed using the above.
Malcolm
--
T M Smith 
Using an ARMX6 and RISC OS 5.21 in the North Riding of Yorkshire
Reply to
T M Smith
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
--
T M Smith 
Using an ARMX6 and RISC OS 5.21 in the North Riding of Yorkshire
Reply to
T M Smith
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...
--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher
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.
Reply to
A. Dumas
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..
--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher
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.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
Probably works well but a complete unkown to me.
Malcolm
--
T M Smith 
Using an ARMX6 and RISC OS 5.21 in the North Riding of Yorkshire
Reply to
T M Smith
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.
Reply to
A. Dumas
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.
Reply to
John Carter
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 :)
--
--------------------------------------+------------------------------------ 
Mike Brown: mjb[-at-]signal11.org.uk  |    http://www.signal11.org.uk
Reply to
Mike
Have you looked at /var/log/boot.log?
--

Chris Elvidge, England
Reply to
Chris Elvidge
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.
Reply to
Pancho
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
Reply to
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
Reply to
Theo

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.