Bug#891806: busybox: Please include stty in busybox-udeb

[Samuel Thibault]

Source: busybox
Version: 1:1.27.2-2
Severity: normal
Tags: a11y

Hello,

In order to be able to tune the console size for better accessibility in
the Debian installer, we would need to have the stty tool available in
d-i, could you enable it?

Thanks,
Samuel

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
* B kicks DW (non mais franchement)
* DW was kicked
 -+- #ens-mim - comment ça hopeless ? -+-

Re: Boot Order

[Dan Norton]

On Wed, 28 Feb 2018 11:41:30 -0500
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> > Why insert itself anywhere in the first place? The machine booted
> > before the installation. To start installing, the installation
> > medium is placed in a CD drive or USB port and the machine is
> > rebooted. During installation, other OSs are detected by the
> > installer. The installer forms the grub menu with the latest
> > install first and the other OSs following. Installer finishes by
> > reminding the admin to remove the installation medium and it
> > reboots the machine. The latest install boots unless the admin
> > intervenes. Where in this process is a requirement to tinker with
> > the UEFI menu?  
> 
> How are you supposed to get grub to run at all if you don't add a boot
> entry for it?  The grub is installed by this installer after.
> 
> There is nothing that makes the latest install boot unless you add it
> to the boot order.  On legacy bios it was different because there you
> just put what you wanted into the MBR boot sector and the BIOS was
> typically configured to boot from the harddisk.  UEFI does not work
> that way.  UEFI uses an explicit entry specifying which filename to
> boot from which harddisk.  So an entry is created specifying to boot
> the grub_x64.efi file from the FAT partition containing the
> bootloaders.
> 
> Now there are some default filenames that UEFI will look for if not
> explicitly told, but they are not always supported and most installers
> don't use those filenames because it isn't reliable, and the explicit
> entry is the official way to do it.
> 
> The installer has no way to tell what else was on your system already
> and how it booted.
> 

OK, I think I see. Installer is not replacing something with grub, it
is adding grub to the ESP, leaving anything else that might be there
alone. Therefore it must make the UEFI menu point to grub. If there is
something from windows, etc. there it is ignored(?). In contrast, with
the primary/logical partitioning scheme it could just rewrite the mbr
and let the user pick alternative systems, if any, from the grub menu.

That leaves the issue of boot order, but with all the possible
configurations and names for entries in the UEFI menu, putting the
latest first instead of trying to parse all that stuff makes sense.

Taking a look at what efibootmgr reports...

# efibootmgr
BootCurrent: 
Timeout: 9 seconds
BootOrder: 0003,0001,0002,,0004,0005,0006
Boot* debian
Boot0001* USB Floppy/CD
Boot0002* USB Hard Drive
Boot0003* ATAPI CD-ROM Drive
Boot0004* Unknown Device
Boot0005* USB Floppy/CD
Boot0006* Hard Drive

...but, if you go into the setup menu on my PC (POST -> Esc) you
see some 'UEFI Boot Sources' and some 'Legacy Boot Sources' with common
items. However, 'debian' is exclusively in the UEFI list and 'Hard
Drive' is exclusively in the Legacy list. One cannot be moved to the
other. If 6 were put first in the boot order or made current, it might
try to legacy boot windows, but windows is long gone. This disk was
cleaned off and several debian distros installed with the GPT and LVM
schemes. 

Thanks very much everybody.

 - Dan

Bug#891757: package's /etc/udhcpd.conf still mentions obsolete "remaining" option

[Nathan Stratton Treadway]

On Wed, Feb 28, 2018 at 10:36:46 -0500, Nathan Stratton Treadway wrote:
> (Comparing those two files quickly I don't see any other obsolete option
> still listed in the Debian /etc/udhcpd.conf file.)

Actually, looking a little more closely it seems that this
Debian-specific file was copied (essentially unchanged) from the
upstream "examples" version of the file shortly before the
above-mentioned commit 2b0e95780863da44f6a9244699ece8620a599e19, and it
hasn't been updated since.  So perhaps it would make sense just to
distribute the upstream version as Debian's /etc/udhcpd.conf rather than
having a separate copy?

=
$ git diff 
2b0e95780863da44f6a9244699ece8620a599e19^1:examples/udhcp/udhcpd.conf 
HEAD:debian/tree/udhcpd/etc/udhcpd.conf | cat
diff --git 
a/2b0e95780863da44f6a9244699ece8620a599e19^1:examples/udhcp/udhcpd.conf 
b/HEAD:debian/tree/udhcpd/etc/udhcpd.conf
index 8c9a968..672c481 100644
--- a/2b0e95780863da44f6a9244699ece8620a599e19^1:examples/udhcp/udhcpd.conf
+++ b/HEAD:debian/tree/udhcpd/etc/udhcpd.conf
@@ -114,7 +114,7 @@ option  lease   864000  # 10 days of seconds
 #opt ntpsrv
 #opt tftp
 #opt bootfile
-
+#opt wpad
 
 # Static leases map
 #static_lease 00:60:08:11:CE:4E 192.168.0.54
$ git log debian/tree/udhcpd/etc/udhcpd.conf
commit 9f5c542f05969830b28e16d73c2f8af69c742a90
Author: Bastian Blank 
Date:   Sat Nov 7 18:26:56 2009 +

* debian/busybox-syslogd.busybox-klogd.init, debian/busybox-syslogd.default,
  debian/busybox-syslogd.init, debian/busybox-syslogd.links,
  debian/udhcpc.install, debian/udhcpc.links,
  debian/udhcpd.install, debian/udhcpd.links: Add.
* debian/config/deb, debian/config/static: Enable FEATURE_PIDFILE-
* debian/control: Add new binary packages.
* debian/copyright: Fix typo.
* debian/rules: Build new binary packages.
* debian/tree/udhcpc, debian/tree/udhcpd: Add trees.

r61201

=


Nathan

Re: Boot Order

[Lennart Sorensen]

On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> Why insert itself anywhere in the first place? The machine booted
> before the installation. To start installing, the installation medium
> is placed in a CD drive or USB port and the machine is rebooted. During
> installation, other OSs are detected by the installer. The installer
> forms the grub menu with the latest install first and the other OSs
> following. Installer finishes by reminding the admin to remove the
> installation medium and it reboots the machine. The latest install
> boots unless the admin intervenes. Where in this process is a
> requirement to tinker with the UEFI menu?

How are you supposed to get grub to run at all if you don't add a boot
entry for it?  The grub is installed by this installer after.

There is nothing that makes the latest install boot unless you add it
to the boot order.  On legacy bios it was different because there you
just put what you wanted into the MBR boot sector and the BIOS was
typically configured to boot from the harddisk.  UEFI does not work
that way.  UEFI uses an explicit entry specifying which filename to boot
from which harddisk.  So an entry is created specifying to boot the
grub_x64.efi file from the FAT partition containing the bootloaders.

Now there are some default filenames that UEFI will look for if not
explicitly told, but they are not always supported and most installers
don't use those filenames because it isn't reliable, and the explicit
entry is the official way to do it.

The installer has no way to tell what else was on your system already
and how it booted.

-- 
Len Sorensen

Bug#891757: package's /etc/udhcpd.conf still mentions obsolete "remaining" option

[Nathan Stratton Treadway]

Package: udhcpd 
Version: 1:1.27.2-2

I noticed that the copy of /etc/udhcpd.conf installed by the udhcpd
package includes a section describing the "remaining" option:

=
# If remaining is true (default), udhcpd will store the time
# remaining for each lease in the udhcpd leases file. This is
# for embedded systems that cannot keep time between reboots.
# If you set remaining to no, the absolute time that the lease
# expires at will be stored in the dhcpd.leases file.

#remaining  yes #default: yes
=

However, this option was actually removed from the udhcpd program many
years ago, in commit 0416e3dde17ea9295635c52183b30fe3d7172333  (See,
e.g.:
  
https://git.busybox.net/busybox/commit?id=0416e3dde17ea9295635c52183b30fe3d7172333
or
  
https://anonscm.debian.org/cgit/d-i/busybox.git/commit/?id=0416e3dde17ea9295635c52183b30fe3d7172333
), and from the examples/udhcp/udhcpd.conf file in the upstream source
in commit 2b0e95780863da44f6a9244699ece8620a599e19 .


(Comparing those two files quickly I don't see any other obsolete option
still listed in the Debian /etc/udhcpd.conf file.)


Nathan

Re: Boot Order

[Ian Campbell]

On Wed, 2018-02-28 at 02:16 +, Steve McIntyre wrote:
> On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> > On Mon, 26 Feb 2018 10:40:20 -0500
> > lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> > > 
> > > With UEFI, adding an entry to the boot meny is what you do when
> > > you
> > > install an OS you want to be able to boot.  UEFI does not rely on
> > > the
> > > boot sector anymore the way legacy BIOS did.
> > > 
> > > Adding it first makes sense since why install it if you don't
> > > want to
> > > use it?  Advanced users can always rearrange the order if they
> > > want
> > > something else.  No way an installer could guess where in an
> > > existing
> > > list to insert itself.  First is the only sane default option.
> > > 
> > 
> > Why insert itself anywhere in the first place? The machine booted
> > before the installation. To start installing, the installation
> > medium
> > is placed in a CD drive or USB port and the machine is rebooted.
> > During
> > installation, other OSs are detected by the installer. The
> > installer
> > forms the grub menu with the latest install first and the other OSs
> > following. Installer finishes by reminding the admin to remove the
> > installation medium and it reboots the machine. The latest install
> > boots unless the admin intervenes. Where in this process is a
> > requirement to tinker with the UEFI menu?
> 
> As Lennart said: "adding an entry to the boot meny is what you do when
> you install an OS you want to be able to boot". Adding an entry in the
> UEFI boot variables *is how UEFI is meant to work*. If you don't add
> an entry there, a correctly-working UEFI won't know how to find the OS
> you just installed.

The entry which Debian is adding to the UEFI boot menu is really a
pointer to the Grub (so a more technically correct title for the entry
would be "Debian's Grub bootloader"[0], but that would be terrible from
a UI perspective).

If Debian didn't install Grub into the UEFI boot menu then nothing else
in the system would know how to read and interpret the Grub menu. So
installing Grub is needed for:

> > The installer forms the grub menu

to have any meaning/use.

The system probably has a Windows bootloader preinstalled (probably
labelled "Hard Drive" in the UEFI menu) but that is not as flexible as
Grub and Debian does/will not mess around with its configuration files.

Ian.

[0] In the same way I suggested earlier that "Hard Drive" was just what
MS (or the system builder or whoever) has decided to call the entry
which points to the Windows bootloader. That's a reasonable choice for
an ecosystem where some large majority of users do not install an
alternative (either replacement or dual boot) OS. In Debian's case a
more specificly named entry makes sense.