By Joe.c on

I've installed a fresh Drupal 7.28 over a clean Ubuntu 14.04. The environment is virtualbox 4.3 with 4Gb ram an 8Gb disk (hosted by win7). PHP version is 5.5.9-1ubuntu4 and db is mysql. The installed site, empty, works normally.

issue

Trying to install any module via URL leads to WSOD or downloading the module package manually the install button does nothing. After the white page i can go back and continue to navigate the site with no errors or warnings.

debug

Enabling the php error reporting didn't produce any record in the apache logs. I browsed also all the system logs. The tips to manage wsod didn't improve the situation.
Then I debugged with netbeans the sequence after the click on install button and discovered that the code stops in system.tar.inc, while reading an array property, an harmless operation. So apparently we have something happening at lower level.

during countless trials I also:

  • changed this php.ini values:
    realpath_cache_ttl = 36000
    max_execution_time = 300
    max_input_time = 60
    memory_limit = 256M
    post_max_size = 128M
    upload_max_filesize = 256M
    default_socket_timeout = 60
  • disabled opcache
  • reinstalled lamp and drupal with different methods
  • gave r+w permissions to all on /sites folders

At this point I'm stuck and can't understand where I'm wrong. Googling around I found only one case identical to mine with no solution. This is weird considering how common should be the installation on ubuntu 14 in a vbox.

Any suggestion?
thks

⋅ Categories: Drupal 7.x

Comments

vm’s picture

vm commented

not that it has anything to do with your issue but ..

post_max_size = 128M
upload_max_filesize = 256M

should be reconsidered. post_max should be a smidge higher than upload_max_filesize. With the way you've currently set this up even if the form took 256M of files it wouldn't post it as you've 1/2'd it.

jaroslavbenes’s picture

jaroslavbenes commented

I am facing the same problem. I use drupal on other Ubuntu 14.04 servers, but all of them are 64-bit. This server which is going to WSOD on tar.gz module installation is the only one running Ubuntu 14.04 32-bit. So I think the problem is only on 32-bit Ubuntu 14.04 server edition.

I am not able to troubleshoot this problem so I reinstall the server to Ubuntu 14.04 64-bit and see if it helps.

Have You resolved the issue?

Thanks

jaypan’s picture

jaypan
Location Victoria, BC
commented

What do your error logs say?

Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
jaroslavbenes’s picture

jaroslavbenes commented

apache log only says:

*****:443 95.47.186.36 - - [24/Aug/2014:18:27:09 +0200] "POST /admin/modules/install HTTP/1.1" 500 130198 "******/admin/modules/install" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0"

and debugger says:

Fatal Error

Call to undefined function gzopen()

File: .../drupal-7.31/modules/system/system.tar.inc:716

706:           }
707:
708:           // ----- File to open if the local copy
709:           $v_filename = $this->_temp_tarname;
710:
711:         } else
712:           // ----- File to open if the normal Tar file
713:           $v_filename = $this->_tarname;
714:
715:         if ($this->_compress_type == 'gz')
716:             $this->_file = @gzopen($v_filename, "rb");
717:         else if ($this->_compress_type == 'bz2')
718:             $this->_file = @bzopen($v_filename, "r");
719:         else if ($this->_compress_type == 'none')
720:             $this->_file = @fopen($v_filename, "rb");
malc_b’s picture

malc_b commented

I have the same issue. This seems to be known bug, that was fixed and has now come back. It only affects 32bit systems. In php5, with big files option, in zlib there is no gzopen only gzopen64. The latest (1.3.12) pear package archive_tar includes a test that checks if gzopen doesn't exist and gzopen64 does, and then it defines its open gzopen to call gzopen64. That fix is close but flawed too, and it doesn't help with Drupal (7, at least) which doesn't call the pear package but has its own (older) copy in core module system.tar.inc.

The fix is edit system.tar.inc to add, after

define ('ARCHIVE_TAR_ATT_SEPARATOR', 90001);
define ('ARCHIVE_TAR_END_BLOCK', pack("a512", ''));

these lines to system.tar.inc

if (!function_exists('gzopen') && function_exists('gzopen64')) {
    function gzopen($filename, $mode, $use_include_path = 0)
    {
        return(gzopen64($filename, $mode, $use_include_path));
    }
}

if (!function_exists('gztell') && function_exists('gztell64')) {
    function gztell($zp)
    {
        return(gztell64($zp));
    }
}

if (!function_exists('gzseek') && function_exists('gzseek64')) {
    function gzseek($zp, $offset, $whence = SEEK_SET)
    {
        return(gzseek64($zp, $offset, $whence));
    }
}

Or I guess to some other module if you wish.

www.fullcircuit.com

Frank@Drupal’s picture

Frank@Drupal commented

Dear malc_b,

This worked for me!

Ubuntu server 14.04
PHP 5.5.9 with zlib 1.2.8

Hopefully it will not be effected by future patching of Drupal 7.39 to 7.xx

Thanks,

Frank

dimetry’s picture

dimetry commented

It is PHP bug with Ubuntu 32bit.

I've solved the problem after installation of newer PHP version

KimNyholm’s picture

KimNyholm commented

For Drupal 8, patch #42 in #1414508: update system.tar.inc to latest Archive_Tar (Pear) fixes this issue with WSOD. A backport to Drupal 7 is still pending.