Santiago Bruno wrote:
> On Wed, Dec 23, 2009 at 11:59 AM, Steven Shiau <ste...@nchc.org.tw> wrote:
>>
>> Santiago Bruno wrote:
>>> On Mon, Dec 14, 2009 at 4:47 AM, Steven Shiau <ste...@nchc.org.tw> wrote:
>>>
>>>> Hi,
>>>> Thanks for the bug reports. I reply your question sin the following.
>>>>
>>>> Santiago Bruno wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to use Clonezilla live in a machine that will boot using
>>>>> PXE through its interface eth1. This machine can redirect the console
>>>>> using Serial over Lan with its own hardware and is configured to do
>>>>> so.
>>>>>
>>>>> I added live-getty and console=ttyS0,115200n8 to the kernel command
>>>>> line but I'm having a strange problem.
>>>>>
>>>>> When I'm looking at the serial console, after booting clonezilla,
>>>>> there is output at the console as expected, but some output also goes
>>>>> to the VGA. And it's not the same output. Is like there are two
>>>>> different clonezilla instances in tty1 and ttyS0. They even start
>>>>> cloning the same partitions at diferent times messing all up. At the
>>>>> end one can go to the command line on both consoles and evidently they
>>>>> are two different processes.
>>>>>
>>>> How did you configure your clonezilla live ? Please show us the config
>>>> files, e.g. syslinux.cfg... So it's easier for me to reproduce the
>>>> problem
>>>> then we can fix this problem.
>>>>
>>> Well, I'm using some custom scripts, but now I reduced the
>>> configuration to try to use a script that does not exists to see if
>>> the problem still happened so it could be easier to reproduce.
>>>
>>> The pxe file for the machine would be like this:
>>>
>>> default Clonezilla
>>> label Clonezilla
>>> kernel /clonezilla/vmlinuz
>>> append initrd=/clonezilla/initrd.img boot=live live-getty
>>> console=ttyS0,115200n8 union=aufs noswap noprompt nosplash
>>> live-netdev="eth1"
>>> fetch=tftp://<SERVER_IP>/clonezilla/filesystem.squashfs
>>> ocs_live_keymap="NONE" ocs_live_batch="yes" ocs_lang="en_US.UTF-8"
>>> ocs_live_run="/blablablabla"
>>>
>>> and what happens when booting is the following.
>>>
>>> VGA starts displaying the pxe boot, "Decompressing Linux..."
>>> decompressing the initrd, and the last lines are
>>> "Ready
>>> Probing EDD (...) ok"
>>>
>>> It stops there, and then, text starts coming out through ttyS0
>>> instead. squashfs is decompressed, init starts, I can see that it
>>> tries to set up eth0 through dhcp because I see some "DHCPDISCOVER..."
>>> lines until it times out.
>>> Then I think it sets up eth1 very fast and then the problem starts.
>>> I think it is when the ocs scripts begin executing.
>>> The VGA changes from the typical console text to another font,
>>> probably a framebuffer, and some scripts begin executing both in tty1
>>> and ttyS0
>>> obviously they fail inmediately because there is no blablablabla
>>> script, but I get the prompt to select what to do next in both
>>> terminals and they are different processes.
>>> If I type "tty" one gives /dev/tty1 and the other /dev/ttyS0.
>>> I would expect that everything happens in ttyS0 if I specified
>>> console=ttyS0 on the command line, or to have an option to do that. Is
>>> it possible? I would expect in that case to keep tty1 blocked or in a
>>> login prompt.
>>>
>>>
>> Yes. Here I think the best solution is in your customized script, add one
>> line in the beginning:
>> ================================
>> [ "$(tty)" != "/dev/ttyS0" ] && exit 1
>> ================================
>>
>> Then the rest of your script will only be run in the /dev/ttyS0.
>>
>> Hope this helps.
> 
> Yes, I considered implementing exactly that workaround. The only
> problem is that I will be using the script as part of a bigger system
> with an user interface where the user may choose to redirect the
> output or not. So I will have two different customized scripts, one
> for redirecting and another for not redirecting, and selecting which
> script to use through the generated pxe config file.
> I thought of reporting the problem so I had to work less :P
> But this should work.
> 
> Thank you!
> 
> Santiago.
Another possibility is we can implement another ocs option to force 
$ocs_live_run to be run in specific tty, e.g. ttyS0. Now it will be run 
in tty1 and ttyS0.
E.g. with boot parameter
ocs_live_tty="/dev/ttyS0"
then the $ocs_live_run will be run in ttyS0 only. Not in tty1.

This should work. Or maybe you have better idea?

Regards,
Steven.

-- 
Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 1024D/9762755A
Fingerprint: A2A1 08B7 C22C 3D06 34DB  F4BC 08B3 E3D7 9762 755A

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Clonezilla-live mailing list
Clonezilla-live@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clonezilla-live

Reply via email to