On Sat, Dec 26, 2009 at 8:24 AM, Steven Shiau <[email protected]> wrote: > > > Santiago Bruno wrote: >> >> On Thu, Dec 24, 2009 at 4:46 AM, Steven Shiau <[email protected]> wrote: >> >>> >>> Santiago Bruno wrote: >>> >>>> >>>> On Wed, Dec 23, 2009 at 11:59 AM, Steven Shiau <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Santiago Bruno wrote: >>>>> >>>>>> >>>>>> On Mon, Dec 14, 2009 at 4:47 AM, Steven Shiau <[email protected]> >>>>>> 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? >>> >> >> That would be something nice to have. I have no other idea. But I >> don´t know how complicated it will be to implement it. I can live with >> the workaround you suggested ;) >> But let me know if you implement it in some future release or if I can >> help in some way, like testing. >> >> Cheers, >> >> Santiago. >> > > I have uploaded Clonezilla live 1.2.3-21 in the testing branch. A boot > parameter "ocs_live_run_tty" was added for this purpose. Please refer to > http://clonezilla.org/clonezilla-live/doc/fine-print.php?path=./99_Misc/00_live-initramfs-manual.doc#00_live-initramfs-manual.doc > for how to use it. > > Please let us know the results if you test that. > Thanks.
I've just integrated this new release of clonezilla to my system and I'm using the new boot parameter when console redirection is selected. I did some tests redirecting and not redirecting and it is working as I expected on the first time. Everything looks good so far. I will let you know if I find any problem later but it seems to be working great! Thanks for your work! Santiago. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/clonezilla-live
