I was not too happy that this just happened after updating one of the DNS secondaries:
May 24 21:29:48 laurel systemd[1]: Starting LSB: Domain Name System (DNS) server, named...
-- Subject: Unit named.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit named.service has begun starting up.
May 24 21:29:49 laurel named[3173]: Starting name server BIND cp: cannot stat '/lib/engines': No such file or directory
May 24 21:29:51 laurel named[3235]: starting BIND 9.10.4-P5 -t /var/lib/named -u named
May 24 21:29:51 laurel named[3235]: running on Linux armv6l 4.3.3-6-raspberrypi #1 Wed Dec 16 08:03:35 UTC 2015 (db72752)
May 24 21:29:51 laurel named[3235]: built with '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var' '--libdir=/usr/lib' '--enable-exportlib' '--with-export-libdir=/usr/lib' '--with-export-includedir=/usr/i
May 24 21:29:51 laurel named[3235]: ----------------------------------------------------
May 24 21:29:51 laurel named[3235]: BIND 9 is maintained by Internet Systems Consortium,
May 24 21:29:51 laurel named[3235]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
May 24 21:29:51 laurel named[3235]: corporation. Support and training for BIND 9 are
May 24 21:29:51 laurel named[3235]: available at https://www.isc.org/support
May 24 21:29:51 laurel named[3235]: ----------------------------------------------------
May 24 21:29:51 laurel named[3235]: adjusted limit on open files from 4096 to 1048576
May 24 21:29:51 laurel named[3235]: found 1 CPU, using 1 worker thread
May 24 21:29:51 laurel named[3235]: using 1 UDP listener per interface
May 24 21:29:51 laurel named[3235]: using up to 4096 sockets
May 24 21:29:51 laurel named[3235]: ENGINE_by_id failed (crypto failure)
May 24 21:29:51 laurel named[3235]: error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:
May 24 21:29:51 laurel named[3235]: error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467:
May 24 21:29:51 laurel named[3235]: error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=gost
May 24 21:29:51 laurel named[3235]: initializing DST: crypto failure
May 24 21:29:51 laurel named[3235]: exiting (due to fatal error)
May 24 21:29:51 laurel named[3173]: ..failed
May 24 21:29:51 laurel systemd[1]: named.service: Control process exited, code=exited status=1
May 24 21:29:51 laurel systemd[1]: Failed to start LSB: Domain Name System (DNS) server, named.
-- Subject: Unit named.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit named.service has failed.
--
-- The result is failed.
May 24 21:29:51 laurel systemd[1]: named.service: Unit entered failed state.
May 24 21:29:51 laurel systemd[1]: named.service: Failed with result 'exit-code'.
It’s in fact a manifestation of [Archive.is] Bug 1040027 – bind (named): fails to start since the introduction of namespaced openSSL packages
A fix is in the pipeline at [Archice.is] Request 496968 – openSUSE Build Service
However, that fix never made it to Raspberry Pi B (the original Rasberry Pi 1B) because that is armv6l and the bind build for that has failed early April 2017.
That’s now in [Archive.is] Bug 1040697 – bind fails building for armv6l since 20170401 causing bugfixes not to make it to the wild.
–jeroen
[9:48pm] <wiert> Hello all.
[9:50pm] <wiert> I just updated one of my Raspberry Pi based secondary DNS servers with zypper duplicate causing named to fail when starting with an issue that is very similar to Debian issues in 2012 and 2016: ghost not loading in a chrooted environment.
[9:54pm] <DimStar> wiert: this sounds a lot like bug 1040027
[9:55pm] <DimStar> can you apply the diff from sr 496968 on your local system? That should get it going
[9:55pm] jordia65 left the chat room. (Ping timeout: 240 seconds)
[9:55pm] <DimStar> (especially the part from /etc/init.d/named )
[9:56pm] <wiert> It is indeed what I was searching for but couldn’t find.
[9:57pm] <wiert> searching for the error lines didn’t reveal any results. Is it OK if I add my journalctl output in the bug?
[9:57pm] <wiert> I’ll probably need some help applying the diff. Not yet proficient enough with diff on the commandline.
[9:58pm] <DimStar> wiert: sure – if it helps others to discover it bettert
[9:58pm] <DimStar> wiert: yeah – I just see that the diff is a bit nasty – as it’s pre-processed during build.. so the easiest will be to just manually edit /etc/init.d/named
[9:58pm] <wiert> OK. I will try editing /etc/init.d/named as I’ve etckeeper running I can always revert when I screw up.
[9:59pm] <DimStar> then around line 185 you have a mkdir /usr/lib64 call.. and below a cp command…
[10:00pm] }-Tux-{ joined the chat room.
[10:00pm] }-Tux-{ left the chat room. (Changing host)
[10:00pm] }-Tux-{ joined the chat room.
[10:00pm] <DimStar> erm.. it’s actually /lib64 in the original file..
[10:00pm] <wiert> I think lines 21-25 of my gist will suffice. Is that OK for you?
[10:01pm] <DimStar> yes, that should be ok for the bug
[10:02pm] robby_ joined the chat room.
[10:09pm] <wiert> I’ve added those and now looking at the diff for vendor-files.tar.bz2/init/named
[10:10pm] <DimStar> wiert: ok.. let me paste you how it should be correctly (at around line 180)
[10:10pm] <wiert> I think I can do this from my joe text editor.
[10:10pm] » wiert is old fart use to WordStar keybindings
[10:11pm] <DimStar> currently you only have /lib64 stuff there – and that should be /usr/lib64/openssl-1_0_0/engines
[10:12pm] » DimStar remembers that the x86_64 snapshot with this issue was actually blocked from being released
[10:19pm] <wiert> actually, none of my Raspberry Pi systems (including the ones not yet updated) have /var/lib/named/usr at all.
[10:20pm] <DimStar> ~that’s right – this is ‘new’ since openSSL moved from /lib to /usr/lib – so up to now the engines were in /var/lib/named/lib64/engines – now they need to be copied to /var/lib/named/user/lib64/openssl-1_0_0/engines
[10:21pm] <wiert> the x64 system also has /var/lib/named/lib64/engines/
[10:21pm] <wiert> so there the .so files are present in two directories
[10:21pm] <DimStar> I’m not sure why the bind package on ARM would not have followed that.. what CPE_NAME do you have there?
[10:21pm] <DimStar> yeah – the /var/lib/named/lib64/engines are no longer in use – but there is no cleanup code there
[10:22pm] <DimStar> grmbl – the checmin of bind was on the 20th..
[10:23pm] <wiert> I assume that the fix is in the x64, but not the ARM version.
[10:23pm] <DimStar> ARM inherits all packages from openSUSE:Factory – it’s ‘just’ a bit slower with building/testing which is why there are less frequent snapshots
[10:24pm] <wiert> Indeed: openSUSE_Tumbleweed -> x86_64 succeeded
[10:24pm] <DimStar> but if 0521 went out, that means it must have completed the build – which would imply the updated bind too
[10:24pm] <wiert> and openSUSE_Factory_ARM -> aarch64 blocked; armv7l -> blocked
[10:25pm] <DimStar> that’s the current situation – not when 0521 was released :)
[10:25pm] <DimStar> the Pi is aarch64, right?
[10:25pm] <DimStar> can you check rpm -q –changelog bind | head ?
[10:27pm] <DimStar> WTF… osc rbl openSUSE:Factory:ARM bind standard aarch64 => this build was complete on Sat May 20 16:30:13 UTC 2017 – way before 0521 was even started
[10:29pm] <DimStar> and then please: rpm -q –qf “%{disturl}\n” bind
[10:31pm] <DimStar> then I really don’t get how this snapshot got published – this makes no sense at all…
[10:31pm] <DimStar> let ‘s look a bit more: rpm -q bind => on aarch64 I see 9.10.4P5-26.1
[10:32pm] <wiert> bind-9.10.4P5-24.1.armv6hl
[10:32pm] <wiert> ah, that shows the architecture.
[10:32pm] <DimStar> ok.. let me look into armv6hl then :)
[10:32pm] <wiert> I think I forgot to tell it’s a Raspberry Pi B plus.
[10:33pm] <DimStar> osc rbl openSUSE:Factory:ARM bind standard armv6l => that makes more sense: build failed on May 20th
[10:34pm] <DimStar> wiert: wouldn’t have helped me at all – I have no idea about the Pi’s and what arch they run :)
[10:34pm] <DimStar> the sad news: osc jobhist openSUSE:Factory:ARM bind standard armv6l
[10:34pm] <DimStar> it implies it was not my change breaking ‘bind’ from building – this already failed on April 1st (it wasn’t me – I was on vacation then :P )
[10:35pm] <wiert> I ran `arch` which shows armv6l
[10:35pm] <wiert> what’s the difference between armv6l and armv6hl (the suffix in bind-9.10.4P5-24.1.armv6hl)
[10:35pm] <fvogt> hardfloat
[10:36pm] <wiert> and in more laymen terms?
[10:36pm] <fvogt> Supports the FPU, which means it’s a different ABI
[10:37pm] <fvogt> You can’t use it on a armv6l system
[10:37pm] robby_ left the chat room. (Quit: Konversation terminated!)
[10:37pm] <wiert> so why does `arch` show `armv6l` and not `armv6hl` ?
[10:38pm] <wiert> A Raspberry Pi 2B in my collection shows armv7l
[10:38pm] <fvogt> The kernel doesn’t care, it’s the userspace
[10:38pm] <wiert> but RPM shows bind-9.10.4P5-25.1.armv7hl
[10:39pm] <wiert> I’m confused as on x64 systems both are x86_64
[10:39pm] <wiert> so I was kind of expecting ARM systems to both be the same as well
[10:40pm] <wiert> Am I right the conclusion so far is this:
[10:41pm] <wiert> – Raspberry Pi 1 has broken bind build, so the patch doesn’t work
[10:41pm] <wiert> – Raspberry Pi 2 and x64 are OK
[10:42pm] <DimStar> almost – the patch ‘would’ work, but as bind fails for completley different reasons to build, no binary is produced
[10:42pm] <DimStar> fvogt: does that ring a bell to you: 147s] contrib/dlz/config.dlz.in:31: warning: underquoted definition of DLZ_ADD_DRIVER
[10:43pm] <wiert> I think that’s what I meant: the bind build was broken earlier, so the patch that got submitted later never got integrated into the distribution
[10:43pm] <DimStar> but ew have 2017 :P
[10:44pm] <DimStar> wiert: yes, in this case that statement would be true – somebody has to fix build of bind of armv6l
[10:44pm] <wiert> OK. Is that in the pipeline somewhere or should I submit a bug because of this?
[10:45pm] <DimStar> wiert: I’d submit an extra bug for bind/armv6l – the bug to address the issue which you acyally SEE is the one I linked / for which the patch is there; the fact that bind fails to build is a deeper rooted one
[10:45pm] <DimStar> and in the view I have, there is no incoming fix for bind at the moment
[10:46pm] <wiert> where is the URL I can see that bind fails to build for armv6l ?
[10:46pm] <wiert> (in which I can see)
[10:47pm] lurchi__ is now known as lurchi_.
[10:48pm] <wiert> I’ll submit a new bug to solve that build output and refer to the existing bug indicating that because the build fails, the existing bug isn’t in the current CPE_NAME
[10:51pm] mjwolf left the chat room. (Quit: Leaving)
[10:52pm] <wiert> Can I keep the same priority/severity as 1040027 ?
[10:52pm] <DimStar> severity yes – prio you should leave unchanged at P5 initially
[10:52pm] lurchi_ is now known as lurchi__.
[10:54pm] Vojtaeus joined the chat room.
[10:58pm] robby_ joined the chat room.
[11:02pm] robby_ left the chat room. (Ping timeout: 255 seconds)
[11:06pm] srinidhi left the chat room. (Ping timeout: 255 seconds)
[11:08pm] <DimStar> wolfiR: cross your fingers: openQA just started the next test with the new disk images
[11:15pm] <|Anna|> bugzilla.suse.com bug 1040697 in openSUSE Tumbleweed (Other) “bind fails building for armv6l since 20170401 causing bugfixes not to make it to the wild” [Major,New]
Like this:
Like Loading...
Related
Leave a Reply