[support] Bungy's docker repository


Recommended Posts

6 hours ago, marduk201 said:

hey anyone got mysql working ? i can't change the password and i cant get root to login.. anyone having the same problem?

Never used the official mySQL container (which is what Bungy's template is for), but have used both lsio's MariaDB (its a faster and leaner fork of mySQL) with no issues whatsoever.

 

But, assuming that you've previously had this working, then you're probably best hitting the mySQL forums itself for that issue.

Link to comment
  • 2 weeks later...

Is it possible to rename the postgresql docker that the gitlab docker depends on to be postgresql-gitlab?

 

It seems to be set up fairly specifically for use with gitlab, and I'd like to have another postgresql docker for general use. Obviously, having the generic name on the app-specific image is confusing.

 

I tried renaming the docker, but then the gitlab docker couldn't see it.

 

(Would be even nicer if postgresql and redis were just incorporated in the gitlab-ce docker, as it keeps the place tidy — but I guess there's a reason it's done this way…)

Link to comment
  • 4 weeks later...
  • 2 weeks later...
  • 2 weeks later...
  • 1 month later...

The new NZBGet hasn't hit the archlinux repo yet:

https://archive.archlinux.org/packages/n/nzbget/

Once it gets in there, I'll trigger a rebuild and get NZBget updated. I'll also try to include those packages. I'm not sure what their equivalents are in archlinux.

  • Like 1
Link to comment

@Katherine

In the meantime, try out this Dockerfile for adding in those packages:

 

FROM jshridha/docker-nzbgetvpn:latest

RUN pacman -S python2-requests-oauthlib python-requests-oauthlib \
              python2-markdown python-markdown \
              python2-decorator python-decorator

That should get you the dependencies into python2 and python3 that you requested. Good luck and feel free to ping me if you notice nzbget get into archlinux's package manager. I don't always do the best job of keeping a close eye on those

  • Like 1
Link to comment
16 hours ago, Bungy said:

I pushed a build that bumps nzbget to v20.0, updates the baseimage, and adds in the packages you need. With the updated baseimage, the setup for the VPN has changed. Please check the docs for setup info. It may take 10 minutes or so for the build to finish.

 

So my docker won't start.  I'm not sure what changes or docs you are referring to.  Can you point me in the right direction?

Edited by ulic
Link to comment
  • 2 weeks later...
18 minutes ago, Bungy said:

 

Yes, change the image to mysql:5 instead of mysql

while that worked like a charm i'm now unable to start it :(
message is
 

Quote

Jun 24 16:33:45 UNRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth31e4db6: link becomes ready
Jun 24 16:33:45 UNRAID kernel: docker0: port 2(veth31e4db6) entered blocking state
Jun 24 16:33:45 UNRAID kernel: docker0: port 2(veth31e4db6) entered forwarding state
Jun 24 16:33:46 UNRAID kernel: docker0: port 2(veth31e4db6) entered disabled state
Jun 24 16:33:46 UNRAID kernel: veth7da8719: renamed from eth0
Jun 24 16:33:47 UNRAID kernel: docker0: port 2(veth31e4db6) entered disabled state
Jun 24 16:33:47 UNRAID kernel: device veth31e4db6 left promiscuous mode
Jun 24 16:33:47 UNRAID kernel: docker0: port 2(veth31e4db6) entered disabled state

 

Edited by Dave-Kay
Link to comment
6 minutes ago, Dave-Kay said:

while that worked like a charm i'm now unable to start it :(
message is
 

 

 

Can you grab the logs from the docker container?

 

something along the lines of this should work, you just may have to change "mysql" to your container name

docker logs mysql

 

Link to comment
docker logs mysql
2018-06-24T14:49:35.857053Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-06-24T14:49:35.859380Z 0 [Note] mysqld (mysqld 5.7.22) starting as process 1 ...
2018-06-24T14:49:35.866733Z 0 [Note] InnoDB: PUNCH HOLE support available
2018-06-24T14:49:35.866771Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-06-24T14:49:35.866783Z 0 [Note] InnoDB: Uses event mutexes
2018-06-24T14:49:35.866794Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2018-06-24T14:49:35.866805Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-06-24T14:49:35.866817Z 0 [Note] InnoDB: Using Linux native AIO
2018-06-24T14:49:35.867388Z 0 [Note] InnoDB: Number of pools: 1
2018-06-24T14:49:35.868236Z 0 [Note] InnoDB: Using CPU crc32 instructions
2018-06-24T14:49:35.871443Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2018-06-24T14:49:35.893420Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-06-24T14:49:35.897308Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-06-24T14:49:35.914911Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2018-06-24 16:49:35 0x1482ac8ef740  InnoDB: Assertion failure in thread 22551473354560 in file ut0ut.cc line 942
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:49:35 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68195 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
mysqld(my_print_stacktrace+0x2c)[0x55fbef4f11ec]
mysqld(handle_fatal_signal+0x479)[0x55fbeee1fe59]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x1482ac4cd0c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x1482aac59fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x1482aac5b42a]
mysqld(+0x628387)[0x55fbeedf6387]
mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55fbef6bfc8d]
mysqld(+0xf9ead1)[0x55fbef76cad1]
mysqld(+0xf9f108)[0x55fbef76d108]
mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55fbef776230]
mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55fbef72b1ee]
mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55fbef6fa34a]
mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55fbef69de23]
mysqld(+0x6274fb)[0x55fbeedf54fb]
mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55fbef66acdd]
mysqld(+0xd69f63)[0x55fbef537f63]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55fbeee6abff]
mysqld(+0xb138e6)[0x55fbef2e18e6]
mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55fbef2e4ad0]
mysqld(+0x64a566)[0x55fbeee18566]
mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55fbeee1a121]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x1482aac472e1]
mysqld(_start+0x2a)[0x55fbeee1080a]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2018-06-24T14:49:45.387944Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-06-24T14:49:45.391051Z 0 [Note] mysqld (mysqld 5.7.22) starting as process 1 ...
2018-06-24T14:49:45.398206Z 0 [Note] InnoDB: PUNCH HOLE support available
2018-06-24T14:49:45.398247Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-06-24T14:49:45.398259Z 0 [Note] InnoDB: Uses event mutexes
2018-06-24T14:49:45.398270Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2018-06-24T14:49:45.398286Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-06-24T14:49:45.398296Z 0 [Note] InnoDB: Using Linux native AIO
2018-06-24T14:49:45.398867Z 0 [Note] InnoDB: Number of pools: 1
2018-06-24T14:49:45.399062Z 0 [Note] InnoDB: Using CPU crc32 instructions
2018-06-24T14:49:45.402126Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2018-06-24T14:49:45.423700Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-06-24T14:49:45.427567Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-06-24T14:49:45.440538Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2018-06-24 16:49:45 0x1480c3218740  InnoDB: Assertion failure in thread 22543262123840 in file ut0ut.cc line 942
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:49:45 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68195 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
mysqld(my_print_stacktrace+0x2c)[0x55760de621ec]
mysqld(handle_fatal_signal+0x479)[0x55760d790e59]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x1480c2df60c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x1480c1582fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x1480c158442a]
mysqld(+0x628387)[0x55760d767387]
mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55760e030c8d]
mysqld(+0xf9ead1)[0x55760e0ddad1]
mysqld(+0xf9f108)[0x55760e0de108]
mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55760e0e7230]
mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55760e09c1ee]
mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55760e06b34a]
mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55760e00ee23]
mysqld(+0x6274fb)[0x55760d7664fb]
mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55760dfdbcdd]
mysqld(+0xd69f63)[0x55760dea8f63]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55760d7dbbff]
mysqld(+0xb138e6)[0x55760dc528e6]
mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55760dc55ad0]
mysqld(+0x64a566)[0x55760d789566]
mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55760d78b121]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x1480c15702e1]
mysqld(_start+0x2a)[0x55760d78180a]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

 

Link to comment
46 minutes ago, Bungy said:

Do you have backups of your appdata by any chance? Otherwise you may be forced to backup using mysql workbench under v8 and then restoring that data into v5

it's a pretty fuckup around here...

the user i connected with is now reported to be not able to login at V8. it sais "he's a definer" and i lost root-pw and i tried mysql -p root but that gives back an error that root is not allowed to do that...

so i don't need much, but there are 2 databases i would like to save. there should be an older backup of appdata, around 3 weeks ago...

is it possible to just overwrite appdata in the folder mysql and everything will be restored from a few weeks ago?

 

Quote

Also, can I ask what issue you're having with v8? It may be easiest to address those issues directly.

 

Kodi Alpha 18 is not connecting to the database anymore. I'm quite sure it started with upgrade to V8

 

Edited by Dave-Kay
Link to comment

Yes, you can restore the appdata from 3 weeks ago and it'll revert your data back to that point. You'll just need to restore the mysql appdata.

 

Without a user or root password, that's probably your only bet. If you have a user password, you should be able to backup the databases that user has access to.

 

Yeah v8 has caused issues with some other apps I've used. In those cases, there was small fixes that I needed to do to get it to work, but restoring appdata will be the easiest way to get you back up and running.

Link to comment
2 minutes ago, Bungy said:

Yes, you can restore the appdata from 3 weeks ago and it'll revert your data back to that point. You'll just need to restore the mysql appdata.

 

Without a user or root password, that's probably your only bet. If you have a user password, you should be able to backup the databases that user has access to.

 

Yeah v8 has caused issues with some other apps I've used. In those cases, there was small fixes that I needed to do to get it to work, but restoring appdata will be the easiest way to get you back up and running.

so the was to do it would be, stop mysql docker, delete mysql appdate, restore the old data and fire it up again?
 

else, when i try to access from docker console an put in 

mysql -u root

it tells me

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

is it in any way possible to get root account to work (again)?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.