URGENT..! Very annoying when UPDATE = debian.map.fastlydns.net

[ISRAEL]

Very annoying when UPDATE = apt update always fail =

*Err:3 http://deb.debian.org/debian 
buster/updates InRelease*
*  Could not connect to debian.map.fastlydns.net
:80*

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

[Andrei POPESCU]

On Mi, 05 mai 21, 01:21:24, Steve McIntyre wrote:
> On Tue, May 04, 2021 at 08:29:03AM +0300, Andrei POPESCU wrote:
> >On Lu, 03 mai 21, 19:52:32, Steve McIntyre wrote:
> >> 
> >> Reassigning to debian-installer, as that builds the mini.iso.
> >> 
> >> I'll take a look when I get a chance...
> >> 
> >> Oh, hmmm - do you have secure boot enabled or not on your machine?
> >
> >It's not enabled (sorry, forgot to mention).
> 
> ACK, thanks.
> 
> OK, I've fixed the problem. The issue was a missing (redirecting)
> grub.cfg in the image to redirect to the correct location where there
> grub menu etc. is located. I've just pushed code to the d-i build repo
> to add that now, and tested locally.
> 
> I think I'm probably too late to pick up the daily d-i build for
> Wednesday, but this should definitely be fixed from Thursday onwards.

It worked for me with the daily from today (didn't check the one from 
yesterday), both the text and GTK versions.

The GTK version now starts in a much lower (apparent) resolution, while 
previously it was using the full native resolution of the display (a 
Full HD TV).

Is this intended? Not that I mind, the lower resolution does help with 
readability ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

[Steve McIntyre]

On Thu, May 06, 2021 at 03:49:39PM +0300, Andrei POPESCU wrote:
>On Mi, 05 mai 21, 01:21:24, Steve McIntyre wrote:
>> On Tue, May 04, 2021 at 08:29:03AM +0300, Andrei POPESCU wrote:
>> >On Lu, 03 mai 21, 19:52:32, Steve McIntyre wrote:
>> >> 
>> >> Reassigning to debian-installer, as that builds the mini.iso.
>> >> 
>> >> I'll take a look when I get a chance...
>> >> 
>> >> Oh, hmmm - do you have secure boot enabled or not on your machine?
>> >
>> >It's not enabled (sorry, forgot to mention).
>> 
>> ACK, thanks.
>> 
>> OK, I've fixed the problem. The issue was a missing (redirecting)
>> grub.cfg in the image to redirect to the correct location where there
>> grub menu etc. is located. I've just pushed code to the d-i build repo
>> to add that now, and tested locally.
>> 
>> I think I'm probably too late to pick up the daily d-i build for
>> Wednesday, but this should definitely be fixed from Thursday onwards.
>
>It worked for me with the daily from today (didn't check the one from 
>yesterday), both the text and GTK versions.

\o/

>The GTK version now starts in a much lower (apparent) resolution, while 
>previously it was using the full native resolution of the display (a 
>Full HD TV).
>
>Is this intended? Not that I mind, the lower resolution does help with 
>readability ;)

Hmmm, odd. I've not touched that at all. But maybe it's part of the
debug that kibi is doing with fonts etc. atm...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#988140: Probably broken code example in installation-guide Appendix B.5 (Running custom commands)

[Boyuan Yang]

Source: installation-guide
Severity: normal
X-Debbugs-CC: sthiba...@debian.org

I received a user report that
https://www.debian.org/releases/bullseye/amd64/apbs05.en.html#preseed-hooks
provides an incorrect code example:

# This command is run immediately before the partitioner starts. It may be
# useful to apply dynamic partitioner preseeding that depends on the state
# of the disks (which may not be visible when preseed/early_command runs).
#d-i partman/early_command \
#   string debconf-set partman-auto/disk "$(list-devices disk | head -n1)"

The reporter claims that the $ sign should be escaped, like:

#d-i partman/early_command \
#string debconf-set partman-auto/disk "\$(list-devices disk | head -n1)"

Since I am not familiar with d-i and preseed at all, please verify whether
this makes sense. If this is a problem, it exists in the installation-guide of
both Debian Buster and Debian Bullseye. If it's not, please feel free to close
this bug report.

-- 
Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#887139: installation-reports: Debian Installer Bullseye RC 1 damages UEFI setup on Dell Latitude 5510

[Thaddeus H. Black]

Package: installation-reports
Followup-For: Bug #887139

Dear Maintainer,

Paul Gevers has asked subscribers to debian-devel-announce to try out
the debian-installer, so I tried it.

-- Package-specific info:

Boot method: netinst.iso on a USB flash drive
Image version: 
https://cdimage.debian.org/cdimage/bullseye_di_rc1/amd64/iso-cd/debian-bullseye-DI-rc1-amd64-netinst.iso
 as downloaded 2021-05-06 14:00 UTC
Date: 2021-05-06 14:30 UTC

Machine: Dell Latitude 5510 laptop, Intel Comet Lake i7-10610U CPU with 
associated Intel chipset, Intel Wifi, Intel integrated graphics

Partitions: the command "df -Tl" reports the following while *buster* is
running.  Is this information useful, though?  I include it only because
installation-report specifically requests it.
Filesystem  Type  1K-blocks  Used Available Use% Mounted on
udevdevtmpfs   16223268 0  16223268   0% /dev
tmpfs   tmpfs   3247352  9972   3237380   1% /run
/dev/nvme0n1p9  ext4  263174212  17009396 232726660   7% /
tmpfs   tmpfs  16236752 69528  16167224   1% /dev/shm
tmpfs   tmpfs  5120 4  5116   1% /run/lock
tmpfs   tmpfs  16236752 0  16236752   0% /sys/fs/cgroup
/dev/nvme0n1p11 ext4 1254007444 451985672 738251968  38% /arc
/dev/nvme0n1p1  vfat 50790411397904  22% /boot/efi
tmpfs   tmpfs   3247348 12756   3234592   1% /run/user/1000
/dev/sda1   iso9660  369664369664 0 100% /media/thb/Debian 
bullseye-DI-rc1 amd64 n

Partitions: the command "fdisk -l" reports the following. This may be
more informative than the above.  Buster is installed on p9; bullseye,
on p12.
Disk /dev/nvme0n1: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Disk model: INTEL SSDPEKNW020T9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E40D7C7A-2099-49F3-808B-FB583DFE4C6C
Device   StartEndSectors   Size Type
/dev/nvme0n1p1204810260471024000   500M EFI System
/dev/nvme0n1p2 10260481288191 262144   128M Microsoft reserved
/dev/nvme0n1p3 1288192  774707199  773419008 368.8G Microsoft basic data
/dev/nvme0n1p4  3995934720 39979622392027520   990M Windows recovery 
environment
/dev/nvme0n1p5  3997962240 40007598072797568   1.3G Windows recovery 
environment
/dev/nvme0n1p6   774709245  774709245  1   512B Microsoft basic data
/dev/nvme0n1p7   774709246  774709246  1   512B Microsoft basic data
/dev/nvme0n1p8   774709247  774709247  1   512B Microsoft basic data
/dev/nvme0n1p9   774709248 1311580159  536870912   256G Linux filesystem
/dev/nvme0n1p10 1311580160 1378689023   6710886432G Linux swap
/dev/nvme0n1p11 1378689024 3928825855 2550136832   1.2T Linux filesystem
/dev/nvme0n1p12 3928825856 3995934719   6710886432G Linux filesystem

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [ ]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[O]

Comments/Problems:

The installation went as expected.  Unfortunately, after installation,

* bullseye testing (newly installed) booted normally but
* buster stable (already installed) booted abnormally.

Installation of bullseye on one partition disrupts buster on another
partition.  Insofar as bullseye's installer was not asked by me to touch
buster's partition, I assume that the problem is a UEFI problem.
It may be that bullseye's installer damages UEFI.

Buster still boots, but takes two or three minutes instead of the
usual 20 seconds or so.  Buster's boot stalled so long, I had time to
write down the messages that appeared live on the screen during the
stall (though I cannot promise that I have precisely copied all the
hexidecimal numbers and such):
fsckd-cancel-msg:Press Ctrl-C to cancel all filesystem checks in progress
[35.99] ioremap-errorr for 0x7698-0x76981000, requested 0x2, got 0x0
[some messages about iwlwifi]
[some messages about Plymouth]
[37.99] tpm tpm0: tpm_try_transmit send(): error -62
[37.99] tpm tpm0: [Firmware bug]: TPM interrupt not working, polling instead
[   ***   ] A start job is running for 
/dev/disk/by-uuid/ef70f152-a70a-4d70-8402-a3e2a0c6db90 (59s / 1min 30s)

To emphasize, the above messages appear during a stall when *buster*
boots after *bullseye* is installed.  There is no stall when bullseye
boots.

-- 

The following were generated while buster was running, not bullseye.

==
Installer lsb-r

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

[Cyril Brulebois]

Steve McIntyre  (2021-05-06):
> Hmmm, odd. I've not touched that at all. But maybe it's part of the
> debug that kibi is doing with fonts etc. atm...

I certainly didn't touch anything yet: unless otherwise specified, my
testing happens before touching the archive.

If one wants to look into it, we have build logs alongside images at:
  https://d-i.debian.org/daily-images/

and also MANIFESTS{,.udeb} files, in case the set of udebs changed.

(I only see a single change in the master branch for the installer, from
Steve as alluded to earlier in this thread.)


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


signature.asc
Description: PGP signature

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

[Andrei POPESCU]

On Jo, 06 mai 21, 23:55:07, Cyril Brulebois wrote:
> Steve McIntyre  (2021-05-06):
> > Hmmm, odd. I've not touched that at all. But maybe it's part of the
> > debug that kibi is doing with fonts etc. atm...
> 
> I certainly didn't touch anything yet: unless otherwise specified, my
> testing happens before touching the archive.
> 
> If one wants to look into it, we have build logs alongside images at:
>   https://d-i.debian.org/daily-images/
> 
> and also MANIFESTS{,.udeb} files, in case the set of udebs changed.
> 
> (I only see a single change in the master branch for the installer, from
> Steve as alluded to earlier in this thread.)

It's probably better like this (and the rc1 netinst works the same), 
especially for compatibility with various displays.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature