I wanted to control the debian installation process on qemu once in a non X environment, being non root. I gave up, modelling myself compiling binary wrappers for suid root programs needed, such as mount something – in order to pass an argument. Well this is not even argument passing, it is more about altering the program. It is passing a boot argument. One needed to inject the argument in the boot loader and then rewrite the boot loader on a hard disk or a cd rom. But well there is no non root tooling for it. Even so, it could happen that the distributor – for security reasons – disables the suid opportunity for compiled binaries as it has already happened for scripts.
I will opt instead for testing the installing with root as a first way out for this cicle.
But for the long run I leave a testfunction for later solution…
So well the second guess from the discussion about controlling such a – packaging – tool chain from qemu invokation to oracle:
-it is a long signaling way, loads of code between.
-their are different j forms of redirects implicated: text and consoles (imagine what is that) redirects, and I have seen arguments redirects
-in other fields may be different the propagation of obfuscation, but in this case even though it is vast- it covers a great deal the history. The history of all humans alive. It comes enveloped with the history of security guide lines in computation – the answer why it is the common history of us all: it touches the os kernel, that is inherently unix, and certainly even though important: the hardware. Imagine! The hardware of the beginning era of personal computation.
Situation now :
A model for a user interface would be: You got some n log facilities around in the different k hierarchy levels and l chapters here and there. Lets classify these logs: sources. More over we have m some channels, programs that transport the logs.
One needed to have a little study about it.
Obviously there is no user interface design for such a thing, at all, maybe out of negligence. And if there is one, it is not favorable more a bullying hurdle run than designed between comfortable and healing, that is: something to juggle and to play with while eventually allowing to grow . One could think of a rather big confusion among any participants. The point is that they needed to afford a communication on those matters with each others then. Some channels are messed by security guide lines not any more understood, maybe. So if the speech is of a program concerning about that: it would have been in defunct state for the whole world for times.
Well, now, one could make a start of a „comprehensive user interface redirection chooser program„. As a pioneer one can propose a free software first step of a such designed functionality, right? Well then lets see if their might be opportunity!
So in the end: What does a user like us wish: any log source, put in by a jlkmn easy scheme to my log file, that is how the name of title is explained: Test_interface_redirect_all_available_qemu-debian_data_to_one_file_scalable_with_two_variables. So there should be a table exposed to the user, about which text sources he chooses out of all.
- Now diving into it: Which are „chapters“ on the signalling way, where as any stages are likely to mess the signal.
1) qemu – 2)grub- 3)linux -4)debian-installer -5)debian-packaging -6)xterm
- What should include such a background study on developing a user interface for logging affairs of „virtualized debian installation“?
-Lists of j1 sources (thousands?), sinks,j2 channels (hundreds?) to be completed,
-usage examples of each,
-historic and security concerns of each,
-completion state to be integrated in the prospect user interface
- A pointer should be debian-qa and there debian-jenkins mainly debian specific testing service.
Even though there is no competence between a qemuburo and debian-qa, they are in a similar perspective on such a user. I remember a speech about an overwhelming amount of log data to be delivered, and the lack of communication about choosing out of it imminent.
Question: Which is debian-qa’s practice/tactic/implementation and its theory/naming scheme/systematic for grasping among logging sources right now ? I could bet one could find an even more chaotic rather than communicate a promising comprehensive approach. No?
So how do they integrate logs?
qemu text output to a file
I would like to redirect any qemu text output to a file. (in a non X environment, connect to server from ssh and xterm)## Test 1:-display none -machine graphics=off -chardev stdio,logfile=qemu.log,id=output,signal=off \ -serial chardev:output qemu-system-x86_64 -version QEMU emulator version 2.6.0 (Debian 1:2.6+dfsg-3.1~bpo8+1) $qemu -hda $qcow2img -cdrom debian.iso -boot d -m $ram -display none -machine \ graphics=off -chardev stdio,logfile=qemu.log,id=output,signal=off \ -serial chardev:output #witho .graphics qemu-system-x86_64: Property '.graphics' not found #without -machine graphics=off $qemu -hda $qcow2img -cdrom debian.iso -boot d -m $ram -display none \ -chardev stdio,logfile=qemu.log,id=output,signal=off -serial chardev:output #it freezes the xterm, (pty, pts) #from another on pty kill -9 `ps ax|grep qemu|grep -v grep|cut -c-5` sleep 10; ls -l qemu.log -rw-r--r-- 1 t t 0 Nov 1 13:23 qemu.log