Bug#766815: installation-reports: please omit "quiet" option

[lee]

Ben Hutchings  writes:

> On Sun, 2014-10-26 at 02:44 +0100, lee wrote:
> [...]
>> I strongly recommend to change the installer to *not* use the quiet
>> option.  Especially with the installer, there is much point in being
>> able to see all messages, and not everyone installs Debian on up-to-date
>> and/or fully known hardware.
>
> No, it is important to see the *error* messages.  The bug is that this
> error message is suppressed when 'quiet' is used.

This message is probably not the only error message you don't see when
"quiet" is used.  IIRC, you don't see it when the killing of modprobe is
being delayed.  I'll have to verify.

>> Besides, the "quiet" option shouldn't be used by default after the
>> installation has completed, either.
> [...]
>
> It is the correct default.  Those *expert* users who feel able to
> interpret the extra information that may be logged to the console are
> exactly the users that are most likely to know how to override this
> default.

You don't have to be that "expert user" to be able to figure out that
something isn't right when you see the messages, and you cannot expect
everyone to know about this option and how it may hide problems.  I've
been using Debian for over 20 years and didn't know it would hide so
much.  I only found out about it by chance and tried it in desperation.

So I don't understand what should be correct about hiding potentially
important and valuable information from users by default.  It seems far
more logical to display such information until the user has verified
that everything works, in which case they can add this option if they
want.

Users who want as much as possible hidden from them can use other OSs.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tpuhutf@gulltop.yagibdah.de

Re: Installing Debian remotely in an unmanaged VPS

[duportail]

Op 26-10-2014 22:36, Mario Castelán Castro schreef:

I see.

I have noticed that there's a preseeding parameter 
network-console/authorized_keys_url, which may point to an URL. Is 
there a way I can *embed* my SSH public key in the initrd and then use 
file:/// or similar and likewise embed the public key to be used by 
the server?


Will it matter which keyboard layout I set in d-i keymap select 
 (since it's going to be installed and then managed through 
SSH)?


Regards and thanks a lot.

P.S: The tutorial in
 
involves downloading an ISO from that user's server, and at any rate 
it seems like the ISO image has to be keep in a partition. I will 
follow the procedure of making a custom net boot image with preseeding.




It is the testing mini.iso
http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/20141002/images/netboot/mini.iso
The wheezy mini.iso does not work yet.


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544e02d9.5010...@telenet.be

Bug#766459: debootstrap: should not try to configure

[Michael Tautschnig]

Hi all,

I'm being heavily bitten by this one as well and I'm mildly shocked to see it
crop up this late in the release cycle. I'm not going to hide that I believe
this ought to be reassigned to base-files. I'll try to elaborate below.


Santiago Vila wrote:
[...]
> In this particular case, I believe the reason for the failure (that
> didn't happen before) is some change in base-passwd, not something
> that base-files does differently now.
> 

I tend to disagree: base-passwd hasn't been touched since 2014-09-04, whereas
debootstrap only started to fail last week, when base-files 7.7 was uploaded.
It's this change I believe:

http://sources.debian.net/src/base-files/7.7/debian/postinst.in/?hl=132,133,134#L132

Causing

chown: invalid user: 'root:root'

Admittedly, though, this just exposes a problem that had been lingering for a
while as the calls to chown using root:root could have been invoked from several
bits of the postinst script.

> In principle, every essential package may depend on any other, and the
> set of real dependencies may change over time, so it's natural that
> debootstrap needs minor adjustments from time to time.

So would you expect some sort of versioned dependencies in debootstrap? As the
upload of base-files 7.7 showed, it is changes in packages that suddenly require
new hacks. And a key problem is that tools like debootstrap ought to work from
within, e.g., stable release to bootstrap future releases like testing or
unstable. Suggesting that a bootstrapping tool is changed due to updates in
another package is going to cause a major dependency loop as at least testing
efforts such as those of jenkins.d.n will be broken.

In fact it would be easier to codify this in dpkg than in debootstrap, I
believe, as dpkg would live in the same suite as the package to be installed.
But this sounds like very bad design indeed.

> > > You will find a more complete explanation of this in the logs for
> > > Bug#760568 where I'm asked no less than to depend on base-passwd,
> > > which is essential! IMHO, this is definitely not the way to go.
> >

Using the "essential!" hammer doesn't sound like a great argument when your
package is essential.

> > It's past time to be untangling the Essential hairball. Correct dependency
> > metadata is much more scalable than hacks in debootstrap.
> 
> I agree that you may have a point here. In fact, in the aforementioned
> bug #760568 against cdebootstrap, which is very similar to this one,
> I suggested the idea that if the knowledge about right package ordering
> among essential packages were codified and written somewhere, other
> similar tools could use the same information without having to
> reinvent the wheel.
> 
> I see now that the control file could be such common place to have
> that information, but I would like to see a little bit of *design*
> before doing anything which is not in policy yet.
> 
> For example, we could use:
> 
> * The same Depends field we are using for normal dependencies.
> 
> * A new field for this particular purpose which dpkg and friends
> ignore under normal circumstances, and an environment variable which
> debootstrap may set to tell dpkg and friends that they should actually
> honor them instead of ignoring them.
> 
> * An extension of the Depends field, much like  is used in
> Build-Depends for build profiles.
> 
> So yes, we could consider to codify this metadata (the fact that
> base-files postinst uses "chown" and expect the root user to exist,
> for example) in *some* way...
> 
> > Stop being part of the problem, and add the dependency already..
> 
> ... but please let us think about it first. Starting to add "Depends"
> field here and there in a random fashion "just because it makes
> debootstrap not to fail anymore" is not something I will be happy
> with.
> 

I do fully agree that care must be taken, as dependency loops would obviously be
a major problem.

> The Depends field is implicit among the set of essential packages.

I'm not too sure about the "among" bit here? No doubt that this is implicit for
any non-essential package, but "among" them I'm not sure whether any rules apply
right now?

> If a tool like apt-get or dpkg really behaves in a different way when
> I add a Depends field which was already implicit, I think that there
> is something fundamentally wrong here.
> 

Does dpkg really add the "essential" information into its dependency
information? Wouldn't this rather be seen as "ah, essential, so it must be
there?" At least briefly looking at dpkg's source code I cannot seem to see dpkg
considering this implicit dependency at all (unless attempting to remove an
essential package).

> So, to summarize: I'm not opposed to modify policy when it says that
> we don't need to include dependencies on essential packages, but if we
> decide to go that route, please let us do it according to some *plan*,
> not in a random fashion, because otherwise, IMHO, *that* would be the
> real hack.
> 

I do appreciate being c

Re: Bug#766459: debootstrap: should not try to configure

[Julien Cristau]

On Mon, Oct 27, 2014 at 08:35:14 +, Michael Tautschnig wrote:

> Hi all,
> 
> I'm being heavily bitten by this one as well and I'm mildly shocked to see it
> crop up this late in the release cycle. I'm not going to hide that I believe
> this ought to be reassigned to base-files. I'll try to elaborate below.
> 
I agree this should be fixed in base-files.

> 
> Santiago Vila wrote:
> [...]
> > In this particular case, I believe the reason for the failure (that
> > didn't happen before) is some change in base-passwd, not something
> > that base-files does differently now.
> > 
> 
> I tend to disagree: base-passwd hasn't been touched since 2014-09-04, whereas
> debootstrap only started to fail last week, when base-files 7.7 was uploaded.
> It's this change I believe:
> 
> http://sources.debian.net/src/base-files/7.7/debian/postinst.in/?hl=132,133,134#L132
> 
> Causing
> 
> chown: invalid user: 'root:root'
> 
Can't base-files call chown with 0:0 instead of root:root to sidestep
this entirely?

Cheers,
Julien


signature.asc
Description: Digital signature

Linux kernel ABI bump in testing: from (none) to 3.16-3

[Linux kernel watcher]

Linux kernel ABI bump in testing: from (none) to 3.16-3


Full summary: http://d-i.debian.org/kernel-summary.html#testing


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xifgi-0007m4...@dillon.debian.org

Linux kernel ABI bump in unstable: from (none) to 3.16-3

[Linux kernel watcher]

Linux kernel ABI bump in unstable: from (none) to 3.16-3


Full summary: http://d-i.debian.org/kernel-summary.html#unstable


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xifgk-0007mv...@dillon.debian.org

Linux kernel ABI bump in experimental: from (none) to 3.17-rc5

[Linux kernel watcher]

Linux kernel ABI bump in experimental: from (none) to 3.17-rc5


Full summary: http://d-i.debian.org/kernel-summary.html#experimental


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xifgn-0007ne...@dillon.debian.org

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Petter Reinholdtsen]

Source: debian-installer-netboot-images
Version: 20130613+deb7u2.b3
Severity: important
User: debian-...@lists.debian.org
Usertags: debian-edu

Hi.  Will there be netboot images for Debian Jessie (version 8)
available?  We used the version 7 packages in Debian Edu Wheezy, and
miss the version 8 packages for our main server profile.  They are
useful for installations without Internet access.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2fl1tptgabd@diskless.uio.no

Bug#762056: d-i.debian.org: update jenkins job to use daily-build-overview

[Holger Levsen]

Hi,

On Donnerstag, 18. September 2014, Cyril Brulebois wrote:
> It'd probably a good idea to update this jenkins job:
>   https://jenkins.debian.net/view/d-i_misc/job/d-i_parse_build_logs/

I was thinking of disabling or removing this job last night and then this 
morning remembered this bug.. :)

> to use this page instead:
>   http://d-i.debian.org/daily-images/daily-build-overview.html

ok, can do. do you know a better data source than grepping the html?
 
what do you think about splitting this job into many, one per architecture? 
that way we could also tune notifications and eg not only notify debian-boot 
but also the ia64-porters when their build fails...


cheers,
Holger




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

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Cyril Brulebois]

Petter Reinholdtsen  (2014-10-27):
> Source: debian-installer-netboot-images
> Version: 20130613+deb7u2.b3
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: debian-edu
> 
> Hi.  Will there be netboot images for Debian Jessie (version 8)
> available?  We used the version 7 packages in Debian Edu Wheezy, and
> miss the version 8 packages for our main server profile.  They are
> useful for installations without Internet access.

Yes. There's no need to open a bug for that.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#766459: debootstrap: should not try to configure

[Julien Cristau]

On Mon, Oct 27, 2014 at 11:08:55 +0100, Santiago Vila wrote:

> This has worked for ages, and it should continue to work, because
> base-passwd is essential.
> 
That argument would work better if base-files wasn't also essential.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Le lundi, 27 octobre 2014, 09.56:38 Petter Reinholdtsen a écrit :
> Source: debian-installer-netboot-images
> Version: 20130613+deb7u2.b3
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: debian-edu
> 
> Hi.  Will there be netboot images for Debian Jessie (version 8)
> available?

We should be doing this soon, indeed.

The following diff would be mostly what's needed:

--- a/debian/rules
+++ b/debian/rules
@@ -1,12 +1,12 @@
 #!/usr/bin/make -f
 
-export MAJOR_VERSION=7.0
-export DISTRIBUTION=wheezy
+export MAJOR_VERSION=8.0
+export DISTRIBUTION=jessie
 export MIRROR=http://http.debian.net/debian
 export VERSION=$(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
 
 # Don't forget to recreate debian/control after editing these lines: $ 
debian/rules debian/control
-SUPPORTED_ARCHITECTURES = amd64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc sparc
+SUPPORTED_ARCHITECTURES = amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el sparc
 UNSUPPORTED_ARCHITECTURES = hurd-i386 s390 s390x
 
 %:

I'm having currently two problems with this:

* http.debian.net redirection for installer-arm64; aka  accessing
  "debian/dists/jessie/main/installer-arm64/20141002/images/SHA256SUMS"
  through http.debian.net sometimes fails, bug is there :
  https://github.com/rgeissert/http-redirector/issues/54
  This is easily circumvented by using a fixed mirror.
* kfreebsd-amd64's images fetching logic fails because there is no un-
  numbered /netboot/ directory under which we could automagically take
  "netboot.tar.gz" as for other architectures. I think this should be
  fixed in the installer through providing a symlink towards the default
  version but can't really find where this should go.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1548959.0eHgEb5EvC@gyllingar

Re: Bug#766459: debootstrap: should not try to configure

[Santiago Vila]

I'm going to reply to Julien first, then to Michael.

On Mon, 27 Oct 2014, Julien Cristau wrote:

> On Mon, Oct 27, 2014 at 08:35:14 +, Michael Tautschnig wrote:
> I agree this should be fixed in base-files.

Bugs should be fixed where they are. If base-files, or any other
package, essential or not, can't make a simple chown root:root, then
it is a bug in whatever package was responsible for making sure that
the root user exist in a Debian system, base-passwd and debootstrap in
this case.

This is regardless the fact that base-files could do things differently
so that this bug remains "hidden" a few more months or a few more years.

I am investigating the last option right now, but not as a way to fix
bugs in debootstrap (which I believe they should be fixed anyway), but
as a way to avoid our users to find this problem.

BTW: At least once in the past I have made little changes to base-files
to fix problems that happen when using debootstrap. I'm not opposed to
that. See for example, changes in base-files 3.0.1 (yes, 12 years ago).
But it will not be anything like adding a Depends on base-passwd. That
would be a hack.

> > chown: invalid user: 'root:root'
>
> Can't base-files call chown with 0:0 instead of root:root to sidestep
> this entirely?

It's a little bit more complex than that.

Sometimes it's root:root, sometimes is root:staff and sometimes is root:mail.

See base-files postinst for details.

This has worked for ages, and it should continue to work, because
base-passwd is essential.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410271044240.29...@cantor.unex.es

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Cyril Brulebois]

Didier 'OdyX' Raboud  (2014-10-27):
> Le lundi, 27 octobre 2014, 09.56:38 Petter Reinholdtsen a écrit :
> > Source: debian-installer-netboot-images
> > Version: 20130613+deb7u2.b3
> > Severity: important
> > User: debian-...@lists.debian.org
> > Usertags: debian-edu
> > 
> > Hi.  Will there be netboot images for Debian Jessie (version 8)
> > available?
> 
> We should be doing this soon, indeed.
> 
> The following diff would be mostly what's needed:
> 
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,12 +1,12 @@
>  #!/usr/bin/make -f
>  
> -export MAJOR_VERSION=7.0
> -export DISTRIBUTION=wheezy
> +export MAJOR_VERSION=8.0
> +export DISTRIBUTION=jessie
>  export MIRROR=http://http.debian.net/debian
>  export VERSION=$(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
>  
>  # Don't forget to recreate debian/control after editing these lines: $ 
> debian/rules debian/control
> -SUPPORTED_ARCHITECTURES = amd64 armel armhf i386 ia64 kfreebsd-amd64 
> kfreebsd-i386 mips mipsel powerpc sparc
> +SUPPORTED_ARCHITECTURES = amd64 arm64 armel armhf i386 kfreebsd-amd64 
> kfreebsd-i386 mips mipsel powerpc ppc64el sparc
>  UNSUPPORTED_ARCHITECTURES = hurd-i386 s390 s390x
>  
>  %:
> 
> I'm having currently two problems with this:
> 
> * http.debian.net redirection for installer-arm64; aka  accessing
>   "debian/dists/jessie/main/installer-arm64/20141002/images/SHA256SUMS"
>   through http.debian.net sometimes fails, bug is there :
>   https://github.com/rgeissert/http-redirector/issues/54
>   This is easily circumvented by using a fixed mirror.

Why is the current mirror pointing to a *.debian.net service in the
first place…

> * kfreebsd-amd64's images fetching logic fails because there is no un-
>   numbered /netboot/ directory under which we could automagically take
>   "netboot.tar.gz" as for other architectures. I think this should be
>   fixed in the installer through providing a symlink towards the default
>   version but can't really find where this should go.

There's only a single version now. Not sure having to care about a
symlink in debian-installer is worth it. Won't stop you from looking
into it though.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Didier 'OdyX' Raboud]

Le lundi, 27 octobre 2014, 11.23:23 Cyril Brulebois a écrit :
> > * kfreebsd-amd64's images fetching logic fails because there is no
> >   un-numbered /netboot/ directory under which we could automagically
> >   take "netboot.tar.gz" as for other architectures. I think this
> >   should be fixed in the installer through providing a symlink
> >   towards the default version but can't really find where this
> >   should go.
> 
> There's only a single version now. Not sure having to care about a
> symlink in debian-installer is worth it. Won't stop you from looking
> into it though.

The current logic in d-i-n-i is to fetch …/netboot/netboot.tar.gz and 
…/netboot/gtk/netboot.tar.gz for all architectures. On those where it 
fails, it will download …/MANIFEST and try downloading everything which 
is under …/netboot/ and use that in the package.

The problem with kfreebsd's numbered directories is that it forces d-i-
n-i to add this kernel version number in its logic, for no good reason. 
That's why I'd prefer to have kfreebsd's either have a /netboot/ symlink 
pointing to the preferred numbered /netboot-$n/ directory or (given it 
currently only has one version, which is likely to be jessie's state), 
rename that directory to be un-numbered. As far as I understood, the 
latter is a matter of renaming some files in build/config/kfreebsd-*/ .

Opinions?

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1470388.VZvvNOiPn6@gyllingar

Re: Bug#766459: debootstrap: should not try to configure

[Michael Tautschnig]

I'm hoping this is not going to be too philosophical, so I'll enlist the facts
first (please let me know if I got any of them wrong):

debootstrap'ing a system fails, because

- chown root:root ... won't work when invoked from base-files' postinst
- version 7.7 of base-files is the first to actually have this call when invoked
  from within (c)debootstrap
- using root:root relies on /etc/passwd and /etc/group being in place and
  populated
- /etc/passwd and /etc/group are provided by base-passwd, which is essential

On Mon, Oct 27, 2014 at 11:08:55 +0100, Santiago Vila wrote:
> I'm going to reply to Julien first, then to Michael.
> 
> On Mon, 27 Oct 2014, Julien Cristau wrote:
> 
> > On Mon, Oct 27, 2014 at 08:35:14 +, Michael Tautschnig wrote:
> > I agree this should be fixed in base-files.
> 
> Bugs should be fixed where they are. If base-files, or any other
> package, essential or not, can't make a simple chown root:root, then
> it is a bug in whatever package was responsible for making sure that
> the root user exist in a Debian system, base-passwd and debootstrap in
> this case.
> 
[...]
> This has worked for ages, and it should continue to work, because
> base-passwd is essential.
> 

So let's see what Debian Policy says in 3.8 Essential packages:

"[...] Since dpkg will not prevent upgrading of other packages while an
essential package is in an unconfigured state, all essential packages must
supply all of their core functionality even when unconfigured. If the package
cannot satisfy this requirement it must not be tagged as essential, and any
packages depending on this package must instead have explicit dependency fields
as appropriate. [...]"

While base-passwd is essential, the question seems to be whether providing
/etc/passwd and /etc/group are its "core functionality." The description of
base-passwd states: "These are the canonical master copies of the user database
files (/etc/passwd and /etc/group), containing the Debian-allocated user and
group IDs."

The package base-passwd, however, will only copy those files into place in its
postinst script. It may thus be argued (if provision of the files is considered
"core functionality") that base-passwd violates policy. Yet it may be impossible
for base-passwd to implement this bit of policy unless unconditionally
overwriting /etc/passwd and /etc/group were deemed acceptable (which it surely
isn't, unless we implement something like /etc/passwd.d/ and /etc/group.d/).

A collection of possible ways forward - feel free to add more:

- base-passwd should no longer be marked essential, but instead base-files
  should depend on it (making base-passwd implicitly essential), hence neither
  would base-passwd be violating policy nor would we any longer face the
  problems in base-files/(c)debootstrap. But maybe other issues arise, which I
  might not be aware of.

- base-files should explicitly depend on base-passwd, because it uses
  functionality that is not considered "core functionality" of base-passwd.

- We ignore the policy violation of base-passwd or consider the use of
  /etc/passwd in base-files use of non-core functionality and hence ignore the
  bug in base-files. Either ignorance will then require working around those
  bugs in (c)debootstrap.

Best,
Michael



pgp8tHayOOAmV.pgp
Description: PGP signature

Re: Bug#766459: debootstrap: should not try to configure

[Santiago Vila]

On Mon, 27 Oct 2014, Michael Tautschnig wrote:
> > In principle, every essential package may depend on any other, and the
> > set of real dependencies may change over time, so it's natural that
> > debootstrap needs minor adjustments from time to time.
> 
> So would you expect some sort of versioned dependencies in debootstrap?

No, not at all.

I just expect debootstrap maintainers to cooperate with the release
managers to ensure that the version in stable is able to debootstrap
the testing distribution, whenever it is possible to do so.

I've heard that the version in wheezy-backports does not have this problem.
Maybe it could be just a matter of making an upload for the next point release.
I don't know.

> [...]
> > The Depends field is implicit among the set of essential packages.
> 
> I'm not too sure about the "among" bit here? No doubt that this is implicit 
> for
> any non-essential package, but "among" them I'm not sure whether any rules 
> apply
> right now?

I mean that the rule saying

Package A does not need a "Depends: B" if B is essential

does not say anything about the essentialness of *A*, which means
the rule is valid regardless of A being essential or not.

The fact that base-files is essential is quite irrelevent. A chown in
the postinst should not fail, and if it does, there is a bug in debootstrap.

> > If a tool like apt-get or dpkg really behaves in a different way when
> > I add a Depends field which was already implicit, I think that there
> > is something fundamentally wrong here.
> 
> Does dpkg really add the "essential" information into its dependency
> information? Wouldn't this rather be seen as "ah, essential, so it must be
> there?" At least briefly looking at dpkg's source code I cannot seem to see 
> dpkg
> considering this implicit dependency at all (unless attempting to remove an
> essential package).

In the general case we don't have to worry about that because once
that essential packages are properly installed and configured, they
will continue to work all the time unless apt-get does some really
weird things.

But how are we expected to have all the essential packages properly
installed and configured?

Should base-files worry about base-passwd being properly installed and
configured before making a chown? Certainly not, this is the work of
debootstrap!

> [...]
> I do appreciate being careful, but then bug fixes for a bug of normal severity
> (#763405) shouldn't be causing RC bugs either.

Fixing bugs in one package usually makes hidden bugs in other packages
to become no longer hidden. This happens all the time and it's not a
good argument to *not* fix the bugs where they are.

In either case, I'm going to re-examine carefully what I did in
base-files 7.7 and see if there is a simple workaround that may be
done to avoid this problem.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410271110590.29...@cantor.unex.es

Bug#766960: debian-installer-netboot-images: Please provide packages for Debian 8

[Cyril Brulebois]

[ Cc: debian-bsd@ ]

Didier 'OdyX' Raboud  (2014-10-27):
> Le lundi, 27 octobre 2014, 11.23:23 Cyril Brulebois a écrit :
> > > * kfreebsd-amd64's images fetching logic fails because there is no
> > >   un-numbered /netboot/ directory under which we could automagically
> > >   take "netboot.tar.gz" as for other architectures. I think this
> > >   should be fixed in the installer through providing a symlink
> > >   towards the default version but can't really find where this
> > >   should go.
> > 
> > There's only a single version now. Not sure having to care about a
> > symlink in debian-installer is worth it. Won't stop you from looking
> > into it though.
> 
> The current logic in d-i-n-i is to fetch …/netboot/netboot.tar.gz and 
> …/netboot/gtk/netboot.tar.gz for all architectures. On those where it 
> fails, it will download …/MANIFEST and try downloading everything which 
> is under …/netboot/ and use that in the package.
> 
> The problem with kfreebsd's numbered directories is that it forces d-i-
> n-i to add this kernel version number in its logic, for no good reason. 
> That's why I'd prefer to have kfreebsd's either have a /netboot/ symlink 
> pointing to the preferred numbered /netboot-$n/ directory or (given it 
> currently only has one version, which is likely to be jessie's state), 
> rename that directory to be un-numbered. As far as I understood, the 
> latter is a matter of renaming some files in build/config/kfreebsd-*/ .

I understand the reasoning but I am not keen on moving files around at
this very late stage; if adding a symlink works, this would probably be
better.

Otherwise, maybe move back files under an unversioned directory and keep
a symlink from the versioned directory. Not sure how {well,badly} tftp
servers deal with symlinks anyway…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#766459: debootstrap: should not try to configure

[Michael Tautschnig]

Apologies if I may be repeating information as we were concurrently working on
those messages.

On Mon, Oct 27, 2014 at 11:34:06 +0100, Santiago Vila wrote:
[...]
> I just expect debootstrap maintainers to cooperate with the release
> managers to ensure that the version in stable is able to debootstrap
> the testing distribution, whenever it is possible to do so.
> 

This should, however, ideally work both ways: any package modification expected
to break debootstrap would have to be communicated. But arguably this will not
necessarily be obvious, as can be seen here.

> I've heard that the version in wheezy-backports does not have this problem.
> Maybe it could be just a matter of making an upload for the next point 
> release.
> I don't know.
> 

That's because of the following workaround, which is being disputed:

 debootstrap (1.0.56) unstable; urgency=low
 .
   [ Tollef Fog Heen ]
   * Install base-passwd and base-files in two calls rather than one to
 avoid problems with home-built media with different ordering in
 Packages.  Thanks to Jo Shields for pointing this out and providing
 the workaround.  Closes: #601670.  LP: #1001131.

Though see my earlier mail: if debootstrap ends up being the package to finally
close this bug, then, yes, this might be the route to go.

[...]
> > > If a tool like apt-get or dpkg really behaves in a different way when
> > > I add a Depends field which was already implicit, I think that there
> > > is something fundamentally wrong here.
> > 
> > Does dpkg really add the "essential" information into its dependency
> > information? Wouldn't this rather be seen as "ah, essential, so it must be
> > there?" At least briefly looking at dpkg's source code I cannot seem to see 
> > dpkg
> > considering this implicit dependency at all (unless attempting to remove an
> > essential package).
> 
> In the general case we don't have to worry about that because once
> that essential packages are properly installed and configured, they
> will continue to work all the time unless apt-get does some really
> weird things.
> 

Yes and no: mind that that "essential" only provides guarantees for
functionality being available as soon as the package is unpacked. The
"configured" bit is irrelevant for features deemed "essential."

> But how are we expected to have all the essential packages properly
> installed and configured?
> 
> Should base-files worry about base-passwd being properly installed and
> configured before making a chown? Certainly not, this is the work of
> debootstrap!
> 

No. As you are using the "base-passwd is essential" argument, base-files can
only rely on functionality provided by base-passwd when that is unpacked. The
order of packages being configured is not covered by "essential" and neither
should it be debootstrap's job to sort this out (but debootstrap 1.0.56 does do
this).

[...]
> In either case, I'm going to re-examine carefully what I did in
> base-files 7.7 and see if there is a simple workaround that may be
> done to avoid this problem.
> 

Much appreciated, but obviously we should, as you suggested, see what the right
way of fixing this is.

Best,
Michael



pgpDPcf798kxO.pgp
Description: PGP signature

Bug#766459: debootstrap: should not try to configure

[Holger Levsen]

Hi,

On Montag, 27. Oktober 2014, Santiago Vila wrote:
> I've heard that the version in wheezy-backports does not have this problem.

yes.

> Maybe it could be just a matter of making an upload for the next point
> release. I don't know.

the^wa fix is in the wheezy branch already:

https://anonscm.debian.org/cgit/d-i/debootstrap.git/log/?h=wheezy


cheers,
Holger


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

Re: Bug#766459: debootstrap: should not try to configure

[Santiago Vila]

On Mon, 27 Oct 2014, Michael Tautschnig wrote:

> I'm hoping this is not going to be too philosophical, so I'll enlist the facts
> first (please let me know if I got any of them wrong):
> 
> debootstrap'ing a system fails, because
> 
> - chown root:root ... won't work when invoked from base-files' postinst
> - version 7.7 of base-files is the first to actually have this call when 
> invoked
>   from within (c)debootstrap

Regarding previous point, it should be noted that base-files postinst
has a lot of chown calls. I would like to know how it is possible that
only the recently added is the one that fails and not the others
(if that's really the case).

BTW: I don't know what is the proper way to debug this (private
repository using reprepro?). Can anybody confirm that the chown that
fails is exactly the one at the very end?

> So let's see what Debian Policy says in 3.8 Essential packages:
> 
> "[...] Since dpkg will not prevent upgrading of other packages while an
> essential package is in an unconfigured state, all essential packages must
> supply all of their core functionality even when unconfigured. If the package
> cannot satisfy this requirement it must not be tagged as essential, and any
> packages depending on this package must instead have explicit dependency 
> fields
> as appropriate. [...]"

This is about dpkg when making upgrades. It means that once an
essential package is properly configured, it should not stop working
because of it being "unconfigured" by dpkg (whatever that means).

I think it does not apply here.

[ snipped philosophical stuff. I would much prefer to have free time
  to work on this rather than discuss about it. Really ].


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410271158060.31...@cantor.unex.es

Bug#766459: debootstrap: should not try to configure

[Cyril Brulebois]

Holger Levsen  (2014-10-27):
> Hi,
> 
> On Montag, 27. Oktober 2014, Santiago Vila wrote:
> > I've heard that the version in wheezy-backports does not have this problem.
> 
> yes.
> 
> > Maybe it could be just a matter of making an upload for the next point
> > release. I don't know.
> 
> the^wa fix is in the wheezy branch already:
> 
> https://anonscm.debian.org/cgit/d-i/debootstrap.git/log/?h=wheezy

Well, from my cursory reading of this thread, this might just be
papering over the issue, rather than fixing it.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#766459: debootstrap: should not try to configure

[Michael Tautschnig]

On Mon, Oct 27, 2014 at 12:07:24 +0100, Santiago Vila wrote:
> On Mon, 27 Oct 2014, Michael Tautschnig wrote:
> 
> > I'm hoping this is not going to be too philosophical, so I'll enlist the 
> > facts
> > first (please let me know if I got any of them wrong):
> > 
> > debootstrap'ing a system fails, because
> > 
> > - chown root:root ... won't work when invoked from base-files' postinst
> > - version 7.7 of base-files is the first to actually have this call when 
> > invoked
> >   from within (c)debootstrap
> 
> Regarding previous point, it should be noted that base-files postinst
> has a lot of chown calls. I would like to know how it is possible that
> only the recently added is the one that fails and not the others
> (if that's really the case).
> 

I suppose none of the others are being executed as all of them are guarded by
some combination of checks?

> BTW: I don't know what is the proper way to debug this (private
> repository using reprepro?). Can anybody confirm that the chown that
> fails is exactly the one at the very end?
> 

Indeed it could be a very different one.  I'm attaching a full log with the
postinst script having set -evx. It might be obvious, but this is being run on a
wheezy system.

> > So let's see what Debian Policy says in 3.8 Essential packages:
> > 
> > "[...] Since dpkg will not prevent upgrading of other packages while an
> > essential package is in an unconfigured state, all essential packages must
> > supply all of their core functionality even when unconfigured. If the 
> > package
> > cannot satisfy this requirement it must not be tagged as essential, and any
> > packages depending on this package must instead have explicit dependency 
> > fields
> > as appropriate. [...]"
> 
> This is about dpkg when making upgrades. It means that once an
> essential package is properly configured, it should not stop working
> because of it being "unconfigured" by dpkg (whatever that means).
> 
> I think it does not apply here.
> 

Then maybe take the first sentence in 3.8 Essential packages instead: "Essential
is defined as the minimal set of functionality that must be available and usable
on the system at all times, even when packages are in the "Unpacked" state."

If not this one (and not the one above), which bit of policy are you then
relying on when you do the chown calls?

> [ snipped philosophical stuff. I would much prefer to have free time
>   to work on this rather than discuss about it. Really ].
> 

As you please. I was just hoping to find potential options other than "revert
the change in base-files."

Best,
Michael

root@mt-farm05:~# mkdir /srv/sid-base.cow
root@mt-farm05:~# pbuilder create --aptcache /srv/jenkins-slave/aptcache 
--debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg 
--buildplace /srv/sid-base.cow --mirror ftp://ftp.uk.debian.org/debian 
--distribution sid --no-targz --extrapackages cowdancer
I: Running in no-targz mode
I: Distribution is sid.
I: Current time: Mon Oct 27 11:44:42 GMT 2014
I: pbuilder-time-stamp: 1414410282
I: Building the build environment
I: running debootstrap
/usr/sbin/debootstrap
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: acl adduser dmsetup 
init-system-helpers insserv libaudit-common libaudit1 libbz2-1.0 libcap2 
libcap2-bin libcryptsetup4 libdb5.3 libdebconfclient0 libdevmapper1.02.1 
libgcrypt20 libgdbm3 libgpg-error0 libkmod2 libncursesw5 libprocps3 
libsemanage-common libsemanage1 libslang2 libsystemd0 libudev1 libustr-1.0-1 
perl perl-modules procps systemd systemd-sysv udev
I: Found additional base dependencies: binutils bzip2 cpp cpp-4.9 
debian-archive-keyring dpkg-dev g++ g++-4.9 gcc gcc-4.9 gnupg gpgv 
libapt-pkg4.12 libasan1 libatomic1 libc-dev-bin libc6-dev libcilkrts5 
libcloog-isl4 libdpkg-perl libgcc-4.9-dev libgmp10 libgomp1 libisl10 libitm1 
liblsan0 libmpc3 libmpfr4 libquadmath0 libreadline6 libstdc++-4.9-dev 
libstdc++6 libtimedate-perl libtsan0 libubsan0 libusb-0.1-4 linux-libc-dev make 
patch readline-common xz-utils
I: Checking component main on ftp://ftp.uk.debian.org/debian...
I: Retrieving acl
I: Validating acl
I: Retrieving libacl1
I: Validating libacl1
I: Retrieving adduser
I: Validating adduser
I: Retrieving apt
I: Validating apt
I: Retrieving libapt-pkg4.12
I: Validating libapt-pkg4.12
I: Retrieving libattr1
I: Validating libattr1
I: Retrieving libaudit-common
I: Validating libaudit-common
I: Retrieving libaudit1
I: Validating libaudit1
I: Retrieving base-files
I: Validating base-files
I: Retrieving base-passwd
I: Validating base-passwd
I: Retrieving bash
I: Validating bash
I: Retrieving binutils
I: Validating binutils
I: Retrieving build-essential
I: Validating build-essential
I: Retrieving

Re: Bug#766459: debootstrap: should not try to configure

[Santiago Vila]

On Mon, 27 Oct 2014, Michael Tautschnig wrote:

+ [ ! -f /usr/info/dir ]
+ [ ! -f /usr/share/info/dir ]
+ install_from_default /usr/share/base-files/info.dir /usr/share/info/dir
+ [ ! -f /usr/share/info/dir ]
+ cp -p /usr/share/base-files/info.dir /usr/share/info/dir
+ chmod 644 /usr/share/info/dir
+ chown root:root /usr/share/info/dir
chown: invalid user: 'root:root'


Thanks a lot for this. I was mistaken/confused. The recently added
three lines at the end of base-files postinst may not be the reason
for debootstrap fail. I've moved them anyway to a better place.

Now we have this "chown root:root /usr/share/info/dir" that fails.

If this is the *only* place where it fails, this could be ommited
because postinst is executed by root and the chown is not really
required.

> > Regarding previous point, it should be noted that base-files postinst
> > has a lot of chown calls. I would like to know how it is possible that
> > only the recently added is the one that fails and not the others
> > (if that's really the case).
> 
> I suppose none of the others are being executed as all of them are guarded by
> some combination of checks?

I refer specifically to the big "if" block starting

if [ "$1" = "configure" ] && [ "$2" = "" ]; then

There are a lot of "install_directory" calls there.

If any of them fails because of the root user does not exist yet, all
of them will fail. But those lines have been there since a long time,
so after base-files_7.9 where I moved the lines that create /mnt on
upgrades, I don't really see what recent change in base-files could be
the reason (or better, the trigger) for debootstrap failure.

It must be something else.

> As you please. I was just hoping to find potential options other
> than "revert the change in base-files."

I'm still open for options for the benefit of wheezy users not using
backports.

But I need to have a better view of why it's failing when it was not
failing before, if that's really the case.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410271258460.32...@cantor.unex.es

Re: Bug#766459: debootstrap: should not try to configure

[Santiago Vila]

For the record, base-files postinst had three lines like this

chown root:root whatever

I've dropped all of them in base-files_7.10.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410271343001.5...@cantor.unex.es

Re: Bug#766459: debootstrap: should not try to configure

[Santiago Vila]

On Mon, 27 Oct 2014, Michael Tautschnig wrote:

> Then maybe take the first sentence in 3.8 Essential packages
> instead: "Essential is defined as the minimal set of functionality
> that must be available and usable on the system at all times, even
> when packages are in the "Unpacked" state."  If not this one (and
> not the one above), which bit of policy are you then relying on when
> you do the chown calls?

My intrepretation of policy regarding essential packages is that *once*
that they are configured for the first time, they should continue to
work at all times even if they are unconfigured for a while in the
middle of an upgrade.

This is consistent with the usual meaning of "bootstrap". It's
something that you only need to do once, because after that,
everything *keeps* working (but only *after* that).

Your interpretation of policy is a little bit different. If you ask
essential packages to provide its core functionality *even* when they
have not been configured for the *first* time, I bet that we would
have to rethink the whole essential thing from the beginning.

For example, your interpretation would force base-passwd to lose its
essential flag, because it can't provide its core functionality only
when in unpacked state. Then, according to policy, base-files and
*every* other package using any of the system users in any of its
maintainer scripts would have to add a "Depends: base-passwd", since
they depend on functionality which is only available after base-passwd
has been configured.

Frankly, I don't think that's what we want.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410271555150.8...@cantor.unex.es

Re: Bug#762401: Installation kFreeBSD-amd64: OK with quirks

[Herbert Kaminski]

On Sun, 26 Oct 2014 15:05:19 +
Steven Chamberlain  wrote:

> NTFS is working for me with the latest fuse4bsd package in sid;  you
> may have to `kldload fuse` if it is not loaded already. 

Apparently, fuse was not loaded, as the command returned no error message 
like the one I got when I issued the command again. But mounting returns 
the same error message that I got w/o loading fuse:

root@debian:/# ntfs-3g /dev/ada0s3 /mnt
ntfs_attr_pread_i: ntfs_pread failed: Das Argument ist ungültig
Failed to read NTFS $Bitmap: Das Argument ist ungültig
The device '/dev/ada0s3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

(Das Argument ist ungültig = the argument is invalid)

BTW: According to https://packages.debian.org/de/fuse4bsd, fuse4bsd 
versions are the same in jessie and sid: 0.3.9~pre1.20080208-9.

Regards,
  Herbert

-- 
Herbert Kaminski   D-26122 Oldenburg


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141027180854.2481b4ca@toshi

Re: Bug#766459: debootstrap: should not try to configure

[Michael Tautschnig]

On Mon, Oct 27, 2014 at 16:36:42 +0100, Santiago Vila wrote:
[...]
> For example, your interpretation would force base-passwd to lose its
> essential flag, because it can't provide its core functionality only
> when in unpacked state. Then, according to policy, base-files and
> *every* other package using any of the system users in any of its
> maintainer scripts would have to add a "Depends: base-passwd", since
> they depend on functionality which is only available after base-passwd
> has been configured.
> 

Yes, indeed this is what I'd infer from policy. But I could easily be wrong.

> Frankly, I don't think that's what we want.
> 

I would say that at least we do not want this at this point in the release
cycle as it appears be bear way too many risks.

Admittedly, all that *I* want is a working debootstrap, so I'm also ok just
having the changes in base-files for now (or maybe also in debootstrap).

Best,
Michael



pgp4bTvfbnFKY.pgp
Description: PGP signature

Bug#767037: installation-reports: jessie on HP EliteBook 820

[Cyril Brulebois]

Hi Claire!

Claire David  (2014-10-27):
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> 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:[ ]
> 
> Comments/Problems:
> 
> On reboot the system cannot find grub. After reinstalling the boot
> loader using the rescue mode of the installer, it is possible to
> manually select grubx64.efi from the firmware but it still does not boot
> on its own.

Thanks for the report; Steve, can you please have a look at this EFI thingy?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Karsten Merker]

Package: installation-reports

Boot method: hd-media (installer booted from USB stick)
Image version:
  http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
  (dated 27-Oct-2014 05:17) together with
  
http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
  (dated 2014-10-27 11:58)
Date: 2014-10-27
U-Boot: 2014.10+dfsg1-1

Machine: LeMaker Banana Pi
Processor: Allwinner A20 (2x Cortex A7)
Memory: 1GB
Mass Storage: 16GB SD card

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

Initial boot:   [O]
Detect network card:[E] (see comments below, getting this to work 
 requires manual loading of the proper
 ethernet PHY driver module)
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:
The "detect network hardware" step fails with
"No Ethernet card was detected. If you know the name of the driver
 needed by your Ethernet card, you can select it from the list."

dmesg shows:
[   73.100072] stmmaceth 1c5.ethernet: no reset control found
[   73.100103]  Ring mode enabled
[   73.100112]  No HW DMA feature register supported
[   73.100120]  Normal descriptors
[   73.100127]  TX Checksum insertion supported
[   73.104782] libphy: stmmac: probed
[   73.104812] eth0: No PHY found

i.e. the correct ethernet MAC driver (stmmac) gets loaded
automatically, but the necessary PHY driver (realtek) does not.
Loading the realtek module after the stmmac driver has probed
for a PHY does not change anything; the stmmac driver does not
re-probe for a PHY upon later loading of the PHY driver.
Manually unloading the stmmac module, loading the PHY driver
and then loading the stmmac module again from a shell by
running

~ # rmmod stmmac
~ # modprobe realtek
~ # modprobe stmmac

results in

[  499.364044] stmmaceth 1c5.ethernet: no reset control found
[  499.364076]  Ring mode enabled
[  499.364084]  No HW DMA feature register supported
[  499.364090]  Normal descriptors
[  499.364097]  TX Checksum insertion supported
[  499.392561] libphy: stmmac: probed
[  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
[  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)

and the ethernet interface works. The kernel version used in this
installer build is 3.16.5-1.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141027213800.ga11...@excalibur.cnev.de

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Cyril Brulebois]

Cc+=debian-kernel@ for input since I seem to recall having seen PHY
drivers (including in a realtek context) being mentioned lately, at
least on IRC, maybe on list as well.

Karsten Merker  (2014-10-27):
> Package: installation-reports
> 
> Boot method: hd-media (installer booted from USB stick)
> Image version:
>   http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz
>   (dated 27-Oct-2014 05:17) together with
>   
> http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo
>   (dated 2014-10-27 11:58)
> Date: 2014-10-27
> U-Boot: 2014.10+dfsg1-1
> 
> Machine: LeMaker Banana Pi
> Processor: Allwinner A20 (2x Cortex A7)
> Memory: 1GB
> Mass Storage: 16GB SD card
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[E] (see comments below, getting this to work 
>  requires manual loading of the proper
>  ethernet PHY driver module)
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [O]
> Install boot loader:[O]
> Overall install:[O]
> 
> Comments/Problems:
> The "detect network hardware" step fails with
> "No Ethernet card was detected. If you know the name of the driver
>  needed by your Ethernet card, you can select it from the list."
> 
> dmesg shows:
> [   73.100072] stmmaceth 1c5.ethernet: no reset control found
> [   73.100103]  Ring mode enabled
> [   73.100112]  No HW DMA feature register supported
> [   73.100120]  Normal descriptors
> [   73.100127]  TX Checksum insertion supported
> [   73.104782] libphy: stmmac: probed
> [   73.104812] eth0: No PHY found
> 
> i.e. the correct ethernet MAC driver (stmmac) gets loaded
> automatically, but the necessary PHY driver (realtek) does not.
> Loading the realtek module after the stmmac driver has probed
> for a PHY does not change anything; the stmmac driver does not
> re-probe for a PHY upon later loading of the PHY driver.
> Manually unloading the stmmac module, loading the PHY driver
> and then loading the stmmac module again from a shell by
> running
> 
> ~ # rmmod stmmac
> ~ # modprobe realtek
> ~ # modprobe stmmac
> 
> results in
> 
> [  499.364044] stmmaceth 1c5.ethernet: no reset control found
> [  499.364076]  Ring mode enabled
> [  499.364084]  No HW DMA feature register supported
> [  499.364090]  Normal descriptors
> [  499.364097]  TX Checksum insertion supported
> [  499.392561] libphy: stmmac: probed
> [  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> [  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
> 
> and the ethernet interface works. The kernel version used in this
> installer build is 3.16.5-1.
> 
> Regards,
> Karsten

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#767037: installation-reports: jessie on HP EliteBook 820

[Julien Cristau]

On Mon, Oct 27, 2014 at 23:16:24 +0100, Cyril Brulebois wrote:

> Hi Claire!
> 
> Claire David  (2014-10-27):
> > Initial boot:   [O]
> > Detect network card:[O]
> > Configure network:  [O]
> > Detect CD:  [O]
> > Load installer modules: [O]
> > Clock/timezone setup:   [O]
> > 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:[ ]
> > 
> > Comments/Problems:
> > 
> > On reboot the system cannot find grub. After reinstalling the boot
> > loader using the rescue mode of the installer, it is possible to
> > manually select grubx64.efi from the firmware but it still does not boot
> > on its own.
> 
> Thanks for the report; Steve, can you please have a look at this EFI thingy?
> 
Steve suggested copying grubx64.efi to /boot/efi/EFI/boot/bootx64.efi,
which worked.  Not exactly ideal, but better than having to navigate
through the ESP at each boot.

Thanks,
Julien


signature.asc
Description: Digital signature

Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module

[Ben Hutchings]

On Tue, 2014-10-28 at 00:18 +0100, Cyril Brulebois wrote:
> Cc+=debian-kernel@ for input since I seem to recall having seen PHY
> drivers (including in a realtek context) being mentioned lately, at
> least on IRC, maybe on list as well.

I don't understand this.

> Karsten Merker  (2014-10-27):
[...]
> > [   73.104782] libphy: stmmac: probed
> > [   73.104812] eth0: No PHY found
> > 
> > i.e. the correct ethernet MAC driver (stmmac) gets loaded
> > automatically, but the necessary PHY driver (realtek) does not.
[...]
> > [  499.392561] libphy: stmmac: probed
> > [  499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> > [  499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
> > 
> > and the ethernet interface works. The kernel version used in this
> > installer build is 3.16.5-1.

$ modinfo -F alias realtek
mdio:???111001100100100010101
mdio:???111001100100100010010

In hex those are 1cc915 and 1cc912.  (The 11 most significant bits are
unspecified.)  So modprobe certainly should find this module when
requested by phylib.

As udev is *not* involved in loading MDIO PHY drivers (NIC drivers
expect them to be bound synchronously) it isn't easy to monitor what's
going on.  You could replace modprobe with a script that logs its
arguments to a file before calling the real modprobe.  That should tell
us whether the bug is in the kernel or userland.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers


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

Bug#668001: debootstrap: cant install systemd instead of sysvinit

[Woody Suwalski]

On Fri, 17 Oct 2014 05:57:30 +0200 Cyril Brulebois  wrote:
> Kenshi Muto  (2014-10-17):
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hi,
> >
> > I made a patch to see each Depends:/Pre-Depends: and
> > respect exclude parameter.
> >
> > If init Pre-Depends: systemd-sysv | sysvinit-core | upstart,
> > exclude= gets systemd-sysv.
> > exclude=systemd-sysv gets sysvinit-core.
> > exclude=systemd-sysv,sysvinit-core gets upstart.
> >
> > (exclude=systemd-sysv,sysvinit-core,upstart gets nothing, but
> > systemd-sysv will be installed later by apt-get.)
>
> Thanks for the patch but…
>
> I'm really uncomfortable adding that kind of patch this late in the
> release cycle, especially since the “I don't want systemd” “problem”
> is trivially solved with a late_command.
>
> Mraw,
> KiBi.

Cyril, Kenshi's debootstrap patch has worked for me. I was able to build 
a nosystemd debootstrap base and then a full custom Debian distro image. 
I had some problems with talking to X, but still managed to make it work.


You have mentioned that there is a trivial late_command workaround for 
systemd. Could you please point to the how-to?


Thanks, Woody


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544ef86c.5060...@gmail.com

Re: Debian 7 with i486 non pae

[Mauricio Aued]

I am going to try both in this weekend.  


I really appreciate your help



El Domingo 26 de octubre de 2014 23:11, Anthony F McInerney  
escribió:
 


Try alt+f4 to see an install log, while the installer is running /
before it cashes.
You could also try various non-free cd's
http://cdimage.debian.org/mirror/cdimage/unofficial/non-free/cd-including-firmware/