mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-26 01:26:00 +03:00
[GH-ISSUE #255] No PDF, Screenshot and DOM generation on Raspberry Pi / headless setup #3199
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#3199
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dueringa on GitHub (Aug 11, 2019).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/255
Describe the bug
When archiving a page via SSH on a Raspberry Pi (Model 3B+), using DietPi (based on Raspbian) as an Operating System, which is setup to work as a headless server, PDF, Screenshot and DOM generation will fail because of chromium errors.
Steps to reproduce
1.Setup ArchiveBox with ./bin/archivebox-setup
2. Try to archive a website, e.g.
echo https://wavesharejfs.blogspot.com/2018/08/make-new-larger-font-for-waveshare-spi.html | ./bin/archivebox3. Archiving fails
Screenshots or log output
Running the command for printing to PDF manually with an additional
--disable-gpuoption still doesn't produce a PDF, but removes theContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.error message. The other error messages are still there.Software versions
e2b054a3.7.3Chromium 74.0.3729.157 Built on Raspbian , running on Raspbian 10)Question
Should it even be possible to archive pages in this setup? Is this a chromium bug?
@pirate commented on GitHub (Aug 11, 2019):
apt install -y lsb-coreIf Chrome is built for Raspbian do you think it will work on a Debian Buster-based system? They're similar but not exactly the same iirc.
Can you try reinstalling
chromium-browserordpkg-reconfigure chromium-browser.@dueringa commented on GitHub (Aug 11, 2019):
Package lsb-core is not available anymore:
However, I installed lsb-base:
This made the warning message go away, but not the errors.
Running only the chromium command displayed in the log, I also tried adding the user to the video group, changing the memory for the GPU to 256MB (using the distribution config tool for the Raspberry) and even running the chromium command as sudo (which required an additional flag, --no-sandbox), but the error messages persisted.
Adding the
--disable-gpuflag only removed the error messageFailed to send GpuChannelMsg_CreateCommandBuffer.I'm not sure if I understand your remark regarding the chromium browser, it is installed from the distribution repos. I should have clarified, Dietpi uses the Raspbian repos.
Reinstalling it doesn't change the behavior.
@pirate commented on GitHub (Aug 13, 2019):
Unfortunately not sure ArchiveBox would be able to provide any type of workaround for this if it's a fundamental Chrome issue. For now you can disable those archive methods and just use wget, wait until Chromium fixes the issue upstream, or wait until we release Firefox support in the far far future.
@dueringa commented on GitHub (Aug 14, 2019):
Thanks for the reply. As far as I'm concerned, this issue can be closed then.
If anyone else is affected and is looking for a solution, you can work around this by using https://wkhtmltopdf.org/ for generating a PDF.
@pirate commented on GitHub (Aug 14, 2019):
I'd also recommend trying a much older version of chrome from back when they first released chrome headless. It might work because it had 0 gpu support initially, everything was done on cpu.
@sbrl commented on GitHub (Jun 12, 2021):
Isn't there a flag to disable GPU support at all? I thought there was