BLAG

BLAG Forums
It is currently Mon Dec 22, 2014 1:33 pm

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: x86_64
PostPosted: Sat Jan 19, 2008 8:00 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
The development box has x64_86 f8 installed so we can get a 64bit blag started.

:)

-Jeff


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 19, 2008 9:34 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
This will be pure x86_64, not i386 packages.... :)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 20, 2008 12:48 am 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
If you have F8 x86_64 installed you can get started with BLAG 80k x86_64 alpha by running:

Code:
rpm -Uvh \
http://www.blagblagblag.org/80000/x86_64/RPMS.extras/blag-package-config-apt-8-4blag.f8.noarch.rpm
http://www.blagblagblag.org/80000/x86_64/RPMS.extras/apt-0.5.15lorg3.93-4.fc8.x86_64.rpm


This is very early stages of being set up (like just now)....

-Jeff


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 1:29 am 
Offline

Joined: Wed Jul 12, 2006 12:19 pm
Posts: 151
Location: Chicago
That's great! Is there anything that we could do to help test this?

How much more will need to be done to blagify it?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 4:35 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
contents wrote:
That's great! Is there anything that we could do to help test this?

How much more will need to be done to blagify it?


Well, there's not *too* much to do at the moment except solve this painful bug:

http://bugzilla.blagblagblag.org/show_bug.cgi?id=963

It has driven me & iron_chef a bit loony. ;) He did come up with a hackaround for it, which is cool.

Solving that bug would help 70001, 80k alpha i386/x86_64 too...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 6:12 pm 
Offline

Joined: Thu Oct 06, 2005 3:49 pm
Posts: 186
Just for fish (the "halibut"), what is the warning placed in /temp?

b-


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 6:21 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
berkbw wrote:
Just for fish (the "halibut"), what is the warning placed in /temp?


Huh?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 6:40 pm 
Offline

Joined: Thu Oct 06, 2005 3:49 pm
Posts: 186
Sorry halibut ->hellofit gringo pun. In the bugzilla screen it says warning placed in /tmp. What is the warning pcaced there?

I'll really try to be more proper and serioun, and drop the attempts at humor.

b-


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 6:42 pm 
Offline

Joined: Fri Nov 18, 2005 3:07 am
Posts: 699
jebba wrote:
http://bugzilla.blagblagblag.org/show_bug.cgi?id=963

It has driven me & iron_chef a bit loony. ;) He did come up with a hackaround for it, which is cool.

Solving that bug would help 70001, 80k alpha i386/x86_64 too...


Reading the fedora 8 bugzilla, it sounds like their is a similar problem that happens if Anaconda writes the partition table immediately because it's low on memory. Don't know if the behavior applies here.

https://bugzilla.redhat.com/show_bug.cgi?id=428314


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 6:44 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
berkbw wrote:
Sorry halibut ->hellofit gringo pun. In the bugzilla screen it says warning placed in /tmp. What is the warning pcaced there?

I'll really try to be more proper and serioun, and drop the attempts at humor.


I dont mind the humour, but I still have no idea what you are talking about ;)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 6:45 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
noldrin wrote:
jebba wrote:
http://bugzilla.blagblagblag.org/show_bug.cgi?id=963

It has driven me & iron_chef a bit loony. ;) He did come up with a hackaround for it, which is cool.

Solving that bug would help 70001, 80k alpha i386/x86_64 too...


Reading the fedora 8 bugzilla, it sounds like their is a similar problem that happens if Anaconda writes the partition table immediately because it's low on memory. Don't know if the behavior applies here.

https://bugzilla.redhat.com/show_bug.cgi?id=428314


This happens 100% of the time irrespective of how much memory there is. It also doesnt give an error, it just stops at "transferring install image to hard drive"...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 7:28 pm 
Offline

Joined: Thu Sep 28, 2006 5:41 pm
Posts: 68
Location: Idaho, USA
Yep, no error is indicated at all. It just hangs forever. But only on 2.6.23 kernels.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 9:16 pm 
Offline

Joined: Fri Nov 18, 2005 3:07 am
Posts: 699
iron_chef wrote:
Yep, no error is indicated at all. It just hangs forever. But only on 2.6.23 kernels.


Weirdness.. Unfortunately I don't know enough to really help, but using my troubleshooting skills, this is what I came up with to try and maybe spark an idea for you guys:

What changes are made to the 2.6.23 kernel that when it's installed it changes the disk image that could screw up anaconda? Does it put things in different places or do funky link things? Maybe you need to have a different program setting up the partitions or formatting the disk image.

Also what are the differences between the BLAG anaconda and the Fedora one? Does BLAG use the latest Anaconda? Maybe something has been updated ot tweaked that is affecting it, or how about all the under pinnings of Anaconda like Python, could an some outdated part be responsible? Is it possible to run the textmode install with verbose python execution (python -m trace -t) ?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 23, 2008 10:03 pm 
Offline
Site Admin

Joined: Sun Mar 14, 2004 3:17 pm
Posts: 4492
Location: Loveland, Colorado, USA
noldrin wrote:
What changes are made to the 2.6.23 kernel that when it's installed it changes the disk image that could screw up anaconda?


This is what it's doing:

Code:
    def systemMounted(self, fsset, chroot):
        if not os.path.exists("%s/images/stage2.img" %(self.tree,)):
            log.debug("Not copying non-existent stage2.img")
            return

        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()
        except Exception, e:
            if win:
                win.pop()

            log.critical("error transferring stage2.img: %s" %(e,))

            if isinstance(e, IOError) and e.errno == 5:
                msg = _("An error occurred transferring the install image "
                        "to your hard drive.  This is probably due to "
                        "bad media.")
            else:
                msg = _("An error occurred transferring the install image "
                        "to your hard drive. You are probably out of disk "
                        "space.")

            self.messageWindow(_("Error"), msg)
            os.unlink(self.loopbackFile)
            return 1

        isys.lochangefd("/dev/loop0", self.loopbackFile)


I should also note, running this command is failing too (!):

Code:
mount foo.iso /mnt/foo
cp -a /mnt/foo /tmp/bar


When copying over some images. Hmm.... zisofs?

noldrin wrote:
Also what are the differences between the BLAG anaconda and the Fedora one?


Patches, including stuff about selinux to disable it. That causes problems sometimes. ;)

noldrin wrote:
Does BLAG use the latest Anaconda?


Same version that shipped with the equivalent fedora version. I have build svn versions as well. Sometimes we add fixes that were added as updates.img's as patches. The big difference is that yum changes and lots of times it's changes break things in anaconda. For this reason, i get irritated with yum and am not as responsive about fixing it in the repo. ;)

noldrin wrote:
Maybe something has been updated ot tweaked that is affecting it, or how about all the under pinnings of Anaconda like Python, could an some outdated part be responsible?


Certainly, or a missing bit. I think it's tied into the fact that it can't copy those ISO images either.


noldrin wrote:
Is it possible to run the textmode install with verbose python execution (python -m trace -t) ?


iron_chef? You ever run it that way?

-Jeff


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 24, 2008 3:35 pm 
Offline

Joined: Thu Sep 28, 2006 5:41 pm
Posts: 68
Location: Idaho, USA
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.

Quote:
I should also note, running this command is failing too (!):

Code:
mount foo.iso /mnt/foo
cp -a /mnt/foo /tmp/bar


When copying over some images. Hmm.... zisofs?


I hadn't considered zisofs... that's entirely possible. We should try an uncompressed ISO, definitely.

noldrin wrote:
Also what are the differences between the BLAG anaconda and the Fedora one?


Yeah, it's 90% cosmetic, and about 10% disabling selinux.

noldrin wrote:
Does BLAG use the latest Anaconda?

One problem is that anaconda is an EXTREMELY volatile moving target. Finding a version of anaconda, yum, rpm, and various other python utils that actually work together is a huge pain in the ass. I think I've even read on the anaconda-devel list, straight from a developer, that Fedora/Red Hat doesn't even necessarily use the version of anaconda that they ship with a distro to actually build that distro.

jebba wrote:
noldrin wrote:
Is it possible to run the textmode install with verbose python execution (python -m trace -t) ?


iron_chef? You ever run it that way?


No, I haven't, actually. That's a good idea, though. Anaconda is actually really verbose with it's debugging output to begin with though, it provides somewhat useful logs. What would be interesting is to build it so that something like strace is packed into stage2.img so that we could drop to a shell and see what sort of kernel/system calls it's doing. I was about to hook gdb up to it yesterday, but then I got busy with "real life" and didn't get a chance too. It would be really good to see what part of the kernel it's getting hung up on.

What sucks is that it could be so many different things, or combinations of those things (ext3/scheduling/disk io/squashfs/lvm/selinux/etc.). I'm 99% certain that it's something lower level than python/anaconda, especially since we can reproduce the same sort of hang just copying stuff from a loop mounted ISO image like jebba mentioned. What also sucks is that the 2.6.23 kernel incorporated a ridiculously huge set of changes, so it's really tricky to figure out what might be causing it. Wasn't there even a brand new "controversial" scheduler that made it's debut in 2.6.23? That's extremely suspicious to me, especially since a permanently sleeping process is likely a kernel scheduling problem. Either that, or it's hung up on disk i/o (the CD-ROM).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group