Re: Boot Order

[Steve McIntyre]

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.

There's more information about Debian and UEFI in https://wiki.debian.org/UEFI

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Re: Boot Order

[Dan Norton]

On Mon, 26 Feb 2018 10:40:20 -0500
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
> > Installing either stretch or buster via netinst results in changes
> > to the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> > replaced with "debian" and this entry is put first in the boot
> > order.
> > 
> > The PC is:
> > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> > 
> > Please tell me the justification for putting "debian" in the menu
> > and having it boot first, ahead of CD/DVD/USB. Thanks.  
> 
> 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?

Re: Boot Order

[Lennart Sorensen]

On Mon, Feb 26, 2018 at 05:42:36PM -0500, Dan Norton wrote:
> I would hate to have to do something because windows does it :-)
> 
> No one's yet mentioned secure boot as a justification. AIUI some
> manufacturers are making it so that you can't even disable secure boot.
> How will you multi-boot linux and windows, or replace windows entirely
> with such a machine?

Secureboot has nothing to do with it.  All secureboot means is that it
won't boot something that isn't signed by a trusted key.  So if enabled
you wouldn't be able to even boot the installer if it wasn't signed.

I have not yet seen a machine where you can't disable secureboot.
For Windows 8 it was a requirement to allow disabling it (but to have
it enabled by default) to get a Windows 8 Lego on the box.  I think
Windows 10 has the same requirement.  Now on some machines you have to
set a UEFI admin password before you get the option to disable secureboot
for some reason.

-- 
Len Sorensen

Re: Clean up bug report for debootstrap

[Cyril Brulebois]

Hideki Yamane  (2018-02-27):
> On Sun, 25 Feb 2018 23:12:21 +0100
> Cyril Brulebois  wrote:
> > >   #871835
> > 
> > At least this one needs serious regression testing. Meaning setting up
> > tests for various sets of options and architectures; and check what
> > happens without and with this patch.
> 
>  Fair enough.
> 
>  But anyway its speed up is *significant* as you know, we should make
>  some plan to push it forward.

Well, it might be. But as I said, while I would want to see it pushed
eventually, I don't want to see it rushed. Any help setting up appropriate
tests to avoid regressions along the way is more than welcome.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Clean up bug report for debootstrap

[Hideki Yamane]

On Sun, 25 Feb 2018 23:12:21 +0100
Cyril Brulebois  wrote:
> >   #871835
> 
> At least this one needs serious regression testing. Meaning setting up
> tests for various sets of options and architectures; and check what
> happens without and with this patch.

 Fair enough.

 But anyway its speed up is *significant* as you know, we should make
 some plan to push it forward.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: Clean up bug report for debootstrap

[Hideki Yamane]

Hi,

On Sun, 25 Feb 2018 21:40:22 +0100
Raphael Hertzog  wrote:
> Why not applying the patches yourself and becoming the maintainer
> of debootstrap for a while? I think it doesn't have any obvious
> regular maintainer and it could benefit from a bit of sustained attention
> to deal with the backlog of bugs.

 Thanks, I want to push those patches but want review for it before
 merge (Maybe put debootstrap into salsa and make its repository
 as protected and I'd push Merge Request is best).


> I'm ccing the 4 uploaders of debootstrap, maybe they can give you
> more guidance.

 :)


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#402491: debootstrap: missing check in x_feign_install

[Hideki Yamane]

On Sun, 10 Dec 2006 21:02:25 +0100 Frans Pop  wrote:
> Package: debootstrap
> Version: 0.3.3.1
> 
> The suite scripts (e.g. scripts/sid) contain the following function:
> x_feign_install () {
> local pkg="$1"
> local deb="$(debfor $pkg)"
> local ver="$(
> ar -p "$TARGET/$deb" control.tar.gz | zcat |
> tar -O -xf - control ./control 2>/dev/null |
> sed -ne 's/^Version: *//Ip' | head -n 1
> )"
> 
> // Some code deleted
> }

 Now its code is changed as below, and perhaps dpkg-deb works better
 than old one.

> x_feign_install () {
> local pkg="$1"
> local deb="$(debfor $pkg)"
> local ver="$(in_target dpkg-deb -f "$deb" Version)"


> I'm aware that this is not supposed to happen, but as installs seem to 
> quite regularly fail at this point, it would be nice if a check could be 
> added here and debootstrap could bail out with a clearer error.

 And in functions,

> in_target_failmsg () {
> local code="$1"
> local msg="$2"
> local arg="$3"
> shift; shift; shift
> if ! $CHROOT_CMD "$@"; then
> warning "$code" "$msg" "$arg"
> # Try to point user at actual failing package.
> msg="See %s for details"
> if [ -e "$TARGET/debootstrap/debootstrap.log" ]; then
> arg="$TARGET/debootstrap/debootstrap.log"
> local pkg="$(grep '^dpkg: error processing ' 
> "$TARGET/debootstrap/debootstrap.log" | head -n 1 | sed 's/\(error processing 
> \)\(package \|archive \)/\1/' | cut -d ' ' -f 4)"
> if [ -n "$pkg" ]; then
> msg="$msg (possibly the package $pkg is at fault)"
> fi
> else
> arg="the log"
> fi
> warning "$code" "$msg" "$arg"
> return 1
> fi
> return 0
> }
> 
> in_target () {
> in_target_failmsg IN_TARGET_FAIL "Failure trying to run: %s" "$CHROOT_CMD $*" 
> "$@"

 It would try to report error, so it'd be okay to close this bug.

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp