Santiago Bruno wrote: > On Wed, Dec 30, 2009 at 5:35 AM, Steven Shiau <[email protected]> wrote: > >> On 2009/12/29 上午 01:31, Santiago Bruno wrote: >> >>> 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. >>> >> Santiago, >> Due to an issue >> (https://sourceforge.net/projects/clonezilla/forums/forum/663168/topic/3499579) >> we have to change this again. Now by default the clonezilla command will be >> run on /dev/tty1 only. If you want to use /dev/ttyS0, you can assign >> "live-getty console=ttyS0,115200n81" and it will be run on /dev/ttyS0 only. >> For more info, please check the changelog: >> http://free.nchc.org.tw/clonezilla-live/experimental/ubuntu-based/ChangeLog-Clonezilla-live.txt >> or >> http://clonezilla.org/clonezilla-live/doc/fine-print.php?path=./99_Misc/00_live-initramfs-manual.doc#00_live-initramfs-manual.doc >> >> I believe this change should make things easier and better. If you have any >> thought or suggestion, please let us know. >> >> Please test it again and let us know the results. >> Thanks again. >> > > Well, I did a couple of tests with the new version and everything > seems to be working as I expected on the first time. So, the > ocs_live_run_tty boot parameter (at least in my case) isn't needed > anymore? I just need to add or remove "live-getty > console=ttyS0,115200n81" to redirect? That is what I did and it > worked. What is ocs_live_run_tty used for now? > Basically you are correct. In your case, ocs_live_run_tty is not required. However, if someone would like to run in tty2, for example, although it's very rare... ocs_live_run_tty provides such a possibility... And since we have implemented it, to keep it is not a bad idea I think. This makes Clonezilla live more flexible. :)
Steven. > Thanks, > > Santiago. > -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/clonezilla-live
