Peter, have you been seeing / hearing about this?

Proposing as a Beta blocker, as Pi 3 is a supported platform for F27, and initial-setup needs to run properly in order for the user to be able to log into the system (without i-s there are no accessible accounts): "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.", from the Alpha criteria.

So if I understand this correctly you can access the system & IS, but only over the serial console and there is nothing on the graphical consoles, right ?

In any case we need logs to debug this further - Initial Setup is logging to Journal, so this should give you it's log once you can get access to a console:

journalctl -u initial-setup

Thanks in advance! :)

Discussed during blocker review [1]:

AcceptedBlocker (Beta) - this sounds like a violation of Alpha criterion " A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system" for Raspberry Pi 3, which is a supported ARM platform for F27. If further testing indicates it's not so clear-cut, we will revisit

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-04/

(In reply to Adam Williamson from comment #1)
> Peter, have you been seeing / hearing about this?

I was aware of something similar, pwhalen knows more details

(In reply to Martin Kolman from comment #3)
> So if I understand this correctly you can access the system & IS, but only
> over the serial console and there is nothing on the graphical consoles,
> right ?

Well, not exactly.
I'm using Minimal (or Server) image. As a side note, Xfce initial-setup GUI works as expected.
Using Minimal and an HDMI display, initial-setup TUI starts, but doesn't react to any input, and also CTRL-C doesn't have effects.
Sadly, if I enable the serial console (in extlinux.conf and config.txt), initial-setup TUI works, either via serial connection and also using the HDMI display and the keyboard.

I will post journalctl logs ASAP.

Thanks.

Created attachment 1322112 [details]
journalctl -u initial-setup -u anaconda

This seems to only affect the Raspberry Pi 3, user input appears on the display but the system doesnt respond. Changing tty's does work but yields the same result. 

Using the Raspberry Pi 2 and other hardware, TUI works as expected.

Have you checked if it's actually working but not updating the screen (i.e. you can do it blind if you know how it works) or just not working at all?

(In reply to Adam Williamson from comment #9)
> Have you checked if it's actually working but not updating the screen (i.e.
> you can do it blind if you know how it works) or just not working at all?

It seems to me that it just doesn't work at all.

I don't know if it could be useful. Here is a video: https://alciregi.fedorapeople.org/webm/rpi3.webm

(In reply to Alessio from comment #10)
> (In reply to Adam Williamson from comment #9)
> > Have you checked if it's actually working but not updating the screen (i.e.
> > you can do it blind if you know how it works) or just not working at all?
> 
> It seems to me that it just doesn't work at all.
> 
> I don't know if it could be useful. Here is a video:
> https://alciregi.fedorapeople.org/webm/rpi3.webm

Could you try the latest u-boot, we fixed usb keyboards there to work recently and that should work with the latest rc4 build, i wonder if the console input is initially passed through from the bootloader before the proper input stack can take over.

https://koji.fedoraproject.org/koji/buildinfo?buildID=966566

(In reply to Peter Robinson from comment #11)
> Could you try the latest u-boot, we fixed usb keyboards there to work
> recently and that should work with the latest rc4 build, i wonder if the
> console input is initially passed through from the bootloader before the
> proper input stack can take over.

I will try ASAP.
However, as said before, if I put exit 0 on top of /usr/libexec/initial-setup/run-initial-setup, I'm able to login.
Once logged in, removing such line and restarting initial-setup systemd service lead to the same situation.

(In reply to Peter Robinson from comment #11)
> Could you try the latest u-boot, we fixed usb keyboards there to work
> recently and that should work with the latest rc4 build, i wonder if the
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=966566

Is it enough to install these two packages?
uboot-images-elf-2017.09-0.5.rc4.fc27.armv7hl.rpm
uboot-tools-2017.09-0.5.rc4.fc27.armv7hl.rpm

If yes, nothing changes.

AFAIK Initial Setup worked correctly on the RPI 3 in F26, right ?

Nothing really changed in the relevant IS/Anaconda code since then & the multi-TTY enabled UI seems to continue working correctly elsewhere (VMs, RPI 2) and I don't see anything wrong in the IS journal log in comment 3. 

So I kinda suspect some form of regressions elsewhere, most likely a quirk in the Linux console code.

BTW, this is the relevant part of the Initial Setup code:
https://github.com/rhinstaller/initial-setup/blob/master/initial_setup/tui/tui.py#L96

There is a select that sits on fds corresponding to all the open consoles and on the Anaconda stdout:

rlist, _wlist, _xlist = select.select(fds, [], [], 1.0)

Once the select is triggered by input (user inputs something and presses enter) the input handling is triggered:

https://github.com/rhinstaller/initial-setup/blob/master/initial_setup/tui/tui.py#L127

What likely happens here is that the select is not triggered when enter is pressed, so Initial Setup gets no input and nothing happens.

(In reply to Peter Robinson from comment #11)
> Could you try the latest u-boot, we fixed usb keyboards there to work
> recently and that should work with the latest rc4 build, i wonder if the
> console input is initially passed through from the bootloader before the
> proper input stack can take over.
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=966566

No change with uboot-images-armv7-2017.09-0.5.rc4.fc27.noarch

(In reply to Martin Kolman from comment #14)
> AFAIK Initial Setup worked correctly on the RPI 3 in F26, right ?

Yes, it worked as expected in F26. 

> 
> Nothing really changed in the relevant IS/Anaconda code since then & the
> multi-TTY enabled UI seems to continue working correctly elsewhere (VMs, RPI
> 2) and I don't see anything wrong in the IS journal log in comment 3. 
> 
> So I kinda suspect some form of regressions elsewhere, most likely a quirk
> in the Linux console code.

We're also seeing some oddities with the console on aarch64 with the rpi3, when using the display it will crash during the boot(messages relating to tty_write_room and uart_write_room). When the serial console is enabled (in config.txt), it boots to initial-setup.

(In reply to Paul Whalen from comment #16)
> (In reply to Martin Kolman from comment #14)
> > AFAIK Initial Setup worked correctly on the RPI 3 in F26, right ?
> 
> Yes, it worked as expected in F26. 
> 
> > 
> > Nothing really changed in the relevant IS/Anaconda code since then & the
> > multi-TTY enabled UI seems to continue working correctly elsewhere (VMs, RPI
> > 2) and I don't see anything wrong in the IS journal log in comment 3. 
> > 
> > So I kinda suspect some form of regressions elsewhere, most likely a quirk
> > in the Linux console code.
> 
> We're also seeing some oddities with the console on aarch64 with the rpi3,
> when using the display it will crash during the boot(messages relating to
> tty_write_room and uart_write_room). When the serial console is enabled (in
> config.txt), it boots to initial-setup.

This really looks more and more like the cause is somewhere else than in Initial Setup, likely somewhere down in the stack where console handling is done (kernel ?) and the bug should probably be reassigned accordingly to get proper triage.

initial-setup on display is working with kernel-4.12, broken when using 4.13. Moving to the kernel.

So looking at this some more it seems the 4.12 DT works with a 4.13 kernel. My guess is that there's been some fixes/improvements around bluetooth support (not there in 4.13 yet) but systemd/something is detecting the BT device on the end of the serial and this is some how screwing stuff up.

scratch build to test https://koji.fedoraproject.org/koji/taskinfo?taskID=21773271

(In reply to Peter Robinson from comment #20)
> scratch build to test
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21773271

Installed 
kernel-4.13.1-300.rpi1.fc27.armv7hl.rpm 
kernel-core-4.13.1-300.rpi1.fc27.armv7hl.rpm 
kernel-modules-4.13.1-300.rpi1.fc27.armv7hl.rpm

Now initial-setup works also using an hdmi monitor and a keyboard. :-)

OK an official build kernel-4.13.1-301.fc27
 https://koji.fedoraproject.org/koji/taskinfo?taskID=21795161

kernel-4.13.1-302.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b52203af49

kernel-4.13.1-302.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b52203af49

kernel-4.13.1-303.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-3c2574cd2a

kernel-4.13.1-303.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3c2574cd2a

kernel-4.13.2-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0da1ebbe4f

kernel-4.13.2-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-0da1ebbe4f

Works fine for workstation, initial gnome set up works as expected.
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20170918.n.1/compose/Workstation/armhfp/images/Fedora-Workstation-armhfp-27-20170918.n.1-sda.raw.xz

sumantro, which kernel have you tested with?

kparal,I didnt update anything on the compose,4.13.0 rc7. I can still reproduce this [https://alciregi.fedorapeople.org/webm/rpi3.webm] for minimal and server for the last compose 
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20170918.n.1/compose/Server/armhfp/images/Fedora-Server-armhfp-27-20170918.n.1-sda.raw.xz
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20170918.n.1/compose/Spins/armhfp/images/Fedora-Minimal-armhfp-27-20170918.n.1-sda.raw.xz

Noteworthy to say , Rawhide with 4.14 is working perfectly fine.

Ok, so Workstation works but Server and Minimal don't. Once kernel kernel-4.13.2-300.fc27 is included in the next compose, we need to test Server and Minimal.

kernel-4.13.2-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Kmail: Why was this reopened without any comment as to why?

This is an accepted blocker, we still need to verify it fixes the bug, even though it has been pushed.

Paul, can you please verify with 20170921 compose once it's up? Thanks.

Fedora-27-20170921.n.0 Minimal works perfectly fine.

Thanks, closing.

Fedora-27-20170921.n.0 Server works fine too

Working with the latest images.