 Hello, everyone. Welcome to my presentation. I will introduce the GNU screen to Debian installer today. I will show you its background, what is Debian installer, and what is GNU screen, and why I want the screen in the installer, and how to support it. Okay, first the background. I know most of you know the Debian installer. It's just the installer, right? But actually, first it's a bootable Debian environment, which is minimized in size. That is to say, there is no document in the image. There is no other non-related, usually used for information for normal people. We just usually put in the slash user, slash share, slash doc. But at the installer stage, we don't need this one. So we want to minimize the environment. Previously, we have the installer in one or two floppy disks. So it's very small. Nowadays it's not possible, because the kernel size is already oversized, the floppy. Right? Okay. Second, there is a partitioner inside the installer. So you can do the partition and create a new disk image inside the installer. After that, we can do the bootstrap to install the Debian environment for you. Finally, the installer will install the bootloader. There are all kinds of bootloader, such as grab for PC or for the ARM64. And for such as ARM platform, which is ARM EL or ARM HF, we use the flash kernel as a bootloader. Okay, the next. What is a kernel screen? First, it's a terminal multiplexer. It means when real terminal, you can have multiple virtual terminals. And you can switch one virtual terminal to another virtual terminal by short key. In screen, the short key is control A, 1, 2, 3, 4. And such as screen alternatives, Tmax, use control B, 1, 2, 3, 4. Okay. Then you must be thinking why we need the kernel screen in Debian installer. What's the benefit? Okay. Let me show you the normal installer. This is the normal installer, right? We have UI. And if we met some problem, such as partition or create a new image, this image, we want to check the logs so we can press the key art F4 to switch to the log console. This is for normal PC case. And if you want to switch back, we can press the art F1. So I can show you the demo. Where did it go? Okay. There we go. So it's the normal Debian installer screen. So I can enter the art F2. It's the command line. So I can check many stuff here. And art F4, you can see the log here. And if we want to turn back, we can art F1. Then we go back. This is for the normal PC case. But there's no such convenient method embedded. For embedded devices, such as ARM, HEL, or ARM, HF, we usually install by the serial console or the SSH installed by the network. So there's only one screen, one real screen for you. There's no much... Actually, there's a way. You can see the previous page. There is a go back option here. We can go back. And we can have this menu. This is the advanced menu. And you can enter a shell here for embedded device. After you enter the shell, you can check the logs. Actually, the logs in the slash var slash log, syslog, it's there. You can check it. But every time you want to do it, you have to go back and enter the shell. You cannot do it any time. Because sometimes the installer is just running, like install packages. You cannot do it any time, like common PC. So I was just thinking. If we have the GNU screen introduced into the device installer, we can just have the same convenience as the common PC in the embedded area, like ARM, EL. So I was starting to work for it. So how to achieve it? After some search, I need to support the screen binary package and its dependencies, such as library, to support UDAP. UDAP is the special format for the device installer, which minimizes the whole image. To say it removes the document, for example. So we have to support UDAP for screen and its library. And we need to add those UDAPs into the device installer image. The third one is we want, we need to write some script to start the GNU screen in the device installer. So first, the UDAP support. Normally, it's controlled by the device slash control. It writes every binary packages for the source package. So we just add an additional section to add UDAP, the new binary. After that, we just create a new UDAP in-store. And it's almost identical to the original in-store file. Just remove some unnecessary files. After that, we can create a patch. Then submit to package maintainer to let him or her to incorporate my changes. Unfortunately, because we add a new package called UDAP package. So if the package maintainer is DM, unfortunately, the DM needs to ask a DD to sponsor the package to upload. And for the same reason, the package will stay in the new queue in FTP master and wait for FTP master to approve the upload. So it takes much longer time than common packages. And what I do is to add the screen, UDAP support, and its dependencies. I create four bugs report. Actually, it's a patch report. After that, so we can have the UDAP package already ready, but we still need to include in the DB installer build. So I patch the installer, GIT report to support it. And finally, we need to start the new screen, the command after we start the DB installer. We also need a screen configuration to emulate the installer environment like PC. We actually have four virtual screens in the DB installer. One is the main screen and the two command line console. And the final is the log console. So we want to emulate it. Now I want to show the demo to you. Actually, I render the DB installer in virtual machine. Okay, this is the DB installer with GNU support. So we have four virtual terminals here. One, two, three, four. And I can switch the terminal by short key, such as control A2, control A3, and the control A4. This is the log. At the PC side, as you see now, it seems not much useful because we can use the RART F1, F2, F3 to switch. But for the embedded side, it's much useful. So I have a progress update. Actually, this update, this action item is already done, such as the first two package, the library, actually is not needed at all. Because I learned from Lauren, and actually the screen can be configured to compile twice. The first time is the normal screen, and the second time, it don't use many, such as audit and the PEM library. So it can be, the screen UDEP binary can be minimized. And actually, the actual library need to support is the end cursors. It has been uploaded to the FTP master two weeks ago and with the screen binary. For the Debian images, I just push the command after DI scratch, R5, 7, release this week. So I just push the commit after release. So you can now try the screen in Debian installer in the DI daily images. Which device will be benefited? So it's usually some onboard installed by server console or SSH network console. And some big machines like Spark 64 or IBM S390X. And even some PC can be benefited because some PC are headless. There's no HDMI or VGA port on that kind of PC like PC server. I would like to thank the various people through early request from command stage of my proposal. And various help during my UDEP package upload stage. Thank you very much. Do you have any questions? First of all, I use smaller, better systems all the time. So absolutely, this will be of great help. So thank you very much for your hard work. I really appreciate this. What was the one thing that you found hardest with doing this and what was the one thing that surprised you the most of how easy it was? Actually, the most difficult part is the upload, the package. Because one package is maintained by a DM. But usually he can upload without the DD sponsorship. But since the UDEP add a new package. So we need a DD to sponsor it. So I think it takes almost two months through the process. The one thing you found really easy to do that you thought was going to be hard? Nothing, it was all hard. From technical side, it's no hard. Because everything is there, I just write some simple patch to add the UDEP support and some script to start the new screen in the DB installer. So from technical side, it's not so difficult. Awesome. Thank you. Next question. You said that it was already in the stretch alpha. No, I comment after. So it's going to be after the freeze? Yes. Do you know if adding all these libraries and screen increases the size of the ISO image, like the mini ISO image a lot or not? Does it make a difference? Yes. The DB installer image will be a little bit larger than before. And such as the one machine that DB installer supports is the QNAP, ARM EL QNAP platform. That platform has the size limitation because we put the kernel image and init-rd image in the flash. And the flash size is about, for kernel, I think it's 2 mega, and for init-rd it's 4 mega. So it's size limited. And the new screen package at about, I think, is 500K. So it's not impossible to incorporate this feature, this new feature, into that specific images. For other images, I think it's okay. There's no big size limitation concern. So currently, it's in the DB installer daily build image. So you can just try it in daily. And URL is, I think I write it. It's here. There are many images in there because we support all the actors, such as AMD64 and GNU-RD kernel-free BSD, such as that. So you need to choose the right architecture and the right image. Okay, this is my talk. Thank you very much.