Bug#931852: [armel/marvell] cmdline mtd partition map without effect

[Ben Hutchings]

On Mon, 2019-07-15 at 09:31 +0200, Chris Laif wrote:
> On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings  wrote:
> > On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote:
> > > Package: debian-installer
> > > Version: 20190702
> > > 
> > > I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
> > > 
> > > The mtd partition map ('mtdparts' cmdline variable) has no effect
> > > (even with 'cmdline' module loaded):
> > [...]
> > 
> > What if you replace "mtdparts=" with "cmdlineparts.mtdparts="?
> > 
> 
> With "cmdlineparts.mtdparts" it does not work:
[...]
> With "cmdlinepart.mtdparts" (without trailing "s", equal to the name
> of the kernel-module) it works!:

Sorry for the typo.

> ~ # cat /proc/cmdline
> console=ttyS0,115200
> cmdlinepart.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
> ~ # cat /proc/mtd
> dev:size   erasesize  name
> mtd0: 000a 4000 "uboot"
> mtd1: 0001 4000 "env"
> mtd2: 0050 4000 "uimage"
> mtd3: 01a4 4000 "rootfs"
> ~ #
> 
> This seems to break backwards compatibility for a lot of devices
> (Google shows lots of hits for "mtdparts=" and only a handful for
> "cmdlinepart.mtdparts", so I think nobody is using the latter).
>
> I wonder what's the best way to have a both Stretch and Buster
> compatible cmdline. A quick test shows that "cmdlinepart.mtdparts"
> works with Stretch, too (even Stretch does not have a seperate
> "cmdlinepart" module). Do you have any recommendations?

I think that "cmdlinepart.mtdparts" will work whether or not the driver
is actually a module.  But I accept it would be better if "mtdparts"
also continued to work when the driver is a module.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.




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

Bug#932149: Early segfault in steal-ctty on Xen DomU install

[Martin Samuelsson]

Package: installation-reports

Boot method: xl create buster.cfg
Image version: Multiple. Please see below.
Machine: Xen DomU (on HP Proliant Dom0)
Memory: 512M
Partitions: N/A (10G allocated for xvda)

Base System Installation Checklist:
[O] = OK, [E] = Error, [ ] = didn't try it

Initial boot:   [E] Kernel boots, d-i fails to launch.
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Attempting to install Buster on a freshly created Xen DomU fails early with 
the following in the log:


[2.698206] Run /init as init process
[2.83] xen_netfront: Initialising Xen virtual ethernet driver
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 69: can't create /var/run/console-devices: 
nonexistent directory
/sbin/reopen-console: line 69: can't create /var/run/console-devices: 
nonexistent directory
/sbin/reopen-console: line 71: can't create /var/run/console-preferred: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
/sbin/reopen-console: line 26: can't create /var/log/reopen-console: 
nonexistent directory
cat: can't open '/var/run/console-preferred': No such file or directory
[2.957523] steal-ctty[125]: segfault at 0 ip 7fbce02c4160 sp 
7ffe4dde3830 error 4 in libc.so.6[7fbce021f000+148000]
[2.957551] Code: 8b e8 74 36 04 00 0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41 
54 53 48 83 ec 48 64 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 <80> 3f 00 0f 84 
47 01 00 00 49 89 f4 be 2f 00 00 00 48 89 fb 49 89
Segmentation fault
cat: can't open '/var/log/reopen-console': No such file or directory
rm: can't remove '/var/log/reopen-console': No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory

The last error, about brltty-Xorg, seems to be repeated perpetually.  
Proceeding with installation is not possible. Pressing Ctrl-C yields no 
visible result.


This happens both with the release image from:

http://deb.debian.org/debian/dists/buster/main/installer-amd64/20190702/images/netboot/xen/

and the latest nightly built from:

https://d-i.debian.org/daily-images/amd64/20190715-00:24/netboot/xen/

Providing "-- console=hvc0", "-- console=tty0", "-- console=" and "" as 
values for the 'extra' config variable makes no difference. No additional 
config options in xl.cfg, apart from pointing out kernel and initial 
ramdisk.


To the best of my understanding, this issue is not mentioned in neither the 
Release Notes nor the Installation Guide for Buster. The Xen page on 
Debian's wiki is also a bit thin on Buster specific details.


For what it's worth Dom0 is running Stretch with Xen 4.8, and has several 
fully functional DomU instances also running Stretch.


One might guess #768657 is related in some way, but unfortunately I do not 
currently fully understand it. I'm reluctant to post directly to it since it 
seems too old (November 2014) to be causing failure only for Buster, but 
please feel free to merge this report with it if confident the issue is 
caused by the same root cause.

--
/Martin

Bug#932130: ODP: Bug#932130: Package: Debian-installer

[Steve McIntyre]

[ Responding to the bug# too so other people can see the information ]

Thanks!

On Mon, Jul 15, 2019 at 05:34:32PM +0200, Mmobilea wrote:
>I have lenovo thinkpad t410 laptop.
>
>Processor: Intel core i5 520M 2,4GHZ, 4GB RAM, Disk ssd sandisk 120GB,
>soundcard conexant cx20585
>
> 
>
>Wysłane z aplikacji Poczta dla Windows 10
>
> 
>
>Od: Steve McIntyre
>Wysłano: poniedziałek, 15 lipca 2019 17:21
>Do: Mmobilea a; 932...@bugs.debian.org
>Temat: Re: Bug#932130: Package: Debian-installer
>
> 
>
>On Mon, Jul 15, 2019 at 05:07:59PM +0200, Mmobilea a wrote:
>
>>Package: Debian-installer
>
>>Version: 20190702
>
>>Severity: high
>
>>I tried to install debian buster, from the accessibility mode, and it shows
>"No
>
>>sound card detected." I add, that in stretch all works fine.
>
> 
>
>Hi!
>
> 
>
>We're trying to track down what's causing this bug, as a few people
>
>have seen things like this. Can I ask what computer you have, please?
>
> 
>
>--
>
>Steve McIntyre, Cambridge, UK.    st...@einval.com
>
>Can't keep my eyes from the circling sky,
>
>Tongue-tied & twisted, Just an earth-bound misfit, I...
>
> 
>
> 
>
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#932130: Package: Debian-installer

[Steve McIntyre]

On Mon, Jul 15, 2019 at 05:07:59PM +0200, Mmobilea a wrote:
>Package: Debian-installer
>Version: 20190702
>Severity: high
>I tried to install debian buster, from the accessibility mode, and it shows "No
>sound card detected." I add, that in stretch all works fine.

Hi!

We're trying to track down what's causing this bug, as a few people
have seen things like this. Can I ask what computer you have, please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#932130: Package: Debian-installer

[Mmobilea a]

Package: Debian-installer
Version: 20190702
Severity: high
I tried to install debian buster, from the accessibility mode, and it shows
"No sound card detected." I add, that in stretch all works fine.

Re: Dropping Release and Release.gpg support from APT

[Philipp Kern]

On 2019-07-09 20:53, Julian Andres Klode wrote:

we currently have code dealing with falling back from InRelease
to Release{,.gpg} and it's all a bit much IMO. Now that buster
has been released with an InRelease file, the time has IMO come for
us to drop support for the old stuff from APT!

Timeline suggestion
---
now add a warning to apt 1.9.x for repositories w/o InRelease,
but Release{,.gpg}
Aug/Sep turn the warning into an error, overridable with an option 
(?)

Q1 2020 remove the code

My idea being that we give this a cycle in the Ubuntu 18.10 stable
release before we drop it, so people are ready for it.

Why remove it?
--
* It's annoying UX to have repositories with Release files and the 
"Ign" lines

* Handling the fallback from InRelease to Release{,.gpg} involves some
abstractions
  and logic and the less logic we have in security-relevant file
fetching, the better


One thing worth noting in case we drop support for generating the files: 
It looks like choose-mirror (no bug found) and net-retriever (bug in 
[1]) in d-i still use Release and not InRelease. Found by investigating 
annoying file races internally that would have been solved by 
InRelease...


Kind regards
Philipp Kern

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926035

Re: Growing the size of e2fsprogs-udeb by ~150k

[Theodore Y. Ts'o]

On Mon, Jul 15, 2019 at 02:41:55PM +0200, Cyril Brulebois wrote:
> Just had a look at your package (sitting in NEW so using a local build
> in an unclean development chroot). Why use .shlibs.local overrides? At
> least the udeb part seems counter-productive, as that's stripping away
> the versions, which can be important at times.
> 
> Results before/after git rm debian/e2fsprogs-udeb.shlibs.local:
> 
> Control files of package e2fsprogs-udeb: lines which differ (wdiff format)
> --
> Depends: [-libblkid1-udeb,-] {+libblkid1-udeb (>= 2.31),+} libc6-udeb (>= 
> 2.28), libuuid1-udeb {+(>= 2.31)+}
>

For e2fsprogs.shlibs.local, it's because I want to force an exact
correspondance between the version of libextfs2 and e2fsprogs, since
some of the programs, e2fsck in particular can be very sensitive to
behavioral changes, and for safety's sake I wanted to restrict it to
what I am reguarly regression testing.

For e2fsprogs-udeb.shlibs.local, it was introduced in commit
7a15db238194 ("Applied NMU patch to fix Debian bugs #203056 and
#203058") to fix a d-i issue sixteen years ago.  I'm not sure what the
true root cause which caused it to be necessary, but certainly appears
not to be necessary any more.  :-)

- Ted

commit 7a15db238194e943150ec32c4cef8e48435f0637
Author: Theodore Ts'o 
Date:   Tue Jul 29 22:15:33 2003 -0400

Applied NMU patch to fix Debian bugs #203056 and #203058

diff --git a/debian/changelog b/debian/changelog
index 6d5ecbbf..048bcd74 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+e2fsprogs (1.34-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * don't call ldconfig in udebs.
+  * fix dependencies of e2fsprogs-udeb.
+
+ -- Bastian Blank   Tue, 29 Jul 2003 12:11:54 +0200
+
 e2fsprogs (1.34-1) unstable; urgency=low
 
   * New upstream version.
diff --git a/debian/e2fsprogs-udeb.shlibs.local 
b/debian/e2fsprogs-udeb.shlibs.local
new file mode 100644
index ..2c6e6fa8
--- /dev/null
+++ b/debian/e2fsprogs-udeb.shlibs.local
@@ -0,0 +1,6 @@
+libblkid 1 libblkid1-udeb
+# force the dependency to libblkid1-udeb, even if it don't include the lib
+libcom_err 2 libblkid1-udeb
+libuuid 1 libblkid1-udeb
+libext2fs 2 libblkid1-udeb
+libe2p 2 libblkid1-udeb
diff --git a/debian/rules b/debian/rules
index 45c6167d..b3081528 100644
--- a/debian/rules
+++ b/debian/rules
@@ -329,7 +329,7 @@ binary-arch: install install-udeb
dh_compress
dh_fixperms
 
-   dh_makeshlibs
+   dh_makeshlibs -Ne2fsprogs-udeb -Nlibblkid1-udeb
dh_makeshlibs -plibcomerr${COMERR_SOVERSION} \
-V 'libcomerr2 (>= 1.33-3)'
 
@@ -337,6 +337,8 @@ binary-arch: install install-udeb
dh_shlibdeps -l${stdbuilddir}/lib
dh_shlibdeps -pe2fsprogs -l${stdbuilddir}/lib \
-u"-Ldebian/e2fsprogs.shlibs.local"
+   dh_shlibdeps -pe2fsprogs-udeb -l${stdbuilddir}/lib \
+   -u"-Ldebian/e2fsprogs-udeb.shlibs.local"
 
dh_gencontrol -Ncomerr-dev -Nss-dev -Nuuid-dev \
-Ne2fsprogs-udeb -Nlibblkid1-udeb

Re: Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Laura Arjona Reina]

Hi all

El 15/7/19 a las 12:36, Holger Wansing escribió:

Hi,

Steve McIntyre  wrote:

On Sat, Jun 22, 2019 at 01:05:01PM +0200, Baptiste BEAUPLAT wrote:

Tags: patch

Added patch:
https://salsa.debian.org/installer-team/installation-guide/merge_requests/7


Merged, thanks for your contribution!


This has been fixed in the installation-guide package, version 20190622
(currently in stable) has the fix.
However, https://www.debian.org/releases/buster/example-preseed.txt
still does not have it.

So CC'ing debian-www for assistance



I've had a look at the www-master.debian.org
I see that the installation guide has been generated on 20190623 but the 
example-preseed.txt file has date 20190324.


I guess something went wrong with that file, and since there has not been 
changes in the installation guide since then, the build has not been retried.


In our cron job, I've temporarily removed the part where it checks if we need to 
build or not the guide, to force a rebuild today, and thus have logs to see what 
happens to that file.


I'll have a look later today to the logs and will update the bug.

Kind regards,
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Re: Scheduling 10.1 and maybe 9.10

[Donald Norwood]

Hi,

On 7/14/19 2:35 PM, Jonathan Wiltshire wrote:
> Hi,
> 
> So, the first point release for buster would normally be about a month
> after release, or something like 3rd August. But I'm aware that already
> doesn't work for some people, so we might have to get a bit creative with
> it.
> 
> Please indicate your availablility out of:
> 
>  - August 3rd

Slightly workable for the 3rd.

>  - August 10th
>  - August 17th
> 
Vacations.
> and failing those, let's look ahead as far as:
> 
>  - August 24th
>  - Auguest 31st
>  - September 7th

September 7th works best for Press as we will both be around.
> 
> We also have a point release of 9.10 to fit in some time - would the same
> day or adjacent weekends be preferable?
> 
> Thanks,
> 
> --
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> 

-- 
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05



signature.asc
Description: OpenPGP digital signature

Re: Growing the size of e2fsprogs-udeb by ~150k

[Cyril Brulebois]

Theodore Ts'o  (2019-07-12):
> Sounds good to me.  I've managed to dh'ified e2fsprogs debian/rules
> file and am currently testing it in preparation for a new release.  If
> we need to add it back later, it should be easier now that
> debian/rules file has shrunk down from ~500 lines to ~200 lines.  :-)

Just had a look at your package (sitting in NEW so using a local build
in an unclean development chroot). Why use .shlibs.local overrides? At
least the udeb part seems counter-productive, as that's stripping away
the versions, which can be important at times.

Results before/after git rm debian/e2fsprogs-udeb.shlibs.local:

Control files of package e2fsprogs-udeb: lines which differ (wdiff format)
--
Depends: [-libblkid1-udeb,-] {+libblkid1-udeb (>= 2.31),+} libc6-udeb (>= 
2.28), libuuid1-udeb {+(>= 2.31)+}



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


signature.asc
Description: PGP signature

Re: Debian 11 and iptables

[Cyril Brulebois]

Hi Arturo,

And thanks for contacting us.

Arturo Borrero Gonzalez  (2019-07-15):
> AFAIK iptables is installed by default by the debian installer up to
> Debian 10 Buster.

Right, because it's Priority: important.

> I would like to start exploring dropping the iptables default for
> Debian 11. I'm referring to don't install the package by default in
> any way:
> 
> * not as part of the base operating system
> * not in any task by tasksel
> * downgrade priority/importance of the package (currently Priority:
>   important)

I don't think it's referenced directly anywhere except through its
priority? (I'm going to pretend I'm not seeing the woody/sarge and
hoary/warty scripts in debootstrap. ;))

> If we still need a default low-level firewalling tool installed by
> default I would suggest we switch to nftables. Also, firewalld should
> be considered as a sensible wrapper at this point, more or less in
> sync with what other distros are doing.
> 
> So my proposal would be to do something like:
> 
> * raise package priority of nftables
> * include nftables in debian installer/base operating system/tasksel

Wouldn't bumping its priority be sufficient, together with lowering it
for iptables?

> * introduce firewalld at least into desktop tasksel tasks

Maybe seeking some kind of consensus on dd@ would be nice before this is
considered? At least asking for some feedback from desktop maintainers
would be more than welcome.

> PS: By default Debian Buster already uses iptables-nft, a version of
> iptables that uses the nf_tables kernel engine.

For those who didn't know about that part, see the release notes, or
update-alternatives --config iptables; one can choose between the legacy
and the nft variants (the former is the historical implementation, the
latter is the default starting with buster).


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


signature.asc
Description: PGP signature

Debian 11 and iptables

[Arturo Borrero Gonzalez]

Hi there,

AFAIK iptables is installed by default by the debian installer up to Debian 10
Buster.

I would like to start exploring dropping the iptables default for Debian 11. I'm
referring to don't install the package by default in any way:

* not as part of the base operating system
* not in any task by tasksel
* downgrade priority/importance of the package (currently Priority: important)

If we still need a default low-level firewalling tool installed by default I
would suggest we switch to nftables. Also, firewalld should be considered as a
sensible wrapper at this point, more or less in sync with what other distros are
doing.

So my proposal would be to do something like:

* raise package priority of nftables
* include nftables in debian installer/base operating system/tasksel
* introduce firewalld at least into desktop tasksel tasks

regards

PS: By default Debian Buster already uses iptables-nft, a version of iptables
that uses the nf_tables kernel engine.

Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Holger Wansing]

Hi,

Steve McIntyre  wrote:
> On Sat, Jun 22, 2019 at 01:05:01PM +0200, Baptiste BEAUPLAT wrote:
> >Tags: patch
> >
> >Added patch:
> >https://salsa.debian.org/installer-team/installation-guide/merge_requests/7
> 
> Merged, thanks for your contribution!

This has been fixed in the installation-guide package, version 20190622
(currently in stable) has the fix.
However, https://www.debian.org/releases/buster/example-preseed.txt
still does not have it.

So CC'ing debian-www for assistance


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#931852: [armel/marvell] cmdline mtd partition map without effect

[Chris Laif]

On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings  wrote:
> On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote:
> > Package: debian-installer
> > Version: 20190702
> >
> > I'm using the current Buster kernel/initrd on my Seagate Blackarmor NAS.
> >
> > The mtd partition map ('mtdparts' cmdline variable) has no effect
> > (even with 'cmdline' module loaded):
> [...]
>
> What if you replace "mtdparts=" with "cmdlineparts.mtdparts="?
>

With "cmdlineparts.mtdparts" it does not work:

~ # cat /proc/cmdline
console=ttyS0,115200
cmdlineparts.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
~ # cat /proc/mtd
dev:size   erasesize  name
mtd0: 0200 4000 "orion_nand"
~ #

With "cmdlinepart.mtdparts" (without trailing "s", equal to the name
of the kernel-module) it works!:

~ # cat /proc/cmdline
console=ttyS0,115200
cmdlinepart.mtdparts=orion_nand:0xa@0x0(uboot),0x01@0xa(env),0x50@0xc(uimage),0x1a4@0x5c(rootfs)
~ # cat /proc/mtd
dev:size   erasesize  name
mtd0: 000a 4000 "uboot"
mtd1: 0001 4000 "env"
mtd2: 0050 4000 "uimage"
mtd3: 01a4 4000 "rootfs"
~ #

This seems to break backwards compatibility for a lot of devices
(Google shows lots of hits for "mtdparts=" and only a handful for
"cmdlinepart.mtdparts", so I think nobody is using the latter).

I wonder what's the best way to have a both Stretch and Buster
compatible cmdline. A quick test shows that "cmdlinepart.mtdparts"
works with Stretch, too (even Stretch does not have a seperate
"cmdlinepart" module). Do you have any recommendations?

Thanks,
Chris