Processed: closing 765757

2015-05-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 close 765757 49
Bug #765757 [live-installer] live-installer: Installation fails when using a 
non-en locale when trying to mount /proc
Marked as fixed in versions live-installer/49.
Bug #765757 [live-installer] live-installer: Installation fails when using a 
non-en locale when trying to mount /proc
Marked Bug as done
 thanks
Stopping processing here.

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


--
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/handler.s.c.143272307525740.transcr...@bugs.debian.org



Solving os-prober related problems by adding it to the desktop task during installation

2015-05-27 Thread Emmanuel Kasper
Hello
I have noticed during fresh debian installs the package os-prober is
automatically installed when you select grub as a bootloader, as a
'Recommends' of grub-common.
Unfortunately the way os-prober detects other OSes on local media, might
prove cumbersome or even dangerous if you use do virtualization.
For instance if using partitions to store Xen DomU, os prober will
create a grub entry for each of your VM in the grub menu list.

There is also this bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701814
where iscsi-exported block devices would get corrupted by os-prober.


To get around this problems, I was wondering if it would a good idea to
downgrad the os-prober 'Recommends' to 'Suggests', and add os-prober as
a package in the desktop Taskel. I have yet to see a dualboot server
install, but on a workstation os-prober makes sense.

The problem that I see with this reasoning, is that it assumes a debian
text-only installation does not require dual boot.

Comments ?

Emmanuel



-- 
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/55658b26.5090...@proxmox.com



[preseed] multiple disks, rules to select the smallest one

2015-05-27 Thread Sandro Tosi
Hello,
in case a machine has just one disk, we can skip the

d-i partman-auto/disk string device

line and the d-i will do the right thing.

Sometimes we also have machines with multiple drives, consider the now
usual case of a fast SSD for the OS and a slower/larger spinning drive
for data.

In order to avoid writing a custom preseed file all the times, we're
wondering if there is already a policy that would instruct d-i to use
the smallest physical drive on the system as the one to partition and
use for installation or alternatively how we should write our
preseed.cfg to obtain that (eventually with some early_command?).

Thanks in advance for your help,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/CAB4XWXzoWecBuXXs1-KX+stO=pqrkqqkgx1pmzjucj9w2s3...@mail.gmail.com



Bug#785149: grub-installer: NVMe boot drives not supported

2015-05-27 Thread Steve Rowe
I just realized that an out-of-band email thread I had with Cyril didn’t make 
it to this issue - here’s the final email to me from Cyril:

-
Steve Rowe sar...@gmail.com (2015-05-12):
 
 On May 12, 2015, at 4:49 PM, Cyril Brulebois k...@debian.org wrote:
 --- grub-installer-1.117/grub-installer 2015-01-12 23:01:14.0 
 -0500
 +++ grub-installer-1.117/grub-installer.fixed   2015-05-12 
 15:13:49.002358498 -0400
 @@ -134,7 +134,7 @@
 # This should probably be rewritten using udevadm or similar.
 device_to_disk () {
 echo $1 | \
 -   sed 
 's:\(/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|ada\|da\)[0-9]\+\|/dev/[hs]d[0-9]\+\|/dev/[a-z]\+\).*:\1:'
 +   sed 
 's:\(/dev/nvme[0-9]n[0-9]\|/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|ada\|da\)[0-9]\+\|/dev/[hs]d[0-9]\+\|/dev/[a-z]\+\).*:\1:'
 
 I moved the addition to the end, which makes visual inspection slightly
 easier.
 
 There’s a problem with this: the preceding pattern /dev/[a-z]\+ will match 
 /dev/nvme.*”, so the nvme pattern will never be reached. 

Good catch, pushed this extra commit accordingly:
 https://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?id=22a8aef

 # Run update-grub in $ROOT
 @@ -252,7 +252,7 @@
/dev/mapper)
 disc_offered_devfs=$bootfs
 ;;
 -
 /dev/[hsv]d[a-z0-9]|/dev/xvd[a-z]|/dev/cciss/c[0-9]d[0-9]*|/dev/ida/c[0-9]d[0-9]*|/dev/rs/c[0-9]d[0-9]*|/dev/mmcblk[0-9]|/dev/ad[0-9]*|/dev/da[0-9]*)
 +
 /dev/nvme[0-9]n[0-9]|/dev/[hsv]d[a-z0-9]|/dev/xvd[a-z]|/dev/cciss/c[0-9]d[0-9]*|/dev/ida/c[0-9]d[0-9]*|/dev/rs/c[0-9]d[0-9]*|/dev/mmcblk[0-9]|/dev/ad[0-9]*|/dev/da[0-9]*)
 
 Same story here.
 
 Looks like there is no general pattern that will match “/dev/nvme.*”
 above, so putting it at the end isn’t a problem.

Adjusted for consistency.

Thanks again!

Mraw,
KiBi.
-

--
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/7e89c0a2-8ed2-4aa2-849c-a12504445...@gmail.com



Bug#782574: installation-reports: d-i does not boot on beaglebone black

2015-05-27 Thread Vagrant Cascadian
On 2015-04-15, Cyril Brulebois wrote:
 Karsten Merker mer...@debian.org (2015-04-15):
 On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote:
  I've tested that it boots the armhf daily hd-media installer and
  boots an installed system. I could upload a new version of u-boot if
  it's deemed worth it; otherwise we'll just need more complicated
  instructions for manually loading the installer on d-i. FWIW, The
  netboot media via tftp works without any changes.
...
 As the deadline for d-i-relevant changes is Friday, the question
 is what to do now.  AFAICS due to the necessity to change the BBB
 boot script in flash-kernel when the patch is applied to u-boot,
 both flash-kernel and u-boot would have to enter Jessie in
 lockstep.  As there is not enough time for regular migration to
 Jessie, the release team would have to urgent both packages in
 addition to an unblock to keep the deadline.  The involved DDs
 are in vastly different timezones, which makes all this even more
 problematic.  As stated above, I probably won't be able to take
 care of flash-kernel in time, so unless Ian would like to handle
 that, I do not see a a realistic chance to get this solved for
 Jessie.
...
 So I've been thinking about this for a while and I'm not too happy about
 possibly rushing these changes at this point. What could be considered
 instead is having these changes staged into unstable, let them migrate
 to testing/stretch when the freeze is lifted, and possibly backport them
 in to the jessie first point release. A workaround can be documented in
 the D-I Jessie RC3 errata.

Seems like we've missed the chance to resolve this for Jessie's first
point release, but perhaps we can make it for the second point release?

I don't see anything mentioned in the errata yet:

  https://www.debian.org/releases/stable/debian-installer/#errata

Not sure what the process is to update that, but I'd be happy to work on
some text for it.


Flash-kernel in unstable has the needed changes and u-boot in unstable
has the needed changes, although I think it would be better to go with
the smaller patch I had proposed earlier rather than backporting the
entire distro_bootcmd stack...


Now that USB support is working on the BBB with the kernel in
jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive
platform for running Debian on, so it would be nice to get d-i support
working out of the box...


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#782574: installation-reports: d-i does not boot on beaglebone black

2015-05-27 Thread Lennart Sorensen
On Wed, May 27, 2015 at 11:36:09AM -0700, Vagrant Cascadian wrote:
 Seems like we've missed the chance to resolve this for Jessie's first
 point release, but perhaps we can make it for the second point release?
 
 I don't see anything mentioned in the errata yet:
 
   https://www.debian.org/releases/stable/debian-installer/#errata
 
 Not sure what the process is to update that, but I'd be happy to work on
 some text for it.
 
 
 Flash-kernel in unstable has the needed changes and u-boot in unstable
 has the needed changes, although I think it would be better to go with
 the smaller patch I had proposed earlier rather than backporting the
 entire distro_bootcmd stack...
 
 
 Now that USB support is working on the BBB with the kernel in
 jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive
 platform for running Debian on, so it would be nice to get d-i support
 working out of the box...

Yay.

I am curious though:  With the am3359-evmsk board I see no network traffic
with gigabit link and the 3.16 (or 4.0) kernel, but I do see traffic at
100Mbit link speed.  Does anyone with a beaglebone see the same behaviour?
Using the TI sdk kernel does work at gigabit speed, so the hardware
seems fine.

-- 
Len Sorensen


-- 
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/20150527202005.gg6...@csclub.uwaterloo.ca



Re: [preseed] multiple disks, rules to select the smallest one

2015-05-27 Thread Hendrik Boom
On Wed, May 27, 2015 at 12:11:26PM -0400, Sandro Tosi wrote:
...
 In order to avoid writing a custom preseed file all the times, we're
 wondering if there is already a policy that would instruct d-i to use
 the smallest physical drive on the system as the one to partition and
 use for installation or alternatively how we should write our
 preseed.cfg to obtain that (eventually with some early_command?).

the smallest drive?  Like, for example, the floopy disk?

-- hendrik


-- 
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/20150527164717.gd18...@topoi.pooq.com



Bug#782574: installation-reports: d-i does not boot on beaglebone black

2015-05-27 Thread Vagrant Cascadian
On 2015-05-27, François-Régis wrote:
 Le 27/05/2015 20:36, Vagrant Cascadian a écrit :
 On 2015-04-15, Cyril Brulebois wrote:
 Karsten Merker mer...@debian.org (2015-04-15):
 On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote:
 So I've been thinking about this for a while and I'm not too happy about
 possibly rushing these changes at this point. What could be considered
 instead is having these changes staged into unstable, let them migrate
 to testing/stretch when the freeze is lifted, and possibly backport them
 in to the jessie first point release. A workaround can be documented in
 the D-I Jessie RC3 errata.
 
 Seems like we've missed the chance to resolve this for Jessie's first
 point release, but perhaps we can make it for the second point release?
 
 I don't see anything mentioned in the errata yet:
 
   https://www.debian.org/releases/stable/debian-installer/#errata
 
 Not sure what the process is to update that, but I'd be happy to work on
 some text for it.

 I was not very pushy to make this mentioned in the errata giving the
 fact that the most popular way to install debian on BBB is to use
 readymade disk images and not d-i.

If it's hard to install using d-i, it'll stay that way, which sounds
like a bug worth fixing to me :)


 That said I'd like to help on documenting.

Good.


 Flash-kernel in unstable has the needed changes and u-boot in unstable
 has the needed changes, although I think it would be better to go with
 the smaller patch I had proposed earlier rather than backporting the
 entire distro_bootcmd stack...
 
 Now that USB support is working on the BBB with the kernel in
 jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive
 platform for running Debian on, so it would be nice to get d-i support
 working out of the box...

 Definitely yes, with flash-kernel, u-boot and kernel having a good
 coverage of bbb hardware, d-i could be the prefered way to use debian on
 bbb. (Vagrant:could you give me a pointer on the kernel supporting usb ?)

It was fixed in linux 3.16.7-ckt11-1 (as well as the 4.x version
currently in sid):

  https://bugs.debian.org/773400

It's currently available in the jessie-proposed-updates repository, and
I presume will be released with the stable point release coming up
shortly:

  https://wiki.debian.org/StableProposedUpdates


live well,
  vagrant


signature.asc
Description: PGP signature


Re: Request to Join Project debian-installer from Vagrant Cascadian (vagrant)

2015-05-27 Thread Christian PERRIER
Quoting Cyril Brulebois (k...@debian.org):

  So if it makes sense for me to have commit access, great, if not, I'll
  keep submitting patches and bug reports.
 
 I don't think both approaches are exclusive. Feel free to push stuff
 you're comfortable with, and to file bug reports with patches for stuff
 you'd appreciate peer review for.

Just one more notice : there is a kind of autobuilduploader working
on d-i git. In short, packages with pending UNRELEASED changes are
usually uploaded with these changes during the days that follow the
commit.

To be clear, I have a daily script that monitors d-i packages and
notifies me when one has unreleased changes. Then, I build and upload
the said package. The rough idea behind all this is get things tested
ASAP rather than accumulate changes and only upload when a d-i release
is being prepared.

*I do not test nor review such changes*

In case someone does not want somthing to be immediately uploaded,
please send a notice to -boot, which I read on a regular basis.




signature.asc
Description: Digital signature


Bug#787044: libdebian-installer: please make new Build-Depends: check optional via build profiles

2015-05-27 Thread Helmut Grohne
Source: libdebian-installer
Version: 0.100
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

You may be aware that libdebian-installer is considered transitively
build-essential. In practise, this means that it needs to be cross
buildable. The most recent upload of version 0.100 added a new build
dependency on check. The usage of check can already be disabled by
setting DEB_BUILD_OPTIONS=nocheck, which helps with cross building.
However it still requires check to be installed and thus cross built.
This can be avoided by marking the dependency as optional by adding a
!nocheck build profile[1] to it. The nocheck profile is meant to
complement DEB_BUILD_OPTIONS=nocheck on the dependency level.

To avoid confusion here, I note that the nocheck profile is in not
related to the package check specifically.

Thanks for considering

Helmut

[1] https://wiki.debian.org/BuildProfileSpec
diff -Nru libdebian-installer-0.100/debian/changelog 
libdebian-installer-0.100+nmu1/debian/changelog
--- libdebian-installer-0.100/debian/changelog  2015-05-25 08:28:41.0 
+0200
+++ libdebian-installer-0.100+nmu1/debian/changelog 2015-05-28 
06:54:55.0 +0200
@@ -1,3 +1,10 @@
+libdebian-installer (0.100+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Make check Build-Depends optional via nocheck profile (Closes: #-1).
+
+ -- Helmut Grohne hel...@subdivi.de  Thu, 28 May 2015 06:54:36 +0200
+
 libdebian-installer (0.100) unstable; urgency=medium
 
   [ Philipp Kern ]
diff -Nru libdebian-installer-0.100/debian/control 
libdebian-installer-0.100+nmu1/debian/control
--- libdebian-installer-0.100/debian/control2015-05-25 08:11:09.0 
+0200
+++ libdebian-installer-0.100+nmu1/debian/control   2015-05-28 
06:55:02.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Install System Team debian-boot@lists.debian.org
 Uploaders: Bastian Blank wa...@debian.org, Colin Watson 
cjwat...@debian.org, Christian Perrier bubu...@debian.org, Steve McIntyre 
93...@debian.org
-Build-Depends: dpkg-dev (= 1.13.5), debhelper (= 9), dh-autoreconf, doxygen, 
pkg-config, check
+Build-Depends: dpkg-dev (= 1.13.5), debhelper (= 9), dh-autoreconf, doxygen, 
pkg-config, check !nocheck
 Standards-Version: 3.9.6
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/libdebian-installer.git
 Vcs-Git: git://anonscm.debian.org/d-i/libdebian-installer.git


Re: Request to Join Project debian-installer from Vagrant Cascadian (vagrant) Welcome

2015-05-27 Thread Geert Stappers
On Thu, May 28, 2015 at 03:04:08AM +0200, Cyril Brulebois wrote:
 nore...@alioth.debian.org nore...@alioth.debian.org (2015-05-28):
  Vagrant Cascadian (vagrant) has requested to join your project. 
 
 Approved.

Nice!

Welcome Vagrant.

Yes, I know, you were allready with us.



Groeten
Geert Stappers
Who appreciates all contributors of d-i
-- 
Leven en laten leven


signature.asc
Description: Digital signature


Re: Request to Join Project debian-installer from Vagrant Cascadian (vagrant)

2015-05-27 Thread Cyril Brulebois
Heya,

(Taking the liberty of quoting your comments to the list.)

nore...@alioth.debian.org nore...@alioth.debian.org (2015-05-28):
 Vagrant Cascadian (vagrant) has requested to join your project. 

Approved.

 Comments by the user:
 
 I wonder if it wouldn't make sense for me to have commit access to
 flash-kernel and debian-installer to streamline u-boot integration on
 armhf platforms, rather than constantly pestering about bug reports...
 on the other hand, the peer review can be useful...
 
 I'm not sure I'm ready to commit to reading all the debian-boot
 traffic yet...
 
 So if it makes sense for me to have commit access, great, if not, I'll
 keep submitting patches and bug reports.

I don't think both approaches are exclusive. Feel free to push stuff
you're comfortable with, and to file bug reports with patches for stuff
you'd appreciate peer review for.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Bug#782574: installation-reports: d-i does not boot on beaglebone black

2015-05-27 Thread François-Régis
Hi Vagrant, Hi Cyril, Hi all,

Le 27/05/2015 20:36, Vagrant Cascadian a écrit :
 On 2015-04-15, Cyril Brulebois wrote:
 Karsten Merker mer...@debian.org (2015-04-15):
 On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote:
 So I've been thinking about this for a while and I'm not too happy about
 possibly rushing these changes at this point. What could be considered
 instead is having these changes staged into unstable, let them migrate
 to testing/stretch when the freeze is lifted, and possibly backport them
 in to the jessie first point release. A workaround can be documented in
 the D-I Jessie RC3 errata.
 
 Seems like we've missed the chance to resolve this for Jessie's first
 point release, but perhaps we can make it for the second point release?
 
 I don't see anything mentioned in the errata yet:
 
   https://www.debian.org/releases/stable/debian-installer/#errata
 
 Not sure what the process is to update that, but I'd be happy to work on
 some text for it.

I was not very pushy to make this mentioned in the errata giving the
fact that the most popular way to install debian on BBB is to use
readymade disk images and not d-i. That said I'd like to help on
documenting.

 Flash-kernel in unstable has the needed changes and u-boot in unstable
 has the needed changes, although I think it would be better to go with
 the smaller patch I had proposed earlier rather than backporting the
 entire distro_bootcmd stack...
 
 Now that USB support is working on the BBB with the kernel in
 jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive
 platform for running Debian on, so it would be nice to get d-i support
 working out of the box...

Definitely yes, with flash-kernel, u-boot and kernel having a good
coverage of bbb hardware, d-i could be the prefered way to use debian on
bbb. (Vagrant:could you give me a pointer on the kernel supporting usb ?)


-- 
François-Régis



signature.asc
Description: OpenPGP digital signature


Bug#782574: installation-reports: d-i does not boot on beaglebone black

2015-05-27 Thread François-Régis
Le 27/05/2015 22:20, Lennart Sorensen a écrit :
 On Wed, May 27, 2015 at 11:36:09AM -0700, Vagrant Cascadian wrote:

 I am curious though:  With the am3359-evmsk board I see no network traffic
 with gigabit link and the 3.16 (or 4.0) kernel, but I do see traffic at
 100Mbit link speed.  Does anyone with a beaglebone see the same behaviour?
 Using the TI sdk kernel does work at gigabit speed, so the hardware
 seems fine.
 

AFAIK beaglebone black has only 10/100 ethernet link [1] so it's hard to
watch the same  behaviour.

[1]
http://elinux.org/Beagleboard:BeagleBoneBlack#BeagleBone_Black_Features

-- 
François-Régis


-- 
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/55665190.6070...@miradou.com