BuildBot changes

[Colin Finck]

Hi all,

As you can see in project-tools SVN, I've improved our Bash scripts for
Buildslaves. They're now also usable under Windows (in a Cygwin
environment) and I'm already doing this on our new Windows Buildslave
Carrier-Win7.
Bash on Windows may look hacky at first, but it's definitely more
comfortable than Batch! Moreover, we now only have a single version of
build scripts to maintain for all our Buildslaves!
This also involved some naming changes on the existing slaves to
maintain a consistent scheme. Tell me if anything broke.
Bringing all desired Windows builders back will still take some time.
I've only started with a RosBE-Windows based one right now and I need
your help here:

For some reason, VirtualBox 4.3.18 (used for reg-testing) doesn't want
to run headless. I can do a 'runas /user:buildbot VBoxManage controlvm
"ReactOS Testbot" poweroff' in a CMD and it will work well. The very
same command executed through BuildBot ends with:

====================================================================
VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code E_ACCESSDENIED (0x80070005) - General access
denied error (extended info not available)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not
running or failed to start.
====================================================================

See
http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/6/steps...
VBoxSVC.log isn't touched when BuildBot tries this command, so I have no
additional information.

Haven't found a solution yet, so I'm asking here if any of the VBox
experts know what could be going wrong.

Cheers,

Colin

[Aleksey Bragin]

Speaking of which, I wonder, if bash for windows contained that famous 
vulnerability?

Regards,
Aleksey

On 27.10.2014 18:04, Colin Finck wrote:
> Hi all,
>
> As you can see in project-tools SVN, I've improved our Bash scripts for
> Buildslaves. They're now also usable under Windows (in a Cygwin
> environment) and I'm already doing this on our new Windows Buildslave
> Carrier-Win7.
> Bash on Windows may look hacky at first, but it's definitely more
> comfortable than Batch! Moreover, we now only have a single version of
> build scripts to maintain for all our Buildslaves!
> This also involved some naming changes on the existing slaves to
> maintain a consistent scheme. Tell me if anything broke.
> Bringing all desired Windows builders back will still take some time.
> I've only started with a RosBE-Windows based one right now and I need
> your help here:
>
> For some reason, VirtualBox 4.3.18 (used for reg-testing) doesn't want
> to run headless. I can do a 'runas /user:buildbot VBoxManage controlvm
> "ReactOS Testbot" poweroff' in a CMD and it will work well. The very
> same command executed through BuildBot ends with:
>
> ====================================================================
> VBoxManage.exe: error: Failed to create the VirtualBox object!
> VBoxManage.exe: error: Code E_ACCESSDENIED (0x80070005) - General access
> denied error (extended info not available)
> VBoxManage.exe: error: Most likely, the VirtualBox COM server is not
> running or failed to start.
> ====================================================================
>
> See
> http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/6/steps...
> VBoxSVC.log isn't touched when BuildBot tries this command, so I have no
> additional information.
>
> Haven't found a solution yet, so I'm asking here if any of the VBox
> experts know what could be going wrong.
>
> Cheers,
>
> Colin

[Thomas Faber]

@Aleksey, yes it's vulnerable just the same. Git, MSYS, cygwin, doesn't
matter.

@Colin, if the BuildBot slave is running as a service, then that's
likely the reason.
Looks like VBoxManage fails to communicate with the RPC server due to
session 0 isolation. A quick try from a psexec command prompt fails for
me too.
One option to solve this seems to be the "VBoxVmService" project:
http://sourceforge.net/projects/vboxvmservice/
Unfortunately I don't have any experience with this so I don't know how
well it works or if there's a better way.

On 2014-10-27 16:07, Aleksey Bragin wrote:
> Speaking of which, I wonder, if bash for windows contained that famous 
> vulnerability?
>
> Regards,
> Aleksey
>
> On 27.10.2014 18:04, Colin Finck wrote:
> > Hi all,
> >
> > As you can see in project-tools SVN, I've improved our Bash scripts for
> > Buildslaves. They're now also usable under Windows (in a Cygwin
> > environment) and I'm already doing this on our new Windows Buildslave
> > Carrier-Win7.
> > Bash on Windows may look hacky at first, but it's definitely more
> > comfortable than Batch! Moreover, we now only have a single version of
> > build scripts to maintain for all our Buildslaves!
> > This also involved some naming changes on the existing slaves to
> > maintain a consistent scheme. Tell me if anything broke.
> > Bringing all desired Windows builders back will still take some time.
> > I've only started with a RosBE-Windows based one right now and I need
> > your help here:
> >
> > For some reason, VirtualBox 4.3.18 (used for reg-testing) doesn't want
> > to run headless. I can do a 'runas /user:buildbot VBoxManage controlvm
> > "ReactOS Testbot" poweroff' in a CMD and it will work well. The very
> > same command executed through BuildBot ends with:
> >
> > ====================================================================
> > VBoxManage.exe: error: Failed to create the VirtualBox object!
> > VBoxManage.exe: error: Code E_ACCESSDENIED (0x80070005) - General access
> > denied error (extended info not available)
> > VBoxManage.exe: error: Most likely, the VirtualBox COM server is not
> > running or failed to start.
> > ====================================================================
> >
> > See
> > http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/6/steps...
> > VBoxSVC.log isn't touched when BuildBot tries this command, so I have no
> > additional information.
> >
> > Haven't found a solution yet, so I'm asking here if any of the VBox
> > experts know what could be going wrong.
> >
> > Cheers,
> >
> > Colin

[Aleksey Bragin]

On 27.10.2014 18:54, Thomas Faber wrote:
> @Aleksey, yes it's vulnerable just the same. Git, MSYS, cygwin, doesn't
> matter.

Ah sorry, I missed the line about Cygwin. I so much hoped we use a 
natively compiled bash version.

Regards,
Aleksey

[Hermès BÉLUSCA - MAÏTO]

There's still MSYS or Git bash, but I noticed here in my PC that they didn't
support accentued characters and other exotic things (only the bash from
Cygwin works for that). I don't know whether it's because I use a version of
MSYS & Git bash 1 year old, or not...

Hermès.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Aleksey
Bragin
Envoyé : lundi 27 octobre 2014 17:02
À : ReactOS Development List
Objet : Re: [ros-dev] BuildBot changes

On 27.10.2014 18:54, Thomas Faber wrote:
> @Aleksey, yes it's vulnerable just the same. Git, MSYS, cygwin, 
> doesn't matter.

Ah sorry, I missed the line about Cygwin. I so much hoped we use a natively
compiled bash version.

Regards,
Aleksey

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Thomas Faber wrote:
> Looks like VBoxManage fails to communicate with the RPC server due to
> session 0 isolation.

Thomas, that was it indeed, many thanks for the hint!
While it wasn't running as a service but from Task Scheduler, it was
also running in session 0. VBoxVMService was no option for us, but I
could put the Buildslave task into a user session now by starting it
only when the user logs in and then auto-logging in that user on system
startup.

With the help of Amine and Sylvain, sysreg3 is also getting its debug
log now.

What's still not working is ReactOS itself though:
* bootcd works well, but bootcdregtest doesn't boot up at all, see
http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step...
I've put up this bootcdregtest for download at
http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z

* The building process of the bootcdregtest also leaves out the gnutls
files in the modules/optional folder, see
http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c...
They definitely exist though, I've checked it in Explorer.

Can anybody help here? Maybe these problems are even reproducible on
Windows hosts?

Cheers,

Colin

[Hermès BÉLUSCA - MAÏTO]

(ntoskrnl/io/iomgr/driver.c:1630) '\Driver\sacdrv' initialization failed,
status (0xc0000037)
(ntoskrnl/io/iomgr/driver.c:64) Deleting driver object '\Driver\sacdrv'
(hal/halx86/legacy/bussupp.c:1159) Slot assignment for 5 on bus 0
(hal/halx86/legacy/bus/pcibus.c:719) WARNING: PCI Slot Resource Assignment
is FOOBAR
[SYSREG] timeout
Exception occured in the LogReader.Run():
Thread was being aborted.

Normally, if I recall correctly, the next drivers to be loaded are Uniata /
disk drivers... Something failing at this point?

H.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Colin Finck
Envoyé : mercredi 29 octobre 2014 19:12
À : [e-mail]
Objet : Re: [ros-dev] BuildBot changes

Thomas Faber wrote:
> Looks like VBoxManage fails to communicate with the RPC server due to 
> session 0 isolation.

Thomas, that was it indeed, many thanks for the hint!
While it wasn't running as a service but from Task Scheduler, it was also
running in session 0. VBoxVMService was no option for us, but I could put
the Buildslave task into a user session now by starting it only when the
user logs in and then auto-logging in that user on system startup.

With the help of Amine and Sylvain, sysreg3 is also getting its debug log
now.

What's still not working is ReactOS itself though:
* bootcd works well, but bootcdregtest doesn't boot up at all, see
http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step
s/test/logs/stdio
I've put up this bootcdregtest for download at
http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z

* The building process of the bootcdregtest also leaves out the gnutls files
in the modules/optional folder, see
http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c
ompile_5/logs/stdio
They definitely exist though, I've checked it in Explorer.

Can anybody help here? Maybe these problems are even reproducible on Windows
hosts?

Cheers,

Colin

[Sylvain Petreolle]

I will commit the uniata update that fixes the boot.We have 2 bugs about it.
 Kind regards,

Sylvain Petreolle
      De : Hermès BÉLUSCA - MAÏTO [e-mail]
 À : 'ReactOS Development List' [e-mail] 
 Envoyé le : Mercredi 29 octobre 2014 19h37
 Objet : Re: [ros-dev] BuildBot changes

(ntoskrnl/io/iomgr/driver.c:1630) '\Driver\sacdrv' initialization failed,
status (0xc0000037)
(ntoskrnl/io/iomgr/driver.c:64) Deleting driver object '\Driver\sacdrv'
(hal/halx86/legacy/bussupp.c:1159) Slot assignment for 5 on bus 0
(hal/halx86/legacy/bus/pcibus.c:719) WARNING: PCI Slot Resource Assignment
is FOOBAR
[SYSREG] timeout
Exception occured in the LogReader.Run():
Thread was being aborted.

Normally, if I recall correctly, the next drivers to be loaded are Uniata /
disk drivers... Something failing at this point?

H.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Colin Finck
Envoyé : mercredi 29 octobre 2014 19:12
À : [e-mail]
Objet : Re: [ros-dev] BuildBot changes

Thomas Faber wrote:
> Looks like VBoxManage fails to communicate with the RPC server due to 
> session 0 isolation.

Thomas, that was it indeed, many thanks for the hint!
While it wasn't running as a service but from Task Scheduler, it was also
running in session 0. VBoxVMService was no option for us, but I could put
the Buildslave task into a user session now by starting it only when the
user logs in and then auto-logging in that user on system startup.

With the help of Amine and Sylvain, sysreg3 is also getting its debug log
now.

What's still not working is ReactOS itself though:
* bootcd works well, but bootcdregtest doesn't boot up at all, see
http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step
s/test/logs/stdio
I've put up this bootcdregtest for download at
http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z

* The building process of the bootcdregtest also leaves out the gnutls files
in the modules/optional folder, see
http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c
ompile_5/logs/stdio
They definitely exist though, I've checked it in Explorer.

Can anybody help here? Maybe these problems are even reproducible on Windows
hosts?

Cheers,

Colin

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Thomas Faber]

On 2014-10-29 19:11, Colin Finck wrote:
> What's still not working is ReactOS itself though:
> bootcd works well, but bootcdregtest doesn't boot up at all, see
>
> http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step...
> I've put up this bootcdregtest for download at
> http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z
> The building process of the bootcdregtest also leaves out the gnutls
>
> files in the modules/optional folder, see
> http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c...
> They definitely exist though, I've checked it in Explorer.
>
> Can anybody help here? Maybe these problems are even reproducible on
> Windows hosts?

I tried to reproduce the configuration according to your log and indeed
VBox terminated with a Guru Meditation.
Switching to a PIIX4 IDE controller instead of the SATA one makes it
work here.

For reference, my usual config would be something like:
- Windows Server 2003 (32 bit)
- 512 MB RAM, PIIX3 chipset, PS/2 Mouse, I/O APIC, PAE, VT-x
- 20 MB video memory, no acceleration
- Single PIIX4 IDE controller with HDD as master, CD as slave
- No sound card
- Single PCnet-FAST III network adapter
- Single COM port
- USB enabled, EHCI enabled

As for the problem with the AHCI controller, the last few lines of the
VBox log before the Guru Meditation indeed seem to indicate we're
talking to the controller incorrectly. I guess that's another thing
that should be addressed in UniATA (since 0.45c1 didn't fix it from
what I see on BuildBot).

00:00:04.054099 RTC: period=0x1000 (4096) 8 Hz
00:00:04.179276 PIT: mode=2 count=0x45e4 (17892) - 66.68 Hz (ch=0)
00:00:04.938043 AHCI#0: Reset the HBA
00:00:04.944072 AHCI#0: Reset the HBA
00:00:04.945271 AHCI#0: Port 0 reset
00:00:04.964756 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:00:04.964757 !!
00:00:04.964758 !!                 Guru Meditation -2634 (VERR_IOM_MMIO_IPE_1)

[Sylvain Petreolle]

See https://jira.reactos.org/browse/CORE-7020 for details.Alter has fixed the crash in 0.45c1.There is only a hang remaining when debug is off.
 Kind regards,Sylvain Petreolle
      De : Thomas Faber [e-mail]
 À : ReactOS Development List [e-mail] 
 Envoyé le : Jeudi 30 octobre 2014 14h51
 Objet : Re: [ros-dev] BuildBot changes

On 2014-10-29 19:11, Colin Finck wrote:
> What's still not working is ReactOS itself though:
> bootcd works well, but bootcdregtest doesn't boot up at all, see
>
> http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step...
> I've put up this bootcdregtest for download at
> http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z
> The building process of the bootcdregtest also leaves out the gnutls
>
> files in the modules/optional folder, see
> http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c...
> They definitely exist though, I've checked it in Explorer.
>
> Can anybody help here? Maybe these problems are even reproducible on
> Windows hosts?

I tried to reproduce the configuration according to your log and indeed
VBox terminated with a Guru Meditation.
Switching to a PIIX4 IDE controller instead of the SATA one makes it
work here.

For reference, my usual config would be something like:
- Windows Server 2003 (32 bit)
- 512 MB RAM, PIIX3 chipset, PS/2 Mouse, I/O APIC, PAE, VT-x
- 20 MB video memory, no acceleration
- Single PIIX4 IDE controller with HDD as master, CD as slave
- No sound card
- Single PCnet-FAST III network adapter
- Single COM port
- USB enabled, EHCI enabled

As for the problem with the AHCI controller, the last few lines of the
VBox log before the Guru Meditation indeed seem to indicate we're
talking to the controller incorrectly. I guess that's another thing
that should be addressed in UniATA (since 0.45c1 didn't fix it from
what I see on BuildBot).

00:00:04.054099 RTC: period=0x1000 (4096) 8 Hz
00:00:04.179276 PIT: mode=2 count=0x45e4 (17892) - 66.68 Hz (ch=0)
00:00:04.938043 AHCI#0: Reset the HBA
00:00:04.944072 AHCI#0: Reset the HBA
00:00:04.945271 AHCI#0: Port 0 reset
00:00:04.964756 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:00:04.964757 !!
00:00:04.964758 !!                Guru Meditation -2634 (VERR_IOM_MMIO_IPE_1)

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Thomas Faber]

Oh, you're right. That issue indeed no longer reproduces with r65108
and the test bot seems to get slightly further. That new failure fails
to reproduce for me though.

On 2014-10-30 16:05, Sylvain Petreolle wrote:
> See https://jira.reactos.org/browse/CORE-7020 for details.Alter has fixed the crash in 0.45c1.There is only a hang remaining when debug is off.
>  Kind regards,Sylvain Petreolle
>       De : Thomas Faber [e-mail]
>  À : ReactOS Development List [e-mail] 
>  Envoyé le : Jeudi 30 octobre 2014 14h51
>  Objet : Re: [ros-dev] BuildBot changes
>
> On 2014-10-29 19:11, Colin Finck wrote:
> > What's still not working is ReactOS itself though:
> > bootcd works well, but bootcdregtest doesn't boot up at all, see
> >
> > http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step...
> > I've put up this bootcdregtest for download at
> > http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z
> > The building process of the bootcdregtest also leaves out the gnutls
> >
> > files in the modules/optional folder, see
> > http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c...
> > They definitely exist though, I've checked it in Explorer.
> >
> > Can anybody help here? Maybe these problems are even reproducible on
> > Windows hosts?
>
> I tried to reproduce the configuration according to your log and indeed
> VBox terminated with a Guru Meditation.
> Switching to a PIIX4 IDE controller instead of the SATA one makes it
> work here.
>
> For reference, my usual config would be something like:
> Windows Server 2003 (32 bit)
> 512 MB RAM, PIIX3 chipset, PS/2 Mouse, I/O APIC, PAE, VT-x
> 20 MB video memory, no acceleration
> Single PIIX4 IDE controller with HDD as master, CD as slave
> No sound card
> Single PCnet-FAST III network adapter
> Single COM port
> USB enabled, EHCI enabled
>
> As for the problem with the AHCI controller, the last few lines of the
> VBox log before the Guru Meditation indeed seem to indicate we're
> talking to the controller incorrectly. I guess that's another thing
> that should be addressed in UniATA (since 0.45c1 didn't fix it from
> what I see on BuildBot).
>
> 00:00:04.054099 RTC: period=0x1000 (4096) 8 Hz
> 00:00:04.179276 PIT: mode=2 count=0x45e4 (17892) - 66.68 Hz (ch=0)
> 00:00:04.938043 AHCI#0: Reset the HBA
> 00:00:04.944072 AHCI#0: Reset the HBA
> 00:00:04.945271 AHCI#0: Port 0 reset
> 00:00:04.964756 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 00:00:04.964757 !!
> 00:00:04.964758 !!                Guru Meditation -2634 (VERR_IOM_MMIO_IPE_1)