'disk I/O error'

Report ID: 40729892

I am using Zotero 1.0.10, under Firefox 3.5.5pre, under Ubuntu Karmic 9.10, and I have a database of 100 or so journal articles and associated PDFs.

My collections are listed correctly in the left-hand pane of Zotero, but when I click on any of them (including "My Library"), the central pane simply shows "Loading items list..." and then waits forever.

The "Report Errors..." function gives a long stream of SQL and Javascript, including "[ERROR: disk I/O error]".

The funny thing is, exporting my library to Zotero RDF format seems to work fine. I glanced at the XML output, and it looks okay.

There appear to be nothing wrong with the ondisk zotero.sqlite file, nor any other obvious problem. Any idea what's going on here?

I'm tempted to just delete the whole Zotero directory, upgrade to Zotero 2.0 beta, and then restore everything from the exported library in Zotero RDF format. Any problem with doing this?
  • A disk I/O error quite possibly means what it says. Have you checked your disk?

    Unless the DB integrity check in the Advanced pane of the Zotero prefs indicates a problem (in which case you could use the DB Repair Tool), there's no real reason to think it's a problem with the database.

    Exporting and importing is not recommended. If you really thought there was a problem with the file that didn't show up in the integrity check, the DB Repair Tool would be preferable to an export/import.
  • Thanks for the reply, Dan! No, the DB integrity check reports no problems. Nor does e2fsck report any problems with the disk, and there's plenty of room in the filesystem. I will try the DB repair tool nonetheless, though.
  • Well, running it through DB repair doesn't do anything.

    I also shut down Firefox, moved my Zotero directory to a backup location, and restarted... creating a whole new Zotero directory. The problem still occurs. Really confused :-(
  • Make a backup and upgrade to 2.0?
  • Just tried that too :-( Tried disabling all other Firefox extensions, deleting the Zotero directory, and upgrading to 2.0. Still gives me disk errors...
  • Not the same as your description, but there is this Karmic bug about apparmor messing with zotero directories.
  • Well what do you know... totally disabling App Armor does the trick!! It's weird, but just putting App Armor into "complain mode" for the Firefox executable didn't do it.

    Is there some external executable used by Zotero??
  • It can use the pdfinfo/pdftotext executables in the Zotero data directory if they're installed, but that's it.
  • Well this is weird... the actual Firefox executable is /usr/lib/firefox-3.5.3/firefox ... but the AppArmor path governing it is /usr/bin/firefox-3.5, which is just a shell script to invoke the real executable. Digging into the AppArmor script, I see that it governs the program, even when invoked via /usr/lib/...

    So, it turns out that disabling the AppArmor profile for Firefox does fix the problem.

    Should I file an Ubuntu bug? I think I ought to figure out some way to gather more info on what's causing the problem with Zotero... The weird thing is my laptop, with a fresh install of Ubuntu Karmic, has no problem with Zotero 2.0 out-of-the-box.
  • UPDATE: I didn't install AppArmor on the laptop... that explains why there's no problem there.
  • I am running into the same issue on Karmic. How do you disable AppArmor for the firefox profile only?

  • I ran into the same problem, but disabling apparmor doesn't help. There seem to be an additional problem. I reinstalled Zotero already and if i copy my database on my intrepid desktop it works fine.

    When I change the folder were the database is saved (a new folder without any database) Zotero still refuses to run.

    dlenski: Did you update to Zotero 2.x to fix the Problem?

    Its Firefox 3.5.3 with Zotero 1.0.10 on Ubuntu karmic.
    Error ID is 77976681

  • eremit7: Did you disable AppArmor completely, or just for Firefox? The former worked for bluloo. This isn't a Zotero issue.
  • edited October 21, 2009
    I used `sudo /etc/init.d/apparmor stop` yesterday to disable apparmor. But this seems only to unload all profiles, not disable apparmor. When I remove the appamor package Zotero works.
    This is a very bad solution because apparmor is a imported security framework.

    As disabling all profiles don't fix the bug it's possible that he is connected to the general apparmor bug:

    I know this is not your business, but in Bug 449286 (all-ready linked by fcheslack) Jamie Strandboge remarks:

    I should point out, that while AppArmor in the kernel is deviating from standard unix semantics by disallowing the access to the deleted file even though the profile allows it, the problem is that zotero seems to have a bug in that it is trying to truncate a file that has already been deleted. If upstream fixes this, then the problem would go away.
  • Removing apparmour ("sudo apt-get remove apparmour" on Ubuntu) worked for me, but I don't like this approach as it affects the system security.
  • edited November 2, 2009
    Just as an update here, based on my reading of the Ubuntu ticket, most causes of this error should be fixed in the latest Firefox and evince packages for Karmic.

    There may be one remaining case of the error that could occur during a Zotero upgrade. As the explanation from the Ubuntu developer quoted above by eremit7 indicates, this is a kernel bug, though we may be able to work around it in Zotero. We'll look into that, but regardless, you should only need to disable AppArmor in order to upgrade, at which point you should be able to reenable it as long as you have the latest packages installed.
  • Actually, scratch that—this issue persists even after upgrading, and it's not something we can fix in Zotero. It needs to be fixed in the kernel, and there's movement on the relevant bug above. Until the new kernel lands you'll need to keep AppArmor disabled for Firefox using the instructions from the second ticket:
    To disable the profile, do:
    $ sudo apparmor_parser -R /etc/apparmor.d/usr.bin.firefox-3.5 ; sudo ln -s /etc/apparmor.d/usr.bin.firefox-3.5 /etc/apparmor.d/disable/usr.bin.firefox-3.5
    You shouldn't need to uninstall AppArmor or disable it completely.
  • Something has changed in this bug. I can confirm it's no longer necessary to deinstall apparmor (as it was a week ago). This is a great benefit.

    Dan, thanks for the update.

  • Looks like the kernel fix is available in karmic-proposed, if anyone wants to test it.
Sign In or Register to comment.