Bug#858849: installation-reports: Successful Jessie installation with backported kernel 4.9.16-1+reiser4.0.1 on i915 system AMD64

[Cyril Brulebois]

Hi,

Metztli Information Technology  (2017-03-27):
> Boot method: CD/USB
> Image version: https://metztli.it/readOnlyEphemeral/xiuhcohuatl.iso built on 
> Mar 25 08:35 (2017)
> Date: Mar 26, 2017, 01:49

A couple of months ago, I asked:
| Do we need to get installation reports for non-Debian installers?
| This isn't something we produce, publish, or support, so…

It would be nice if those installation reports could be sent elsewhere;
thanks already.


KiBi.


signature.asc
Description: Digital signature

B2B contact list

[josefina . chavez]

Hi,

Would you be interested in acquiring any of the updated contact databases
of below specified titles that will add great value to your marketing
programs?

We can segment Industry List & Technology Users List by C-level, VP-level,
Director-Level and Manager Level as per your requirements.

*Industry List*

*Technology Users Lists*

*Specialties List*

Information Technology

Epicor

Dermatologist

Healthcare

NetSuite

Plastic Surgeons

Retail Industry

Cloud Users

Radiologist

Hospitality Industry

Epical

Optometrist

Manufacturing Industry

IBM FileNet / Storage

Oncologists

Services Industry

Avaya

Dentist

Insurance

Mainframe

Obstetricians & Gynaecologists

Education

EMC Storage

Orthopaedic

Business Services

SAP Users

Registered Nurse

Oil and Gas

Oracle Users

Urologists

Energy and Utilities

Microsoft Dynamic

Anaesthesiologists

Media

CRM /ERP

Cardiologist

Marketing/Advertising

MS SharePoint

Haematology

Retail & Wholesale

Cisco

Lab Directors

Construction

Rack space

Psychologist

Telecom

Zen desk

Family Practitioner/Medicine *etc.*


Let me know your thoughts or pass on the message to the right person in
your company.

 Thanks & regards,

* Josefina Chavez   *

 Business Development Executive

Bug#858849: installation-reports: Successful Jessie installation with backported kernel 4.9.16-1+reiser4.0.1 on i915 system AMD64

[Metztli Information Technology]

Package: installation-reports
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

Boot method: CD/USB
Image version: https://metztli.it/readOnlyEphemeral/xiuhcohuatl.iso built on 
Mar 25 08:35 (2017)
Date: Mar 26, 2017, 01:49

Machine: HP Pavilion Notebook PC 2x8192MB RAM
Partitions: 
udev   devtmpfs 102400 10240   0% /dev
tmpfs  tmpfs  3276596 9488   3267108   1% /run
/dev/sda6  reiser4   92791120  5182708  87608412   6% /
tmpfs  tmpfs  8191484 7048   8184436   1% /dev/shm
tmpfs  tmpfs 51204  5116   1% /run/lock
tmpfs  tmpfs  81914840   8191484   0% /sys/fs/cgroup
/dev/sda9  ext213626980061 48938  63% /boot
tmpfs  tmpfs  16383008   1638292   1% /run/user/118
tmpfs  tmpfs  1638300   20   1638280   1% /run/user/1000


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

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:[O]
Overall install:[O]

Comments/Problems: Netboot debian-installer was unable to load firmware from 
second USB for wifi connection;
accordingly, in another virtual screen, I mounted the 2nd USB and manually 
copied the firmware
directory onto the installer environment /lib. d-i then detected the wifi 
signal, etc.

I selected a non-expert installation & d-i proceeded normally, by downloading 
via SSL from metztli.it
jessie-packport 4.9.16-1+reiser4.0.1 (2017-03-24), reiser4progs 1.1.x, as well 
as bp replacements of:

nfs-common_1.3.4-2.1_amd64.deb 
libgssapi-krb5-2_1.15-1.1_amd64.deb
libk5crypto3_1.15-1.1_amd64.deb
libkrb5-3_1.15-1.1_amd64.deb
libkrb5support0_1.15-1.1_amd64.deb

In this installer I noticed a lot of debugging verbosity (F4), but overall 
installation was successfull.
In this Reiser4 'retrofitted' d-i, a non-expert install will leave the regular 
kernel in addition to
the Reiser4-enabled bp kernel.
< https://metztli.it/readOnlyEphemeral/xiuhcohuatl_0.png >

notwithstanding a netstat will show same services available as in a non-reiser4 
install.
Regular kernel may be purged by user -- who, if having selected option 'Debian 
Desktop Environment' will see:
< https://metztli.it/readOnlyEphemeral/xiuhcohuatl_01.png >

Again, as in the last installation, dmesg shows segmentation faults as user 
operates her/his new jessie, as shown in snapshot:

< https://metztli.it/readOnlyEphemeral/xiuhcohuatl_02.png >

which introduce latency in the operation of the newly installed jessie. These 
issues will go away by doing:

apt-get -t jessie-backports update
apt-get -t jessie-backports dist-upgrade

Except that non-expert install does not provide jessie-backports option or by 
default. The user thus has to add directive:

deb http://ftp.debian.org/debian jessie-backports main

(at least) to her/his /etc/apt/sources.list

Finally, unlike user who reported bug 858078 with i915,
< https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858078 >
this system booted normally into a GUI without modification on my part:

lsmod | grep i915
i915 1241088  5 
drm_kms_helper155648  1 i915
drm   360448  6 i915,drm_kms_helper
i2c_algo_bit   16384  1 i915
video  40960  1 i915
button 16384  1 i915

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20170325-15:09"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux xiuhcohuatl 4.9.0-2+reiser4.0.1-amd64 #1 SMP Debian 
4.9.16-1+reiser4.0.1 (2017-03-24) x86_64 Xonecuiltzin
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0104] (rev 09)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1658]
lspci -knn: 00:02.0 

Re: 8.8 planning

[Ansgar Burchardt]

On Tue, 2017-03-14 at 12:00 +0100, Julien Cristau wrote:
> It's time to start thinking about our next stable point
> release.  Here
> are some dates, please let us know which ones would work.
> 
> * April 8-9

Not ideal, but should work.

> * April 15-16

Only on 16th.

> * April 22-23
> * April 29-30
> * May 6-7

These should all be okay.

Ansgar

Bug#749991: Wrong kernel in debian-installer package

[Holger Levsen]

On Mon, Mar 27, 2017 at 12:54:18PM +0100, Ian Campbell wrote:
> > > One can always use http://snapshot.debian.org/ as one's mirror and
> > specify a dated URL that matches the ISO's creation date.
> I think (based on the last few paragraphs in the "Usage" section of
> that URL) that one would also need to preseed some stuff to cause it to
> accept the expired signatures on that repo (with all that implies wrt
> security), not sure if/how that can be done in practice though.
 
if accepting expired signatures in this case were made the default, I'd
consider this as much worse than the status quo. if there was a question
explaining this is dangerous and this question has a "proceed (y/N)" question
default to "no" it might be acceptable in my book…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#749991: Wrong kernel in debian-installer package

[Ian Campbell]

On Mon, 2017-03-27 at 13:32 +0200, Philip Hands wrote:
> > Alexander Sosedkin  writes:
> 
> > On Mon, 27 Mar 2017 12:43:40 +0200
> > > > Philipp Kern  wrote:
> > 
> > > Even if we'd leave the old kernel udebs in testing for a while, you'd 
> > > still hit a point where we'd need to drop them and old installers
> > > would break.
> > 
> > I can see that it's impossible to support downloading modules for all
> > old ISOs.
> 
> > One can always use http://snapshot.debian.org/ as one's mirror and
> specify a dated URL that matches the ISO's creation date.

I think (based on the last few paragraphs in the "Usage" section of
that URL) that one would also need to preseed some stuff to cause it to
accept the expired signatures on that repo (with all that implies wrt
security), not sure if/how that can be done in practice though.

Ian.

Bug#749991: Wrong kernel in debian-installer package

[Alexander Sosedkin]

On Mon, 27 Mar 2017 13:32:46 +0200
Philip Hands  wrote:

> Alexander Sosedkin  writes:
> 
> > On Mon, 27 Mar 2017 12:43:40 +0200
> > Philipp Kern  wrote:
> >  
> >> Even if we'd leave the old kernel udebs in testing for a while,
> >> you'd still hit a point where we'd need to drop them and old
> >> installers would break.  
> >
> > I can see that it's impossible to support downloading modules for
> > all old ISOs.  
> 
> One can always use http://snapshot.debian.org/ as one's mirror and
> specify a dated URL that matches the ISO's creation date.

My point is that for ISOs that makes at least some sense,
but having an old netboot kernel lying in-tree with no modules to
complement it a grave bug. I shouldn't hunt for a snapshot to make my
virt-install invocation work.

Bug#749991: Wrong kernel in debian-installer package

[Philip Hands]

Alexander Sosedkin  writes:

> On Mon, 27 Mar 2017 12:43:40 +0200
> Philipp Kern  wrote:
>
>> Even if we'd leave the old kernel udebs in testing for a while, you'd 
>> still hit a point where we'd need to drop them and old installers
>> would break.
>
> I can see that it's impossible to support downloading modules for all
> old ISOs.

One can always use http://snapshot.debian.org/ as one's mirror and
specify a dated URL that matches the ISO's creation date.

Cheers, Phil.

P.S. I suppose we could build-in such a snapshot URL, as a fallback in
case mirrors have dropped the files we're after, but I think doing so is
asking for trouble.  It would be the sort of code that gets used rarely
enough to end up rotting, and would also have the potential to mask bugs
in the normal code path.  Generally, if you want to survive this, just
use a CD image that includes the matching modules.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#749991: Wrong kernel in debian-installer package

[Alexander Sosedkin]

On Mon, 27 Mar 2017 12:43:40 +0200
Philipp Kern  wrote:

> Even if we'd leave the old kernel udebs in testing for a while, you'd 
> still hit a point where we'd need to drop them and old installers
> would break.

I can see that it's impossible to support downloading modules for all
old ISOs.

But how about supporting at least one target: current netboot kernel?
Both module udebs and netboot kernel seem to belong in a single
repository hierarchy, why do they desync then?

Bug#749991: Wrong kernel in debian-installer package

[Philipp Kern]

On 2017-03-27 11:56, Nye Liu wrote:

The reason I ask is because I have custom  grub menu configs that I
don't want to constantly hand edit or patch on a cron job along with a
cron to download the dailies... and then have no idea if the cron will
do the right thing, or if the daily even works. I'd like a "known
good" net boot install server for testing and this is making it
difficult.


Well, no-one can give you that guarantee with testing (rather than 
stable, but even there you might need to re-download the installer). One 
way would be to mirror a snapshot of testing, get an installer to work 
with it and then let the install process upgrade everything 
post-install. There isn't necessarily a need to install the most current 
at all times.


Even if we'd leave the old kernel udebs in testing for a while, you'd 
still hit a point where we'd need to drop them and old installers would 
break.


So if you are serious about the "even works", which is also a function 
of the hardware you install on, then maybe you need to run your own 
installer qualification process once in a while.



If you think this might be useful I'd be willing to help develop a
patch and/or help test one.


Well, if you have ideas that work within the current framework, we can 
see about that. Thanks for the offer. :)


Kind regards
Philipp Kern

Bug#749991: Wrong kernel in debian-installer package

[Nye Liu]

Thanks for your response.

On Sun, 26 Mar 2017 18:31:45 +0200 Philipp Kern  wrote:

> IOW: Is there a way to guarantee that
> (dist)/main/installer-amd64/current/images/netboot/netboot.tar.gz does not
> contain a kernel that has no modules package IN THAT SAME mirror?
>
> Or maybe even an automated way to update netboot.tar.gz every time a
> dists linux-image-(arch).deb is updated, a new netboot.tar.gz can be
> created from 
(dist)/main/installer-amd64/current/images/netboot/netboot.tar.gz?

Unfortunately such a mechanism does not currently exist. You can try to
peruse the daily builds hosted on https://d-i.debian.org for this. They
are rebuilt daily and should be able to install testing.


Understood.

Another crazy idea then: have a way to specify where the "current" 
kernel .deb (for whatever kernel is in netboot.tar.gz) is via preseed or 
something?


Or keep a copy of the that .deb for a given netboot.tar.gz in the same 
dir (main/installer-amd64/current/images/netboot?) or other known 
location on a mirror?


The reason I ask is because I have custom  grub menu configs that I 
don't want to constantly hand edit or patch on a cron job along with a 
cron to download the dailies... and then have no idea if the cron will 
do the right thing, or if the daily even works. I'd like a "known good" 
net boot install server for testing and this is making it difficult.


If you think this might be useful I'd be willing to help develop a patch 
and/or help test one.


Thanks for your time, as usual, Ben.

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Sun, Mar 26, 2017 at 08:18:16PM +0200, Karsten Hilbert wrote:

> One thing I *haven't* tested yet is whether earlier kernel
> would make a difference -- not that I would think but who
> knows.

Just for kicks I booted all kernels installed on this machine
(all prior experimentation was done under 4.10) -- the
console did not get properly configured under any of 4.3,
4.6, or 4.9.

I did manage to have parallelism detection kick in once though:

[...]
1087 - 2017-03-27 09:54:40.488734408+02:00: 
/cached_setup_font.sh.running created
1087 - 2017-03-27 09:54:40.509440184+02:00: 
/cached_setup_font.sh.running deleted
[reboot]
426 - 2017-03-27 09:57:39.157315082+02:00: 
/cached_setup_font.sh.running created
502 - 2017-03-27 09:57:40.195551438+02:00: 
/cached_setup_font.sh.running exists and contains [426 / 2017-03-27 
09:57:39.157315082+02:00], exiting
426 - 2017-03-27 09:57:40.709767317+02:00: 
/cached_setup_font.sh.running deleted
657 - 2017-03-27 09:57:42.245186312+02:00: 
/cached_setup_font.sh.running created
657 - 2017-03-27 09:57:42.268458964+02:00: 
/cached_setup_font.sh.running deleted

so at least we got this right, technically :-)

These boots were under slightly heavier load: two external
USB mass storage devices being online during the entire
reboot cycle, one of which acts as backup swap while the
other is a backup device being hit by another machine over
the network as soon as the problem machine reaches network
target.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346