FAQ   Search   Memberlist  
Profile    Log in to check your private messages    Register    Log in
x86_64
Goto page Previous  1, 2
 
Post new topic   Reply to topic    BLAG Forum Index -> development
View previous topic :: View next topic  
Author Message
noldrin
PostPosted: Fri Jan 25, 2008 6:38 pm    Post subject: Reply with quote

Is anaconda running on the newest kernel? or is the new kernel just what's being installed.

Kernel 2.6.24 is out so it will be interesting to see if it's still there.

jebba
PostPosted: Sun Jan 27, 2008 6:26 am    Post subject: Reply with quote

Code:
Linux blag80k64.blagblagblag.org 2.6.24-0blag.f8 #1 SMP Sat Jan 26 22:33:39 EST 2008 x86_64 x86_64 x86_64 GNU/Linux


This is the "cleaned source"/deblobbed kernel available at:
ftp://ftp.blagblagblag.org/pub/BLAG/linux/kernel/v2.6/TESTING/

jebba
PostPosted: Sun Jan 27, 2008 10:44 am    Post subject: Reply with quote

iron_chef wrote:
This bit right here is where it hangs:
Code:

  self.loopbackFile = "%s%s%s" % (chroot,
           fsset.filesystemSpace(chroot)[0][0],
           "/rhinstall-stage2.img")

   try:
     win = self.waitWindow (_("Copying File"),
                     _("Transferring install image to hard drive..."))
     shutil.copyfile("%s/images/stage2.img" % (self.tree,),
                   self.loopbackFile)
     win.pop()


The 'shutil.copyfile()' call is executing, but it goes off into the weeds and never finishes. The win.pop() line is what makes the pop-up message window disappear, which never happens. shutil.copyfile() is copying the file stage2.img from the mounted CD (at /mnt/source) to the newly formatted root partition (mounted at /mnt/sysimage) as rhinstall-stage2.img. stage2.img is a squashfs'ed filesystem that is also loop-mounted at /mnt/runtime, and that's where anaconda is running from.
Anaconda actually finishes the file copy (if you get to a shell and look at /mnt/sysimage/rhinstall-stage2.img, you can even see that it's the same size as stage2.img. But it just never finishes. Running ps -ax from a shell shows that the anaconda processes is in the "D" state, or uninterruptable sleep, which should never ever happen unless the kernel screws something up.


From 70k's python-2.5-15.fc7 Python-2.5/Lib/shutil.py:

Code:
def copyfile(src, dst):
    """Copy data from src to dst"""
    if _samefile(src, dst):
        raise Error, "`%s` and `%s` are the same file" % (src, dst)

    fsrc = None
    fdst = None
    try:
        fsrc = open(src, 'rb')
        fdst = open(dst, 'wb')
        copyfileobj(fsrc, fdst)
    finally:
        if fdst:
            fdst.close()
        if fsrc:
            fsrc.close()

iron_chef
PostPosted: Sun Jan 27, 2008 7:30 pm    Post subject: Reply with quote

jebba wrote:

From 70k's python-2.5-15.fc7 Python-2.5/Lib/shutil.py:

Code:
def copyfile(src, dst):
    """Copy data from src to dst"""
    if _samefile(src, dst):
        raise Error, "`%s` and `%s` are the same file" % (src, dst)

    fsrc = None
    fdst = None
    try:
        fsrc = open(src, 'rb')
        fdst = open(dst, 'wb')
        copyfileobj(fsrc, fdst)
    finally:
        if fdst:
            fdst.close()
        if fsrc:
            fsrc.close()


I've looked into that before. It's pretty straightforward, just basic built-in python calls. I've even ripped the call to shutil.copyfile() out and replaced it, in anaconda, with the lower-level os.open() calls in order to tweak some of the file descriptor flags. That didn't work either.
It's interesting that there's no except: clause in that function. The finally: section gets run no matter what happens in the try: section, even if there's exceptions thrown. Maybe something's happening and it's not getting caught?
Also, if you look at the code for copyfileobj():

Code:

def copyfileobj(fsrc, fdst, length=16*1024):
    """copy data from file-like object fsrc to file-like object fdst"""
    while 1:
        buf = fsrc.read(length)
        if not buf:
            break
        fdst.write(buf)

you can see where it's getting into the infinite loop. I guess what's happening is that the built-in read() call isn't returning an EOF when there's no more data. It's just blocking forever, thus it never breaks out of the while loop. Interesting. Well, frustrating mostly, but still interesting... :)

jebba
PostPosted: Sun Jan 27, 2008 8:27 pm    Post subject: Reply with quote

I tried to md5sum the rhinstall-stage2.img (from HD) and stage2.img (from CD) on vt2 during the hang. I was able to md5sum the former fine, but not the latter. In fact, I couldn't md5sum the latter on my laptop either--that command is hanging in a terminal right now. So don't think it's anaconda. I think we have something related to the loopback device or perhaps corrupt ISOs. The fact that it builds fine and works with 2.6.22 but not 2.6.23 or 2.6.24 tells us quite a bit. In sum, I dont think we're going to solve this by poking at anaconda and/or python. Perhaps rebuilding `mkisofs` (cdrkit) and such would do the trick.... I'm not sure, but I think we need to head in that direction.
Display posts from previous:   
Post new topic   Reply to topic    BLAG Forum Index -> development Goto page Previous  1, 2
Page 2 of 2

Protected by Anti-Spam ACP