Bug#818481: installation-reports: Xen PV drivers not present in 32-bit installer kernel (but present in installed kernel)

[Ben Hutchings]

The default installer uses the 686 (non-PAE) kernel which I believe
cannot run in a Xen PV domain.  You're supposed to use the Xen netboot
image to install a PV domain, e.g. from:


Given that you were able to boot the default installer anyway, it
sounds like you are using a PVHVM domain rather than a PV domain.  Is
that correct?

Perhaps it does makes sense to include the Xen PV drivers even in the
686 kernel and installation images, to support this.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#818457: installation-reports: successfull installation on HP ProLiant Microserver N36L

[root]

Package: installation-reports
Severity: wishlist

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: USB media
Image version: Debian 8 Jessie netinst 8.0 amd64
Date: 

Machine: HP ProLiant Microserver N36L
Partitions: 


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:  [ ]
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:




-- 

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 20150422"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux n36l 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
RS880 Host Bridge [1022:9601]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: 00:01.0 PCI bridge [0604]: Hewlett-Packard Company Device 
[103c:9602]
lspci -knn: 00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 
PCI to PCI bridge (PCIE port 2) [1022:9606]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:11.0 RAID bus controller [0104]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [Non-RAID5 mode] [1002:4392] (rev 
40)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ahci
lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 
SMBus Controller [1002:4385] (rev 42)
lspci -knn: 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
SBx00 PCI to PCI Bridge [1002:4384] (rev 40)
lspci -knn: 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Family 10h Processor HyperTransport Configuration [1022:1200]
lspci -knn: 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Family 10h Processor Address Map [1022:1201]
lspci -knn: 

Question prompted by [Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?)]

[Richard Owlett]

On 3/17/2016 8:22 AM, Marco d'Itri wrote:

On Mar 17, Charles Plessy  wrote:
[snip]


main reason for wanting HTTPS support by default.  Are you suggesting that the
benefit is too small compared to the disadvantage of having slightly larger
size for cloud images that contain all the packages of "Important" priority ?

The common deployment model for this kind of cloud services is to
install the software on the new instance using some kind of
orchestration system (ansible, puppet, etc).
So everything which is not required to begin the first installation of
other packages is superfluous.
"Important" is a label that was invented for human-managed servers and
I do not believe that it is relevant anymore in this context.



I have not followed this thread closely as I have no significant 
contact with "the cloud".


However I do have an interest in "minimal" installs - "minimal" 
having vague definitions. As a working definition I take the 
point of view likely held by those working on embedded systems 
when they were slow and resource constrained. My problem with 
priority designations in the current installer(s) is they are too 
strongly tied to the concept once expressed as "what facility 
would _everybody_ expect in _any_ system".


My question "Are there key words that I should search for to get 
current ideas for useable small installs?"

TIA

Bug#818592: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Package: s390-zfcp
Version: 1.0.1
Severity: important
Tags: d-i

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also related Debian Bug #818586 for the disk-detect package.

Patch for the control file will follow.

Thanks and kind regards,
  Hendrik

Bug#818586: disk-detect/control: Improve harddrive detection dependency on s390x

[Hendrik Brueckner]

Control: block -1 by 818591 818592

Re: Bad release in install documentation

[Holger Wansing]

Hi,

Laura Arjona Reina  wrote:
>  Ok, it seems the jessie installation guide is published correctly and
>  it's not overwritten with lessoften script.
> 
>  I don't know if there should be a stretch installation guide right now,
>  or only after stretch is published as stable.
>  The page https://www.debian.org/releases/stretch/ seems it has no link
>  to the installation guide.
>  The page https://www.debian.org/devel/debian-installer/ links to the
>  stable version of the manual, and to d-i.debian.org/manual
> 
>  So I guess this problem is fixed, and everything is ok? (until the next
>  release?). Or do I need to manually generate the stretch version of the
>  installmanual, as I did with jessie?

Seems fine now!
Manual for stable is the correct one, and the one for stretch is not yet
published on the website (except the development versions on
https://d-i.debian.org/manual/ which correctly document stretch).

So this is done for now, many thanks, Laura!

Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

SFRN 4.0.1 Reiser4-enabled netboot iso/USB

[Jose R R]

Niltze, all!

Reiser4 -enabled Debian-Installer with user selectable Reiser4-patched
kernel has been submitted to an open minded media organization for
evaluation:

-- Forwarded message --
From: Jose R Rodriguez 
Date: Thu, Mar 17, 2016 at 4:47 AM
Subject: Re: XXYYY.com Inquiry
To: XX YYY 


Good morning, XX-

Here is a link to an approximately 42 MB Reiser4-enabled
Debian-Installer (d-i) netboot: metztli.iso
https://metztli.it/readOnlyEphemeral/metztli.iso
https://metztli.it/readOnlyEphemeral/metztli.SHA256

If you wanna burn the metztli.iso file to a USB device -- to boot from
bare metal, for instance:
(sudo) dd if=metztli.iso of=/dev/sdb bs=4M; sync
where, of course, /dev/sdb represents your USB device

I recommend doing an expert install from the d-i menu and to install
Sid -- as d-i is gonna work until the next unstable kernel becomes
default* (around the weekend). Of course, you may also fall back to
Stretch -- but not Jessie (stable) as we are using unstable d-i.

Most important: please create a small /boot partition (say 100 - 150
MB formatted in ext2), since default GRUB2 installer does not
recognize Reiser4.

Note: since the metztli.iso image runs a streamlined (UDEB) custom
reiser4-enabled kernel, please ignore the warning (as exemplified in
snapshot attached). Thus, select yes to continue the install without
loading (debian repository) kernel modules.
https://pbs.twimg.com/media/CdxuY-EUEAAC398.jpg:large

And finally when presented with menu list of Linux kernels AMD64
available to install, of course, select "linux-reiser4-amd64." After a
successful Debian installation, you'll find syslog at
/var/log/installer.

Thank you in advance, XX.


Best Professional Regards.

P.S Care has bee taken to provide a usable software -- as well as
limited virtual and/or physical testing -- but as in all free
software, no implicit and/or explicit warranties are offered by
Metztli IT.


-- 
Jose R R
http://metztli.it
-
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
-
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
-

Processed: Re: Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +help
Bug #818604 [win32-loader] Relies on MD5SUM and SHA1SUM to download d-i images 
in a trustful way
Added tag(s) help.

-- 
818604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818604
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?)

[Charles Plessy]

> On Mar 15, Adam Bolte  wrote:
> 
> > What does it buy you exactly? Debian repositories already do package
> > signing, so we know things haven't been tampered with. Probably any

Le Wed, Mar 16, 2016 at 11:52:49AM +0100, Marco d'Itri a écrit :
> 
> I fully agree.

Hi Marco,

have you followed the part of the discussion related to privacy ?  This is the
main reason for wanting HTTPS support by default.  Are you suggesting that the
benefit is too small compared to the disadvantage of having slightly larger
size for cloud images that contain all the packages of "Important" priority ?

I noted your previous comment about the need to provide minimal images for
containers and I fully agree, but this is not what is propoosed here: in my
understanding, container images would typically be built with debootstrap's
"minbase" variant, which only installs packages of priority "Required".

On the other hand, if you think that the argument of size applies to both
cases, can you comment on which packages should in your opinion have their
priority corrected form Important to something lower ?

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#818586: disk-detect/control: Improve harddrive detection dependency on s390x

[Hendrik Brueckner]

Package: hw-detect
Version: 1.116
Severity: important
Tags: d-i

On Linux on z Systems, there are two major disk storage environments,
the direct-attached storage disk (DASD) and SCSI over Fibre-Channel.

There are the s390-dasd and s390-zfcp d-i modules to configure and
enable DASDs and FCP devices.  Note that on s390x, disks are not
available by default to Linux and must be enabled in advance.

The s390-dasd and s390-zfcp both provide the harddrive-detection
dependency and, thus, each could fulfill the dependency to silenty
ignore the other.  That behavior does not allow to mix DASDs and
SCSI disk on single installation (except you call both manually,
for example, in the expert mode).

To improve and provide a "guided" flow, I have split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

disk-detect depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.

With this split, the guided installation will install disk-detect to
solve the harddrive-detection dependency.  In turn, disk-detect will
then rely on the s390-dasd and s390-zfcp d-i modules to provide DASD
and FC-attached SCSI disks.  If both modules fail, the user perceives
the default disk-detect behavior, for example, users might configure
iSCSI.

The other nice benefit of this dependency split is the seamlessly
enablement of multipath with disk-detect (through preseeding).
For s390, multipathing should be always considered when SCSI is used.
I probably will extend the s390-zfcp module to set disk-detect's
multipath debconf variable for usability.


I will attach a patch with changelog when I have received the bug
number for report.  For s390-dasd and s390-zfcp, I will also open
bug reports to implement the dependency chain.

Feedback is welcome.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen

Installing on Samsung Ativ 500T

[Nils]

Hello,
I'm trying to install on a Samsung Ativ 500T tablet with keyboard dock.
It has an Atom Z2670 processor.

Details:
- using the debian-8.3.0-i386-netinst image written to USB with
win32diskimager
- quirk: when hitting F10 for the boot menu after power on, the tablet
only sees the USB stick every second boot or so... if it doesn't see it,
I go into the bios, exit without saving and then it sees it. Probably a
harmless timing issue.
- UEFI secure boot is off; there is no "legacy mode" in the BIOS (power
and volume buttons get to the BIOS as well as the F10 boot selection)
- The BIOS on this device is minimal: Info - Security (just TPM and
secure boot options) - Exit
- Grub loads fine
- selecting any install option (normal, advanced, graphical, etc.)
directly causes an almost immediate freeze, with the USB stick blinking
for a few seconds then stopping
- adding apci=off (and removing the -quiet) gives the usual textflood
and then the installer comes up (both text and graphical show correctly)
- the installer hangs immediately. Both graphical and text installers
don't take input (keyboard or mouse) any more. USB keyboard doesn't even
react to caps/num lock
- I've tried --vga=733 as well, no difference.

Here are some related Ubuntu install issues if that helps:
http://ubuntuforums.org/showthread.php?t=2312779
http://forum.tabletpcreview.com/threads/boot-from-usb-500t.53946/

Any thoughts on what else to try? Is there an installer image with
--debug=insane that writes complete debug logs to the USB stick so I can
post them?

Thanks
Nils

Bug#814923: tasksel: Please add task-lxqt-desktop to tasksel

[陳昌倬]

Any progress for this patch?


-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D


signature.asc
Description: PGP signature

Re: Archive changes

[Adam Conrad]

On Wed, Mar 16, 2016 at 10:26:25AM +0100, Ansgar Burchardt wrote:
> 
> debootstrap already requires xz support: the binary packages are
> compressed with xz (at least data.tar.xz).

Ahh, this is a fair point, since we failed to make everything in the
debootstrap set compressed with gzip (which I think was a goal at one
point, but a goal we clearly failed to meet).

In that case, I have no qualms about adding Packages.xz support to it
as well, and updating stable/oldstable as well, so people can use it
to debootstrap sid chroots.

If no one beats me to it, I'll at least do the sid commits and upload
a bit $later, and maybe get to the stables as well.

... Adam

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Stephen Kitt]

Hi Didier,

On Fri, Mar 18, 2016 at 06:43:41PM +0100, Didier 'OdyX' Raboud wrote:
> Le vendredi, 18 mars 2016, 16.25:10 Didier 'OdyX' Raboud a écrit :
> > win32-loader (its standalone version, available from debian/tools/ )
> > currently relies exclusively on MD5 and SHA1 to trustfully download
> > the d-i images.
>
[...]
> 
> B) Write a new standalone sha256sum.c NSIS plugin from one of the
>existing implementations:
>   - libgcrypt: cipher/sha256.c (LGPLv2.1+)
>   - coreutils: lib/sha256.c (GPLv3+)
>   - e2fsprogs: lib/ext2fs/sha256.c (GPLv2)
>   - wget: lib/sha256.c (GPLv3+)
>   - glibc: crypt/sha256.c (LGPLv2.1+)
>   - … plenty of others
> 
> Given that win32-loader is GPLv3 +, this excludes e2fsprogs', but others 
> should be fine.

It might be possible to use libgcrypt-mingw-w64-dev, currently in
experimental, to write a new NSIS plugin without duplicating the
hashing implementation... The libgcrypt package should end up in
Stretch before the release, since the whole point of it is to support
the Windows build of gnupg2.

Regards,

Stephen



signature.asc
Description: PGP signature

Bug#818591: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Package: s390-dasd
Version: 0.0.35
Severity: important
Tags: d-i

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also the related Debian bug report #818586 for the disk-detect
package.

As usual, I will attach a patch with changelog and bug information.

Thanks and kind regards,
  Hendrik

Processed: block 818463 with 818604

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 818463 with 818604
Bug #818463 [ftp.debian.org] archive changes: md5/sha1, gz/xz
818463 was blocked by: 818324
818463 was not blocking any bugs.
Added blocking bug(s) of 818463: 818604
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
818463: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818463
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: ata1.00: exception Emask 0x0 SAct 0x7f00000c SErr 0x0 action 0x6 frozen

[Jose R R]

Perhaps I spoke too soon, I have successfully selected (from the menu
of d-i) a Reiser4-enabled Linux kernel, built the 'Debian way', during
new Debian installation in a virtual environment:

Selecting a Reiser4-patched Linux Kernel From Reiser4-enabled
Debian-Installer (d-i) Menu

https://metztli.it/blog/index.php/ixiptli/aH3


Best Professional Regards.

On Fri, Mar 18, 2016 at 7:57 PM, Jose R R  wrote:
> Niltze, all-
>
> Any insight appreciated. Thank you.
>
> Using SFRN 4.0.1 Reiser4*-patched kernel source 4.4.6-2 UDEB in unstable d-i
> *(reiser4-for-4.4.0.patch.gz)
>
> It has already happened 3 times during my test install in VirtualBox
> 5.0.14 and 5.0.16
>
> [...]
> Mar 19 01:03:38 anna-install: Installing partman-auto-lvm
> Mar 19 01:03:38 anna[3589]: DEBUG: retrieving e2fsprogs-udeb
> 1.43~WIP.2016.03.15-2
> Mar 19 01:03:40 anna[3589]: DEBUG: retrieving lvm2-udeb 2.02.146-1
> Mar 19 01:03:42 anna[3589]: DEBUG: retrieving partman-auto-lvm 59
> Mar 19 01:03:43 anna[3589]: DEBUG: retrieving partman-lvm 112
> Mar 19 01:03:46 anna-install: Installing partman-auto-crypto
> Mar 19 01:03:46 anna[3736]: DEBUG: retrieving partman-auto-crypto 24
> Mar 19 01:03:48 anna[3736]: DEBUG: retrieving partman-crypto 87
> Mar 19 01:03:50 kernel: [  463.246921] ntfs: driver 2.1.32 [Flags: R/W 
> MODULE].
> Mar 19 01:03:51 kernel: [  463.323580] raid6: sse2x1   gen()  3377 MB/s
> Mar 19 01:03:51 kernel: [  463.402165] raid6: sse2x1   xor()  2977 MB/s
> Mar 19 01:03:51 kernel: [  463.472176] raid6: sse2x2   gen()  5881 MB/s
> Mar 19 01:03:51 kernel: [  463.543505] raid6: sse2x2   xor()  5213 MB/s
> Mar 19 01:03:51 kernel: [  463.622093] raid6: sse2x4   gen() 11703 MB/s
> Mar 19 01:03:51 kernel: [  463.692105] raid6: sse2x4   xor()  8443 MB/s
> Mar 19 01:03:51 kernel: [  463.692108] raid6: using algorithm sse2x4
> gen() 11703 MB/s
> Mar 19 01:03:51 kernel: [  463.692109] raid6:  xor() 8443 MB/s, rmw 
> enabled
> Mar 19 01:03:51 kernel: [  463.692111] raid6: using ssse3x2 recovery algorithm
> Mar 19 01:03:51 kernel: [  463.693511] xor: automatically using best
> checksumming function:
> Mar 19 01:03:51 kernel: [  463.762093]avx   : 39088.000 MB/sec
> Mar 19 01:03:51 kernel: [  463.773480] Btrfs loaded
> Mar 19 01:03:51 kernel: [  463.785316] JFS: nTxBlock = 7975, nTxLock = 63801
> Mar 19 01:03:51 kernel: [  463.797510] Loading Reiser4 (format
> release: 4.0.1) See www.namesys.com for a description of Reiser4.
> Mar 19 01:03:51 kernel: [  463.811589] SGI XFS with ACLs, security
> attributes, realtime, no debug enabled
> Mar 19 01:03:51 md-devices: mdadm: No arrays found in config file or
> automatically
> Mar 19 01:03:51 kernel: [  464.061106] device-mapper: uevent: version 1.0.3
> Mar 19 01:03:51 kernel: [  464.061349] device-mapper: ioctl:
> 4.34.0-ioctl (2015-10-28) initialised: dm-de...@redhat.com
> Mar 19 01:03:51 partman:   No matching physical volumes found
> Mar 19 01:03:51 partman:   Reading all physical volumes.  This may
> take a while...
> Mar 19 01:06:47 partman: mke2fs 1.43-WIP (15-Mar-2016)
> Mar 19 01:06:49 partman: mke2fs 1.43-WIP (15-Mar-2016)
> Mar 19 01:06:57 kernel: [  649.939221] reiser4: sda6: found disk format 4.0.1.
> Mar 19 01:06:57 kernel: [  649.950236] reiser4: sda6: using Hybrid
> Transaction Model.
> Mar 19 01:06:57 kernel: [  650.164258] EXT4-fs (sda1): mounting ext2
> file system using the ext4 subsystem
> Mar 19 01:06:57 kernel: [  650.205386] EXT4-fs (sda1): mounted
> filesystem without journal. Opts: (null)
> Mar 19 01:06:57 kernel: [  650.283688] EXT4-fs (sda5): mounted
> filesystem with ordered data mode. Opts: (null)
> Mar 19 01:06:58 apt-install: Queueing package e2fsprogs for later installation
> Mar 19 01:06:58 apt-install: Queueing package reiser4progs for later
> installation
> Mar 19 01:06:58 apt-install: Queueing package initramfs-tools for
> later installation
> Mar 19 01:06:58 apt-install: Queueing package linux-base for later 
> installation
> Mar 19 01:06:58 apt-install: Queueing package ca-certificates for
> later installation
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> /lib/partman/free_space/50new/do_option:
> Mar 19 01:06:58 main-menu[3206]: (process:3575): line 226:
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> /lib/partman/active_partition/copy/choices: not found
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> /lib/partman/free_space/50new/do_option:
> Mar 19 01:06:58 main-menu[3206]: (process:3575): line 226:
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> /lib/partman/active_partition/copy/choices: not found
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> /lib/partman/free_space/50new/do_option:
> Mar 19 01:06:58 main-menu[3206]: (process:3575): line 226:
> Mar 19 01:06:58 main-menu[3206]: (process:3575):
> /lib/partman/active_partition/copy/choices: not found
> Mar 19 01:06:58 main-menu[3206]: 

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Didier 'OdyX' Raboud]

Package: win32-loader
Version: 0.7.14
Severity: important
Tags: d-i
Control: blocks 818463 by -1

win32-loader (its standalone version, available from debian/tools/ ) currently
relies exclusively on MD5 and SHA1 to trustfully download the d-i images.

Processed: Re: Bug#818591: control: split and improve dependency handling for disk detection

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #818591 [s390-dasd] control: split and improve dependency handling for disk 
detection
Added tag(s) patch.

-- 
818591: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818591
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#818611: netcfg: Misleading error message when parsing line with trailing blank

[Hendrik Brueckner]

Control: tags -1 + patch

Bug#818499: busybox: CVE-2016-2147: OOB heap write due to integer underflow

[Salvatore Bonaccorso]

Source: busybox
Version: 1:1.20.0-7
Severity: normal
Tags: security upstream fixed-upstream

Hi,

the following vulnerability was published for busybox, filling for
tracking purpose.

CVE-2016-2147[0]:
OOB heap write due to integer underflow

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-2147

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way

[Didier 'OdyX' Raboud]

Control: tags -1 +help

Le vendredi, 18 mars 2016, 16.25:10 Didier 'OdyX' Raboud a écrit :
> win32-loader (its standalone version, available from debian/tools/ )
> currently relies exclusively on MD5 and SHA1 to trustfully download
> the d-i images.

After some more checking, this doesn't appear to be a quick and easy 
fix, and here's why:

plugins/sha1sum.c is an NSIS plugin file, inheriting from Werner Koch's 
sha1sum.c [0,1], itself inheriting from GnuPG 1.3.92. It has the 
advantage of allowing win32-loader.exe to proceed with the verification 
inline, without any Windows-specific dependency.

Here are the possibilities I see:

A) Package, and then use an NSIS plugin leveraging the Windows CryptoAPI
   [2]:
  - http://nsis.sourceforge.net/Crypto_plug-in
(doesn't support SHA256, last updated in 2013)
  - http://nsis.sourceforge.net/NsisCrypt_plug-in
Does support various hashes
First and only version in 2010
License quite unclear
https://sourceforge.net/projects/angabin/files/Version%201.0.0/

B) Write a new standalone sha256sum.c NSIS plugin from one of the
   existing implementations:
  - libgcrypt: cipher/sha256.c (LGPLv2.1+)
  - coreutils: lib/sha256.c (GPLv3+)
  - e2fsprogs: lib/ext2fs/sha256.c (GPLv2)
  - wget: lib/sha256.c (GPLv3+)
  - glibc: crypt/sha256.c (LGPLv2.1+)
  - … plenty of others

Given that win32-loader is GPLv3 +, this excludes e2fsprogs', but others 
should be fine.

C) Get coreutils build a hashsums-win32 package containing cross-
   compiled win32 executables (as we're doing for gpgv-win32 and cpio-
   win32). It could also provide these files through byhand, to allow
   users to check images on Windows platforms themselves too [3].

I don't like the first option, as it relies on outdated glue software; 
the second option probably provides the cleanest solution from the 
win32-loader point of view, at the cost of yet another sha256 
implementation. The third option feels like the correct way to do it, at 
the risk of adding win32 compilers in the bootstrap circle, through 
coreutils.

I'll see whether I can produce a patch to do C), and keep this bug 
posted.

-- 
Cheers,
OdyX

[0] https://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html
[1] ftp://ftp.gnupg.org/gcrypt/binary/sha1sum.c
[2] https://en.wikipedia.org/wiki/Microsoft_CryptoAPI
[3] 
https://lists.fedoraproject.org/pipermail/infrastructure/2009-November/008052.html

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

ABI bump libdebian-installer

[Bastian Blank]

Hi folks

We finally need to do an ABI bump for libdebian-installer.  It currently
have hardcoded only support for md5 and I hacked in support for sha1
some years back.  This needs to be fixed finally, but will change so
core structures of the packages support.

Please speak up if there are problems with that.

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

[Felipe Sateler]

On 6 March 2016 at 19:29, Anton Zinoviev  wrote:
> Thank you for the useful explanations in your message!

Glad they are useful :)

>
> On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote:
>>
>> I meant the logic to determine if setupcon or the cached scripts should be
>> run. If in the future that part is changed (eg, the names are changed, or
>> more scripts are generated), there is no guarantee the change will reach
>> users, since they may have modified the init script.
>
> I see...  Yes, you are correct about this.
>
>> However, this is not exactly the same: if the cached script fails, then
>> setupcon would not be run.
>
> I was just pondering on the different options I had.  One of them was
> to change the cached script so that it runs setupcon when necessary.

Yet another one would be to have setupcon itself detect the existence
of the cached scripts.


>> Also, I would advise against having different logic in the systemd services
>> than in the init scripts: the maintenance burden is higher, and requires a
>> higher initial understanding from people not already familiar with the
>> package.
>
> I agree in 100% with this.

Would you be OK, until further development comes along, to use a
wrapper unit like this:

[Unit]
Description=Set the console keyboard layout
DefaultDependencies=no
Before=local-fs-pre.target
Wants=local-fs-pre.target
ConditionPathExists=/bin/setupcon

[Service]
Type=oneshot
ExecStart=/etc/init.d/keyboard-setup.sh start
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target



And mutatis mutandis for console-setup.sh? While not being the optimal
setup, it works, and avoids reliance on the debian-specific runlevel S
support.

I plan to do a NMU fixing this bug via a unit like the above, please
tell me if you want to address this in some other way.

-- 

Saludos,
Felipe Sateler

Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?)

[Marco d'Itri]

On Mar 17, Charles Plessy  wrote:

> have you followed the part of the discussion related to privacy ?  This is the
Yes: I agree that if somebody has a privacy fetish then TOR is the 
correct solution since packages can still be identified by traffic 
analisys.

> main reason for wanting HTTPS support by default.  Are you suggesting that the
> benefit is too small compared to the disadvantage of having slightly larger
> size for cloud images that contain all the packages of "Important" priority ?
The common deployment model for this kind of cloud services is to 
install the software on the new instance using some kind of 
orchestration system (ansible, puppet, etc).
So everything which is not required to begin the first installation of 
other packages is superfluous.
"Important" is a label that was invented for human-managed servers and 
I do not believe that it is relevant anymore in this context.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

[Anton Zinoviev]

On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote:
> 
> Yet another one would be to have setupcon itself detect the existence
> of the cached scripts.

The only reason there are cached scripts is that people are complaining 
that console-setup is slow at boot.  The cached scripts contain the 
mininum configuration sufficient to configure the console.  If we run 
setupcon, we don't need cached scripts.

> Would you be OK, until further development comes along, to use a
> wrapper unit like this:

Yes and thank you!
 
> I plan to do a NMU fixing this bug via a unit like the above, please
> tell me if you want to address this in some other way.

However, I don't think it is appropriate to do a NMU with such changes.  
Instead you should make a regular upload of the package.  I don't know 
whether you have commit rights in the repository of Debian installer 
(where the sources of console-setup are), or not, but in any case I 
think you can obtain such rights in no time.

Anton Zinoviev

Bug#818497: busybox: CVE-2016-2148: heap overflow in OPTION_6RD parsing

[Salvatore Bonaccorso]

Source: busybox
Version: 1:1.20.0-7
Severity: normal
Tags: security upstream fixed-upstream

Hi,

the following vulnerability was published for busybox, filling for
tracking purpose.

CVE-2016-2148[0]:
heap overflow in OPTION_6RD parsing

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-2148

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#818481: installation-reports: Xen PV drivers not present in 32-bit installer kernel (but present in installed kernel)

[Ian Campbell]

On Fri, 2016-03-18 at 06:50 +, John Dilley wrote:
> Correct, I'm running the installer as a PVHVM domain (this is how
> XenServer supports Jessie onwards).
> 
> I tried running the xen netboot image, but although it booted it then
> complained about a display issue, and didn't seem to bring up the
> disk, so it doesn't look like that is PVHVM compatible.

IMHO it should be, so whatever the display issue is is most likely a
bug somewhere which should be addressed.

> Would be good if the Xen drivers could be included in the 686 kernel,
> or if there was a Xen PVHVM compatible installer we could use
> (although a separate kernel may cause complications for CD installs).

IIRC the Xen PVHVM drivers in Linux are tied closely enough to the Xen
PV drivers that they cannot currently be enabled without PAE. Fixing
that would be one for the upstream Xen team I'm afraid, since I think
it will be non-trivial.

Ian.

Bug#818611: netcfg: Misleading error message when parsing line with trailing blank

[Hendrik Brueckner]

Package: netcfg
Version: 1.137
Severity: normal
Tags: d-i

Dear maintainer(s),

when specifying IP addresses with leading or trailing blanks, netcfg does not
correctly identify the IP address and fails.  For example,

Configure a network using static addressing  
---  
  
The IP address is unique to your computer and may be:  
  
 * four numbers separated by periods (IPv4);  
 * blocks of hexadecimal characters separated by colons (IPv6).  
  
You can also optionally append a CIDR netmask (such as "/24").  
  
If you don't know what to use here, consult your network administrator. 
 
IP address:  
Prompt: '?' for help> 9.152.162.103
9.152.162.103 
  
!! ERROR: Malformed IP address  
  
The IP address you provided is malformed. It should be in the form 
x.x.x.x   
where each 'x' is no larger than 255 (an IPv4 address), or a sequence 
of blocks 
 
of hexadecimal digits separated by colons (an IPv6 address). Please try 
again.  
Press enter to continue

This can easily happen, especially, when entering IP addresses within
command line console, such as the z/VM console on z Systems (s390x).

The expected behavior is that leading and trailing blanks should be ignored.
Note that the root cause of the error condition above is triggered by a
failing inet_pton() call which does not expect blanks for an IP address
string.

To correct this behavior, I have attached two patches for discussion:

The first patch removes trailing blanks for the case above. Note that there
is already an rtrim() function that has been reused.  Also an additional
function, strtrim(), is introduced to remove any leading blanks.
The "make test" has been enhanced to verify this behavior.

The second patch removes leading and trailing blanks on IP addresses entered
for other network configurations, for example, point-to-point.

Feedback is welcome.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen
>From 944acf2a089e5eb60a76c58d896f8c3713aad0a4 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Fri, 5 Feb 2016 16:32:42 +0100
Subject: [PATCH 1/2] common/ipaddr: remove leading and trailing whitespaces

Leading or trailing whitespaces are not removed from the IP address,
for example, when specified by the user.  If the IP address contains
whitespaces, parsing the address fails and a malformed address is
reported even if the IP address would be valid.

To remove trailing whitespaces, extend the rtrim() function to remove
multiple spaces.  Introduce a new function, strtrim() to remove any
leading spaces.

Also add a test case to verify the changed behavior.

Signed-off-by: Hendrik Brueckner 
---
 netcfg-common.c   | 24 +---
 netcfg.h  |  1 +
 test/test_netcfg_parse_cidr_address.c | 26 ++
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/netcfg-common.c b/netcfg-common.c
index 376e6ca..c6d1d8d 100644
--- a/netcfg-common.c
+++ b/netcfg-common.c
@@ -1577,10 +1577,11 @@ int netcfg_parse_cidr_address(const char *address, 
struct netcfg_interface *inte
 struct in_addr addr;
 struct in6_addr addr6;
 int ok;
-char *maskptr, addrstr[NETCFG_ADDRSTRLEN];
+char *maskptr, *addrstr, addrbuf[NETCFG_ADDRSTRLEN];
 int i;
 
-strncpy(addrstr, address, NETCFG_ADDRSTRLEN);
+strncpy(addrbuf, address, NETCFG_ADDRSTRLEN);
+addrstr = strtrim(addrbuf);
 
 if ((maskptr = strchr(addrstr, '/'))) {
 /* Houston, we have a netmask; split it into bits */
@@ -1730,7 +1731,24 @@ void rtrim(char *s)

n = strlen(s) - 1;

-   while (isspace(s[n])) {
+   while (n >= 0 && isspace(s[n])) {
s[n] = '\0';
+   n--;
}
 }
+
+char *strtrim(char *s)
+{
+   size_t len;
+
+   len = strlen(s);
+   if (!len)
+   return s;
+
+   rtrim(s);
+
+   while (*s && isspace(*s))
+   s++;
+
+   return s;
+}
diff --git a/netcfg.h b/netcfg.h
index 771fed3..00a2cea 100644
--- a/netcfg.h
+++ b/netcfg.h
@@ -249,6 +249,7 @@ extern void preseed_hostname_from_fqdn(struct debconfclient 
*client, char *fqdn)
 extern int netcfg_dhcp(struct debconfclient *client, struct netcfg_interface 
*interface);
 
 extern void rtrim(char *);
+extern char *strtrim(char *s);
 
 /* ipv6.c */
 extern void nc_v6_wait_for_complete_configuration(const struct 
netcfg_interface *interface);
diff --git a/test/test_netcfg_parse_cidr_address.c 
b/test/test_netcfg_parse_cidr_address.c
index 8f0f919..2b1cdca 100644
--- 

Re: Bad release in install documentation

[Laura Arjona Reina]

Hi everybody

El 15/03/16 a las 23:58, Laura Arjona Reina escribió:
[...]

> 
> I've tried to (manually) run the build of the installation manual for
> jessie, and I think it went ok.
> This is what I did, based on the lessoften script [1]:
> 
> ls -t1 /srv/www.debian.org/cron/ftpfiles/pool/installation-guide_*.dsc
> | head -1
> 
> sudo -u debwww dpkg-source -sn -x
> /srv/www.debian.org/cron/ftpfiles/pool/installation-guide_20150423+deb8u
> 2.dsc
> 
> cd installation-guide-20150423+deb8u2/build && sudo -u debwww
> manual_release=jessie
> destination=/srv/www.debian.org/installmanual/jessie/ ./buildweb.sh >
> /srv/www.debian.org/installmanual/jessie.log 2>&1
> 
> sudo -u debwww cp -a /srv/www.debian.org/installmanual/jessie/*
> /srv/www.debian.org/www/releases/jessie/
> 
> Let's see what happens in the next lessoften build. I think stretch
> manual is not built yet, but maybe it's build after this is fixed. If
> tomorrow after lessoften I see the jessie manual fixed, and the
> stretch manual not appearing, I would try to build it manually too.
> 
> [1]
> https://anonscm.debian.org/cgit/debwww/cron.git/tree/lessoften-parts/1in
> stallation-guide
> 

Ok, it seems the jessie installation guide is published correctly and
it's not overwritten with lessoften script.

I don't know if there should be a stretch installation guide right now,
or only after stretch is published as stable.
The page https://www.debian.org/releases/stretch/ seems it has no link
to the installation guide.
The page https://www.debian.org/devel/debian-installer/ links to the
stable version of the manual, and to d-i.debian.org/manual

So I guess this problem is fixed, and everything is ok? (until the next
release?). Or do I need to manually generate the stretch version of the
installmanual, as I did with jessie?

Cheers

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

Re: Archive changes

[Colin Watson]

On Wed, Mar 16, 2016 at 12:54:03AM +0100, Cyril Brulebois wrote:
> Pretty sure this breaks (will break, when the change is propagated outside
> experimental) d-i as it stands, due to the check on all 3 checksums in
> net-retriever.

Looking at the code, I don't think that's true.  It skips checksums that
are missing from Release, and it stops after the first checksum that it
successfully finds.  Unless I'm looking at the wrong bit of
net-retriever?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#818481: installation-reports: Xen PV drivers not present in 32-bit installer kernel (but present in installed kernel)

[John Dilley]

Package: installation-reports
Severity: important

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: network
Image version: 
http://ftp.uk.debian.org/debian/dists/stretch/main/installer-i386/20160106/images/netboot/debian-installer/i386/
Date: 

Machine: XenServer 6.5 Virtual Machine
Partitions: 


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

Initial boot:   [O]
Detect network card:[E]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [E]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

When installing i386 Debian testing, the disks and network interfaces enumerate 
differently in the installer and the installed system (this does not apply to 
amd64)

This causes the following noticable issues:
1) The system doesn't boot, as the grub config is populated with "sda" rather 
than "xvda"
2) The network doesn't come up by default after boot, as 
/etc/network/interfaces refers to "ens4" rather than "eth0"

This appears to be because the installer kernel/initrd lacks the Xen kernel 
modules.

In the installer:

~# find /lib/modules/ -name *xen*
/lib/modules/4.3.0-1-686/kernel/drivers/net/ethernet/qlogic/netxen
/lib/modules/4.3.0-1-686/kernel/drivers/net/ethernet/qlogic/netxen/netxen_nic.ko

In the installed sytem:

~# find /lib/modules/4.3.0-1-686-pae/kernel/ -name *xen*
/lib/modules/4.3.0-1-686-pae/kernel/drivers/pci/xen-pcifront.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/scsi/xen-scsifront.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/char/tpm/xen-tpmfront.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/block/xen-blkback
/lib/modules/4.3.0-1-686-pae/kernel/drivers/block/xen-blkback/xen-blkback.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/block/xen-blkfront.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/net/xen-netback
/lib/modules/4.3.0-1-686-pae/kernel/drivers/net/xen-netback/xen-netback.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/net/ethernet/qlogic/netxen
/lib/modules/4.3.0-1-686-pae/kernel/drivers/net/ethernet/qlogic/netxen/netxen_nic.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/net/xen-netfront.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-gntalloc.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-pciback
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-pciback/xen-pciback.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-acpi-processor.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-evtchn.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-gntdev.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xenfs
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xenfs/xenfs.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-privcmd.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/xen/xen-scsiback.ko
/lib/modules/4.3.0-1-686-pae/kernel/drivers/watchdog/xen_wdt.ko

-- 

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="9 (stretch) - installer build 20160106"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux debian 4.3.0-1-686 #1 SMP Debian 4.3.3-5 (2016-01-04) i686 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC 
[Natoma] [8086:1237] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA 
[Natoma/Triton II] [8086:7000]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II] [8086:7010]
lspci -knn: Subsystem: XenSource, Inc. Device [5853:0001]
lspci -knn: Kernel driver in use: ata_piix
lspci -knn: Kernel modules: ata_piix, ata_generic
lspci -knn: 00:01.2 USB controller [0c03]: Intel Corporation 82371SB PIIX3 USB 
[Natoma/Triton II] [8086:7020] (rev 01)
lspci -knn: Subsystem: XenSource, Inc. Device [5853:0001]
lspci -knn: 

Bug#818591: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Control: tags -1 + patch
>From 18604958d335666c4154c1e500dc424aff0c5998 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Fri, 18 Mar 2016 12:05:01 +0100
Subject: [PATCH] control: split and improve dependency handling for disk
 detection

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also related Debian Bugs for:
  disk-detect: #818586
  s390-zfcp: #818592

Signed-off-by: Hendrik Brueckner 
---
 debian/changelog | 8 
 debian/control   | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 69a0aa2..c83ad59 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+s390-dasd (0.0.36) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Split and improve dependency handling for disk detection and
+move the module before the disk-detect d-i module (Closes: #818591)
+
+ -- Hendrik Brueckner   Fri, 18 Mar 2016 
11:59:33 +0100
+
 s390-dasd (0.0.35) unstable; urgency=low
 
   * Team upload
diff --git a/debian/control b/debian/control
index f036662..e4c75fb 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Package: s390-dasd
 Package-Type: udeb
 Architecture: s390 s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}, dasd-modules, 
s390-sysconfig-writer, s390-tools-udeb
-Provides: harddrive-detection
-XB-Installer-Menu-Item: 3700
+Provides: harddrive-detection-dasd
+XB-Installer-Menu-Item: 3400
 Description: Configure DASD
  Configure DASD, s390 specific harddisks. 
-- 
2.7.0

Bug#818457: marked as done (installation-reports: successfull installation on HP ProLiant Microserver N36L)

[Debian Bug Tracking System]

Your message dated Thu, 17 Mar 2016 09:53:56 -0700
with message-id <20160317165356.ga25...@jirafa.cyrius.com>
and subject line Re: Bug#818457: installation-reports: successfull installation 
on HP ProLiant Microserver N36L
has caused the Debian Bug report #818457,
regarding installation-reports: successfull installation on HP ProLiant 
Microserver N36L
to be marked as done.

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

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


-- 
818457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818457
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: installation-reports
Severity: wishlist

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: USB media
Image version: Debian 8 Jessie netinst 8.0 amd64
Date: 

Machine: HP ProLiant Microserver N36L
Partitions: 


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:  [ ]
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:




-- 

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 20150422"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux n36l 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
RS880 Host Bridge [1022:9601]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: 00:01.0 PCI bridge [0604]: Hewlett-Packard Company Device 
[103c:9602]
lspci -knn: 00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 
PCI to PCI bridge (PCIE port 2) [1022:9606]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:11.0 RAID bus controller [0104]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [Non-RAID5 mode] [1002:4392] (rev 
40)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ahci
lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 
SMBus Controller [1002:4385] (rev 42)
lspci -knn: 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1609]
lspci -knn: 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] 
SBx00 PCI to PCI Bridge [1002:4384] (rev 40)
lspci -knn: 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. 
[AMD/ATI] 

Processed: Re: Bug#818611: netcfg: Misleading error message when parsing line with trailing blank

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #818611 [netcfg] netcfg: Misleading error message when parsing line with 
trailing blank
Added tag(s) patch.

-- 
818611: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818611
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems