Building Haiku x86_64 on Haiku x86_64 issues

[Luposian]

I can build a raw image of Haiku x86_64, within Haiku x86_64 (but not CD .iso nor Anyboot image), but cannot copy the files (nor install them) to the second partition I have. I can copy the files (of the 64-bit image) fine, from within a standard Haiku (32-bit) install.

It seems odd, to be able to build a 64-bit image, from within Haiku x86_64, but yet am unable to do anything with that image afterwards.

[axeld]

What exactly fails, and how? Any enlightening message?

[Luposian]

It basically says it can't copy the files (trying to copy files directly from the image, to a folder, or attempting to install to the second partition, from the image). Something about them being the wrong type or corrupted or something. It brings up the error message for every single file. I will try to either write down the exact message or take a picture later today.

[Luposian]

Error message is:

Error copying file "[name of file]": Bad Address

Would you like to continue? [Cancel] [Ok]

That's it. The files copy over, but they're just a page icon (two sheets of blank paper) with the filname and zero bytes. Oddly enough, the folder the files are in seems to look normal, however.

Copying the image file, itself, from Haiku64 to the mounted Haiku32 partition, is possible. Just no way of installing the files (by copy or installer) within that image file, to that partition, or anywhere within Haiku64.

So, it doesn't seem to be a general "copy bug", perse... but something specifically related to the files within the Haiku64 image. Just a guess.

[bonefish]

It would be nice, if you could be bit more precise when reporting a bug. From the information given so far, here's what I guess you are doing (please correct where I'm guessing incorrectly, add details where missing):

• You're running a Haiku x86-64. So obviously the ticket "Version" field ("R1/alpha4.1") isn't correct. What revision are you running? Where did you get it/how did you build it?
• You are building a Haiku image. What revision? How? How was it configured?
• You mount the successfully created image. How?
• You copy a file from the mounted image to another partition via Tracker. Does cp in the Terminal work or print any interesting error messages? Is anything of interest written to the syslog?
• From within a 32 bit Haiku installation mounting the image and copying files from it to the partition in question works without error.

Supposing most of the above is correct, I don't see why you selected "Build System" as the ticket component. The last point suggests the image has been created OK, so (at least so far) there's no reason to assume this is related to the build system. The bug seems to be in Tracker, libbe/libroot, the VFS, or BFS.

[Luposian]

Do not assume, as an end-user, I automatically know exactly what category to position a ticket. I go with what seems like the closest category. I built the image and I could not copy nor install the files. So I naturally assume the build was corrupted.

What is Haiku x86_64 classified under? I assumed it was a branch of the R1/A4 code. Was it not?

I will attempt to gather any other missing information as I can.

You want the revision of Haiku x86_64 I used to build the "Haiku64" image? Ok, I'll get that for you.

I got that particular revision as a nightly.

I do not recall what revision the image was, after jamming it. Is there a way to find that out?

I mount the image by double-clicking on it.

How do I use cp in the terminal? Haven't done that yet. I'm not a "terminal geek" and prefer to do everything at the GUI level, unless forced to do otherwise.

I will submit a syslog of the nightly.

I think that sums up my answers. I'll get the other requested information ASAP.

[Luposian]

Ok, the revision of the nightly Haiku x86_64 I am using, is hrev45362.

Now this next thing doesn't make any sense...

I decided to "mess around" and delete everything out of the mounted Haiku image, by dragging it to the trash. It copies to the trash fine. In fact, upon emptying the trash, the 300Mb Haiku image file was now completely empty! Even after a reboot! But, the weird thing was... I was able to INSTALL to that 300Mb image file (it errored because it ran out of room)! And, upon trying to copy one of the files in it, it copied perfectly fine!

So, the question is... are the files, themselves, corrupted and CAN'T be copied? But how does that explain being able to copy them from within Haiku32?

Does the image file need to be large enough (sufficiently larger than it's contents) to have room to copy it's files elsewhere (or install from) properly? Assuming, it uses some of the image's space for temp use or something?

Grasping at straws here, but hoping something makes sense.

Now gotta recreate a new Haiku.image file... my current one is now no longer valid, as it's been completely messed up by my tinkering! HA!

I'm gonna make the image file larger, this time, to see if that helps.

I'll enclose a Syslog with my next reply.

[Luposian]

Ok, just discovered something... I CAN copy files from within the image, but only SOME files and not others. I dragged the "system" folder (of the image) to the "Transfer" folder on my desktop and it copied a bunch of files/programs (280 of 'em), but then stopped and gave the error message, like before! If I rapidly click on [Ok], I can get it to continue copying many other files and the ones that copy fine are runnable, but the others are dead, zero byte nothings.

So, the question is now... why are SOME (actually a whole bunch, but I have no way of knowing how many) files "dead" and the rest are perfectly fine? Oddly enough, "WebPositive" is one of the dead files!

It seems to me, that something isn't quite JAMming right, from within Haiku x86_64. Yet they look fine (icons and filesize count, etc.).

So, where do we go from here? What is the most logical next step?

As a side note (which hopefully gives a useful clue), when I tried to run WebPositive from within the image, it basically said: "you can't run "WebPositive" using "WebPositive" (Bad Address)"

Weird.

[bonefish]

Replying to Luposian:

Do not assume, as an end-user, I automatically know exactly what category to position a ticket. I go with what seems like the closest category. I built the image and I could not copy nor install the files. So I naturally assume the build was corrupted.

When in doubt just leave the component "General".

What is Haiku x86_64 classified under? I assumed it was a branch of the R1/A4 code. Was it not?

x86-64 was originally developed in a branch and merged into the main repository master after the last alpha.

I will attempt to gather any other missing information as I can.

You want the revision of Haiku x86_64 I used to build the "Haiku64" image? Ok, I'll get that for you.

I got that particular revision as a nightly.

I do not recall what revision the image was, after jamming it. Is there a way to find that out?

If you have pulled the tags git describe --tags prints the closest tag. git rev-parse HEAD gives you the hash of the latest commit (or you can get it from the git log output). Since I don't think this is build system related the information probably isn't relevant.

How do I use cp in the terminal? Haven't done that yet. I'm not a "terminal geek" and prefer to do everything at the GUI level, unless forced to do otherwise.

The syntax in this case is cp <file-to-copy> <destination-directory>. You can drag and drop an entry onto the Terminal window to get its path inserted. Please find a file that doesn't copy in Tracker and try to copy it with cp. The result of this and the syslog are the most interesting information ATM.

BTW, moving to trash is a complete different operation than copying. Let's stick to the failing copying please.

[Luposian]

Ok, so I should try to cp a broken file and then submit a Syslog. Will do...

I simply assumed, since I discovered some files copied and others didn't, that it wasn't the copy process that was munged up, but just some of the files. And since it's always the same files that won't copy, that lent credibility to that thought. I also assumed that whatever we did in the GUI was just a visual representation of what was done "behind the scenes" at a CLI level. But dragging an icon from one location to another, on the desktop (GUI), is actually functionally different than copying that same file, using the cp command in the Terminal?

[anevilyak]

Replying to Luposian:

But dragging an icon from one location to another, on the desktop (GUI), is actually functionally different than copying that same file, using the cp command in the Terminal?

In the case of dragging to the Trash in particular, it isn't a copy but a move that occurs, so it's not the same operation at all. Also, yes, there are a number of different ways to write file copy routines, so there's no guarantee whatsoever that e.g. cp and Tracker's methodologies are the same.

[Luposian]

Ok, just did a cp in the Terminal (of WebPositive), from the image file, to the Transfer folder and... we have success! However, this is what Terminal said:

~> cp /Haiku1/apps/WebPositive /boot/home/Desktop/Transfer cp: reading `/Haiku1/apps/WebPositive': Bad address ~>

So, it copied the file (and the file runs!), but it gives a similar message. Also, the filesize is different. The WebPositive is the same one, so how is it there are two different filesizes? I can understand the sector size or whatever being different, but the program, itself, should, be the same size. Or is it just the way Haiku is displaying the information (i.e. it doesn't differentiate between the file itself and the place it resides (doesn't quote them seperately))?

[bonefish]

Since cp encountered an error, it is not surprising the file sizes aren't the same. Please give the sizes and attach the syslog.

[Luposian]

The filesizes of WebPositive are:

Inside Image = 642.14KiB (657,548 bytes) Inside Folder = 640.0 KiB (655,360 bytes)

I've also just added the Syslog. It's a fresh/clean one, right after a reboot. Let me know if you need one, under different circumstances.

[bonefish]

Replying to Luposian:

I've also just added the Syslog. It's a fresh/clean one, right after a reboot. Let me know if you need one, under different circumstances.

Yeah, one *after* the error happens would be helpful.

[Luposian]

Oops, my bad... seems I thought you wanted a syslog, period. But, something told me to look at the clean Syslog and then check it after doing the cp... BINGO! There's the difference! I'm replacing the Syslog I just sent, with the current one, showing... lo and behold... a few ERRORS! Why, lookie there!

Here's the part I think you're looking for (but look at the entire Syslog, just to make sure):

USER: app application/x-vnd.Haiku-StyledEdit send to client failed: Bad port ID KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/virtual/files/8/raw) KERN: intel: ep_std_ops(0x1) KERN: trying: partitioning_systems/intel/extended/v1 KERN: returned: -1 KERN: intel: ep_std_ops(0x2) KERN: trying: partitioning_systems/intel/map/v1 KERN: intel: pm_identify_partition(15, 8: 0, 838860800, 512) KERN: returned: 0.5 KERN: trying: file_systems/bfs/v1 KERN: returned: 0.8 KERN: trying: file_systems/devfs/v1 KERN: returned: -1 KERN: trying: file_systems/rootfs/v1 KERN: returned: -1 KERN: trying: partitioning_systems/session/v1 KERN: returned: -1 KERN: trying: file_systems/attribute_overlay/v1 KERN: returned: -1 KERN: trying: file_systems/iso9660/v1 KERN: identify(15, 0xffffffff80d3f828) KERN: returned: -1 KERN: trying: file_systems/nfs4/v1 KERN: returned: -1 KERN: trying: file_systems/write_overlay/v1 KERN: returned: -1 KERN: scanning with: file_systems/bfs/v1 KERN: bfs: mounted "Haiku" (root node at 131072, device = /dev/disk/virtual/files/8/raw) USER: app application/x-vnd.haiku-mountvolume send to client failed: Bad port ID KERN: file_cache: read pages failed: Bad address Last message repeated 2 times USER: app application/x-vnd.Haiku-StyledEdit send to client failed: Bad port ID

[bonefish]

I don't see much difference to the previously attached syslog. Anyway, both feature the file_cache: read pages failed: Bad address errors, which definitely isn't good. It may or may not be relevant that the last, partial page could not be read. Hard to say without more debug output.

[Luposian]

Is there anything else I can do, to give you more info?

[xyzzy]

Sorry for taking a while to look at this, I'll see if I can reproduce it at all.

[xyzzy]

Well, I've reproduced it. I'll look into what's causing it.

[xyzzy]

Should be fixed in hrev45397.