Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4347 closed bug (fixed)

R1 alpha1 Installer go to KDL during install process.

Reported by: mt Owned by: mmlr
Priority: normal Milestone: R1/alpha1
Component: File Systems Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

R1 alpha1 Installer go to KDL during install process.

Tested hrev32727 on VirtualBox OSE on Ubuntu 9.04 alpha1 image(gcc2/gcc4 hybrid) built by jam -q @alpha-cd

Attachments (2)

Screenshot1.png (61.3 KB) - added by mt 10 years ago.
Screenshot2.png (90.9 KB) - added by mt 10 years ago.

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by mt

Attachment: Screenshot1.png added

Changed 10 years ago by mt

Attachment: Screenshot2.png added

comment:1 Changed 10 years ago by umccullough

Isn't the OSE version that comes with ubuntu 9.04 based on virtualbox 2.x?

I'm pretty certain we had known problems with that version. (In fact, it seems we still have problems with VirtualBox in general, as I still seem to hear people complaining with the latest 3.0.4)

comment:2 in reply to:  1 Changed 10 years ago by mt

Replying to umccullough:

Isn't the OSE version that comes with ubuntu 9.04 based on virtualbox 2.x?

I'm pretty certain we had known problems with that version.

I use Virtualbox OSE 2.14-dfsg-1ubuntu3.
I hear R1alpha1 installer has same problem on VMware, so I think this issue is not specific to Virtualbox. More test will be needed (include real hardware).

comment:3 Changed 10 years ago by mt

I test on real hardware with CD made from haiku-alpha-candidate-hrev32785 iso image (from haiku-files.org) and installer seems to work fine.

I think this issue occurred because virtual machine's CD drive is faster than real hardware's .

comment:4 Changed 10 years ago by mmlr

Component: Applications/InstallerFile Systems
Milestone: R1R1/alpha1
Owner: changed from korli to mmlr
Status: newassigned

That's a write_overlay issue. This node part of the MIME database and probably has been created when starting the debug_server from the bootscript. Since it is a virtual node, it should never ask the iso9660 filesystem for it.

comment:5 Changed 10 years ago by mmlr

Resolution: fixed
Status: assignedclosed

Fixed in hrev32815. A virtual node was put and therefore destroyed. Then it was iterated again and it was tried to get the node again, which didn't exist anymore. Therefore the request got through to the underlaying iso9660 filesystem, for which the inode number was invalid. The reason why you see it under emulation and not under real hardware is that you have less memory under emulation, so the node is put due to the low memory situation. Under real hardware memory pressure is not that high, so the node stayed in memory (pure luck really).

comment:6 Changed 10 years ago by nielx

Version: R1 alpha1R1/alpha1
Note: See TracTickets for help on using tickets.