major regression

[hbelusca]

So... at which revision this problem starts to happen?

[oldman]

So... at which revision this problem starts to happen?

This does not answer your question, but according to Jim Tabor, it's Freeloader that's the problem!

jimtabor added a comment - 2015-01-14 21:18 - edited
Before throwing the 27 inch LED out the window......

I upped "svn up -r 65904" the ReactOS test branch. Then going into base/setup/usetup "svn up" there. Then going into win32ss "svn up" there too!
It booted from CD and like before installed on real hardware. Guessing one could go through other directories and do the same and stay out of Free Loader "freeldr" one.

Upped everywhere except freeldr directory, boot cd and installs.
jimtabor added a comment - 2015-01-15 12:03
Need to be careful, upping includes could break the build. Overall it works and is boot-able. Freeldr is the problem, and reading all the changes, it's hard to follow.
The hardware breakage is in Freeldr........

[middings]

...according to Jim Tabor, it's Freeloader that's the problem!

Jim Tabor reported his results in JIRA issue CORE-9032.

[Webunny]

So... at which revision this problem starts to happen?

Well...doesn't he say it in that JIRA report?

"livecd-65905-dbg.iso . does not boot on a real computer livecd-65905-66036 . and livecd-65904 works "

[middings]

Good news!

CORE-9032
* jimtabor added a comment - 2015-01-17 16:32
[~hpoussin] Thank you! Good job! Hardware is back!~ 8^D R66048 tested good.

I tried r66048 and I give it the Boots On My Machine seal of approval. I nominate Jim Tabor's r66048 for the Fix of the Week.

[oldman]

Good news!

CORE-9032
* jimtabor added a comment - 2015-01-17 16:32
[~hpoussin] Thank you! Good job! Hardware is back!~ 8^D R66048 tested good.

I tried r66048 and I give it the Boots On My Machine seal of approval. I nominate Jim Tabor's r66048 for the Fix of the Week.

Good news indeed! But, shouldn't 'Fix of the Week' go to H Poussin (see below) and the credit for hunting down the bug to FreeLoader, go to Jim Tabor?

hpoussin committed changeset 66048 to the ReactOS Main Repository project

[FREELDR] PXE: fix backward seeking (broken by r66036)

+3 -3 trunk/reactos/boot/freeldr/freeldr/fs/pxe.c

ChangesetYesterday at 22:48

--------------------------------------------------------------------------------------------

hpoussin committed changeset 66047 to the ReactOS Main Repository project

[FREELDR] Limit disk buffer size to 0xC000 bytes, like before r65905

+1 -1 trunk/reactos/boot/freeldr/freeldr/include/arch/pc/x86common.h

ChangesetYesterday at 22:48

[middings]

Good news indeed! But, shouldn't 'Fix of the Week' go to H Poussin... and the credit for hunting down the bug to FreeLoader, go to Jim Tabor?

Yes, you are correct. You caught that before I noticed my error and could sneak back to edit my earlier post.

My thanks to both hpoussin and Jim Tabor for their work to fix this very annoying bug.

[Webunny]

If it's fixed, why does the issue remains on 'unresolved' in JIRA?

[oldman]

If it's fixed, why does the issue remains on 'unresolved' in JIRA?

Stop moaning and be thankful that you can now test again with real hardware. The issue will get closed when someone gets around to doing it.

[Webunny]

If it's fixed, why does the issue remains on 'unresolved' in JIRA?

Stop moaning and be thankful that you can now test again with real hardware. The issue will get closed when someone gets around to doing it.

Where do you see moaning? I simply observed the fact it is said here it's fixed, yet is still 'unresolved' on the JIRA-bugtracker. It's obvious that this is contradictory, hence my question.

As for being thankful, that goes both ways. In fact, logic would indicate it should foremost come from the other direction. I mean, if some error occurred on their contribution-bar, and they fix it; if I ask a question about it, are you then going to say: "Stop moaning and be glad you can give away your money."? Isn't the normally expectancy that it's the one RECEIVING the money that should be thankful in the first place?

Not that I want to make a point of this, but you brought it up. Just saying.

[middings]

If (CORE-9032 is) fixed, why does the issue remains on 'unresolved' in JIRA?

I've noticed that a delay of a day or two occasionally occurs between the time a supposed fix is entered into the ReactOS source code repository and the time the corresponding JIRA issue is marked 'Fixed'. I suppose there is a reasonable explanation.

[Webunny]

If (CORE-9032 is) fixed, why does the issue remains on 'unresolved' in JIRA?

I've noticed that a delay of a day or two occasionally occurs between the time a supposed fix is entered into the ReactOS source code repository and the time the corresponding JIRA issue is marked 'Fixed'. I suppose there is a reasonable explanation.

Really? The bugs that I know of got turned into 'resolved' within hours of confirmation. I thought mayhap it wasn't completely fixed yet, or maybe they were waiting on more confirmation(s) that it's fixed, before changing the status. That could be possible too.

I could provide the latter, but I only have time for it this weekend.

[Jedi-to-be]

https://jira.reactos.org/browse/CORE-8899

This issue has pacth that helps, test it!

You could try my liveiso https://yadi.sk/d/Fw7QjIine9cnW

[Webunny]

If (CORE-9032 is) fixed, why does the issue remains on 'unresolved' in JIRA?

I've noticed that a delay of a day or two occasionally occurs between the time a supposed fix is entered into the ReactOS source code repository and the time the corresponding JIRA issue is marked 'Fixed'. I suppose there is a reasonable explanation.

Well, we're the 24th today, and it still hasn't changed. So, as I suspected, it had nothing to do with a presumed 'normal delay of two days'.

I'll be unwarrantable optimistic and assume it's because they want extra confirmation. That's about the only reasonable explanation left, at this point. Well, I did test it with the latest build just now, and it - indeed - works again. No need to keep open this particular issue indefinitely, thus.