system: run getty on boot console by default

We used to specify explicitly serial port with all its settings for init to instantiate getty.

This limits usecases when the same one rootfs could be used.

For example following cases won't work well with hardcoded serial console settings:
* On the same board other serial port is expected to be used
* The same rootfs is intended to be used on different boards with different serial ports (like ttySx vs ttyAMAx or even ttyx)

With this change by default we rely on "console" specified in kernel's boot command line.

What is important getty will be set on the last console specified in bootargs.

For example is a kernel comand line:
--->---
bootargs="... console=tty0 console=ttyS3,115200n8..." --->---

This now will instantiate serial console on ttyS3 but not on tty0.

Tested with both Busybox and SysV init.

Signed-off-by Alexey Brodkin <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Peter Korsgaard <[email protected]>

---
 system/Config.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

system/Config.in +2 -3

index 0fa0dc6..6447be8 100644
@@ -263,13 +263,13 @@ if BR2_TARGET_GENERIC_GETTY
 menu "getty options"
 config BR2_TARGET_GENERIC_GETTY_PORT
        string "TTY port"
-       default "ttyS0"
+       default "console"
        help
          Specify a port to run a getty on.
 
 choice
        prompt "Baudrate"
-       default BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200
+       default BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP
        help
          Select a baudrate to use.
 
--

2.1.0

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 22 lines · Alexey Brodkin

We used to specify explicitly serial port with all its settings for init to instantiate getty.

This limits usecases when the same one rootfs could be used.

For example following cases won't work well with hardcoded serial console settings:
* On the same board other serial port is expected to be used
* The same rootfs is intended to be used on different boards with different serial ports (like ttySx vs ttyAMAx or even ttyx)

With this change by default we rely on "console" specified in kernel's boot command line.

What is important getty will be set on the last console specified in bootargs.

For example is a kernel comand line:
--->---
bootargs="... console=tty0 console=ttyS3,115200n8..." --->---

Quoted 3 lines

This now will instantiate serial console on ttyS3 but not on tty0.

Tested with both Busybox and SysV init.

But can you login as root via /dev/console? AFAIK it was the main problem by this approach. There is also another alternative: cttyhack

Hi Yegor,

Quoted 24 lines · Yegor Yefremov

Quoted 22 lines · Alexey Brodkin

We used to specify explicitly serial port with all its settings for init to instantiate getty.

This limits usecases when the same one rootfs could be used.

For example following cases won't work well with hardcoded serial console settings:
* On the same board other serial port is expected to be used
* The same rootfs is intended to be used on different boards with different serial ports (like ttySx vs ttyAMAx or even ttyx)

With this change by default we rely on "console" specified in kernel's boot command line.

What is important getty will be set on the last console specified in bootargs.

For example is a kernel comand line:
--->---
bootargs="... console=tty0 console=ttyS3,115200n8..." --->---

Quoted 6 lines

Quoted 3 lines

This now will instantiate serial console on ttyS3 but not on tty0.

Tested with both Busybox and SysV init.

But can you login as root via /dev/console? AFAIK it was the main problem by this approach. There is also another alternative: cttyhack

Probably I don't quite understand your question.
What is a problem with "/dev/console"?

I do login as root with these new settings:
--->---

# whooami
root
--->---

Did I miss something?

Quoted 4 lines · Alexey Brodkin

Hi Yegor,

Did I miss something?

It could be this issue: http://www.busybox.net/FAQ.html#job_control

Does it still make problems? When not, then there is no problem.

Even thought I haven't done any extensive testing I don't see any suspicious behavior.

So I think "console" in BR2_TARGET_GENERIC_GETTY_PORT should be fine.

Dear Alexey Brodkin,

Quoted 4 lines · Alexey Brodkin

Even thought I haven't done any extensive testing I don't see any suspicious behavior.

So I think "console" in BR2_TARGET_GENERIC_GETTY_PORT should be fine.

No, you can only login as root if you add "console" to /etc/securetty.

Interesting, then how it worked for me?

I have the same login prompt as usual:
--->---
Welcome to Buildroot
buildroot login:
--->---

Here I enter "root" as usual, press Enter and that's it. "whoami" says "root" and I may modify any files etc.

What do I do wrong?

Dear Alexey Brodkin,

Quoted 11 lines · Alexey Brodkin

Interesting, then how it worked for me?

I have the same login prompt as usual:
--->---
Welcome to Buildroot
buildroot login:
--->---

Here I enter "root" as usual, press Enter and that's it. "whoami" says "root" and I may modify any files etc.

Quoted 1 line

What do I do wrong?

Weird, when I tested I had to add "console" to /etc/securetty, otherwise login would not let me log in as root. Are you using just Busybox, or some other login/getty implementation? Are you using an unmodified /etc/securetty?

Quoted 13 lines · Alexey Brodkin

Quoted 12 lines

Interesting, then how it worked for me?

I have the same login prompt as usual:
--->---
Welcome to Buildroot
buildroot login:
--->---

Here I enter "root" as usual, press Enter and that's it. "whoami" says "root" and I may modify any files etc.

Quoted 6 lines

Quoted 1 line

What do I do wrong?

Weird, when I tested I had to add "console" to /etc/securetty, otherwise login would not let me log in as root. Are you using just Busybox, or some other login/getty implementation? Are you using an unmodified /etc/securetty?

Indeed it's strange.
I've just re-tested it and still see root login working perfectly.

I'm on mainline/master branch with my patch applied (no other changes):
--->---
(my patch) 7af7de3 system: run getty on boot console by default f7add51 qemu: add host/target Linux version check
--->---

And this is output of "make savedefconfig":
--->---
BR2_x86_pentiumpro=y
BR2_KERNEL_HEADERS_VERSION=y BR2_DEFAULT_KERNEL_VERSION="3.18" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_18=y BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.18" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.18.config" BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
--->---

Note that this is based on "qemu_x86_defconfig" and with my patch applied that's why you don't see mention of "console".

You may try even without my patch and manually set BR2_TARGET_GENERIC_GETTY_PORT=console

We used to specify explicitly serial port with all its settings for init to instantiate getty.

system/Config.in +0 -1

index 0fa0dc6..6447be8 100644
@@ -263,13 +263,13 @@ if BR2_TARGET_GENERIC_GETTY
 menu "getty options"
 config BR2_TARGET_GENERIC_GETTY_PORT
 	string "TTY port"
-	default "ttyS0"