[11RC BUG] Grubinstaller.py fails due to locked file.

[mintuser]

UPDATE: BUG EXISTS IN 32 AND 64 BIT VERSIONS. READ THREAD FOR DETAILS.

Greetings. I'm sorry for posting this here but I refuse to sign up to sites to submit bugs (I prefer mailing lists). I'm actually posting this from a bugmenot.com account.

Anyway, here's the deal, I have found two bugs in both the 32 and 64 bit versions:
* Non-critical: Stale NFS file handles (was supposedly fixed a long time ago but still rears its ugly head)
* Nuclear bomb critical: /var/cache/debconf/config.dat is locked by "debconf-communi", causing the installer to fail.

The Linux Mint installer crashes every time towards the end, for this reason:
* Ubiquity executes /usr/lib/ubiquity/ubiquity/components/plugininstall.py which runs grubinstaller.py from the same folder, which in turn exits with Error code 1. I am not familiar enough with Python to know what it is doing but I checked the code of grubinstaller.py and noted the command in there.
* /usr/share/grub-installer/grub-installer is the command executed by grubinstaller.py. Trying to manually run it gives this error:
* debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
* So the problem seems to be that the installer goes plugininstall.py -> grubinstaller.py which in turn runs /usr/share/grub-installer/grub-installer which in turn crashes with the error I just pasted, which causes grubinstaller.py to return error code 1 and abort the installer.
* I've tried the install 4-5 times over several restarts and it always fails.
* Another guy reports the exact same crashes at viewtopic.php?f=151&t=71455#p416170

I decided to see what was locking this config.dat file:

Code: Select all

    mint@mint /mnt $ sudo fuser -v /var/cache/debconf/config.dat
    Cannot stat file /proc/3602/fd/38: Stale NFS file handle
    Cannot stat file /proc/3602/fd/39: Stale NFS file handle
    Cannot stat file /proc/3602/fd/44: Stale NFS file handle
    Cannot stat file /proc/3602/fd/45: Stale NFS file handle
    Cannot stat file /proc/3990/fd/12: Stale NFS file handle
    Cannot stat file /proc/7449/fd/12: Stale NFS file handle
    Cannot stat file /proc/7449/fd/13: Stale NFS file handle
    Cannot stat file /proc/16809/fd/36: Stale NFS file handle
                         USER        PID ACCESS COMMAND
    /var/cache/debconf/config.dat:
                         root      14437 F.... debconf-communi


As you see, not only did I find the program locking the file and preventing grub from installing; I also found that the "Stale NFS file handle" bug still exists!

So next thing to try:
* Manually killing process 14437 (debconf-communi) and then trying the manual command from grubinstaller.py again, yielded success in that /usr/share/grub-installer/grub-installer ran perfectly. No complaints about config.dat being locked.
* However, debconf-communi is periodically restarted by either the system or the installer itself, and simply killing it and trying to run the installer will not do any good, since it will be re-launched in time for the grub installer to fail. So I tried killing it while the installer was running, but that lead to another installer crash, meaning that there's no easy way to fix this file lock problem.

So what needs to be fixed in Katya?
* Stale NFS file handles bug should not be there.
* Figure out why debconf-communi is locking /var/cache/debconf/config.dat to the point where it causes /usr/share/grub-installer/grub-installer to crash with the error above, leading to an aborted installation.

[mintuser]

Some extra info:

* 64 bit DVD iso
* MD5 matches
* Booted "liveCD" from a flash drive using http://www.pendrivelinux.com/universal- ... -as-1-2-3/
* Intel Core i5-2500K 64 bit CPU

[mintuser]

For justin's sake, I re-created the USB stick from scratch using Unetbootin instead, and found that Unetbootin and Pendrivelinux are 99.999% identical; they both create FAT32 partitions mounted as /cdrom with the content as well as an extended and swap partition. They really are so similar that the choice of USB installer creator has nothing to do with this bug.

I did find one additional thing though: debconf-communi is NOT running at system startup. It is started by the Ubiquity installer as soon as the initial scripts start running (the ones copying the base OS to the target disk, which runs immediately after you have selected the target partition).

This means that the problem can be narrowed down to: The installer scripts launch debconf-communi but don't close it properly, leading to the /var/cache/debconf/config.dat file staying locked and therefore crashing grubinstaller.py since it cannot open the file.

Now I'll make a final installer disk using the 32 bit DVD instead.

[mintuser]

The config.dat file locking bug exists under the 32 bit version as well, as does the separate problem of Stale NFS handles.

I've ordered a nice, big Pizza to aid with further bug seeking. I have a theory on why debconf-communi is launched and never closed, and will be trying it out.

It is launched whenever I choose "Something else" during the installation and manually delete and re-add the partition (to start fresh). What I will be trying is to pre-make the partitions, reboot, and just select the partition as-is and see if that prevents debconf-communi from launching.

[mintuser]

Oh and a small update; debconf-communi is the truncated name for http://www.tin.org/bin/man.cgi?section= ... ommunicate

[mintuser]

Gee. Okay now I noticed that debconf-communicate launches immediately when the installer launches so there really is no way for me to avoid it from launching. How freaking weird is that? I mean how can I be the only person that has a persistently-locked config.dat file from a program launched by the installer, which in turn prevents grub-installer from running (even trying it standalone on the command line complains about the locked config.dat).

Installer launches -> debconf-communicate launches and locks /var/cache/debconf/config.dat -> this prevents grub-installer from running, whether you try it standalone or in the installer itself. Both in 32 and 64 bit versions.

I have narrowed it down to the fact that debconf-communicate launches and locks once the installer launches, and that grub-installer does not even want to run standalone in the terminal without any parameters; it errors with the message "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable". The latter fact means that it won't matter how many different drive and partition combinations I try in the installer, since grub-installer fundamentally CANNOT launch as long as /var/cache/debconf/config.dat is locked by the process that the INSTALLER launches every time. There is nothing I can do about this!

Justin and I have been talking over IRC and he is going to make a USB boot drive with Unetbootin and try to replicate the fact that debconf-communicate is launched by the installer and then stays open, refusing to let go of the config.dat file.

We'll see what happens.

[mintuser]

I tried letting the installer finish the initial write step and get to the "enter your name" step, and took that lull in the action to see if I could kill debconf. When I hit forward, I got an interesting call stack complaining about the broken pipe to debconf.

Very interesting indeed:
The installer is written in python which in turn includes /usr/lib/python2.7/dist-packages/debconf.py which opens the process debconf-communicate and keeps a pipe to it for sending commands to debconf through it. This literally means that the debconf-communicate is SUPPOSED to be running uninterrupted throughout the whole installation process.

Why is this information so interesting? Because it means debconf-communicate is SUPPOSED to be running constantly.

That narrows down the bug to only two different causes:
A) either grub-install is not supposed to CARE that the /var/cache/debconf/config.dat file is locked and that's the problem; or
B) debconf-communicate is not supposed to LOCK the file forever (and should only lock it when writing to it).

[mintuser]

I'VE REPLICATED THE BUG IN A VIRTUAL MACHINE NOW, THEREBY TAKING MY HARDWARE OUT OF THE PICTURE... WELL, NOT EXACTLY, READ ON...

I went over to my Mac Pro and created a Virtual Machine in Parallels, set it up with 2 GB RAM, 4 CPU cores, and a hefty hard disk, and used it to directly boot from the RAW 64 bit DVD iso, thereby taking the whole "USB loader" out of the picture.

Linux Mint booted up in the Virtual Machine. I then opened a terminal and checked:
"sudo fuser -v /var/cache/debconf/config.dat"
Saw that it had no locks.

I then started the Linux Mint Installer ("Install Linux Mint" on the Desktop), which, as described in the previous post, will launch debconf-communicate and keep it running nonstop.

Checked locks for config.dat again, and saw (as expected) that debconf-communicate was locking the file.

I then tried to execute the exact same binary that the grubinstaller.py script uses, and AS EXPECTED, got the error: "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable"

Even though this had already CONFIRMED that the bug exists, and that this would DEFINITELY PREVENT GRUB-INSTALLER FROM RUNNING DURING THE SETUP, I still ran the setup for good measure.

Results: ... CONFUSING! The installer runs through without a complaint, despite the FACT that trying to run grub-installer standalone LOUDLY COMPLAINS that the file is locked and that it cannot run.

What the hell... Honestly, what the hell?

I've now tried it on 2 computers; the file lock prevents grub-installer from running both machines, it literally refuses to run because the file is locked, on BOTH of the machines. Despite this, one of the machines completes the installation! How the hell can that even happen? grubinstaller.py runs /usr/share/grub-installer/grub-installer and this process FAILS on both machines, but the overall installation succeeds in the VM!

[soren_dk]

I'm experiencing the same (at least I think so?).

Downloaded the mint 11 iso, checked the MD5, moved to a bootable USB drive. I can boot from it and get to the new desktop. Installation starts, but crashes at installing Grub2

May 14 18:40:28 mint plugininstall.py: InstallStepError: GrubInstaller failed with code 1

[mintuser]

I'm experiencing the same (at least I think so?).

Downloaded the mint 11 iso, checked the MD5, moved to a bootable USB drive. I can boot from it and get to the new desktop. Installation starts, but crashes at installing Grub2

May 14 18:40:28 mint plugininstall.py: InstallStepError: GrubInstaller failed with code 1

Yes. That is the bug. The problem is that plugininstall.py runs grubinstaller.py which in turn runs /usr/share/grub-installer/grub-installer and that program crashes when /var/cache/debconf/config.dat is in use (locked). That crash causes grubinstaller.py to return error code 1 and abort. The reason that /var/cache/debconf/config.dat is locked is that the installer is written in python and runs a program called "debconf-communicate" which stays open for as long as the installer is open, and that is the process which is locking the file.

I replicated the file locking bug in a virtual machine, which loudly complained that the config.dat file was in use when I tried to manually run the grub-installer executable, but then I decided to try doing an actual install and it just ignored the fact that grub-installer was unable to run (alternatively, maybe the installer script turned off the file lock (by shutting down debconf-communicate) for a brief moment to allow it to run grub-installer).

Either way, this points to a possible platform error since the exact same file locking bug was replicated in a VM but the installation finished anyway. The only difference between the VM and my own machine is the hardware. I'm on a cutting edge Sandy Bridge B3 motherboard released a month ago, with a Core i5-2500K processor.

What is your setup?

[mintuser]

WORKAROUND FOR EXTREMELY ADVANCED USERS *ONLY*:

As my investigation uncovered, the problem is that the Installer runs debconf-communicate permanently in the background, which in turn locks /var/cache/debconf/config.dat, so that the grub-installer CANNOT access that file and therefore cannot install itself to the file system.

Well, this is not likely to be fixed very quickly, so I decided to create a workaround.

Do the following:
cd /usr/lib/ubiquity/ubiquity/components/
sudo rm grubinstaller.pyc (removes the precompiled script)
sudo gedit grubinstaller.py (opens the remaining script in a text editor)

Now look for this section:

Code: Select all

class GrubInstaller(FilteredCommand):
    def prepare(self):
        return (['/usr/share/grub-installer/grub-installer', '/target'],
                ['^grub-installer/bootdev$', 'ERROR'],
                {'OVERRIDE_UNSUPPORTED_OS': '1'})


And replace it with:

Code: Select all

class GrubInstaller(FilteredCommand):
    def prepare(self):
        return (['ls', '/target'],
                ['^grub-installer/bootdev$', 'ERROR'],
                {'OVERRIDE_UNSUPPORTED_OS': '1'})


What this does is that the grubinstaller.py script will NOT install Grub. Instead, it will simply execute a meaningless "ls" (directory index) command. That means that you never run into the problem of grub-installer crashing since it's NEVER EXECUTED.

The installer will happily "perform" the Grub installation (except nothing happens of course since we replaced it with "ls"), and then carry on with the final steps of the installation.

Since this overrides the bootloader installation step, you will not have any bootloader. All you have to do now is MANUALLY install Grub2 and it must be done with the CORRECT configuration for your system, which resides on the disk/partition where you installed Linux Mint. What we must therefore do is mount the disk where we installed the OS as our root disk for the session, so that the grub-install tool can find the correct config. That can be done in the following way, but you need to be advanced enough to know what you are doing, these are guidelines and must be adapted for your own setup situation:

sudo passwd root
<choose any password, it's just temporary, I used "meow" because cats are awesome>
su
<enter the password you chose in the step above>
mount /dev/thedeviceorpartitionwhereyouinstalledtheOS /target (obviously, you must replace this with the correct device or partition path, such as /dev/sda1 (this will be the most common one))
mount -o bind /dev /target/dev
mount -o bind /dev/pts /target/dev/pts
mount -o bind /sys /target/sys
mount -o bind /proc /target/proc
chroot /target
grub-install /thedevicewhereyouwantthebootloadertosit (if the OS was installed to a partition of /dev/sda, then this would be grub-install /dev/sda for instance)
reboot (this command will reboot your system immediately. remove any cdrom or usb stick that you launched LiveCD from before it finishes rebooting, so that your system will boot from the new Linux disk)

[Celp]

cheers i was having the same problem and i needed to install the 11 version as i tried my 10 one and it didn't have the ethernet drivers i needed >< i noticed 11-RC failed a few times at the grub stage and your work saved me alot of hassle

but yeah i'm not an advanced user at all but i found this handy article about installing grub and it worked using your dummy method and following the guide so use at own risk obviously but for me i can now boot up with internet access ^_^

https://help.ubuntu.com/community/Grub2#METHOD%203%20-%20CHROOT

dunno if thats the best method or not but it suits my needs for the time being

[mintuser]

cheers i was having the same problem and i needed to install the 11 version as i tried my 10 one and it didn't have the ethernet drivers i needed >< i noticed 11-RC failed a few times at the grub stage and your work saved me alot of hassle

but yeah i'm not an advanced user at all but i found this handy article about installing grub and it worked using your dummy method and following the guide so use at own risk obviously but for me i can now boot up with internet access ^_^

https://help.ubuntu.com/community/Grub2#METHOD%203%20-%20CHROOT

dunno if thats the best method or not but it suits my needs for the time being

Hi, yeah the reason that I did not post any instructions was that I didn't want to deal with telling people about all the different variations due to the millions of possible partitions they might have installed Linux on, but I saw your post and thought I'd do it anyway since I realized people deserve to have at least some form of instructions here for that step. The area under the red text in the previous post shows those new instructions. I then went and checked the page you mentioned to see if you had read correct instructions (and therefore installed grub correctly) -- you have, those are good instructions, congrats. Everyone else - just follow the short ones in this thread, they both describe how to do the same thing (chrooting, mounting devices, and installing the bootloader).

Oh and what is your motherboard and processor? Is it a Sandy Bridge B3 motherboard? Trying to find some common hardware between the people that experience this bug.

[Celp]

Hi, yeah i get why you didn't post any instructions but i thought i'd just confirm that i had this issue and if your an idiot like me that once finding this thread it's to google how to do it since i dont know how may as well post up ones that worked for me.

Ok i'll give all the info i can but it could also be down to me not knowing what i'm doing but trying stuff anyway

About my motherboard/processor
Asus P8H67-V
Intel i5-2500

I installed linux mint 10 from DVD successfully but the Ethernet controller wasn't working and thats how i connect. I searched this and found what seemed to be the hardware driver issue but couldn't try the fix as the driver on the manufacters site was corrupted for me on download as ppl mention on page 2
http://ubuntuforums.org/showthread.php?t=1677122

I then tried Ubuntu 11.04 from disc and that installed fine and worked with the ethernet controller ... i then installed Virtual Box and tried the Linux Mint 11-RC from a usb stick. That also worked fine.

I then tried the USB stick on my hard drive wiping the partitions and creating my own *NOTE* this might be the issue as i never did that with the Ubuntu or virtual install of Mint i just used the default setting.

it failed at grub 2 stage a couple of times ... i then downloaded testdisk and it said there was no partition marked as bootable or something, this is hazy and out of my league. Think i might have changed the flag in gparted after that. I then found this and with installing grub manually it works.

partitions i went for using whole disk
/boot
/
/swap
above primary below logical
/tmp
/home

[mintuser]

About my motherboard/processor
Asus P8H67-V
Intel i5-2500

Thank you for the report, this is interesting! My setup is:
Asus P8H67-I B3 (Mini-ITX)
Intel Core i5-2500K

If others with this problem are reading this thread, please post your motherboard and CPU information.

[Halfie]

I have the same issue, I'm currently running through your fix and crossing my fingers as this is my first Linux install.

Core i5 2500K
ASUS P8P67 pro

[garthcn]

I'm having the same problem. My laptop is a Thinkpad X120e.

[dracona]

About my motherboard/processor
Asus P8H67-V
Intel i5-2500

Thank you for the report, this is interesting! My setup is:
Asus P8H67-I B3 (Mini-ITX)
Intel Core i5-2500K

If others with this problem are reading this thread, please post your motherboard and CPU information.

I am having the same problem trying to install Linux Mint 11 64bit from usb stick.
my system setup is:
intel core i5 2500k
asus P67 Sabertooth motherboard
8 gig corsair ram
2- 500GB Western Digital hard drive
Windows 7 is on the first HD, I had ubuntu 11.04 installed on the second HD, i deleted the ubuntu OS an i am trying to install Linux Mint 11 in its place.

[h4x02]

I am having the same problem trying to install Linux Mint 11 64bit from usb stick.
my system setup is:
intel core i5 2500k
asus P67 Sabertooth motherboard
8 gig corsair ram
2- 500GB Western Digital hard drive
Windows 7 is on the first HD, I had ubuntu 11.04 installed on the second HD, i deleted the ubuntu OS an i am trying to install Linux Mint 11 in its place.

You will have to install grub on whichever hard drive boots first then map it to the 2nd drive. If your hard drives are the same brand/model, I'd recommend a Raid0 configuration and then dual boot - which is what I do.

I was able to get grub installed on my RAID0 setup by following the above work-around to fix the grub installer, and following the instructions in this post to install grub: viewtopic.php?f=42&t=20170#p465939

[wafaa]

I too am having the same problem. I've a partitioned hard drive, and had a dual Windows/Ubuntu oneiric installation. I was trying to install Linux Mint 11 to replace Ubuntu.
I'm going to try the work around. Keeping fingers crossed.

My laptop details:
Acer Aspire 5920
intel core2duo T5750