Snap update broke launching and printing on 20.04 Ubuntu.

[Dalik]

Two deployed ubuntu images, 20.04 and 22.04. Both images are fully updated.

Issue appears to only impact 20.04.
chrome snap version 2529

Launching chrome from menu shortcut that is managed by the snap works and it using this location /snap/bin/chromium

Launching chrome from desktop shortcut that I manage on 20.04 fails - /snap/chromium/current/usr/lib/chromium-browser/chrome
Updating the desktop shortcut with this location on 20.04 works - /snap/bin/chromium

Try and print from the browser, print dialog in chrome does not list any system printers, only shows PDF.
Doing the same on 22.04 image, I get a list of printers.

CLI I run cups.lstat -v which works on 22.04, does not work on 20.04. 20.04 I get an error "cannot stat /var/lib/snapd/seccomp/bpf/snap.cups.lpstat.bin: No such file or directory"
I've run these tests on multiple 20.04 and 22.04 machines and I'm getting 100% failure rate on 20.04.

I get this error when running chrome from cli from this path on 20.04 /snap/chromium/current/usr/lib/chromium-browser which points to 2529 snap image.

/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /snap/chromium/2529/usr/lib/chromium-browser/libffmpeg.so)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /snap/chromium/2529/usr/lib/chromium-browser/libffmpeg.so)

[Nathan Teodosio (nteodosio)]

You mention snap update in the title. What specific snap are you
referring to, Chromium, Cups or Snapd? The output of "snap changes"
could be useful. If you roll it back with "snap revert <snap-name>",
does it work again?

 > Launching chrome from menu shortcut that is managed by the snap works
 > and it using this location /snap/bin/chromium
 >
 > Launching chrome from desktop shortcut that I manage on 20.04 fails -
/snap/chromium/current/usr/lib/chromium-browser/chrome
 > Updating the desktop shortcut with this location on 20.04 works -
/snap/bin/chromium

Indeed, you should let the snap manage the shortcut, as the one you used
in 20.04 invokes the binary directly, out of the snap sandbox. Do you
get issues with that in place?

Please attach the output of

   snap connections chromium
   snap connections cups

[Marcus Pope (marcuspope)]

Same issue for me on Ubuntu 20.04.1 LTS

Same version of chromium snap with the same error output as @Dalik

Output of `snap connections chromium`

```
Interface Plug Slot Notes
audio-playback chromium:audio-playback :audio-playback -
audio-record chromium:audio-record :audio-record -
bluez chromium:bluez :bluez -
browser-support chromium:browser-sandbox :browser-support -
camera chromium:camera :camera -
content chromium:foo-install-cups - -
content[gnome-42-2204] chromium:gnome-42-2204 gnome-42-2204:gnome-42-2204 -
content[gtk-3-themes] chromium:gtk-3-themes gtk-common-themes:gtk-3-themes -
content[icon-themes] chromium:icon-themes gtk-common-themes:icon-themes -
content[sound-themes] chromium:sound-themes gtk-common-themes:sound-themes -
cups chromium:cups cups:cups -
desktop chromium:desktop :desktop -
desktop-legacy chromium:desktop-legacy :desktop-legacy -
gsettings chromium:gsettings :gsettings -
home chromium:home :home -
joystick chromium:joystick :joystick -
mount-observe chromium:mount-observe - -
mpris - chromium:mpris -
network chromium:network :network -
network-bind chromium:network-bind :network-bind -
network-manager chromium:network-manager - -
opengl chromium:opengl :opengl -
password-manager-service chromium:password-manager-service - -
personal-files chromium:chromium-config :personal-files -
raw-usb chromium:raw-usb - -
removable-media chromium:removable-media :removable-media -
screen-inhibit-control chromium:screen-inhibit-control :screen-inhibit-control -
system-files chromium:etc-chromium-browser-policies :system-files -
system-packages-doc chromium:system-packages-doc :system-packages-doc -
u2f-devices chromium:u2f-devic...

[Nathan Teodosio (nteodosio)]

Thanks for the confirmation, but I don't yet know the context of the issue.

Did you update from Bionic to Focal or did you simply notice the issue after the last Chromium update?

Is there any problem when running 'chromium' from a terminal or is it a issue specific to the launcher?

Please try to be as specific as possible, context is also very welcome.

[Marcus Pope (marcuspope)]

Sure thing, I can provide any information you need.

1. Happened with the latest update to Chromium, has been working fine for over a year. I use it for functional testing in combination with selenium and facebook webdriver. Have it installed as a snap, so I presume it was auto updated, but I do not have a previous install listed so I cannot revert.

2. Running chromium from the terminal in headless mode produces the same series of GLIBC errors as posted by @Dalik.

```
/snap/chromium/current/usr/lib/chromium-browser/chrome --headless --disable-gpu --disable-software-rasterizer
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /snap/chromium/current/usr/lib/chromium-browser/chrome)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /snap/chromium/2529/usr/lib/chromium-browser/libffmpeg.so)
/snap/chromium/current/usr/lib/chromium-browser/chrome: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /snap/chromium/2529/usr/lib/chromium-browser/libffmpeg.so)
```

If I run chromium without the qualified path I get a permission denied issue, regardless of sudo/--no-sandbox.

Dev environment is ubuntu 20.04 running on a macbook pro in a virtualbox vm.

We also have this exact same issue on our CI server which is an ubuntu 20.04 server on aws. I'm booting that up to see if snap reports any previous versions, but we get the exact same error on that server too.

[Marcus Pope (marcuspope)]

Our CI server was manually updated to the edge version of the snap in an attempt to resolve the issue, but it produces the same error output.

Edit: Our CI server is on Ubuntu 20.04.6 LTS

```
chromium 116.0.5845.4 2527 latest/edge canonical✓ -
```

Glibc version:

```
~$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.9) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
```

[Till Kamppeter (till-kamppeter)]

Anyone suffering the described problem, could you follow Nathan's instructions if you have not done so yet, and could you run the following commands and paste the output here?

    lpstat -r
    lpstat -v
    lpstat -p
    cuos.lpstat -r
    cups.lpstat -v
    cups.lpstat -p

Aleo try to print through the CUPS Snap, for example via

    cups.lp -d PRINTER FILE.PDF

Replace PRINTER by the name of a working print queue and FILE.PDF by the name of a PDF file which you have. Does this work? If not, could you also try

    lp -d PRINTER FILE.PDF

Does this work?

[Joel Vandal (joelvandal)]

I need to execute :

snap revert chromium

In order to resolve the issue using Ubuntu 20.04 or 20.10.

-

[Nathan Teodosio (nteodosio)]

Thank you very much for elaborating, that is much clearer. A couple of questions:

1. When you do not use /snap/chromium/current/usr/lib/chromium-browser/chrome, but rather chromium or /snap/bin/chromium, do you ever get those GLIBC errors? If not, what is the exact error you get? You mention permission denied, can you give me that full error message? Also, if you think the message is not clear enough, please try --enable-logging=stderr.

2. I have uploaded the older version to the stable/core20 channel, with which you can replace the current one:

  snap refresh --channel stable/core20 chromium

Does that fix any of the issues you observed?

As a matter of fact, I can reproduce the error when using the full unconfined path (/snap/chromium/current/usr/lib/chromium-browser/chrome), but that is discouraged and not supported.

[Nathan Teodosio (nteodosio)]

3. Please specify whether the errors are only observed for headless Chromium or if it is also observed for normal Chromium.

[Joel Vandal (joelvandal)]

If I execute the following command then I no more have issues :

snap refresh --channel stable/core20 chromium

[Dalik (tek2001x)]

I noticed that when I use the snap version of chromium that loads the
browser printer list doesn't list any printers. I see that under
/var/lib/snapd/seccomp/bpf/ the cups files only have src files and no
bin files and other snaps in this folder do have bin files. I'm
guessing this is why the I'm getting timeout issues when running
commands cups.lpstat -v and why the snap version of chrome can't list
the printers.

On Thu, 2023-07-06 at 18:29 +0000, Till Kamppeter wrote:
> Anyone suffering the described problem, could you follow Nathan's
> instructions if you have not done so yet, and could you run the
> following commands and paste the output here?
>
>     lpstat -r
>     lpstat -v
>     lpstat -p
>     cuos.lpstat -r
>     cups.lpstat -v
>     cups.lpstat -p
>
> Aleo try to print through the CUPS Snap, for example via
>
>     cups.lp -d PRINTER FILE.PDF
>
> Replace PRINTER by the name of a working print queue and FILE.PDF by
> the
> name of a PDF file which you have. Does this work? If not, could you
> also try
>
>     lp -d PRINTER FILE.PDF
>
> Does this work?
>

[Marcus Pope (marcuspope)]

@Nathan Teodosio:

Running either produces the same issue:

```
$ /snap/bin/chromium
cannot open path of the current working directory: Permission denied

$ /snap/bin/chromium --enable-logging=stderr
cannot open path of the current working directory: Permission denied
```

I presume these are issues with shelling into my vm as a vagrant user.

If I run under our service user I get this output:

```
sudo runuser -l xxxx -c 'chromium --headless --disable-gpu'
[0706/142016.391512:WARNING:sandbox_linux.cc(393)] InitializeSandbox() called with multiple threads in process gpu-process.
[0706/142016.397591:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.

sudo runuser -l xxxx -c 'chromium --headless --disable-gpu --disable-software-rasterizer --enable-logging=stderr'
[0706/142336.953854:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.
```

Which is the same output I get when the snap works.

We have had to use the current/user path from the start, however I just tried replacing the setBinary call for webdriver with the /snap/bin/chromium path and it did not resolve the issue either.

Running the `snap refresh` command you provided resolves my problem. So thank you for that! But I'm still available for any debugging requests.

And finally, I only have access to headless installs for ubuntu, so I don't have a way of running it headed.

[Marcus Pope (marcuspope)]

@Nathan Teodosio:

Just tried running our test harness via runuser and that works with the edge version of chromium - which is a valid path forward for me, especially if running directly from the current/user snap path is not supported.

But I'm still around if you want me to investigate further.

[Till Kamppeter (till-kamppeter)]

Dalik, there is an upstream bug report about your observation of missing *.bin files for CUPS on /var/lib/snapd/seccomp/bpf/:

https://github.com/OpenPrinting/cups-snap/issues/16

It is reported by GitHub user d3al. Is that you?

I am not able to reproduce this problem on Ubuntu 23.04 and 23.10.

[Nathan Teodosio (nteodosio)]

To be clear, the reason why this has hit you is that Chromium in the stable channel switched from Core20 in 114.0.5735.106 to Core22 in 114.0.5735.198 (this is a downstream, in other words Ubuntu maintainer's, decision, not Chromium's maintainers').

Core20 is a base from Ubuntu 20.04, while core22, from 22.04.

As such, it makes sense that you had no library problems in Focal with the unconfined command (/snap/chromium/.../chrome) when Core20 was used — as the base and your system libraries were the same, they were compatible environments.

Once Core22 is used to build, Chromium is linked against its libraries, and if you run the unconfined command in 20.04 now, it will find the host's GLIBC 2.31 instead of the base's 2.35; That aligns with the error messages.

And that's why we discourage and cannot support unconfined runs.

We are not tempted to switch back to Core20 — unless issues with the supported run (/snap/bin/chromium, snap run chromium or simply chromium) are found — because Core22 is the newer base, and actually solves bugs with hardware acceleration.

I created the stable/core20 channel with the previous snap so you, the affected users, could confirm the switch was the cause and have time to adapt. But very importantly: This does not mean that we are going to actively maintain that new channel, so please don't rely on it for long term.

[Nathan Teodosio (nteodosio)]

Marcus, from what I gather, and correct me if I'm wrong, you were able to fix all your problems in your headless environment with Chromium edge. Not with Chromium stable?

And hats off to you for responding to the proposed questions and investigating the issue. That was a great help and much appreciated!

[Joel Vandal (joelvandal)]

Previously, I'm used /snap/chromium/current/usr/lib/chromium-browser/chrome to start Chrome in kiosk mode in order to access file:// on local system.

Now all work as expected using latest version (2529) when I execute using : /snap/bin/chromium

[Michaelus (szabo-michael-a)]

I've been using headless chromium on the cli with the --print-to-pdf parameter to generate PDF documents on Ubuntu 20.04 for well over a year.

Chromium has been invoked at:

/snap/chromium/current/usr/lib/chromium-browser/chrome

... by the Apache user, and, because APT forces the SNAP Chromium package, rather than the standard Debian package, and because the Apache user's (www-data) home directory is /var/www and not /home/www-data, one cannot invoke Chromium via Apache at /snap/bin/chromium because of the SNAP home directory requirement

It is my opinion that IF Ubuntu 20.04 LTS (supported until April 2025) is built with SNAP Core20, building a single Chromium SNAP on Core22 going forward will continue to break Ubuntu 20.04 systems

Please do not make assumptions that everyone is calling Chromium with an actual/normal user

I can confirm that this "fixes" the issue for me:

  snap refresh --channel stable/core20 chromium

Nathan Teodosio said: "...And that's why we discourage and cannot support unconfined runs."

... well, the fact that /snap/chromium/**current**/usr/lib/chromium-browser/chrome (current) is a symlink to whatever build # is the "current" suggests Chromium can/and-without-problems-should-be-able-to-be called from that path (as it has been, until someone decided to make the latest Chromium build against Core22)

That, and the fact that there's no option to revert to a previous Chromium build, is why this is "broken"

With respect, not "everyone and everything" is running on the "latest and greatest"

[Marcus Pope (marcuspope)]

Nathan, thanks for the detailed followup. I'm unfortunately not in a good working state, as I introduced a typo in an environment variable used to run our functional test harness when I converted to invoking /snap/bin/chromium with `runuser` instead of a direct invocation form our vagrant user. The result was our test harness ran firefox instead of chromium :(

After fixing that issue, I'm back where I started with chromium failing to find the proper glibc library with stable or edge.

I can fully appreciate your situation regarding the core22, and I can re-confirm that the stable/core20 package does work for us with the unconfirmed command, but I knew that was never going to get a support path. That being said, I'm wondering if you have any advice on the following issues:

1. Is there any way we can influence where chromium looks for glibc to find the base 2.35? (Is this something that would be resolved if I could get /snap/bin/chromium working?)

2. I still cannot get `chromium` or `/snap/bin/chromium` to work on any of the versions, stable / edge / stable/core20. It reports the rather unhelpful `cannot open path of the current working directory: Permission denied`

Migrating to 22.04 is pretty much off the table for our situation as 20.04 is still under lts and we have a _lot_ of other dependencies to deal with. I'm also ok with opening a new ticket if you are set on keeping this one closed.

Thanks in advance!
-Marcus

[Nathan Teodosio (nteodosio)]

Am 07/07/2023 um 17:59 schrieb Michaelus:
 > ... by the Apache user, and, because APT forces the SNAP Chromium
 > package, rather than the standard Debian package, and because the Apache
 > user's (www-data) home directory is /var/www and not /home/www-data, one
 > cannot invoke Chromium via Apache at /snap/bin/chromium because of the
 > SNAP home directory requirement

That is LP:1620771.

 > It is my opinion that IF Ubuntu 20.04 LTS (supported until April 2025)
 > is built with SNAP Core20, building a single Chromium SNAP on Core22
 > going forward will continue to break Ubuntu 20.04 systems

That invocation is not supported, so one could argue that it breaks
unsupported setups. I say that although I appreciate that as per
LP:1620771 that might currently have been the only way for you.

 > ... well, the fact that /snap/chromium/**current**/usr/lib/chromium-
 > browser/chrome (current) is a symlink to whatever build # is the
 > "current" suggests Chromium can/and-without-problems-should-be-able-to-
 > be called from that path (as it has been, until someone decided to make
 > the latest Chromium build against Core22)

That's unfortunate because, in general, it cannot. Please feel free file
a bug against snapd if you believe that should change, this one is mixed
up with printing so it wouldn't be proper to target it to snapd as of now.

 > That, and the fact that there's no option to revert to a previous
 > Chromium build, is why this is "broken"

There is, as for all snaps, with "snap revert", but that is indeed not
at all a solution.

 > With respect, not "everyone and everything" is running on the "latest
 > and greatest"

Sure, and I'm glad no one here holds that opinion.

[Nathan Teodosio (nteodosio)]

I also appreciate your situation and I'm sorry this has been giving you
a hard time. I'm happy to help with what I can.

 > 1. Is there any way we can influence where chromium looks for glibc to
 > find the base 2.35? (Is this something that would be resolved if I
 > could get /snap/bin/chromium working?)

Not really. Yes, this would be resolved if you managed to get
/snap/bin/chromium working.

 > 2. I still cannot get `chromium` or `/snap/bin/chromium` to work on any
 > of the versions, stable / edge / stable/core20. It reports the rather
 > unhelpful `cannot open path of the current working directory: Permission
 > denied`

That could be some things, e.g. LP:1973321, LP:1620771.

 > Migrating to 22.04 is pretty much off the table for our situation as
 > 20.04 is still under lts and we have a _lot_ of other dependencies to
 > deal with. I'm also ok with opening a new ticket if you are set on
 > keeping this one closed.

20.04 is definitely supported and your experience should be as good as
in 22.04; I'm sorry that is not the case.

Please, if your problem isn't already covered in the ones I mentioned,
do open a new ticket, this one is a bit mixed up.

[Michaelus (szabo-michael-a)]

Nathan Teodosio:

>> "That invocation is not supported, so one could argue that it breaks unsupported setups."

My apologies, but that comes off as a rather convenient way of saying, "Well, you shouldn't have been doing it that way in the first place, and be happy it's worked for you this long."

To be clear, you're saying invoking chromium via a fully qualified, real-path, with a SNAP-created symbolic link to a actual build directory, is a "unsupported setup" ?

If I could just install Chromium directly via apt, and not be forced into a SNAP ...

(I'm not going to try to argue that, here, though)

[Marcus Pope (marcuspope)]

Thanks Nathan, I came to the same conclusion as the tickets you provided, as we were trying to run the snap from a shared nfs mount, but glad/sad to know that snap was the ultimate problem - sigh. I can now run the snap directly, without glibc issues so hooray.

I'm now dealing with a different issue after switching to `/snap/bin/chromium.chromedriver` - `error: unknown flag `port'`

Are you able to confirm that there should be no difference in the cli of these binaries?

/snap/chromium/current/usr/lib/chromium-browser/chromedriver
vs
/snap/bin/chromium.chromedriver

I'll investigate further on the selenium side, but if I have to open a different ticket for the driver would I do that here as well? or is there a separate bug repo for that package?

Thanks a bunch! Your support ethos is superb.

edit:

To Nathan - I'm fully past my issues with snap / chromium / selenium and the snap path is working for both chromium and the driver.

To Dalik - sorry for polluting your bug ticket - I was convinced you and I were dealing with the same issue and that cups was just a downstream problem.

To Michaelus - I would generally agree with you except that when it comes to snap, what ya gonna do right? The distinction I think is that when you run /snap/bin/chromium, you aren't running a symbolic link to the actual endpoint, you are running a symbolic link to snap itself, which then does voodoo in a privileged process.

To future googlers who end up here with my specific problem, I simply needed to upgrade selenium-server to 4.x (was on a 3x branch) and 4.x no longer provides a 'port' parameter to the chromium.chromedriver binary.

[Nathan Teodosio (nteodosio)]

-- Michaelus

> you're saying invoking chromium via a fully qualified, real-path, with a SNAP-created symbolic link to a actual build directory, is a "unsupported setup" ?

Yes, running a snap via /snap/chromium/current/usr/lib/chromium-browser/chrome is unsupported. (I don't know how you conclude that is a "symbolic link to a build directory" though.)

-- Marcus

I'm glad you solved all the issues that this update gave rise to and shared your solution with chromedriver.

For what it's worth, yes, were you to find a problem with it, you would file a bug for chromium-browser.

Thank you too for your superb cooperation and responsiveness.

[Michaelus (szabo-michael-a)]

-- Nathan

The symlink I'm referring to is the *current* in this path:

/snap/chromium/**current**/usr/lib/chromium-browser/chrome

... which is a symlink to build 2529 or, now I have 2497

(I still maintain that if Ubuntu 20.04 LTS is supported until April 2025, and its base SNAP is core20, it is not appropriate (if, only because of my biased opinion) to build snaps on core22, which, you admit, is the base snap core for Ubuntu 22.04)

Do you have any sense of "how long" the stable/core20 channel will be available?

I am grateful for the stable/core20 build as of now, but need to plan to either migrate to Ubuntu 22.04 (or later) or off Ubuntu altogether

[Nathan Teodosio (nteodosio)]

> (I still maintain that if Ubuntu 20.04 LTS is supported until April
> 2025, and its base SNAP is core20, it is not appropriate (if, only
> because of my biased opinion) to build snaps on core22, which, you
> admit, is the base snap core for Ubuntu 22.04)

I think there is a misunderstanding here. Snaps for core22 can run in
any series, be it 18.04, 20.04, 22.04 etc., otherwise it would really
mean that for each series XX we would have to use the corresponding coreXX.

They can only run in any series because they are not run directly as a
binary that sees the host libraries, but rather uses snap confinment. So
if your base is 20.04, a snap based on core22 works nonetheless, because
it's seeing the libraries provided by core22 instead of your host system.

That is _exactly_ what is sidestepped once you run it with the
/snap/chromium/current/usr/lib/chromium-browser/chrome instead of the
normal /snap/bin/chromium, namely the snap runs unconfined an thus uses
the system libraries, which may be (and in the present case is)
different than what it was linked it during its build, justifying the
errors you see.

> Do you have any sense of "how long" the stable/core20 channel will be
> available?
>
> I am grateful for the stable/core20 build as of now, but need to plan to either migrate to Ubuntu 22.04 (or later) or off Ubuntu altogether

By default it's 30 days after launch, I'm happy to keep it alive for
longer though if it will help, just note it is frozen, it will not be
maintained, so new CVEs in Chromium or any of its dependent libraries
won't be addressed and so on.

[Michaelus (szabo-michael-a)]

@Nathan

Thank you for the clarity on the Core20 vs Core22, however, I will still maintain that had this latest Chromium SNAP been built on Core20, as has seemingly been until now, we wouldn't be having this dialog.

When Chromium has been built against Core20, I've been able to call chromium headless from Apache via:

/snap/chromium/current/usr/lib/chromium-browser/chrome

... and it hasn't mattered which "build" the ../current/... pointed to.

For me, Chromium built on Core22 is what "broke" my setup.

Again, I appreciate the stable/core20 build, and will have to commit to within 30 days:

a) Upgrade our production environments to Ubuntu 22.04

b) Stop using Ubuntu altogether, and go with straight-Debian, so "apt install chromium-browser" actually installs the Debian package, not force install a SNAP (comment for future readers, not trying to argue that APT pushes the SNAP installs for Chromium on Ubuntu)

c) find an alternative way to generate PDF from HTML reports

[David Venz (david-venz)]

This breaks our command-line pack of an in-house extension, under Ubuntu 20.04.
Is there a way to do this using the confined run?

Our current unconfined run build command-line (please excuse legacy from years ago, eg --headless might be more appropriate now):

xvfb-run /snap/chromium/current/usr/lib/chromium-browser/chrome --user-data-dir=/tmp/ChrUnsnapped --class="ChrUnsnapped" --pack-extension=MyExt --pack-extension-key=MyExt.pem

This understandably gets libm GLIBC version errors with a core22 dependent chromium snap.

Trying with confinement and --headless (and files moved to a subdirectory of /home/<user>):
user@host:~/tmp/ChromeExtensions$ /snap/bin/chromium --headless --enable-logging=stderr --pack-extension=MyExt --pack-extension-key=MyExt.pem
[0726/200919.476268:WARNING:sandbox_linux.cc(393)] InitializeSandbox() called with multiple threads in process gpu-process.
[0726/200919.543209:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.

user@host:~/tmp/ChromeExtensions$ echo $?
0

Sadly no .crx comes out that I can find.

[Nathan Teodosio (nteodosio)]

As far as I know, Xvfb and --headless result in quite different
environments, as the first will run in normal graphical mode and the
latter won't.

I see no reason why this would affect your extension packing, however I
have no experience with extensions in Chromium. Could the graphical
environment be playing a role here?

Did you try the natural

--->
xvfb-run /snap/bin/chromium --class="ChrUnsnapped"
--pack-extension=MyExt --pack-extension-key=MyExt.pem
<---

instead? The snap won't have access to the system's /tmp, but I think
you can work around that, at least for the sake of testing.

[David Venz (david-venz)]

Thanks Nathan,

I finally lined up all the ducks, and it appears to have worked.

- The dir I'm building in has to be in my home dir
- the xvfb-run seems necessary
- don't attempt to use --headless
- both --user-data-dir=/tmp/ChrUnsnapped and --class="ChrUnsnapped" seem unnecessary

So,

user@host:~/tmp/ChromeExtensions$
   xvfb-run /snap/bin/chromium --pack-extension=MyExt --pack-extension-key=MyExt.pem

Tested with chromium snap v2556 (115.0.5790.102).

I'll have to update our build system to copy files to somewhere in /home/<user>, build there, and copy the results back.

[Nathan Teodosio (nteodosio)]

Thanks for sharing your resuilts, David!

[Michaelus (szabo-michael-a)]

@Nathan Teodosio:

Wow -- exactly ONE MONTH to-the-day, and it's broken again.

I guess I should have replaced Chromium as the PDF generation on our servers back-end

For anyone else reading this, I still maintain that, contrary to what @Nathan Teodosio says, that since Ubuntu is intercepting the `apt install chromium-browser` and force-installing their SNAP version, and that said SNAP version of Chromium creates the following paths:

/snap/chromium/2565
/snap/chromium/2572
/snap/chromium/current -> 2572

...and the "target" of /snap/chromium/current changes with every build, why the "h-e-double-hockey-sticks" should I NOT be able to invoke chromium using the static path of /snap/chromium/current/ ?

WHY does the SNAP create /snap/chromium/current in the first place?

Otherwise, what is the purpose of it?
For "unsupported executions" as Nathan called it ?

The www-data (apache2) user cannot invoke chromium-browser at /snap/bin/chromium because of the home directory restriction (another restriction forced by the SNAP, not Debian, on which Ubuntu is based)

It's my fault -- I've left this "fix" in for a month, with nothing better to do than replace a previously working solution ...

Or, is it, "Just upgrade to Ubuntu 22.04 already, and stop complaining ? "

[Michaelus (szabo-michael-a)]

OK -- I've implemented my likely permanent fix:

Instead of having the server/backend generate an HTML document, and calling chromium-browser on the CLI to generate the PDF, and returning the PDF as base64 to the "client" where a BLOB URL is generated and embedded in an <iframe> to the user, with [Print] [Save] and [Close] buttons in the modal/dialog, I'm generating the same html, adding `onload="window.print()` to the <body> tag within the HTML markup, and when returning to the client, adding an <iframe> to the page on-the-fly, and the `onload="window.print()` will trigger the client's own browser "Print Dialog" where they can select >> "Save as PDF"

It doesn't have the same user-experience, being able to "preview" the PDF before committing it to a local file and/or printing it to actual paper, but it:

a) solves the immediate problem
b) allows me to remove chromium-browser as a dependency altogether

Thanks a lot !