Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8252 > unrolled thread

remote OS install and boot issues for test PCs

Back to article view | Back to alt.os.development

Contents

  remote OS install and boot issues for test PCs "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-29 19:16 -0400
    Re: remote OS install and boot issues for test PCs "James Harris" <james.harris.1@gmail.com> - 2015-07-01 11:12 +0100
      Re: remote OS install and boot issues for test PCs "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-01 16:25 -0400
        Re: remote OS install and boot issues for test PCs "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-01 21:29 -0700
          Re: remote OS install and boot issues for test PCs "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-02 18:24 -0400
            Re: remote OS install and boot issues for test PCs "James Harris" <james.harris.1@gmail.com> - 2015-07-03 08:39 +0100
              Re: remote OS install and boot issues for test PCs "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 04:09 -0400
                Re: remote OS install and boot issues for test PCs "James Harris" <james.harris.1@gmail.com> - 2015-07-03 10:31 +0100
        Re: remote OS install and boot issues for test PCs "James Harris" <james.harris.1@gmail.com> - 2015-07-02 07:15 +0100
        Re: remote OS install and boot issues for test PCs "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2015-07-04 08:58 -0700
          Re: remote OS install and boot issues for test PCs "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-05 02:27 -0400

#8252 — remote OS install and boot issues for test PCs

Remote OS install and boot issues for test PCs.

In the BootProg thread, Alexei wrote:

> The idea was that small kernels could be booted off [of] the dev
> computer over the wire without the need to eject and insert a floppy.

The issue of remotely booting test machines was discussed here in the
past, perhaps with James.

The project below came up on Hackaday.  It's not for PC's, but may of
use for this situation.  It has an app which copies keystrokes and
mouse commands to a serial line.  On the receiving machine, they're
converted to HID commands to be received via USB.

app -> USB to serial adapter -> serial line -> serial to USB adapter

http://hackaday.com/2015/06/27/keymouserial-solves-your-raspberry-pi-keyboard-problems/

Also, another Hackaday article provides a USB PID for free.
http://hackaday.com/2015/04/03/usb-pids-for-all/

Hackaday
http://hackaday.com

The method above would probably be far cheaper than a commercial
IPKVM solution, but I'd think we'd want an Ethernet to USB solution
to support multiple test machines.

Otherwise, perhaps a compact flash memory card to IDE adapter card
could be modified to accept data via another computer or a
microcontroller.  Note, that's an IDE interface, not floppy.  A SATA
bridge adapter would be needed for SATA to convert the IDE adapter.
At this point in time, it seems to be difficult to location floppy
adapters, which could possibly be use for something like this.

At a minimum, I would think that at least one machine is needed
to receive bootable images from the internet, copy files to the
test machines' boot drive, boot it, reformat it, reset it if it
hangs, etc.  This, of course, would seem to require some custom
hardware too.

Another option would be a machine which "ping-pong" boots.  It
would still need some hardware to reset the machine if it hangs,
but otherwise would be self-contained.  The BIOS would boot a
modern OS first, like Linux, download an image to boot, write
the image to a drive, re-boot and boot the downloaded image.
The downloaded image would need to re-boot to return to Linux.
IIRC, there is a daisy-chain booting effect on Int 18h or 19h
for modern BIOSes, but not older BIOSes.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [next] | [standalone]

#8259

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x00llt13yfako5@localhost...
>
> Remote OS install and boot issues for test PCs.
>
> In the BootProg thread, Alexei wrote:
>
>> The idea was that small kernels could be booted off [of] the dev
>> computer over the wire without the need to eject and insert a floppy.
>
> The issue of remotely booting test machines was discussed here in the
> past, perhaps with James.
>
> The project below came up on Hackaday.  It's not for PC's, but may of
> use for this situation.  It has an app which copies keystrokes and
> mouse commands to a serial line.  On the receiving machine, they're
> converted to HID commands to be received via USB.
>
> app -> USB to serial adapter -> serial line -> serial to USB adapter
>
> http://hackaday.com/2015/06/27/keymouserial-solves-your-raspberry-pi-keyboard-problems/

I am not sure how that would help. You would still need to see the 
screen output to know what keystrokes to use.

...

> The method above would probably be far cheaper than a commercial
> IPKVM solution, but I'd think we'd want an Ethernet to USB solution
> to support multiple test machines.

I have a real (i.e. not IP) KVM at home. Apart from the monitor it takes 
PS/2 mouse and keyboard connectors (rather than USB) and supports up to 
eight machines. I was lucky in that I saw it going at a knock-down price 
complete with all cables. I think such things are considered old now and 
the company was probably selling old stock. Such devices may still be 
for sale, perhaps second hand.

> Otherwise, perhaps a compact flash memory card to IDE adapter card
> could be modified to accept data via another computer or a
> microcontroller.  Note, that's an IDE interface, not floppy.  A SATA
> bridge adapter would be needed for SATA to convert the IDE adapter.
> At this point in time, it seems to be difficult to location floppy
> adapters, which could possibly be use for something like this.
>
> At a minimum, I would think that at least one machine is needed
> to receive bootable images from the internet, copy files to the
> test machines' boot drive, boot it, reformat it, reset it if it
> hangs, etc.  This, of course, would seem to require some custom
> hardware too.

Why would you need to "receive" bootable images from the internet? Would 
you not make the bootable images yourself?

Any why would you need custom hardware? Perhaps you are thinking of 
doing something more than I had in mind.

I think I posted details of my PXE solution before.

> Another option would be a machine which "ping-pong" boots.  It
> would still need some hardware to reset the machine if it hangs,
> but otherwise would be self-contained.  The BIOS would boot a
> modern OS first, like Linux, download an image to boot, write
> the image to a drive, re-boot and boot the downloaded image.
> The downloaded image would need to re-boot to return to Linux.
> IIRC, there is a daisy-chain booting effect on Int 18h or 19h
> for modern BIOSes, but not older BIOSes.

You may be thinking of booting machines in remote locations but you 
still need to see the screen output, AFIACS.

I may not have understood what you are intending this to achieve.

James

[toc] | [prev] | [next] | [standalone]

#8262

On Wed, 01 Jul 2015 06:12:00 -0400, James Harris
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message  
> news:op.x00llt13yfako5@localhost...

>> Remote OS install and boot issues for test PCs.
>>
>> In the BootProg thread, Alexei wrote:
>>
>>> The idea was that small kernels could be booted off [of] the dev
>>> computer over the wire without the need to eject and insert a floppy.
>>
>> The issue of remotely booting test machines was discussed here in the
>> past, perhaps with James.
>>
>> The project below came up on Hackaday.  It's not for PC's, but may of
>> use for this situation.  It has an app which copies keystrokes and
>> mouse commands to a serial line.  On the receiving machine, they're
>> converted to HID commands to be received via USB.
>>
>> app -> USB to serial adapter -> serial line -> serial to USB adapter
>>
>> http://hackaday.com/2015/06/27/keymouserial-solves-your-raspberry-pi-keyboard-problems/
>
> I am not sure how that would help. You would still need to see
> the screen output to know what keystrokes to use.
>

I'm not sure if it's bi-directional or not.  That would be more useful.
Then, it would be just like a serial terminal.

>> Otherwise, perhaps a compact flash memory card to IDE adapter card
>> could be modified to accept data via another computer or a
>> microcontroller.  Note, that's an IDE interface, not floppy.  A SATA
>> bridge adapter would be needed for SATA to convert the IDE adapter.
>> At this point in time, it seems to be difficult to location floppy
>> adapters, which could possibly be use for something like this.
>>
>> At a minimum, I would think that at least one machine is needed
>> to receive bootable images from the internet, copy files to the
>> test machines' boot drive, boot it, reformat it, reset it if it
>> hangs, etc.  This, of course, would seem to require some custom
>> hardware too.
>
> Why would you need to "receive" bootable images from the internet?

E.g., hypothetical, James, Alex, Rod set up a test center of computers.
I.e., one of them is near the center but not living there, and the other
two are far away.  Ben, Steve, wolfgang, etc of course, are far away too.
Obviously, you can't use government mail to send and load the floppy.
What do you do?

> Would you not make the bootable images yourself?

s/not/"" ... ?

Of course, I would make my own images.  So would you, Alex, Ben, Steve,
wolfgang, whomever ...

> Any why would you need custom hardware? Perhaps you are thinking
> of doing something more than I had in mind.

"Any why"? ...  "[Anyway], why" or just "Why" here?

How would you intend to have a remote computer boot an image
and reset itself in preparation of another?  How do you intend
to reset it if it has hung, if you can't push the power button?
I.e., it probably requires some custom hardware, but I [or we]
would like to minimize that as much as possible to keep costs low.

> I think I posted details of my PXE solution before.

Sorry, I don't recall.  PXE could possibly be used with remote USB
keyboard and mouse. So, doesn't PXE have the issue of seeing the
screen too? ...

>> Another option would be a machine which "ping-pong" boots.  It
>> would still need some hardware to reset the machine if it hangs,
>> but otherwise would be self-contained.  The BIOS would boot a
>> modern OS first, like Linux, download an image to boot, write
>> the image to a drive, re-boot and boot the downloaded image.
>> The downloaded image would need to re-boot to return to Linux.
>> IIRC, there is a daisy-chain booting effect on Int 18h or 19h
>> for modern BIOSes, but not older BIOSes.
>
> You may be thinking of booting machines in remote locations but
> you still need to see the screen output, AFIACS.

s/AFIACS/AFAICS

There are options, but they all require extra hardware, AFAICT.

0) terminal software, but that would require USB or serial to
Ethernet hardware if the computers are on the internet, i.e., not
serial only

1) telnet, but the booted OS would need to support Ethernet which
is unlikely for some disk images, e.g., DOS or simple bootsector

2) video hardware to capture and view the screen remotely, perhaps
via IPKVM or video chat, e.g., Skype, or webpage that updates with
image of screen, or a method to send text screen data back to host,
or the test OS must redirect the screen text to disk image to be
copied out

I.e., I'm not sure how to fully control a remote PC remotely
without additional hardware of some sort.

A web interface would be "cool."  I.e., you go to a webpage, upload
an image, e.g., like Dropbox, Rapidshare, Filedriopper, etc, tell
the machine to boot the image, interact with command line via text
box.  There are already online Linux machines set up this way, but
you can't upload your own bootable image and execute it.

> I may not have understood what you are intending this to achieve.

Pretend that a computer of yours is locked in your best friend's closet
as a prank because he's a prick, but he connected to the internet.  You
want to use it, load a floppy image to boot, boot it, then re-boot it
to reset it to it's prior OS.  Is this possible?  Or, is some hardware
required to do so?

The BIOS BBS menu on newer PCs allows you to select a different OS and
drive to boot, but you need remote keyboard and video.  Int 19h or 18h
will let you boot another device too, IIRC.  You need some way to load
and write the image, i.e., an installed, more powerful OS, perhaps Linux
with terminal or telnet access.  You probably need a software method to
push the reset and power-down buttons.  You can't use ACPI via the more
powerful OS since you've booted a test OS and the test OS probably isn't
ACPI capable.  The test OS probably won't support Ethernet or telnet
either.  So, no connections to it or the screen.  Another option, which
would defeat the purpose of real-hardware testing, would be to use an
emulator on Linux.  Then, the host OS, Linux, would always be in control
of the machine and controllable remotely.


Rod Pemberton
P.S.  I still think you need to change your encoding.  It's not
hard wrapping lines per Usenet protocols.

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8264

On Wednesday, July 1, 2015 at 1:25:47 PM UTC-7, Rod Pemberton wrote:
> On Wed, 01 Jul 2015 06:12:00 -0400, James Harris
> <...@gmail.com> wrote:
...
> P.S.  I still think you need to change your encoding.  It's not
> hard wrapping lines per Usenet protocols.

It's not encoding as such. In Outlook Express there's an option in
"send mail/news" / "news sending format" / "plain text settings"
that tells how many characters per line to allow before forcing
wrapping to the next line. Either the value is too high or
something else isn't configured. The value should be no larger
than 76 or so. In contrast, if you use google groups to post, you
have to manually break the lines, which is what I sometimes forget
to do. And it doesn't tell you the cursor position.

Alex

[toc] | [prev] | [next] | [standalone]

#8269

On Thu, 02 Jul 2015 06:08:20 -0400, James Harris
<james.harris.1@gmail.com> wrote:
>> On Wednesday, July 1, 2015 at 1:25:47 PM UTC-7, Rod Pemberton wrote:
>>> On Wed, 01 Jul 2015 06:12:00 -0400, James Harris
>>> <...@gmail.com> wrote:

>>> P.S.  I still think you need to change your encoding.  It's not
>>> hard wrapping lines per Usenet protocols.

James, I've repeated your following paragraph twice.
Do they appear the same to you on your end?

> When I view my earlier posts of this thread in Outlook Express or Google  
> Groups it seems to me to have split long lines before sending them,  
> except for the URL which it has not split but OE has always worked that  
> way and such behaviour is a good thing because the URL remains clickable  
> without the reader having to copy and paste each section.

Those lines are not hard wrapped.  For unknown reasons, they have two
spaces at the end of the line prior to the carriage returns (ASCII CR LF).
Some newsreaders will automatically wrap or adjust them to the viewing
window.  Some newsreaders will only wrap them for the initial text and
not replied to text, etc.

E.g., here, a large viewing window will wrap the line first inbetween
"long lines", while a small viewing window will wrap the line first
inbetween "Google Groups".

> When I view my earlier posts of this thread in Outlook Express or Google
> Groups it seems to me to have split long lines before sending them,
> except for the URL which it has not split but OE has always worked that
> way and such behaviour is a good thing because the URL remains clickable
> without the reader having to copy and paste each section.

These lines are hard wrapped by me.  The two spaces have been deleted
and they now have only carriage returns at the end, because I hit
"return" on the keyboard at that point.

I.e., both a large and small viewing window will first wrap the line
first at "Google Groups", always.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8273

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x05263dbyfako5@localhost...
> On Thu, 02 Jul 2015 06:08:20 -0400, James Harris
> <james.harris.1@gmail.com> wrote:
>>> On Wednesday, July 1, 2015 at 1:25:47 PM UTC-7, Rod Pemberton wrote:

...

>>>> P.S.  I still think you need to change your encoding.  It's not
>>>> hard wrapping lines per Usenet protocols.
>
> James, I've repeated your following paragraph twice.
> Do they appear the same to you on your end?

Yes, they do, and that applies even if I make the viewing window wider 
or narrower. They still split at essentially the same points.

>> When I view my earlier posts of this thread in Outlook Express or 
>> Google  Groups it seems to me to have split long lines before sending 
>> them,  except for the URL which it has not split but OE has always 
>> worked that  way and such behaviour is a good thing because the URL 
>> remains clickable  without the reader having to copy and paste each 
>> section.
>
> Those lines are not hard wrapped.  For unknown reasons, they have two
> spaces at the end of the line prior to the carriage returns (ASCII CR 
> LF).
> Some newsreaders will automatically wrap or adjust them to the viewing
> window.  Some newsreaders will only wrap them for the initial text and
> not replied to text, etc.
>
> E.g., here, a large viewing window will wrap the line first inbetween
> "long lines", while a small viewing window will wrap the line first
> inbetween "Google Groups".
>
>> When I view my earlier posts of this thread in Outlook Express or 
>> Google
>> Groups it seems to me to have split long lines before sending them,
>> except for the URL which it has not split but OE has always worked 
>> that
>> way and such behaviour is a good thing because the URL remains 
>> clickable
>> without the reader having to copy and paste each section.
>
> These lines are hard wrapped by me.  The two spaces have been deleted
> and they now have only carriage returns at the end, because I hit
> "return" on the keyboard at that point.
>
> I.e., both a large and small viewing window will first wrap the line
> first at "Google Groups", always.

What you describe doesn't seem too big a problem. I have left the full 
content above in case it is relevant in the way this reply is laid out.

James

[toc] | [prev] | [next] | [standalone]

#8275

On Fri, 03 Jul 2015 03:39:32 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> What you describe doesn't seem too big a problem.

It's a problem for anyone on Usenet.  The lines don't come
across as wrapped, but continue on forever ...

It mostly seems to be from people with gmail accounts.
However, it's my understanding you're not using Google Groups,
but posting via Eternal September.  This makes me believe it's
an encoding option option on your end, or perhaps a setting
as Alexei said.  I usually don't take much issue with this
except to tell people they've got an issue, but I was hoping
that in your case, I could help.  If it's too much trouble
to track down and fix, forget about it.


RP

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8277

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x06t97fjyfako5@localhost...
> On Fri, 03 Jul 2015 03:39:32 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> What you describe doesn't seem too big a problem.
>
> It's a problem for anyone on Usenet.

What problem does it cause?

> The lines don't come
> across as wrapped, but continue on forever ...

Don't they get wrapped when you view them?

Do you define 100 characters as "forever"...?

> It mostly seems to be from people with gmail accounts.

If I understand your complaint Google postings have done this for years, 
*and* they added quoted printable which ISTM is far worse.

James

[toc] | [prev] | [next] | [standalone]

#8265

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x0321kfiyfako5@localhost...
> On Wed, 01 Jul 2015 06:12:00 -0400, James Harris
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
>> news:op.x00llt13yfako5@localhost...
>
>>> Remote OS install and boot issues for test PCs.

...

>>> app -> USB to serial adapter -> serial line -> serial to USB adapter
>>>
>>> http://hackaday.com/2015/06/27/keymouserial-solves-your-raspberry-pi-keyboard-problems/
>>
>> I am not sure how that would help. You would still need to see
>> the screen output to know what keystrokes to use.
>>
>
> I'm not sure if it's bi-directional or not.  That would be more 
> useful.
> Then, it would be just like a serial terminal.

Only if the bare metal machine acted as a serial terminal. Perhaps they 
should. I don't think they do.

...

>>> At a minimum, I would think that at least one machine is needed
>>> to receive bootable images from the internet, copy files to the
>>> test machines' boot drive, boot it, reformat it, reset it if it
>>> hangs, etc.  This, of course, would seem to require some custom
>>> hardware too.
>>
>> Why would you need to "receive" bootable images from the internet?
>
> E.g., hypothetical, James, Alex, Rod set up a test center of 
> computers.
> I.e., one of them is near the center but not living there, and the 
> other
> two are far away.  Ben, Steve, wolfgang, etc of course, are far away 
> too.
> Obviously, you can't use government mail to send and load the floppy.
> What do you do?

So you are thinking of us getting remote access to a farm of test 
machines?

>> Would you not make the bootable images yourself?
>
> s/not/"" ... ?
>
> Of course, I would make my own images.  So would you, Alex, Ben, 
> Steve,
> wolfgang, whomever ...
>
>> Any why would you need custom hardware? Perhaps you are thinking
>> of doing something more than I had in mind.
>
> "Any why"? ...  "[Anyway], why" or just "Why" here?

Sorry. I think that should have been "And why".

> How would you intend to have a remote computer boot an image
> and reset itself in preparation of another?  How do you intend
> to reset it if it has hung, if you can't push the power button?
> I.e., it probably requires some custom hardware, but I [or we]
> would like to minimize that as much as possible to keep costs low.
>
>> I think I posted details of my PXE solution before.
>
> Sorry, I don't recall.  PXE could possibly be used with remote USB
> keyboard and mouse. So, doesn't PXE have the issue of seeing the
> screen too? ...

Yes. I didn't know what you were trying to achieve.

>>> Another option would be a machine which "ping-pong" boots.  It
>>> would still need some hardware to reset the machine if it hangs,
>>> but otherwise would be self-contained.  The BIOS would boot a
>>> modern OS first, like Linux, download an image to boot, write
>>> the image to a drive, re-boot and boot the downloaded image.
>>> The downloaded image would need to re-boot to return to Linux.
>>> IIRC, there is a daisy-chain booting effect on Int 18h or 19h
>>> for modern BIOSes, but not older BIOSes.
>>
>> You may be thinking of booting machines in remote locations but
>> you still need to see the screen output, AFIACS.
>
> s/AFIACS/AFAICS
>
> There are options, but they all require extra hardware, AFAICT.
>
> 0) terminal software, but that would require USB or serial to
> Ethernet hardware if the computers are on the internet, i.e., not
> serial only
>
> 1) telnet, but the booted OS would need to support Ethernet which
> is unlikely for some disk images, e.g., DOS or simple bootsector
>
> 2) video hardware to capture and view the screen remotely, perhaps
> via IPKVM or video chat, e.g., Skype, or webpage that updates with
> image of screen, or a method to send text screen data back to host,
> or the test OS must redirect the screen text to disk image to be
> copied out
>
> I.e., I'm not sure how to fully control a remote PC remotely
> without additional hardware of some sort.

To "fully control" would need hardware, if only for power switching, but 
for the software part:

3) A hypervisor https://en.wikipedia.org/wiki/Hypervisor.

4) A boot manager.

Perhaps either could be used to load images from a remote user.

> A web interface would be "cool."  I.e., you go to a webpage, upload
> an image, e.g., like Dropbox, Rapidshare, Filedriopper, etc, tell
> the machine to boot the image, interact with command line via text
> box.  There are already online Linux machines set up this way, but
> you can't upload your own bootable image and execute it.

Understood. Yes, that would be good.

James

[toc] | [prev] | [next] | [standalone]

#8294

On Wednesday, July 1, 2015 at 3:25:47 PM UTC-5, Rod Pemberton wrote:
> On Wed, 01 Jul 2015 06:12:00 -0400, James Harris
> <james.harris.1@gmail.com> wrote:
> > "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message  
> > news:op.x00llt13yfako5@localhost...
> 
> >> Remote OS install and boot issues for test PCs.
> >>
> >> In the BootProg thread, Alexei wrote:
> >>
> >>> The idea was that small kernels could be booted off [of] the dev
> >>> computer over the wire without the need to eject and insert a floppy.
> >>
> >> The issue of remotely booting test machines was discussed here in the
> >> past, perhaps with James.
> >>
> >> The project below came up on Hackaday.  It's not for PC's, but may of
> >> use for this situation.  It has an app which copies keystrokes and
> >> mouse commands to a serial line.  On the receiving machine, they're
> >> converted to HID commands to be received via USB.
> >>
> >> app -> USB to serial adapter -> serial line -> serial to USB adapter
> >>
> >> http://hackaday.com/2015/06/27/keymouserial-solves-your-raspberry-pi-keyboard-problems/
> >
> > I am not sure how that would help. You would still need to see
> > the screen output to know what keystrokes to use.
> >
> 
> I'm not sure if it's bi-directional or not.  That would be more useful.
> Then, it would be just like a serial terminal.
> 
> >> Otherwise, perhaps a compact flash memory card to IDE adapter card
> >> could be modified to accept data via another computer or a
> >> microcontroller.  Note, that's an IDE interface, not floppy.  A SATA
> >> bridge adapter would be needed for SATA to convert the IDE adapter.
> >> At this point in time, it seems to be difficult to location floppy
> >> adapters, which could possibly be use for something like this.
> >>
> >> At a minimum, I would think that at least one machine is needed
> >> to receive bootable images from the internet, copy files to the
> >> test machines' boot drive, boot it, reformat it, reset it if it
> >> hangs, etc.  This, of course, would seem to require some custom
> >> hardware too.
> >
> > Why would you need to "receive" bootable images from the internet?
> 
> E.g., hypothetical, James, Alex, Rod set up a test center of computers.
> I.e., one of them is near the center but not living there, and the other
> two are far away.  Ben, Steve, wolfgang, etc of course, are far away too.
> Obviously, you can't use government mail to send and load the floppy.
> What do you do?
> 

For this test center of computers..

Modify grub to halt the boot and listen on some dedicated ip port for a remote
client to connect, authenticate, and pass the test image, to which
grub-netboot would install and boot and provide a dedicated scratch volume
for a file system.  A telnet client should suffice to connect to the test
computer and pass the test image to grub-netboot.  Not too different from
telnetting to cp/m-80 simulator to run cpm.

I'm not sure on how to reboot afterward, or on a 'hang'..

Q. What happens on a execution hang?

ISTM there are two types of hangs, one in which ctrl-alt-del proceeds to
reboot, and one which won't - requiring power-off/power-on.

Q. Does the timer int freeze is such cases? -if not, perhaps a substitute
handler can be installed to catch a hang by way of time-out.

The grub-netboot idea seems not to need special hardware, all done in software,
except perhaps the addition of a second network card for use by the 'guest OS'.

Each test computer has its own IP address, and should not answer to a client
request while already busy.

Steve

> > Would you not make the bootable images yourself?
> 
> s/not/"" ... ?
> 
> Of course, I would make my own images.  So would you, Alex, Ben, Steve,
> wolfgang, whomever ...
> 
> > Any why would you need custom hardware? Perhaps you are thinking
> > of doing something more than I had in mind.
> 
> "Any why"? ...  "[Anyway], why" or just "Why" here?
> 
> How would you intend to have a remote computer boot an image
> and reset itself in preparation of another?  How do you intend
> to reset it if it has hung, if you can't push the power button?
> I.e., it probably requires some custom hardware, but I [or we]
> would like to minimize that as much as possible to keep costs low.
> 
> > I think I posted details of my PXE solution before.
> 
> Sorry, I don't recall.  PXE could possibly be used with remote USB
> keyboard and mouse. So, doesn't PXE have the issue of seeing the
> screen too? ...
> 
> >> Another option would be a machine which "ping-pong" boots.  It
> >> would still need some hardware to reset the machine if it hangs,
> >> but otherwise would be self-contained.  The BIOS would boot a
> >> modern OS first, like Linux, download an image to boot, write
> >> the image to a drive, re-boot and boot the downloaded image.
> >> The downloaded image would need to re-boot to return to Linux.
> >> IIRC, there is a daisy-chain booting effect on Int 18h or 19h
> >> for modern BIOSes, but not older BIOSes.
> >
> > You may be thinking of booting machines in remote locations but
> > you still need to see the screen output, AFIACS.
> 
> s/AFIACS/AFAICS
> 
> There are options, but they all require extra hardware, AFAICT.
> 
> 0) terminal software, but that would require USB or serial to
> Ethernet hardware if the computers are on the internet, i.e., not
> serial only
> 
> 1) telnet, but the booted OS would need to support Ethernet which
> is unlikely for some disk images, e.g., DOS or simple bootsector
> 
> 2) video hardware to capture and view the screen remotely, perhaps
> via IPKVM or video chat, e.g., Skype, or webpage that updates with
> image of screen, or a method to send text screen data back to host,
> or the test OS must redirect the screen text to disk image to be
> copied out
> 
> I.e., I'm not sure how to fully control a remote PC remotely
> without additional hardware of some sort.
> 
> A web interface would be "cool."  I.e., you go to a webpage, upload
> an image, e.g., like Dropbox, Rapidshare, Filedriopper, etc, tell
> the machine to boot the image, interact with command line via text
> box.  There are already online Linux machines set up this way, but
> you can't upload your own bootable image and execute it.
> 
> > I may not have understood what you are intending this to achieve.
> 
> Pretend that a computer of yours is locked in your best friend's closet
> as a prank because he's a prick, but he connected to the internet.  You
> want to use it, load a floppy image to boot, boot it, then re-boot it
> to reset it to it's prior OS.  Is this possible?  Or, is some hardware
> required to do so?
> 
> The BIOS BBS menu on newer PCs allows you to select a different OS and
> drive to boot, but you need remote keyboard and video.  Int 19h or 18h
> will let you boot another device too, IIRC.  You need some way to load
> and write the image, i.e., an installed, more powerful OS, perhaps Linux
> with terminal or telnet access.  You probably need a software method to
> push the reset and power-down buttons.  You can't use ACPI via the more
> powerful OS since you've booted a test OS and the test OS probably isn't
> ACPI capable.  The test OS probably won't support Ethernet or telnet
> either.  So, no connections to it or the screen.  Another option, which
> would defeat the purpose of real-hardware testing, would be to use an
> emulator on Linux.  Then, the host OS, Linux, would always be in control
> of the machine and controllable remotely.
> 
> 
> Rod Pemberton
> P.S.  I still think you need to change your encoding.  It's not
> hard wrapping lines per Usenet protocols.
> 
> -- 
> Tolerance and socialism attracts intolerance and terrorism.  See:
> France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8296

On Sat, 04 Jul 2015 11:58:35 -0400, s_dubrovich@yahoo.com  
<s_dubrovich@yahoo.com> wrote:

> For this test center of computers..
>
> Modify grub to halt the boot and listen on some dedicated ip port for a
> remote client to connect, authenticate, and pass the test image, to which
> grub-netboot would install and boot and provide a dedicated scratch  
> volume
> for a file system.  A telnet client should suffice to connect to the test
> computer and pass the test image to grub-netboot.  Not too different from
> telnetting to cp/m-80 simulator to run cpm.

 From a very quick webpage skim, it seems like grub-netboot will pull files
via tftp.  It just needs a dedicated IP address set up to pull from ...


Rod Pemberton
P.S. I guess Usenet is truly dead when Steve starts top-posting. ;-)

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web