Hello,
Is there a build command to install ReactOS to a folder. Something
equivalent to "make install" of good old RBuild days?
I used to install ReactOS on real hardware this way, because it allowed
me to have more control over the install process (aka control it
completely).
Thanks,
João Jerónimo
Hi all,
After finally setting up replication slaves for redundancy, our LDAP
setup went live today! BuildBot and all SVN repositories now
authenticate against a shared user directory.
If everything went well, you shouldn't notice a difference :)
Except that you can now change your SVN password yourself at
https://lam.reactos.org
Keep your credentials safe. We can now easily add more ReactOS developer
services like file sharing and Mumble without needing to duplicate all
user information. And we will do so!
Cheers,
Colin
Link, for ease of access: https://jira.reactos.org/browse/CORE-7864
The bug was assigned to me a while ago, but this seems to be primarily
win32k issues, which are outside my area of expertise. Someone else may be
able to handle it better.
Hi all !
In this video :
https://drive.google.com/file/d/0BzFtJhksW7viRDRVMzluTnFjMlU/view?usp=sharin
g
(with strong French accent, sorry :P, and it was my first attempt at making
a video with a camera in one hand while doing the other things with the
other hand ^^), I show an attempt to create a hybrid-USB key by configuring
freeldr to load either a livecd (shown in the video) or a bootcd in ramdisk.
Many remarks are in order:
- theres a crash when booting the bootcd image, early in phase 1 boot in Io
(can be reproduced locally on vbox for example, with similar freeldr.ini
parameters that I show in the video).
- the whole story consists in loading a ramdisk, so I avoid all the
USB-related storage problems we could (and certainly) encounter if I used
the USB key more like as we do for our current livecds, i.e. permanent reads
to the removable device.
- a ROS livecd that can be removable (in the sense that one can use another
cd to test something, while ROS is still running) should be done with some
kind of hdd image file instead, that is then loaded in memory (so that we
can then read and write to this virtual drive).
- something weird happens when freeldr loads the livecd iso in memory: first
it takes 7 minutes to just try to open the iso file, and then 7 other
minutes to load the iso proper. This problem needs to be investigated.
- we still report strange dates when listing files from the livecd (at least
when it is mounted as ramdisk), see the video.
- finally, when using Standard PC (non-ACPI) HAL, I dont really think we
reposition HDD heads into sleep position, because when I switch PC power
off with the button I can hear the HDD making the noise of the heads quickly
going back to sleep position, whereas I dont think this should happen if
the heads were being already in the correct position before I switch power
off (when using the shutdown command of FreeDOS, the other OS I have
installed in the PC, the noise isnt produced).
Cheers,
Hermès.
PS: I keep the right to remove the video at any time if I notice misuses.
And its not an official video (even if I was playing around with Windows
Movie Maker with the ReactOS logo during the first seven seconds, and with
the website links at the end) !!
Dear all,
Due to a hard disk dying, we'll attempt to anticipate its total death
tomorrow at noon CET to change it before it quits working.
It is a disk in one of our hypervisor. The following services will be hit:
-> ReactOS main website
-> Jira/Fisheye
-> Main DNS server
-> ReactOS community website
Sorry for the caused inconvenience.
With my best regards,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all,
As more and more computers these days come without optical drives, we're
thinking about switching from ReactOS CD giveaways to USB flash drive
giveaways on exhibitions (like this month's FOSDEM). ReactOS would then
come preinstalled in a VM on these drives. When ReactOS' USB support
gets better, we may even think about making these drives bootable.
Now the prices for 1GB USB drives haven't quite reached the costs of
blank CDs yet. Also many countries put a high fee on USB drives, because
you will for sure always use them to pirate copyrighted work... For
example, we're talking about a fee of 1€/unit here in Germany. Germany
is fair enough though to not apply the fee if you're ordering from
outside Germany. Maybe this also works the other way round, i.e. we as
ReactOS Deutschland e.V. order USB drives from another European country
and don't have to pay this fee.
Sooo, who of you knows a good supplier in your (European) country for
bulk ordering USB drives with the best per-unit price? Even better if
your supplier can print a custom logo on these drives.
Depending on the price, we're talking about 50-200 drives here.
Reply on the forum please:
https://reactos.org/forum/viewtopic.php?f=2&t=13917
Thanks for your help in making a great ReactOS presentation at exhibitions!
- Colin
From our investigations (Timo & I), there seems to be a memory
corruption when using a PXE boot on VBox.
You're committing a hack to workaround this memory corruption (which
replaces code which seems correct by some other code which is probably
correct), which lets you go a little bit further, where memory
corruption seems to strike again. And thus, this doesn't bring PXE boot
in better shape.
Furthermore, it appears that you're working around a bug which isn't in
ReactOS but in VBox. As a reminder, PXE boot works fine with Qemu, with
VMware. And when changing the ROM of VBox [1], then PXE boot works on
VBox as well.
Revert and report to VirtualBox instead. Our code is correct.
Thanks to Timo & Hervé for their help on digging into this issue.
[1]: https://git.ipxe.org/ipxe.git/blob/HEAD:/src/config/vbox/README
On 10/01/2015 01:21, hbelusca(a)svn.reactos.org wrote:
> Author: hbelusca
> Date: Sat Jan 10 00:21:33 2015
> New Revision: 66022
>
> URL: http://svn.reactos.org/svn/reactos?rev=66022&view=rev
> Log:
> [FREELDR]: Commit a temporary "hackfix" for (Pc)GetTime: on VBox when booting with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get CMOS Time) *never ever* returns!! (however without PXE everything works). So... is it some kind of stack overflow or whatever that makes the Int386 function stack messy? Or something else? So in the meantime we use direct CMOS port reads. Timo, Hervé (and others), can you please review? And in particular why does it happen only with PXE?
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c
>
> Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/…
> ==============================================================================
> --- trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1] Sat Jan 10 00:21:33 2015
> @@ -20,10 +20,50 @@
>
> #define BCD_INT(bcd) (((bcd & 0xf0) >> 4) * 10 + (bcd &0x0f))
>
> +#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED
> +
> +/* CMOS Registers and Ports */
> +#define CMOS_CONTROL_PORT (PUCHAR)0x70
> +#define CMOS_DATA_PORT (PUCHAR)0x71
> +
> +#define RTC_REGISTER_A 0x0A
> +#define RTC_REG_A_UIP 0x80
> +
> +static UCHAR
> +HalpReadCmos(IN UCHAR Reg)
> +{
> + /* Select the register */
> + WRITE_PORT_UCHAR(CMOS_CONTROL_PORT, Reg);
> +
> + /* Query the value */
> + return READ_PORT_UCHAR(CMOS_DATA_PORT);
> +}
> +
> +#endif
> +
> TIMEINFO*
> PcGetTime(VOID)
> {
> static TIMEINFO TimeInfo;
> +
> +#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED
> +
> + /* Loop while update is in progress */
> + while ((HalpReadCmos(RTC_REGISTER_A)) & RTC_REG_A_UIP);
> +
> + /* Set the time data */
> + TimeInfo.Second = BCD_INT(HalpReadCmos(0));
> + TimeInfo.Minute = BCD_INT(HalpReadCmos(2));
> + TimeInfo.Hour = BCD_INT(HalpReadCmos(4));
> + TimeInfo.Day = BCD_INT(HalpReadCmos(7));
> + TimeInfo.Month = BCD_INT(HalpReadCmos(8));
> + TimeInfo.Year = BCD_INT(HalpReadCmos(9));
> +
> + /* Compensate for the century field */
> + TimeInfo.Year += (TimeInfo.Year > 80) ? 1900: 2000;
> +
> +#else
> +
> REGS Regs;
>
> for (;;)
> @@ -86,6 +126,9 @@
>
> break;
> }
> +
> +#endif
> +
> return &TimeInfo;
> }
>
>
>
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
On 05/01/2015 00:49, hbelusca(a)svn.reactos.org wrote:
> Author: hbelusca
> Date: Sun Jan 4 23:49:18 2015
> New Revision: 65982
>
> URL: http://svn.reactos.org/svn/reactos?rev=65982&view=rev
> Log:
> [FREELDR]
> - Correctly append a backslash to the BootPath (if needed).
> - Be able to specify relative boot paths (relative to the current boot device): as a consequence, remove the "LiveCD" hackish special value that was introduced long long ago.
> - Fix BootPath retrieval in ReactOSSetup mode (via the SystemPath optional value), and use a better way to build the temporary txtsetup.sif full file names.
>
> As a consequence we can now build hybrid cds with the following architecture:
> \
> --> loader\ (bootsectors + free/setupldr.sys)
> --> myboot\ (contents of what_defaults_to_reactos directory for the bootcd)
> --> mylive\ (contents of what_defaults_to_reactos directory for the livecd)
> --> <regular_files>
> and
> freeldr.ini specifying the following values:
>
> ; The Setup entry
> [Setup]
> BootType=ReactOSSetup
> SystemPath=\myboot
>
> ; The LiveCD entry
> [LiveCD]
> BootType=Windows2003
> SystemPath=\mylive
> Options=/MININT
>
> Part 2/2
> CORE-9023
>
> Modified:
> trunk/reactos/boot/bootdata/livecd.ini
> trunk/reactos/boot/freeldr/freeldr/CHANGELOG
> trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c
> trunk/reactos/boot/freeldr/freeldr/windows/winldr.c
>
> Modified: trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo…
> ==============================================================================
> --- trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] Sun Jan 4 23:49:18 2015
> @@ -178,17 +178,40 @@
> HasSection = IniOpenSection(SectionName, &SectionId);
>
> UiDrawBackdrop();
> - UiDrawProgressBarCenter(1, 100, "Loading NT...");
> + UiDrawProgressBarCenter(1, 100, "Loading ReactOS Setup...");
>
> /* Read the system path is set in the .ini file */
> if (!HasSection ||
> !IniReadSettingByName(SectionId, "SystemPath", BootPath, sizeof(BootPath)))
> {
> + // MachDiskGetBootPath(BootPath, sizeof(BootPath));
> + // strcpy(BootPath, SectionName);
> + }
Why?
Can you please stop commenting out code without further explanations?
Either you comment out (better doing so with #if 0, for the record) and
you explain why you do so alongside in the code, for next developers
coming into the code, or you don't comment out.
So, just don't answer here, just commit an explanation ;-).
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Dear all,
ReactOS will be present this year at FOSDEM, in Brussels, on the 31st of
Jan & the 1st of Feb. More information at: https://fosdem.org/2015/
We will have a stand so that you can come and meet the people behind
ReactOS!
We will dispatch more information about the stand & its location when we
have them.
We're looking forward to seeing you at Brussels!
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
