[Solved] hwdb.bin does not exist

weirddan455 · 2014-11-17 05:06:33

weirddan455 wrote:

root wrote:
A bit puzzling though that for some the message shows up in the journal and for others, me included (though my Archy is quite an 'open bar' as of late lol), it does not...
I think it will only show for initramfs images created after the update to systemd 217. I only got this error when I updated to kernel 3.17.3 today.

Sorry I misread that... I thought you meant showing up in general. It does not show up in journalctl nor dmesg for me. I noticed it on boot because it appears a couple lines above where it asks me for my LUKS passphrase. The reason it doesn't show up in journalctl I think is because it's before root even gets mounted and it won't show up in dmesg because it's coming from a userspace program, not the kernel. There's not really a good system in place to log very early userspace like this.

hoschi · 2014-11-17 08:52:14

Thanks for the explanation, why the message is missing from the log. That is the only bewildering thing left here.

But why some people can see the message in the log? Difference between usage of an initramfs and no initramfs at all? Or hook systemd vs. base? Or loglevel?

Last edited by hoschi (2014-11-17 09:00:44)

weirddan455 · 2014-11-17 11:01:17

hoschi wrote:

Thanks for the explanation, why the message is missing from the log. That is the only bewildering thing left here.
But why some people can see the message in the log? Difference between usage of an initramfs and no initramfs at all? Or hook systemd vs. base? Or loglevel?

One person suggested to look in journalctl (probably incorrectly) but I don't think anyone has reported actually finding it there. The error appears to be coming from the udev hook in initramfs. I don't know of any configuration that will allow logging of initramfs hooks. Systemd can't log it because systemd hasn't been loaded yet and the kernel won't log it because it's userspace.

karol · 2014-11-17 11:35:47

weirddan455 wrote:

One person suggested to look in journalctl (probably incorrectly) but I don't think anyone has reported actually finding it there.

https://bbs.archlinux.org/viewtopic.php … 0#p1474780

hoschi · 2014-11-17 11:57:13

Hello "one person"
Did you changed any log setting?

karol · 2014-11-17 11:59:12

What exactly do you mean? What commands should I run or what configs should I post?

hoschi · 2014-11-17 16:43:10

This is not necessary
I just want to know if you changed any of the defaults responsible for logging on your system.

mcloaked · 2014-11-17 18:20:17

Is systemd version 2.18 likely to arrive in [core] fairly soon? - if so then this issue will likely resolve itself. However we have been told that the message is harmless so why worry about it?

root · 2014-11-18 00:42:55

@cfr

I checked as soon as I logged in. And the closest I got (and get) is to see the 'starting version 217' notification which appears right before the hwdb.bin one.

@weirddan455

No worries. The thing is, just as I told the user cfr, that the 'starting version 217' notification which, at least in my case, does appear right before is indeed being logged but the hwdb.bin one is not. And as the user karol has shown the journal is indeed able to log it (maybe a look at his journald.conf - can't think of another place for this - could help to see if there is a hint as to why exactly in his case it did happen)

@mcloaked

More than the message itself the discussion, as far as I understand it, has evolved as to why the notification does appear in the journal or not.
For example, imagine that you see this thread and you want to know if your system had this message as you didn't pay attention during the startup. Reboot or simply check the journal?
Using the system tools that should give you that kind of information would be the advisable way to do it.
Additionally, if the 'karol mistery' is solved it might offer the clue to expand the journal's logging capacities for those who do not have the notification listed. Something that always comes in handy in terms of getting/providing the necessary information when dealing with issues.

karol · 2014-11-18 00:48:04

hoschi wrote:

This is not necessary
I just want to know if you changed any of the defaults responsible for logging on your system.

I don't recall messing much with the journal, I've just set the max size.

Raynman · 2014-11-18 09:29:46

karol wrote:

hoschi wrote:
This is not necessary
I just want to know if you changed any of the defaults responsible for logging on your system.
I don't recall messing much with the journal, I've just set the max size.

I haven't set anything (everything's commented in journald.conf), but like you, I have the message showing up in the journal.

WorMzy · 2014-11-18 12:56:37

I suspect that Karol uses the systemd hook in mkinitcpio.conf, but you do not. As this happens in the early userspace, and is not a kernel message, I assume that the journal would need to be running to intercept it.

karol · 2014-11-18 16:37:23

Yup:

HOOKS="systemd autodetect modconf block filesystems sd-vconsole fsck"

Radioactiveman · 2014-11-18 16:55:53

systemd 217-7 from [testing] is supposed to fix this [1], but I still see the message.
I am using "quiet loglevel=3" as kernel parameters.

[1] https://projects.archlinux.org/svntogit … 824e04aee4

falconindy · 2014-11-19 01:56:03

Because you didn't rebuild your initramfs.

terry · 2014-11-19 05:36:58

Very informative thread. I hit exactly the same issue when updating the Arch Linux Vagrant Box. Ran the

udevadm hwdb --update

to no avail. Ended up finding this thread.

As many have already pointed out, this message will not be logged unless the systemd hook is added into the initramfs.

Thanks @karol for pointing this out. Once base and udev HOOKS were replaced by systemd, regenerate the initramfs and boot. The error message will be written in to the journal. Confirmed.

Below is a screenshot from VirtualBox showing the "warning" message. I think we can just ignore it.

Last edited by terry (2014-11-19 06:15:27)

hoschi · 2014-11-19 12:57:22

WorMzy wrote:

I suspect that Karol uses the systemd hook in mkinitcpio.conf, but you do not. As this happens in the early userspace, and is not a kernel message, I assume that the journal would need to be running to intercept it.

That is possible, at work im running "base" and at home "systemd". So I will boot up my machine and home and check if it is logged there

root · 2014-11-20 02:14:40

Just checked the wiki again and it seems the comment regarding the 'incompatibility' between the resume hook and the systemd one was just updated marking the latter as 'obsolete'.
I might give it a shot once I get some time and see how it performs (yes, and checking the journal again too afterwards )

@terry

falconindy already stated that it can be ignored

Last edited by root (2014-11-20 02:57:24)

weirddan455 · 2014-11-20 03:21:15

WorMzy wrote:

I suspect that Karol uses the systemd hook in mkinitcpio.conf, but you do not. As this happens in the early userspace, and is not a kernel message, I assume that the journal would need to be running to intercept it.

Well I think that answers that. I'm using the base hook instead of systemd and the message did not get logged for me. It must be that systemd hook that let it get logged for those that do see it.

root · 2014-11-20 04:45:02

I couldn't resist and already have updated my mkinitcpio.conf with the systemd hook removing the udev and the resume one (I kept the base hook as a rescue shell always comes in handy IMHO).

Regarding the notification it does now show up in my journal but it does not during my startup anymore.
This circumstance lets me thinking as to why would I look for something in the journal when I do not even know that the message is "supposed" to call my attention and can be checked there after the boot process?
At first I thought it could be due to keeping the base hook but after removing it and creating a new kernel image it still does not show up as it did before.

As soon as I restore the old hooks, especially the udev one I presume, the message shows up again (even though due to the testing rush I forgot to check the journal but I honestly don't think there was any change as with regard the previous 'no showings' due to the lack of the systemd hook).

Still quite puzzling...

karol · 2014-11-20 04:48:49

I don't understand what you mean.
Can you rewrite your post a bit and open a new thread please? Tell us what exactly is your current setup, your kernel command line, hooks, package versions etc. and what's happening as opposed to what you think should be happening.

root · 2014-11-20 05:06:37

karol wrote:

I don't understand what you mean.
Can you rewrite your post a bit and open a new thread please? Tell us what exactly is your current setup, your kernel command line, hooks, package versions etc. and what's happening as opposed to what you think should be happening.

I am not sure if you addressing me as I am the last poster or possibly meant to post in a different thread :-?

If it is the former, it is as simple as

- without the systemd hook to mkinitcpio.conf (+base + udev + resume) = hwdb.bin notication shows up during boot (but not in the journal)

- with the systemd hook added to mkinitcpio.conf (+/-base -udev -resume) = hwdb.bin notification does not show up during boot (but it does in the journal).

If it is the latter, please, ignore this message.

acottrell · 2014-11-20 16:19:21

@LarryAtLinaxe: +1. I'm seeing this message fleetingly at boot, but not via journalctl or dmesg.
There have been some other messages of this general sort from previous kernels that only
show up on-screen at boot. Wassup with the journal, I wonder?

ukhippo · 2014-11-20 17:49:33

@acottrell:
This message is a userspace message, not a kernel one - so it won't appear in dmesg.
This message is occurring very early in the boot process before systemd (and hence journaling) has been started - thus the only place to send this message is the screen.

As explained earlier in this thread, you have to switch to using the systemd hook in your mkinitcpio.conf if you want to have the message logged to your journal. Depending on your system, it may not be possible to switch to using the systemd hook.

@root:
By default the ForwardToKMsg and ForwardToConsole options of journald.conf are false. You probably need to enable one of these (and maybe change the corresponding MaxLevel* option).
I don't know if the hook uses an initramfs specific journald.conf

root · 2014-11-21 02:05:30

@ukhippo

Thanks for the hint. I played around with those settings and the closest I get is to see the 'Starting version 217' notification when I set 'MaxLevelConsole' to 'debug'. After this, where the hwdb.bin one is supposed to appear (and which by the way now after the addition of the systemd hook appears after the fsck process :-?) I get some loaded modules list.

Could someone who sees the hwdb.bin notification during boot and gets it logged in the journal be so kind as to post their journald.conf? Thanks in advance.

I might also give the removal of the base hook another try in case that changes the behaviour.

Arch Linux

#26 2014-11-17 05:06:33

Re: [Solved] hwdb.bin does not exist

#27 2014-11-17 08:52:14

Re: [Solved] hwdb.bin does not exist

#28 2014-11-17 11:01:17

Re: [Solved] hwdb.bin does not exist

#29 2014-11-17 11:35:47

Re: [Solved] hwdb.bin does not exist

#30 2014-11-17 11:57:13

Re: [Solved] hwdb.bin does not exist

#31 2014-11-17 11:59:12

Re: [Solved] hwdb.bin does not exist

#32 2014-11-17 16:43:10

Re: [Solved] hwdb.bin does not exist

#33 2014-11-17 18:20:17

Re: [Solved] hwdb.bin does not exist

#34 2014-11-18 00:42:55

Re: [Solved] hwdb.bin does not exist

#35 2014-11-18 00:48:04

Re: [Solved] hwdb.bin does not exist

#36 2014-11-18 09:29:46

Re: [Solved] hwdb.bin does not exist

#37 2014-11-18 12:56:37

Re: [Solved] hwdb.bin does not exist

#38 2014-11-18 16:37:23

Re: [Solved] hwdb.bin does not exist

#39 2014-11-18 16:55:53

Re: [Solved] hwdb.bin does not exist

#40 2014-11-19 01:56:03

Re: [Solved] hwdb.bin does not exist

#41 2014-11-19 05:36:58

Re: [Solved] hwdb.bin does not exist

#42 2014-11-19 12:57:22

Re: [Solved] hwdb.bin does not exist

#43 2014-11-20 02:14:40

Re: [Solved] hwdb.bin does not exist

#44 2014-11-20 03:21:15

Re: [Solved] hwdb.bin does not exist

#45 2014-11-20 04:45:02

Re: [Solved] hwdb.bin does not exist

#46 2014-11-20 04:48:49

Re: [Solved] hwdb.bin does not exist

#47 2014-11-20 05:06:37

Re: [Solved] hwdb.bin does not exist

#48 2014-11-20 16:19:21

Re: [Solved] hwdb.bin does not exist

#49 2014-11-20 17:49:33

Re: [Solved] hwdb.bin does not exist

#50 2014-11-21 02:05:30

Re: [Solved] hwdb.bin does not exist

Board footer