Bug#995209: d-i: partman-basicfilesystems: missing btrfs mount option descriptions

[Pascal Hambourg]

Package: partman-basicfilesystems
Version: 156
Tags: patch

Hello d-i team,

The following mount options are advertised in mountoptions/btrfs from 
package partman-btrfs but lack descriptions in 
debian/partman-basicfilesystems.templates :


nodatasum
nodatacow
nobarrier
compress
ssd
noacl
notreelog
flushoncommit

Also, select_mountoptions wrongly stops reading the option list when 
encountering a missing description, skipping all remaining options 
instead of just skipping options with no description. I spotted this 
because the "discard" option is not available for btrfs even though it 
has a description and is available for other filesystems which support 
it (ext4, fat*).


For now, the attached patch does not skip any options and just shows 
bare options instead of the missing descriptions.


Q: Which package should provide the descriptions for filesystem-specific 
mount options ? partman-basicfilesystems or partman- ?
--- a/select_mountoptions	2021-07-23 19:14:05.0 +0200
+++ b/select_mountoptions	2021-09-27 22:37:28.609316256 +0200
@@ -24,12 +24,13 @@
 for op in $(cat $optionsfile); do
 	if db_metaget partman-basicfilesystems/text/$op description && \
 	   [ "$RET" ]; then
-		all_options="${all_options:+$all_options, }$op"
-		descriptions="${descriptions:+$descriptions, }$RET"
+		:
 	else
-		logger -t partman "Error: no description for mount option $op found; skipping"
-		break
+		logger -t partman "Error: no description for mount option $op found"
+		RET="$op"
 	fi
+	all_options="${all_options:+$all_options, }$op"
+	descriptions="${descriptions:+$descriptions, }$RET"
 
 	if [ -f $part/options/$op ]; then
 		full_options="${full_options:+$full_options,}$(cat $part/options/$op)"

Re: partman, growlight, discoverable partitions, and fun

[Metztli Information Technology]

On 9/27/21 4:01 AM, John Paul Adrian Glaubitz wrote:

Hello Nick!

On 9/26/21 16:29, Nick Black wrote:

I'd be delighted to support them -- as in, I am honestly eager
to add ATARI support; that sounds awesome -- I just need some
way to test the implementations, either via someone running it
on the environment, or getting access to such a machine.

There are emulators available for Atari such as Aranym. And emulators
available for Amiga such as fs-uae. FWIW, parted should contain everything
needed to be able to implement your own support for these partition tables.


I think it makes little sense to not use libparted as it already supports
all common and less common partition types and reimplementing everything
that libparted makes little sense to me.

parted did not have ZFS support when I embarked on this project
(it appears to have it now). i would not be opposed to
leveraging libparted if it presents a definite advantage;
supporting more partition types, so long as it exposes an API i
can easily work with, would be such an advantage.

Well, using a missing feature in the past against parted that is present
there is not such a good argument against using it, to be honest.


i do note that libparted2 is 621K in the archive, whereas
growlight itself is only 555K. it is of course possible that
all that weight is desirable functionality.

I think 70k more disk space is not really a concern.


with that said, i would *still want to test on the target
environment*, to make sure i'm using libparted correctly there.
so that necessity remains.

I thought you didn't depend on libparted?


would this allay your concerns?

No, not really. I consider a partitioning tool to be too important
to be replaced by an unproven solution.

Growlight seems like an adequate tool for Debian expert option as it has 
potential to enable additional flexibility and extensibility for file 
system options which may not offered in the current set of Parted 
utilities. For instance, the current Growlight string/option 'enter 
filesystem name' could be re-implemented, with a couple lines of code, 
into something like 'enter plugin override'


< https://metztli.it/bullseye/gl/gl-reiser4-plugin-override.png >

etc., for other filesystems.


Also Growlight may reduce at least a subset of UDEB modules needed for 
each file system supported by Debian, thus reducing complexity. For 
instance, it was relatively straightforward to add support for reiser4 
-- as compared to initial efforts developing substantial code for a 
partman-[filesystem] UDEB module.


< https://metztli.it/bullseye/gl/growlight-reiser4.png >

In other words, even if there is no compelling reason to update d-i at 
the moment, Growlight has potential to decrease complexity in the long run.


Just a point of view from an outsider, of course, I do not want anyone 
'to have a cow' for refusing to potentially move away from their place 
of comfort and/or entertaining a perspective that may be considered 'taboo.'



Best Professional Regards.

--

Jose R R
http://metztli.it 
-
Download Metztli Reiser4: Debian Buster w/ Linux 5.13.14 AMD64
-
feats ZSTD compression https://sf.net/projects/metztli-reiser4/ 


-
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/ 


---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/ 

Re: partman, growlight, discoverable partitions, and fun

[Marco d'Itri]

On Sep 27, John Paul Adrian Glaubitz  wrote:

> Not for me, though. Debian has always followed the philosophy to be a 
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects 
> develop.
It never meant that.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

> On Sep 27, 2021, at 3:41 PM, Luca Boccassi  wrote:
> 
> On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote:
>> 
 On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
>>> 
>>> Even if that interpretation would work as an excuse to never do
>>> anything, and I'm not really sure it does, this specification has been
>>> published in 2014 [0] so even by Debian standard it's old stuff.
>> 
>> That’s not what I said so. You’re trying to dismiss my opinion as completely 
>> invalid now by trying to frame it such that I am against progress. I am not.
> 
> You dismissed it because it's "new technology":
> 
>> Not for me, though. Debian has always followed the philosophy to be a 
>> universal
>> operating system, which also meant that we can't (immediately) use all the 
>> new
>> technologies and features that other distributions or upstream projects 
>> develop.

You’re reducing my argument to the word “new” which is definitely not my point. 
As you can see from the rest of my message my primary point is that Debian 
follows a different philosophy meaning that we don’t always adopt technologies 
that other distributions use.

Fedora and openSUSE are much more similar to each other than Debian is to both.

> I simply pointed out that it's a 7 years old spec that saw an entire
> LTS Debian version (8, we are now at 11) being released and EOL'ed
> since the time it was published. If this is too new to consider, then
> so are all Debian releases newer than Wheezy.

Yes, but the age was never my argument. My argument was that replacing such a 
fundamental software component like the partitioning tool in an installer is 
something that has to be justified by technical merits and by weighing pros and 
cons against each other.

The fact that’s it’s newer or has the single feature X is not sufficient in my 
opinion. Especially when there is no proof yet that getting support for 
discoverable partitions justifies the loss of features that parted has.

>>> It's
>>> older than Debian Jessie, which was EOL'd last year. If libparted can't
>>> keep up with 7 years old stuff that in the meantime was implemented in
>>> util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
>>> and so on, then to me it sounds like a tool in maintenance mode:
>>> perfectly fine and adequate for existing tools and programs, but not
>>> quite the best choice for new tools developed from scratch.
>> 
>> Whether a tool that was developed new from scratch is automatically better 
>> is not a given. The burden of proof is on the person trying to introduce the 
>> new software, not on the people maintaining the current set of software.
>> 
>> And claiming that parted is in pure maintenance mode is not true either. It 
>> has a paid developer working on the project and is receiving updates and 
>> improvements.
>> 
>> Whether growlight is better and more suitable for Debian needs to be 
>> technically proven, not just by arguing that it’s the newer project.
>> 
>> Adrian
> 
> Of course. But jumping in and saying "you should use X instead of Y",
> you can't pretend that nobody asks questions such as "ok, but does libX
> support this very much related and relevant 7 years old specification
> that other comparable tools support", no matter how awkward it is for
> libX.

I was not the one that was making this request, it was Nick. I’m perfectly fine 
with the status quo.

Again, the party introducing the new solution should provide the arguments to 
convince the maintainers of the existing solution.

For example, a convincing argument would be a demonstration installation ISO 
which let’s others interested in the project test it and check whether it 
delivers the improvements that were promised.

I don’t think that this is such an extraordinary requirement to ask for.

Also, I would be interested to know what approaches are currently used in 
Fedora, Arch, Gentoo and openSUSE (I will check that later myself when I’m back 
at the computer).

Adrian 

Re: partman, growlight, discoverable partitions, and fun

[Lennart Sorensen]

On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
> Whether a tool that was developed new from scratch is automatically better is 
> not a given. The burden of proof is on the person trying to introduce the new 
> software, not on the people maintaining the current set of software.
> 
> And claiming that parted is in pure maintenance mode is not true either. It 
> has a paid developer working on the project and is receiving updates and 
> improvements.
> 
> Whether growlight is better and more suitable for Debian needs to be 
> technically proven, not just by arguing that it’s the newer project.

I would have thought that if libparted was missing 1 or 2 features,
it would make more sense to add those features than to write a new tool
duplicating most of the functionality.

Well unless working with the maintainers of libparted is imposible.
There are a few projects like that but I don't remember ever seeing
complains about libparted.  Now you have two tools both missing some
features.  Hardly an improvement.

-- 
Len Sorensen

Re: partman, growlight, discoverable partitions, and fun

[Luca Boccassi]

On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote:
> 
> > On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> > 
> > Even if that interpretation would work as an excuse to never do
> > anything, and I'm not really sure it does, this specification has been
> > published in 2014 [0] so even by Debian standard it's old stuff.
> 
> That’s not what I said so. You’re trying to dismiss my opinion as completely 
> invalid now by trying to frame it such that I am against progress. I am not.

You dismissed it because it's "new technology":

> Not for me, though. Debian has always followed the philosophy to be a 
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects 
> develop.

I simply pointed out that it's a 7 years old spec that saw an entire
LTS Debian version (8, we are now at 11) being released and EOL'ed
since the time it was published. If this is too new to consider, then
so are all Debian releases newer than Wheezy.

> > It's
> > older than Debian Jessie, which was EOL'd last year. If libparted can't
> > keep up with 7 years old stuff that in the meantime was implemented in
> > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> > and so on, then to me it sounds like a tool in maintenance mode:
> > perfectly fine and adequate for existing tools and programs, but not
> > quite the best choice for new tools developed from scratch.
> 
> Whether a tool that was developed new from scratch is automatically better is 
> not a given. The burden of proof is on the person trying to introduce the new 
> software, not on the people maintaining the current set of software.
> 
> And claiming that parted is in pure maintenance mode is not true either. It 
> has a paid developer working on the project and is receiving updates and 
> improvements.
> 
> Whether growlight is better and more suitable for Debian needs to be 
> technically proven, not just by arguing that it’s the newer project.
> 
> Adrian

Of course. But jumping in and saying "you should use X instead of Y",
you can't pretend that nobody asks questions such as "ok, but does libX
support this very much related and relevant 7 years old specification
that other comparable tools support", no matter how awkward it is for
libX.

-- 
Kind regards,
Luca Boccassi


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

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

> On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> 
> Even if that interpretation would work as an excuse to never do
> anything, and I'm not really sure it does, this specification has been
> published in 2014 [0] so even by Debian standard it's old stuff.

That’s not what I said so. You’re trying to dismiss my opinion as completely 
invalid now by trying to frame it such that I am against progress. I am not.

> It's
> older than Debian Jessie, which was EOL'd last year. If libparted can't
> keep up with 7 years old stuff that in the meantime was implemented in
> util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> and so on, then to me it sounds like a tool in maintenance mode:
> perfectly fine and adequate for existing tools and programs, but not
> quite the best choice for new tools developed from scratch.

Whether a tool that was developed new from scratch is automatically better is 
not a given. The burden of proof is on the person trying to introduce the new 
software, not on the people maintaining the current set of software.

And claiming that parted is in pure maintenance mode is not true either. It has 
a paid developer working on the project and is receiving updates and 
improvements.

Whether growlight is better and more suitable for Debian needs to be 
technically proven, not just by arguing that it’s the newer project.

Adrian

Re: partman, growlight, discoverable partitions, and fun

[Holger Levsen]

On Sat, Sep 25, 2021 at 06:49:53PM -0400, Nick Black wrote:
> So the only ones covered by partman and not covered by growlight would be:
> amiga, atari, sun,
> and mac (if mac is not the same as APM). I don't see any difficulty in
> adding these four, so long
> as there's someone with an Amiga or ATARI who'd be willing to test them
> out. If there are no such
> people, is it that important?

those ancient hardwares are not important to Debian, we have ceased to support
them years ago.

some people OTOH support them on Debian Ports and some of these people are very
vocal about the need of supporting architectures there. In my opinion they 
should 
only be heard if they also offer to do the work needed to keep those ancient
architectures alive. (and so far I've not even read an offer to help *testing*
such code there and also no offer to help developing such code...)

blocking progress on main Debian architectures because of some unsupported 
ancient
hardwares seems more problematic to me than not supporting those ancient
plattform.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not about saving the climate or the planet, it's about saving us, the
children and grandchildren. The planet will survive anyway.


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[Luca Boccassi]

On Mon, 2021-09-27 at 13:06 +0200, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 9/27/21 12:46, Luca Boccassi wrote:
> > > Also, since parted is maintained by RedHat, I would expect that this 
> > > feature
> > > would land in parted soon as well.
> > > 
> > If the question is "why does X not use libparted", "does not support
> > discoverable parts spec" is a good enough answer for me.
> 
> Not for me, though. Debian has always followed the philosophy to be a 
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects 
> develop.
> 
> For example, we don't use systemd-homed or systemd-firstboot either. That 
> doesn't
> mean Debian is per se worse off. It just means Debian tries to cater 
> different use
> cases and follows different concepts.
> 
> It's different for distributions like Fedora or openSUSE which focus on a very
> limited set of targets and use cases. That's why they can quickly adopt to all
> the new features and technologies that upstream projects like systemd develop.
> 
> I'm not saying that one philosophy is better than the other. I'm just saying 
> that
> Debian is not like these other distributions.
> 
> Adrian

Even if that interpretation would work as an excuse to never do
anything, and I'm not really sure it does, this specification has been
published in 2014 [0] so even by Debian standard it's old stuff. It's
older than Debian Jessie, which was EOL'd last year. If libparted can't
keep up with 7 years old stuff that in the meantime was implemented in
util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
and so on, then to me it sounds like a tool in maintenance mode:
perfectly fine and adequate for existing tools and programs, but not
quite the best choice for new tools developed from scratch.

-- 
Kind regards,
Luca Boccassi

[0]
https://cgit.freedesktop.org/wiki/www/log/Specifications/DiscoverablePartitionsSpec.mdwn


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

Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i
Control: fixed 994042 2.32-3

Hi,

On Sun, 2021-09-26 at 22:16 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2021-09-26 20:46, Adam D. Barratt wrote:
> > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
> > [...]
> > > In the meantime another issue that would need to be fixed in sid
> > > > > came
> > > as
> > > bug#994042. 
> > > 
> > > This time the issue is in the preinst. To summarize, in the case
> > > debconf is not usable to prompt the user about the upgrade, the
> > > preinst switches to text prompt. However as the debconf module
> > > has
> > > been loaded got control of the tty, which prevent any input from
> > > the
> > > user. For skilled users it still possible to kill the upgrade
> > > from
> > > another, but other users will probably try other actions that
> > > might
> > > have damaging effects (like rebooting the system).
> > > 
> > > The fix is to get the debconf configuration without using the
> > > debconf
> > > module, as suggested by Colin Watson.
> > > 
> > 
> > Thanks. That looks OK to me, particularly with Colin's review.
> 
> Thanks for the review. I guess that now it just needs a kibi-ack.

Yep; re-tagging accordingly.

> > Is there an ETA for getting the fix into unstable?
> 
> Upgrades from buster to bookworm are not supported, so it means
> upgrade
> to bookworm starts from bullseye, which has a fixed debconf (the
> issue
> has been fixed in version 1.5.76). Therefore the fix in unstable has
> been done in glibc 2.32-3 by just dropping all the workaround:
> 
> https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789

Aha, thanks for connecting the dots. I was misled / confused slightly
by the lack of fixed versions on #994042, where the version tracking
implies that unstable is still affected, and 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994042;msg=33 not
indicating which branch the fix was on (I realise I {c,sh}ould have
checked). I've added a fixed version based on your explanation above;
hopefully that makes the status clearer.

Regards,

Adam

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

Hello!

On 9/27/21 12:46, Luca Boccassi wrote:
>> Also, since parted is maintained by RedHat, I would expect that this feature
>> would land in parted soon as well.
>>
> If the question is "why does X not use libparted", "does not support
> discoverable parts spec" is a good enough answer for me.

Not for me, though. Debian has always followed the philosophy to be a universal
operating system, which also meant that we can't (immediately) use all the new
technologies and features that other distributions or upstream projects develop.

For example, we don't use systemd-homed or systemd-firstboot either. That 
doesn't
mean Debian is per se worse off. It just means Debian tries to cater different 
use
cases and follows different concepts.

It's different for distributions like Fedora or openSUSE which focus on a very
limited set of targets and use cases. That's why they can quickly adopt to all
the new features and technologies that upstream projects like systemd develop.

I'm not saying that one philosophy is better than the other. I'm just saying 
that
Debian is not like these other distributions.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

Hello Nick!

On 9/26/21 16:29, Nick Black wrote:
> I'd be delighted to support them -- as in, I am honestly eager
> to add ATARI support; that sounds awesome -- I just need some
> way to test the implementations, either via someone running it
> on the environment, or getting access to such a machine.

There are emulators available for Atari such as Aranym. And emulators
available for Amiga such as fs-uae. FWIW, parted should contain everything
needed to be able to implement your own support for these partition tables.

>> I think it makes little sense to not use libparted as it already supports
>> all common and less common partition types and reimplementing everything
>> that libparted makes little sense to me.
> 
> parted did not have ZFS support when I embarked on this project
> (it appears to have it now). i would not be opposed to
> leveraging libparted if it presents a definite advantage;
> supporting more partition types, so long as it exposes an API i
> can easily work with, would be such an advantage.

Well, using a missing feature in the past against parted that is present
there is not such a good argument against using it, to be honest.

> i do note that libparted2 is 621K in the archive, whereas
> growlight itself is only 555K. it is of course possible that
> all that weight is desirable functionality.

I think 70k more disk space is not really a concern.

> with that said, i would *still want to test on the target
> environment*, to make sure i'm using libparted correctly there.
> so that necessity remains.

I thought you didn't depend on libparted?

> would this allay your concerns?

No, not really. I consider a partitioning tool to be too important
to be replaced by an unproven solution.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: partman, growlight, discoverable partitions, and fun

[Luca Boccassi]

On Sun, 2021-09-26 at 12:45 +0200, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 9/26/21 12:40, Luca Boccassi wrote:
> > Does libparted support the discoverable partitions spec?
> 
> I'm not sure, this thread is the first time I have heard about discoverable
> partitions. I have read up first what the motivations for these are and
> how useful they would be for Debian.
> 
> Also, since parted is maintained by RedHat, I would expect that this feature
> would land in parted soon as well.
> 
> Adrian

If the question is "why does X not use libparted", "does not support
discoverable parts spec" is a good enough answer for me.

-- 
Kind regards,
Luca Boccassi


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