Setting up virtual terminals in initrd? (never mind)
- Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
Setting up virtual terminals in initrd? (never mind)
I'm trying to set up virtual terminals in initrd. As in, if I boot with pfix=rdsh, I'll have access to them. I've added getty, id, autologinroot, chvt, tty, the needed libraries, and inittab, shadow, gshadow, and passwd. I might have added a couple other things I don't remember at the moment.
Using this line:
(/sbin/getty -n -l /bin/autologinroot 38400 tty1)&
makes error messages like "cannot find gn, cannot find nu" (I'll write down the exact message soon). Runny tty shows me that sometimes it thinks I'm using /dev/console, and sometimes /dev/tty1. The one it thinks I'm in determines which history I see when I hit the up key.
The same thing happens if I use tty2 instead of tty1. If I do both (run the command twice), it switches between /dev/console, /dev/tty1, and /dev/tty2. Everything else still behaves the same, with /dev/tty2 still sharing f1.
Also, the alt-f1 and alt-f1 combos don't do anything. If I try chvt 2 it gives me a blank screen (no prompt, accepts no input). From then on, I can use the alt-f1 and alt-f2 combos to traverse between the "working" terminal on f1 and the blank one on f2.
Any ideas or advice about getting it working correctly? I'm guessing I'm either still missing some app or I'm not starting it the right way.
Using this line:
(/sbin/getty -n -l /bin/autologinroot 38400 tty1)&
makes error messages like "cannot find gn, cannot find nu" (I'll write down the exact message soon). Runny tty shows me that sometimes it thinks I'm using /dev/console, and sometimes /dev/tty1. The one it thinks I'm in determines which history I see when I hit the up key.
The same thing happens if I use tty2 instead of tty1. If I do both (run the command twice), it switches between /dev/console, /dev/tty1, and /dev/tty2. Everything else still behaves the same, with /dev/tty2 still sharing f1.
Also, the alt-f1 and alt-f1 combos don't do anything. If I try chvt 2 it gives me a blank screen (no prompt, accepts no input). From then on, I can use the alt-f1 and alt-f2 combos to traverse between the "working" terminal on f1 and the blank one on f2.
Any ideas or advice about getting it working correctly? I'm guessing I'm either still missing some app or I'm not starting it the right way.
Last edited by Pizzasgood on Mon 21 May 2007, 22:39, edited 1 time in total.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
- Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
Okay, the correct error message:
Also, when I don't try to start the terminals in the background, they don't fight for control. Instead, they stack on top of eachother within the same screen. If I start tty1 first like that, then try to start tty2 in parallel, it goes into the background and pauses with this message:
[1]+ stopped (tty output) (/sbin/getty -n -l /bin/autologinroot 38400 tty2)
So from what I can tell, the problem is that I can't seem to start up a new screen for tty2 to use.
Code: Select all
warning: cannot change to home directory
<date and time> login[1538]: root login on 'tty1'
gn: applet not found
un: applet not found
u: applet not found
[: 14: unknown operand
un: applet not found
[1]+ stopped (tty output) (/sbin/getty -n -l /bin/autologinroot 38400 tty2)
So from what I can tell, the problem is that I can't seem to start up a new screen for tty2 to use.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
applet means an applet in busybox ... for example:
# busybox echo 'hello'
hello
# busybox echoxxx 'hello'
echoxxx: applet not found
#
if "echo" is a symlink to busybox, then to busybox, executing "echo" is the same as executing "busybox echo"
[ is usually a symlink to "test", which is probably a symlink to busybox
when Linux boots, the kernel starts executing /sbin/init , which uses /etc/inittab ... i might be wrong, but i would think if inittab is setup correctly you would have access to the vts ... you shouldn't need autologin, you would just press ctrl+alt+F2 or alt+F2 or whatever, type "root" and press enter for the password ... i don't really know, i haven't tried switching vts in the initrd/initramfs
# busybox echo 'hello'
hello
# busybox echoxxx 'hello'
echoxxx: applet not found
#
if "echo" is a symlink to busybox, then to busybox, executing "echo" is the same as executing "busybox echo"
[ is usually a symlink to "test", which is probably a symlink to busybox
when Linux boots, the kernel starts executing /sbin/init , which uses /etc/inittab ... i might be wrong, but i would think if inittab is setup correctly you would have access to the vts ... you shouldn't need autologin, you would just press ctrl+alt+F2 or alt+F2 or whatever, type "root" and press enter for the password ... i don't really know, i haven't tried switching vts in the initrd/initramfs
Thnx - (expected as much, Damn crippled B/B)
But isn't (# busybox) a command - same as typing (#bash) ?
AFAIK (Echo) is also a command not a symlink (as you know, often used to test statements, print to screen ( ala "printf")
Unless I misinterpreted, & you were referring only to the "["
reserved function (ala bash)
As said, any non-defined letter or symbol is an unrecognised command function
Login/logout definitions are pre-defined for Ea user
Once booted into kernel. O/System profile sets usemodes/services
"CTRL" is redundant UNLESS switching from running GUI desktop > Pre-defined "hot-key" mapping is Alt+F_xxn
XDM is the normal login function, but ~/.xinitrc overides /etc/skel profile
XDM
, Plse see: http://www.tuxfiles.org/linuxhelp/shell.html
Slackware has an alterntate solution, it's utility "screen"
Isn't switching terminal in text mode a function of defined keymapping ?
(Xmodmap Xkbmap < Xresources run by xinit)
X resources are a major PITA
Here's hoping Pizza_toppings are more to our tastebuds
But isn't (# busybox) a command - same as typing (#bash) ?
AFAIK (Echo) is also a command not a symlink (as you know, often used to test statements, print to screen ( ala "printf")
Unless I misinterpreted, & you were referring only to the "["
reserved function (ala bash)
As said, any non-defined letter or symbol is an unrecognised command function
Did you mean the "respawn" statement in inittab ?i would think if inittab is setup correctly you would have access to the vts
Correct- unless a variation to utility "sandbox" was used (not in Puppy)... you shouldn't need autologin, you would just press ctrl+alt+F2 or alt+F2 or
Login/logout definitions are pre-defined for Ea user
Once booted into kernel. O/System profile sets usemodes/services
"CTRL" is redundant UNLESS switching from running GUI desktop > Pre-defined "hot-key" mapping is Alt+F_xxn
XDM is the normal login function, but ~/.xinitrc overides /etc/skel profile
XDM
, Plse see: http://www.tuxfiles.org/linuxhelp/shell.html
Slackware has an alterntate solution, it's utility "screen"
Isn't switching terminal in text mode a function of defined keymapping ?
(Xmodmap Xkbmap < Xresources run by xinit)
X resources are a major PITA
Here's hoping Pizza_toppings are more to our tastebuds
- Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
Okay, I cleaned up some of my problems. [ was symlinked directly to busybox, not to text. Also, I didn't realize that id wasn't included in the particular busybox in initrd. Neither was tty, but I was accidentally linking that to the one in /pup_ro2/bin/.
So, after pointing those links to the correct places, I instead get errors because the id applet can't translate my uid and gid into text. Both of them are zero, which should correspond to root. I have already added /etc/group and /etc/passwd.
Other than a different error message, it still behaves the same
Another thing I've noticed is that when I'm dropped onto the commandline, the last line above my prompt is this:
sh: can't access tty; job control turned off
As for the 'openvt' command, thanks. That won't help me at the moment, but it does solve the next headache I'd have after I get the virtual terminals working. It's also a nice alternative to backgrounding the getty command. Good stuff.
So, after pointing those links to the correct places, I instead get errors because the id applet can't translate my uid and gid into text. Both of them are zero, which should correspond to root. I have already added /etc/group and /etc/passwd.
Other than a different error message, it still behaves the same
Another thing I've noticed is that when I'm dropped onto the commandline, the last line above my prompt is this:
sh: can't access tty; job control turned off
That's what I was hoping, but it doesn't seem to be the case unless the above error is the culperit. Actually, now that I think about it, that sounds about right. I'm going to toss that error into google and see what I can glean.when Linux boots, the kernel starts executing /sbin/init , which uses /etc/inittab ... i might be wrong, but i would think if inittab is setup correctly you would have access to the vts
As for the 'openvt' command, thanks. That won't help me at the moment, but it does solve the next headache I'd have after I get the virtual terminals working. It's also a nice alternative to backgrounding the getty command. Good stuff.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
Looks like you have Terminated the CLI parsing at a prior point in scriptsthe last line above my prompt is this:
(Set debug points or run scripts through a trace utility)
/etc/inittab is not needed - AFAIK , it is a SysV run level initiate standard
Used after the (initrd ram boot process) has been handed off to the O/System kernel which then runs (initiate > the "mother" of run processes)
Dropped from what -dropped onto the commandline
a GUI login shell ?
As mentioned , then the apropo x-server is still running
Do you have top or ps available ?
Puppy is a little different from most Linux distros, because it uses busybox, and busybox does behave a bit strangely sometimes
i'm pretty sure (well, a little bit sure) that busybox's init applet does use /etc/inittab
i think what happens is that Grub loads the kernel (vmlinuz) in ram, and initrd.gz gets loaded in ram ... the kernel executes some init code, then starts executing the code in the init executable, which for an initial ram drive is by default in /sbin ... in the initial ram drive, init is a script written by Barry, but i think it eventually executes busybox init, which is the init applet built into busybox, which i think does use /etc/inittab ... inittab starts the terminal shell which starts the autologin program (otherwise you would have to type in an id and a password) ... the shell automatically executes the code in /etc/profile, which eventually executes xwin, which starts X windows
busybox is one executable program which contains applets that do the work of a number of other programs (the Gnu utilitles, like ls, echo, free, head, tail, kill, etc etc etc)
if you rename busybox to "ls", it will behave like the ls program ... if you rename busybox to "echo", it will behave like the echo program ... if you rename busybox to "kill" it will behave like the kill program
there isn't much point in doing that ... but if you have one copy of busybox, and make a number of symlinks to busybox which are named "echo", "free", "head", "tail", "kill", etc etc etc, that is useful, because each symlink will behave as if it was a copy of busybox renamed ... so you get a number of programs that take up almost no space in the file system, because symlinks take almost no space in the file system
it's simple, and effective, and saves a bit of space ... but the busybox replacements do not behave exactly like the programs they replace ... they have fewer options, and also, there may be bugs (for example, pidof, killall, which, don't work properly if there is a file or dir in the working dir with the same name as the executable you are trying to process)
anyway, i may be wrong, but i think Puppy eventually uses the init executable applet in busybox, and i think busybox does use /etc/inittab when it's init applet executes
i'm pretty sure (well, a little bit sure) that busybox's init applet does use /etc/inittab
i think what happens is that Grub loads the kernel (vmlinuz) in ram, and initrd.gz gets loaded in ram ... the kernel executes some init code, then starts executing the code in the init executable, which for an initial ram drive is by default in /sbin ... in the initial ram drive, init is a script written by Barry, but i think it eventually executes busybox init, which is the init applet built into busybox, which i think does use /etc/inittab ... inittab starts the terminal shell which starts the autologin program (otherwise you would have to type in an id and a password) ... the shell automatically executes the code in /etc/profile, which eventually executes xwin, which starts X windows
busybox is one executable program which contains applets that do the work of a number of other programs (the Gnu utilitles, like ls, echo, free, head, tail, kill, etc etc etc)
if you rename busybox to "ls", it will behave like the ls program ... if you rename busybox to "echo", it will behave like the echo program ... if you rename busybox to "kill" it will behave like the kill program
there isn't much point in doing that ... but if you have one copy of busybox, and make a number of symlinks to busybox which are named "echo", "free", "head", "tail", "kill", etc etc etc, that is useful, because each symlink will behave as if it was a copy of busybox renamed ... so you get a number of programs that take up almost no space in the file system, because symlinks take almost no space in the file system
it's simple, and effective, and saves a bit of space ... but the busybox replacements do not behave exactly like the programs they replace ... they have fewer options, and also, there may be bugs (for example, pidof, killall, which, don't work properly if there is a file or dir in the working dir with the same name as the executable you are trying to process)
anyway, i may be wrong, but i think Puppy eventually uses the init executable applet in busybox, and i think busybox does use /etc/inittab when it's init applet executes
Thnx for Puppy /B-B "Bkgrnd
('cept for the "sure I'm sure - but not sure of that )
> It was harder to parse than Puppy init_xx
It was mentioned B4 - WHY does Puppy use "own" wizardy names that are modified true CLI functions
Profiled Path environment would get very confused, if I.E. a file named 'bash were only a file, Esp. if the recursive IOCTL seek finds it first.
Inittab doesn't control virtual terminal keymap behaviour, nor switching
(unless of course, Puppy has included own scripted "work-arounds" there)
Which were noted by BK B4 > as: Not needed (if all initiate services were pre-defined, since no alternate run levels)
BUSYBOX
In the "pfix" mode, 1<> 2 VTs would be all really needed IF
the desired utilities were available without the full O/System boot process being completed ?
AFAICT , It is an inter-active "test" mode - without more functional Bash or a text editor, that is sort've crippled:
> Defeats intent of having it in 1st place.
.
('cept for the "sure I'm sure - but not sure of that )
> It was harder to parse than Puppy init_xx
Better rethink that statement.bugs (for example,
It was mentioned B4 - WHY does Puppy use "own" wizardy names that are modified true CLI functions
Profiled Path environment would get very confused, if I.E. a file named 'bash were only a file, Esp. if the recursive IOCTL seek finds it first.
Inittab doesn't control virtual terminal keymap behaviour, nor switching
(unless of course, Puppy has included own scripted "work-arounds" there)
Which were noted by BK B4 > as: Not needed (if all initiate services were pre-defined, since no alternate run levels)
BUSYBOX
(Mind I have already been "informed" above would be "false command" since obviously Puppy doesn't have that many ttys)BusyBox init doesn't support multiple runlevels. The runlevels field of the /etc/inittab file is completely ignored by BusyBox init. If you
want runlevels, use sysvinit.
BusyBox init works just fine without an inittab. If no inittab is found, it has the following default behavior:
::sysinit:/etc/init.d/rcS
::askfirst:/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
if it detects that /dev/console is _not_ a serial console, it will also run:
tty2::askfirst:/bin/sh
tty3::askfirst:/bin/sh
tty4::askfirst:/bin/sh
In the "pfix" mode, 1<> 2 VTs would be all really needed IF
the desired utilities were available without the full O/System boot process being completed ?
AFAICT , It is an inter-active "test" mode - without more functional Bash or a text editor, that is sort've crippled:
> Defeats intent of having it in 1st place.
.
- Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
Well, I'm just using the pfix=rdsh option to "pause" the boot process. I planned to add some code to the /sbin/init script to set them up automatically. I wanted to create a bootsplash program, using one terminal to show the image and shunting the text to the other one. I figured that would be better than trying to store all the output and regurgitating it on demand.
I'm starting to think this is actually the harder method though. I didn't realize it would take so much fiddling to get things working right this early in the boot process. /sbin/init does call the busybox init, but it does so at the very end, right after the pivot_root. So if I wait for that to kick in, I might as well just do it in the pup_xxx.sfs where it would be easy, and that wouldn't help with all the stuff prior to that point.
So I think I'm going to just go with plan B. I'll route all the output into a temp file and just cat it back if I need it. I've also hacked fbv enough to let it run in the background, which was one of the reasons this is plan B instead of A.
Thanks for trying though
I'm starting to think this is actually the harder method though. I didn't realize it would take so much fiddling to get things working right this early in the boot process. /sbin/init does call the busybox init, but it does so at the very end, right after the pivot_root. So if I wait for that to kick in, I might as well just do it in the pup_xxx.sfs where it would be easy, and that wouldn't help with all the stuff prior to that point.
So I think I'm going to just go with plan B. I'll route all the output into a temp file and just cat it back if I need it. I've also hacked fbv enough to let it run in the background, which was one of the reasons this is plan B instead of A.
Thanks for trying though
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
Hi PG
Yes, that sure seems the best method, why fight or add more pre-boot functions if not needed ?
Bet when Googling for info, you noted same as I -
umpteen telling how to Alternately "F this or F that -
not HOW those functions are configured ?
That is endemic to all of Linux - lots of how-to's _ few explanations of the actual sycall functions, parent > child processes, etal.
Is this for a new version - thought you were going to have a "holiday" from pressures ?
Anyhow,,, best wishes & reserve some "quality time for yourself.
Yes, that sure seems the best method, why fight or add more pre-boot functions if not needed ?
Bet when Googling for info, you noted same as I -
umpteen telling how to Alternately "F this or F that -
not HOW those functions are configured ?
That is endemic to all of Linux - lots of how-to's _ few explanations of the actual sycall functions, parent > child processes, etal.
Is this for a new version - thought you were going to have a "holiday" from pressures ?
Anyhow,,, best wishes & reserve some "quality time for yourself.
- Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
I'm not making a new version until after summer, but I do want to get a basic bootsplash sorted out before I leave. It's the last item on my list of "commitments" from this last school year. Then I'll relax over summer, make some money, and come up with more ideas for the coming school year.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
Pizza, the error you got when exiting to rdsh is normal (or should I say, "normal" -- you always get it).
I'm pretty sure that when you boot the file /linuxrc is executed (in Puppy's case linked so /sbin/init).
The Busybox init is executed after pivot_root -- so it's the Busybox in the sfs, not the ramdisk (which uses /etc/inittab, not /initrd/etc/inittab).
I'm pretty sure that when you boot the file /linuxrc is executed (in Puppy's case linked so /sbin/init).
The Busybox init is executed after pivot_root -- so it's the Busybox in the sfs, not the ramdisk (which uses /etc/inittab, not /initrd/etc/inittab).
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
- Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
Code: Select all
#exit to initial ramdisk shell...
[ "$RDSH" = "yes" ] && exec /bin/sh >/dev/console 2>&1
cd /pup_new
sync
umount /proc
#echo "pivot_root now changing from initial ramdisk..."
pivot_root . initrd
exec chroot . sh -c "exec /bin/busybox init" <dev/console >dev/console 2>&1
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
it think it is busybox's init applet that sets up the extra virutal terminals according to the way /etc/inittab is configured ... busybox's init may not have executed at the point you want to be able to switch vts
the shell (busybox's ash shell) is capable of multitasking anyway ... so you could background a task, and do something else, then switch back to the first task, etc etc ... for example:
e3pi /etc/fstab
(press ctrl+Z to background the e3 task)
ls /etc
fg
the shell (busybox's ash shell) is capable of multitasking anyway ... so you could background a task, and do something else, then switch back to the first task, etc etc ... for example:
e3pi /etc/fstab
(press ctrl+Z to background the e3 task)
ls /etc
fg