man breaks after upgrade to 18.04

[goathunter]

In a possibly silly move, last night, I upgraded Ubuntu MATE on my Pine A64+ from 16.04 to 18.04.

I'm still running the longsleep kernel 3.10.105. I was a little surprised that the upgrade worked, but it did. Everything was/is looking good, except that man is broken. When I run "man --debug man", I see:

Code:

man: can't execute preconv: Operation not permitted
loading seccomp filter (permissive: 1)
loading seccomp filter (permissive: 1)
loading seccomp filter (permissive: 0)
seccomp already enabled
man: can't execute col: Operation not permitted
man: can't execute tbl: Operation not permitted
trying encoding UTF-8 -> UTF-8//IGNORE
groff: couldn't exec troff: Operation not permitted

I can, of course, run all of those interactively without any problem.

Has anybody else tried upgrading to 18.04 and/or have any idea what the problem here might be?

Thanks!

[goathunter]

The error later changed to "Permission denied," and with that, I was able to find a match for my problem.

https://bugs.launchpad.net/ubuntu/+sourc...ug/1778684

The problem is due to a change in 18.04 that isn't handled by the older kernel. Here's the workaround from one of the posts on that page. I executed these steps, and now man is working just fine for me.

Alex (alexthreed) wrote on 2018-08-15:
#10

Seems that problem in apparmor profile loading on older kernels.

I have the same issue on custom kernel 4.4, but with ubuntu kernel 4.15 everything ok.
Workaround for older kernels:

apt install apparmor-utils
aa-disable /usr/bin/man

Upstream Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889617

[tllim]

The error later changed to "Permission denied," and with that, I was able to find a match for my problem.

https://bugs.launchpad.net/ubuntu/+sourc...ug/1778684

The problem is due to a change in 18.04 that isn't handled by the older kernel. Here's the workaround from one of the posts on that page. I executed these steps, and now man is working just fine for me.

Alex (alexthreed) wrote on 2018-08-15:
#10

Seems that problem in apparmor profile loading on older kernels.

I have the same issue on custom kernel 4.4, but with ubuntu kernel 4.15 everything ok.
Workaround for older kernels:

apt install apparmor-utils
aa-disable /usr/bin/man

Upstream Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889617

Thanks on the update. Glad to know that able upgrade to 18.04.

[cr2016]

In a possibly silly move, last night, I upgraded Ubuntu MATE on my Pine A64+ from 16.04 to 18.04...

Not closely following the forum, but glad to see that there are still things moving for the pine64+ 

Most of the releases/news seem to apply to rock64 and pinebook series, not much for the pine64+ 

It sounds like the update is not as smooth for everybody, would you mind leaving details about how you updated your system from 16.04 to 18.04?
Thanks!

[goathunter]

In a possibly silly move, last night, I upgraded Ubuntu MATE on my Pine A64+ from 16.04 to 18.04...

Not closely following the forum, but glad to see that there are still things moving for the pine64+ 

Most of the releases/news seem to apply to rock64 and pinebook series, not much for the pine64+ 

It sounds like the update is not as smooth for everybody, would you mind leaving details about how you updated your system from 16.04 to 18.04?
Thanks!

Sorry for my extended delay in replying. I somehow missed your question.

Having done this same thing again yesterday, all I did was execute:

Code:

sudo do-release-upgrade

That was it, aside from issuing the commands above to fix man.

I switched to the Armbian 4.19 kernel earlier this year on two of my Pines. I deployed a third one recently, but found that the built-in Ethernet port didn't work. Light on left blinks once per second, but no lights at all on the right. After trying everything I could think, I noticed that the chip on this Pine differs slightly from the chip on the two that work OK. So yesterday, I started from scratch with the Xenial Mate distribution, and I discovered that the Ethernet port works just fine with the 3.10.104 longsleep kernel. So that Pine is now running longsleep again, and I upgraded it to 18.04.2 with just the command above. (With my very first Pine, I noticed that the network throughput was abysmal, but upgrading to 3.10.105 fixed that problem. With this Pine, an earlier version of the Pine, 104 works just fine. So apparently, whatever bug in 104 that affected the others does not affect this chip, and Armbian, which supports the others, does not support this older chip.)

Hunter

Hunter

[cr2016]

Having done this same thing again yesterday, all I did was execute:

Code:

sudo do-release-upgrade

That was it, aside from issuing the commands above to fix man.

I switched to the Armbian 4.19 kernel earlier this year on two of my Pines. I deployed a third one recently, but found that the built-in Ethernet port didn't work. Light on left blinks once per second, but no lights at all on the right. After trying everything I could think, I noticed that the chip on this Pine differs slightly from the chip on the two that work OK. So yesterday, I started from scratch with the Xenial Mate distribution, and I discovered that the Ethernet port works just fine with the 3.10.104 longsleep kernel. So that Pine is now running longsleep again, and I upgraded it to 18.04.2 with just the command above. (With my very first Pine, I noticed that the network throughput was abysmal, but upgrading to 3.10.105 fixed that problem. With this Pine, an earlier version of the Pine, 104 works just fine. So apparently, whatever bug in 104 that affected the others does not affect this chip, and Armbian, which supports the others, does not support this older chip.)

Hunter

Hunter

Thanks for the reply! No problem with the delay, the ubuntu forum is rather... sleepy, better 'late' than no reply ;-)
Xenial mate is the goal, because it's also what is running on my main system. As far as I got it, upgrating longsleep's kernels 3.10.104/105 with the above command should be ok.

[casial]

The error later changed to "Permission denied," and with that, I was able to find a match for my problem.

https://bugs.launchpad.net/ubuntu/+sourc...ug/1778684

The problem is due to a change in 18.04 that isn't handled by the older kernel. Here's the workaround from one of the posts on that page. I executed these steps, and now man is working just fine for me.

Alex (alexthreed) wrote on 2018-08-15:
#10

Seems that problem in apparmor profile loading on older kernels.

I have the same issue on custom kernel 4.4, but with ubuntu kernel 4.15 everything ok.
Workaround for older kernels:

apt install apparmor-utils
aa-disable /usr/bin/man

Upstream Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889617

Thanks! This man issue has bothered me on my Pinebook with KDE Neon for some time now - and I really didn't know where to begin, the error msg. wasn't very helpful.

I wouldn't guess it was because of app-armor tho... 

[cr2016]

Sorry for my extended delay in replying. I somehow missed your question.

Having done this same thing again yesterday, all I did was execute:

Code:

sudo do-release-upgrade

I switched to the Armbian 4.19 kernel earlier this year on two of my Pines. I deployed a third one recently, but found that the built-in Ethernet port didn't work. Light on left blinks once per second, but no lights at all on the right. After trying everything I could think, I noticed that the chip on this Pine differs slightly from the chip on the two that work OK. So yesterday, I started from scratch with the Xenial Mate distribution, and I discovered that the Ethernet port works just fine with the 3.10.104 longsleep kernel. So that Pine is now running longsleep again, and I upgraded it to 18.04.2 with just the command above. (With my very first Pine, I noticed that the network throughput was abysmal, but upgrading to 3.10.105 fixed that problem. With this Pine, an earlier version of the Pine, 104 works just fine. So apparently, whatever bug in 104 that affected the others does not affect this chip, and Armbian, which supports the others, does not support this older chip.)

Hunter

Hunter

Is this image the one you're speaking about:
https://www.stdin.xyz/downloads/people/l...p-3.tar.xz ?

The files on longsleep's github seem to be the source only.

[goathunter]

Is this image the one you're speaking about:
https://www.stdin.xyz/downloads/people/l...p-3.tar.xz ?

The files on longsleep's github seem to be the source only.

Yes, that's the 105 image I mentioned. I haven't deployed it on my third Pine yet, but that's mainly because I just haven't had time to do it.

Hunter

[cr2016]

Is this image the one you're speaking about:
https://www.stdin.xyz/downloads/people/l...p-3.tar.xz ?

The files on longsleep's github seem to be the source only.

Yes, that's the 105 image I mentioned. I haven't deployed it on my third Pine yet, but that's mainly because I just haven't had time to do it.

Hunter

Good news!
I will download this image and try to find some time too to run again my pine64. It has been taking the dust for too long