| Message ID | 1419336373-30919-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Accepted |
| Headers | show |
On Tue, Dec 23, 2014 at 1:06 PM, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > 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. But can you login as root via /dev/console? AFAIK it was the main problem by this approach. There is also another alternative: cttyhack Yegor > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Peter Korsgaard <peter@korsgaard.com> > --- > system/Config.in | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/system/Config.in b/system/Config.in > index 0fa0dc6..6447be8 100644 > --- a/system/Config.in > +++ b/system/Config.in > @@ -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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Yegor, On Tue, 2014-12-23 at 13:18 +0100, Yegor Yefremov wrote: > On Tue, Dec 23, 2014 at 1:06 PM, Alexey Brodkin > <Alexey.Brodkin@synopsys.com> wrote: > > 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. > > 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? -Alexey
On Tue, Dec 23, 2014 at 1:32 PM, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Yegor, > > > On Tue, 2014-12-23 at 13:18 +0100, Yegor Yefremov wrote: >> On Tue, Dec 23, 2014 at 1:06 PM, Alexey Brodkin >> <Alexey.Brodkin@synopsys.com> wrote: >> > 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. >> >> 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? 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. Yegor
Hi Yegor, On Tue, 2014-12-23 at 14:57 +0100, Yegor Yefremov wrote: > On Tue, Dec 23, 2014 at 1:32 PM, Alexey Brodkin > <Alexey.Brodkin@synopsys.com> wrote: > > 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. -Alexey
Dear Alexey Brodkin, On Tue, 23 Dec 2014 14:35:40 +0000, Alexey Brodkin wrote: > 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. Thomas
Hi Thomas, On Tue, 2014-12-23 at 20:52 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Tue, 23 Dec 2014 14:35:40 +0000, Alexey Brodkin wrote: > > > 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? -Alexey
Dear Alexey Brodkin, On Tue, 23 Dec 2014 21:18:56 +0000, Alexey Brodkin wrote: > 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? 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? Thomas
Hi Thomas, On Tue, 2014-12-23 at 23:10 +0100, Thomas Petazzoni wrote: > Dear Alexey Brodkin, > > On Tue, 23 Dec 2014 21:18:56 +0000, Alexey Brodkin wrote: > > > 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? > > 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 -Alexey
Hi Thomas, On Wed, 2014-12-24 at 12:03 +0300, Alexey Brodkin wrote: > > On Tue, 23 Dec 2014 21:18:56 +0000, Alexey Brodkin wrote: > > > > > 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? > > > > 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 I'm wondering if there's anything else I may help with this one? Or if there're no other objections please consider applying. Regards, Alexey
Dear Alexey Brodkin, On Tue, 23 Dec 2014 15:06:13 +0300, Alexey Brodkin wrote: > We used to specify explicitly serial port with all its settings > for init to instantiate getty. Applied, thanks. Thomas
Dear Alexey Brodkin, On Tue, 23 Dec 2014 15:06:13 +0300, Alexey Brodkin wrote: > diff --git a/system/Config.in b/system/Config.in > index 0fa0dc6..6447be8 100644 > --- a/system/Config.in > +++ b/system/Config.in > @@ -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. I've just tested with agetty from util-linux, and while "console" as the default getty works fine, having 0 as the baudrate doesn't work. You have to specify a correct serial port speed apparently. You can try with the following config: BR2_arm=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSV=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_GETTEXT=y BR2_PACKAGE_IFUPDOWN=y BR2_PACKAGE_AT=y BR2_PACKAGE_COREUTILS=y BR2_PACKAGE_START_STOP_DAEMON=y BR2_PACKAGE_UTIL_LINUX=y BR2_PACKAGE_UTIL_LINUX_BINARIES=y BR2_PACKAGE_UTIL_LINUX_AGETTY=y BR2_PACKAGE_UTIL_LINUX_LOGIN_UTILS=y BR2_PACKAGE_UTIL_LINUX_MOUNT=y which you can boot using an ARM Vexpress kernel under Qemu. Though, this does not say I'm not fine with the current situation. I believe the current situation (with your patch) works fine in the normal cases. People using agetty probably know what they are doing. Best regards, Thomas
diff --git a/system/Config.in b/system/Config.in index 0fa0dc6..6447be8 100644 --- a/system/Config.in +++ b/system/Config.in @@ -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.
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 <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> --- system/Config.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)