Bug: Buster 10.0 Testing 20190617 Image LiveCD Will Not Boot

2019-06-19 Thread John L. Males 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Using the LiveCD LXDE image of 20190617 Will not boot to Live
Image.

Messages flash very quickly that make it difficult to see the
actual messages.  Adding the "debug" option to the boot command
line for the LiveCD boot has no impact on the speed or type of
error occurring.

The best I can see from several attempts to boot the LiveCD
image is some sort of error in the options for booting the
LiveCD image.

If one chooses any other menu option to boot such as installing
Debian there is no error and the image boots to the install or
 intended menu item of initial boot splash screen to select
what one wants.

This is actually not strictly a Buster  Testing 10.x error.
This is fact also occurs more selectively with Debian Stretch
9.9.0 and many prior versions.  I will skip the messy details
of how I have played the bugs against each other to workaround
what is in essence the same bug.

Same system has even messier problems trying to boot back to
Debian Stretch 9.9.0 of system with LiveCD Buster 10 Testing
image.  I will skip the messy details as I believe if the real
bug(s) are fixed then the collateral damage messy bugs will
not occur.

This posting to mailing list is because based on the "Debian 10
- -- Reporting Problems" web page:



page the buckets are for install related issues, upgrade
issues, and post install issues.  This is a LiveCD issue so I
am at loss where to report and how later have the fixes
cascaded back to Stretch 9.x.

Also would be helpful how one can secure the actual error
message being flashed on the splash screen so fast it defies
even trying to video record with cell phone and clearly cannot
take a pic of the messages.

As FYI I also tried different combinations of removing the
keywords for booting the LiveCD after the initrd keyword.  So
clearly the initrd, kernel image et al were not touched as part
of these attempts.


John L. Males
Toronto, Ontario
Canada
19 June 2019 23:55




2019-06-20 03:35:18.609634134+-UTC Time:
1561001718.613086915

20 Jun 03:35:18 ntpdate[29356]: ntpdate 4.2.8p10@1.3728-o Sun
Feb 25 21:22:56 UTC 2018 (1)

20 Jun 03:35:33 ntpdate[29364]: step time server 206.108.0.133
offset -0.005563 sec

Linux 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12)

Modified Debian GNU/Linux 9.9 (stretch)
(Alternative to Debian determined, work in progress)

cat /proc/cpuinfo (Selected):

model name  : AMD E-350 Processor

vmstat -s:

 16026156 K total memory
  3707556 K used memory
 10558284 K active memory
  3157544 K inactive memory
  1827348 K free memory
   289836 K buffer memory
 10201416 K swap cache
0 K total swap
0 K used swap
0 K free swap
140415048 non-nice user cpu ticks
 52438258 nice user cpu ticks
153832655 system cpu ticks
371254320 idle cpu ticks
  2462710 IO-wait cpu ticks
0 IRQ cpu ticks
  3387242 softirq cpu ticks
0 stolen cpu ticks
289202750 pages paged in
 30526348 pages paged out
0 pages swapped in
0 pages swapped out
   1995463735 interrupts
   2154594133 CPU context switches
   1557283473 boot time
364026356 forks

/proc/vmstat (Selected):

pgpgin 289202750
pgpgout 30526348
pswpin 0
pswpout 0
pgfree 45241683448
pgfault 75901284377
pgmajfault 904106

/proc/meminfo (Selected):

Mlocked: 128 kB
VmallocTotal:   34359738367 kB
VmallocChunk:  0 kB
HugePages_Total:   0

vmstat --partition /dev/sda8 (Swap):

partition was not found

sar -b:

Linux 4.9.0-9-amd64 (debian)06/20/2019
_x86_64_(2 CPU)

12:00:01 AM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s
pgscank/s pgscand/s pgsteal/s%vmeff

03:15:01 AM  0.00874.00  21904.06  0.00
12263.56  6.20  0.00  6.20100.00 03:25:01
AM  0.00  0.00  22597.23  0.00  12364.00
0.00  0.00  0.00  0.00 03:35:01 AM  0.00
0.00  21889.06  0.00  11518.24  0.00  0.00
0.00  0.00 Average: 0.47251.14  22379.46
0.00  12231.98 38.05  0.04 38.09100.00

ps -A:

%CPU  START   TIME  C CLS COMMAND TIME  NI   PID
POL PRISZ   RSSVSZ  SIZE  MAJFL  MINFL SCH STAT
TIME WCHAN

 0.0 May  8  51:09  0  TS kswapd0 00:51:09   035
TS   19 0 0  0 0  0  0   0 S
00:51:09 -

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQxRId2q5JPHFiozTr5X9dS0HpoEAUCXQsDnwAKCRD5X9dS0Hpo
ECGZAJ9jOD8Ov3PhwOgkod3WRW2B5V5wsQCcDy4rRq4Da0Zo1iJln/9Q3DUbkwc=
=fEKA
-END PGP SIGNATURE-

Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-19 Thread ButterflyOfFire 
Hi,
I think it is okay for those diacritics.
Regards,

‐‐‐ Original Message ‐‐‐
Le mardi 18 juin 2019 22:26, Holger Wansing  a écrit :

> Hi,
>
> Samuel Thibault sthiba...@debian.org wrote:
>
> > Hello,
> > Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit:
> >
> > > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing:
> > >
> > > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault:
> > > >
> > > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit:
> > > > >
> > > > > > > > "لاحقاً"
> > > > > >
> > > > > > This word means "later" and can be replaced by "لاحقا".
> > > > >
> > > > > That avoids the issue here indeed. I however see it used in various
> > > >
> > > > Hmm.
> > > > There has been no changing in the ar.po of partman-auto
> > > > for 3 years now (JFTR), thus the real problem seems to be
> > > > sitting somewhere else ...
> > >
> > > How should we proceed here?
> > > Since we are late in the freeze, and it's most probably not that
> > > easy to find out what happened and what the real issue is:
> > > should we go with the "work-around" proposed by
> > > Butterflyoffire and confirmed to fix the issue by Samuel?
> >
> > Personally, I don't think I'll have the time to debug what is actually
> > happening inside gtk until the release, so even if it's ugly, I guess
> > the browntape fix is the least worst I can come up with.
>
> That looks fair.
> I have committed the proposed fix now.
>
> @butterflyoffire: could you please take a look at
> https://salsa.debian.org/installer-team/d-i/commit/fa17b7afffb2ee4888a371efa4153c5c075915e7
> to double-check if the fix is fine by you?
> Thanks!
>
> Holger
>
>
> -
>
> Holger Wansing hwans...@mailbox.org
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Bug#930684: pbuilder: creation of build env fails when run inside Docker container

2019-06-19 Thread Thorsten Glaser 
Tobias Junghans dixit:

>> But with {cow|p}builder --login --save-after-login you can
>> upgrade the base to buster inside pbuilder.
>
>It's not about the pbuilder environment itself but the Docker container used 
>for invoking pbuilder/debootstrap. Using a stretch-based Docker container and 
>debootstrapping Buster works fine.

Ah okay. Yes, that’s supported, a difference of only one version,
as long as the host has (at least) the stretch kernel.

As for the other things, the debootstrap people might look at it.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#894034: marked as done (debian-installer: mount point /boot/efi)

2019-06-19 Thread Debian Bug Tracking System 
Your message dated Wed, 19 Jun 2019 11:43:22 +0100
with message-id <20190619104322.ga3...@tack.einval.com>
and subject line Re: Bug#894034: debian-installer: mount point /boot/efi
has caused the Debian Bug report #894034,
regarding debian-installer: mount point /boot/efi
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
894034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894034
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-installer
Version: 20171204
Severity: normal

I am installing Debian buster armhf on a BananaPi.
This is the image I am using:
debian-testing-armhf-netinst.iso2018-03-25 18:24

Grub expects that the EFI partition is mounted as /boot/efi.
When setting up the partions some default paths are offered but
/boot/efi is missing.
Please, add /boot/efi to the list of default paths.

Best regards

Heinrich Schuchardt
--- End Message ---
--- Begin Message ---
On Mon, Mar 26, 2018 at 05:20:41PM +0100, Ben Hutchings wrote:
>On Sun, 2018-03-25 at 22:20 +0200, Heinrich Schuchardt wrote:
>> debian-installer/packages/partman-efi/check.d/efi starts with these lines:
>> 
>> if [ ! -d /proc/efi ] && [ ! -d /sys/firmware/efi ]; then
>> exit 0
>> fi
>> 
>> if [ -f /var/lib/partman/ignore_uefi ]; then
>> exit 0
>> fi
>> 
>> 
>> So it seems installation for EFI is only supported if the installer is
>> booted via EFI.
>
>This is because EFI booting normally requires setting variables through
>EFI runtime services.
>
>> The armhf netinstall iso does not make use of the UEFI implementation of
>> u-boot in contrast to what Suse and Fedora do. So we get stuck in a
>> legacy mode of booting. This is unsatisfactory if we want to setup a
>> multi-boot installation.
>
>That should be fixed, presumably through changes to debian-cd.

And it has - we have UEFI armhf support included now. Closing...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss--- End Message ---

Bug#930684: pbuilder: creation of build env fails when run inside Docker container

2019-06-19 Thread Tobias Junghans 
Am Dienstag, 18. Juni 2019, 21:10:53 CEST schrieb Thorsten Glaser:
> Tobias Junghans dixit:
> >I tried to upgrade my Docker-based pbuilder containers from stretch to
> 
> Erm… why do you use chroots inside of chroots? That’s… tricky.

Simple because we use Gitlab Runners with the builtin Docker Executor 
(https://docs.gitlab.com/runner/executors/docker.html) for running all kinds 
of jobs in a generic manner. Depending on the project individual pre-built 
Docker images (specified in the CI config) providing the desired build tools 
and toolchains are used. The jobs for building Debian packages use a Docker 
container with Debian and pbuilder installed.

This used to work for years but for Buster-based containers (i.e. pbuilder and 
debootstrap from Buster) it doesn't any longer.


> >mount: failed to read mtab: No such file or directory
> 
> This might be a container issue.

The mounts are fine before running pbuilder/debootstrap. Afterwards proc is 
not mounted even in the Docker container. The state of the container and its 
mounts shouldn't change when running debootstrap. I also saw Docker/container-
related changes between 1.0.89 (stretch) and buster (1.0.114) which likely 
cause the misbehaviour:

https://salsa.debian.org/installer-team/debootstrap/commit/
5a0f16664066b24c42c074643a4ca178890d7af7
https://salsa.debian.org/installer-team/debootstrap/commit/
0962af1527a1ba0e996a0b442b159b4dbf164988
https://salsa.debian.org/installer-team/debootstrap/commit/
1e7549c57c0f15816c89c4f243051785ca383be9

> >mount: /proc: mount(2) system call failed: Too many levels of symbolic
> >links.
> Check if /proc outside of pbuilder but inside the container is right.

/proc in the container is fine, see first output of "cat /proc/mounts
" in by original bug report.
 
> But with {cow|p}builder --login --save-after-login you can
> upgrade the base to buster inside pbuilder.

It's not about the pbuilder environment itself but the Docker container used 
for invoking pbuilder/debootstrap. Using a stretch-based Docker container and 
debootstrapping Buster works fine.

Thanks and best regards

Tobias