Re: Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)

[Julien Cristau]

Control: reassign -1 grub-installer 1.117
Control: severity -1 important
Control: retitle -1 grub-installer: too much hardcoding of device names, fails 
with /dev/nvme*

On Wed, Nov 25, 2015 at 00:06:57 +0100, Julien Cristau wrote:

> Installation went fine (well, had to stay close to the screen because
> the text was quite small on this high-dpi display) until the
> grub-installer step.  Which failed horribly, I think because the
> /dev/nvme0n1 device name for the drive isn't expected.  See attached
> excerpt from syslog (contains a few invocations of grub-installer while
> I was trying to understand what was going on; the last one has
> DEBCONF_DEBUG and set -x enabled.
> 
Reassigning.

Cheers,
Julien


signature.asc
Description: PGP signature

Re: Which pseudo-package do ARM netboot image slices belong to?

[Jonas Smedegaard]

Quoting Karsten Merker (2015-11-12 21:10:42)
> On Wed, Nov 11, 2015 at 05:07:45PM +0100, Cyril Brulebois wrote:
> > Jonas Smedegaard  (2015-11-10):
> > > I've hit a bug¹ in a non-package part of Debian, identified that it is 
> > > tied to variations not in package releases but web-facing parts of 
> > > official Debian:
> > > http://ftp.de.debian.org/debian/dists/stretch/main/installer-armhf/$timestamp/images/netboot/SD-card-images/
> > > 
> > > I filed a bugreport against the pseudo-package seeming most appropriate, 
> > > but then got no (maintainer) response for a week.  That delay might be 
> > > perfectly fine (I often have far worse reaction time myself), but made 
> > > me wonder: Did I file it wrongly, so that the bug isn't "heard"?
> > > 
> > >   Which pseudo-package do ARM netboot image slices belong to?
> > > 
> > > or more generally:
> > > 
> > >   Is there some way of verifying which pseudo-package(s) is(/are)
> > >   appropriate for targeting a bugreport, when web address is known?
> > > 
> > > For real packages where I have located a file involved, I can verify if 
> > > a proper package is targeted by use of "dpkg -L ..." or "apt-file search 
> > > ..." or similar tools.  Do we have similar ways to check (preferrably 
> > > without needing login to specific Debian hosts) which pseudo-package 
> > > some official area of Debian web services belong to?  E.g. a public list 
> > > of which team has write access to which parts of our web-facing 
> > > services?
> > > 
> > > I am aware of https://www.debian.org/Bugs/pseudo-packages but that's 
> > > comparable to grep'ing package descriptions to pinpoint where a bug 
> > > belongs, nowhere as accurate a verification as "dpkg -L ..." or 
> > > "apt-file search ...".
> > 
> > Karsten, Ian, and other arm people,
> > 
> > This makes me wonder whether those sd card images should be packaged and
> > shipped somehow (through d-i-n-i or elsewhere), instead of just being
> > published through the installer-* directories.
> > 
> > What's your take on this?
> 
> Hello,
> 
> personally I don't think that packaging the images would bring us
> an advantage that is worth the costs.
> 
> Adding them to debian-installer-netboot-images would IMHO not
> really fit - d-i-n-i provides files for serving over the network
> ("real" netboot stuff, i.e. TFTP/PXE boot), while the SD-card
> images are the ARM equivalent of the i386/amd64 mini.iso, which
> we also don't package in d-i-n-i.  Besides that, finding the
> proper package to report bugs against via "dpkg -L" or "apt-file
> search" also doesn't work with the binary packages generated by
> d-i-n-i, because their actual content - against which one would
> want to file a bug - is not built by d-i-n-i but by
> src:debian-installer.  This could of course be changed by
> integrating d-i-n-i into the d-i build system and making the
> packages children of d-i, but from my personal point of view I
> don't see much need for that.

I agree that easy locating how to file bug is not a big benefit: That 
can be addressed by adding contact info at the bottom of the web page 
serving the images.

A real benefit of shipping SD card images as binary packages would be 
ease of trusted bootstrapping:

Imagine Bob, a cautious but non-geekie person.  He hires an expert to 
carefully inspect his laptop to ensure that it is really truly running 
only Debian, no other code is installed.  He then wants to install 
Debian on another host.  He would then need to hire an expert yet again, 
because he cannot - easily and secured by APT - get install media for 
another machine, but needs to use different more technical trust paths 
of manually downloading and verifying stuff from the big bad internet.

If d-i images was available as binary packages, then FreedomBox could 
offer an install service for custom-configured laptop setups, 
dynamically injecting preseeding file into a trusted installer image.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#805321: [Reproducible-builds] Bug#805321: Bug#805321: debian-installer: builds unreproducible netboot images

[Mattia Rizzolo]

On Sat, Nov 28, 2015 at 12:08:44AM +, Steven Chamberlain wrote:
> > FWIW, I'm not exactly entirely convinced by the exporting of the
> > SOURCE_DATE_EPOCH variable from debian/rules; all other variables have
> > been passed without exporting so I'm wondering if we shouldn't adapt
> > this to behave like other variables, reducing possible surprise for
> > users.
> 
> Just to explain that -- if it's defined in the environment, it requires
> no special handling and doesn't need to be (re-)exported.  I think this
> is maybe the case now for dpkg-buildpackage in sid?

it's not, dpkg hasn't merged that patch (tbh I'm not even sure we
forwarded that). Though debhelper exports SOURCE_DATE_EPOCH when using
the dh sequencer.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Integrate fully partman-reiser4 into d-i

[Jose R R]

Niltze, everyone!

On Mon, Nov 16, 2015 at 7:37 AM, Jose R R  wrote:
> I hacked (literally) a preliminary version of the of GNU Parted 3.2
> source with Reiser4 support.
>
> On Thu, Nov 12, 2015 at 8:23 AM, Edward Shishkin
>  wrote:
>>
>>
>> On 11/12/2015 12:28 PM, Jose R R wrote:
>>>
>>> On Mon, Sep 21, 2015 at 7:49 AM, Edward Shishkin
>>>  wrote:

 On 09/21/2015 01:12 PM, Colin Watson wrote:
>
> On Sun, Sep 20, 2015 at 07:40:37AM -0700, Jose R R wrote:
>>
>> I have realized that although partman-reiser4 udeb enables Reiser4 to
>> be listed as an option during the Debian-Installer routine of a
>> netboot ISO image, the lack of support for reiser4 in GNU Parted
>> (Debian's libparted) prevents installation from the GUI interface.
>
> It should be pretty easy to add that to parted, since nowadays the only
> filesystem support it has is probing support.  I suggest preparing a
> patch against git://git.sv.gnu.org/parted.git master that adds the
> ability to detect existing reiser4 partitions and sending it upstream;
> it should only be on the order of a hundred lines.



 Does anybody care to prepare the patch?
>>>
>>> I am working on it Ed. I have been ironing out some wrinkles from the
>>> last Reiser4 patch proposed several years ago in the GNU Parted
>>> mailing lists. It's components and structure were basically cloned by
>>> the initial btrfs patch submitted to Debian. autoreconf has been my
>>> friend ;-)
>>>
 I think we just need to a read a sector at REISER4_MAGIC_OFFSET
 and check the magic string ("ReIsEr4"), see definition of the struct
 reiser4_master_sb.
>>>
>>> Please enlighten me with reference to its documentation -- online or
>>> in the Reiser4 source code?
>>
>>
>> Alas, only source code..
>>
>> In reiser4 kernel sources look for REISER4_MAGIC_OFFSET
>> and REISER4_SUPER_MAGIC_STRING.
>>
>> In reiser4progs it is called REISER4_MASTER_OFFSET and
>> REISER4_MASTER_MAGIC respectively.
>>
>
> It can be built with the usual:
>
> apt-get install libdevmapper-dev
>
> ./configure [ --prefix=/opt/parted-3.2/usr/local ]
> make
> make install
>
> The resulting parted binary recognizes Reiser4 partitions when invoked
> at your shell:
> $ parted
> GNU Parted 3.2
> Using /dev/xda
> Welcome to GNU Parted! Type 'help' to view a list of commands.
> (parted) print
> And it will print recognized partitions -- including reiser4, of course.
>
> Although it was developed and tested in a local machine,
> I ran PoC build on small Google Compute Engine (GCE) Cloud instance
> with a couple of existing Reiser4 partitions:
>
> Snapshot:
> https://pbs.twimg.com/media/CT8U78zUwAE-ZTc.png:large
>
> Here is GNU Parted 3.2 bz2-compressed src modified for Reiser4 (in
> case I no longer have time to improve it ;-)
> Source: 2.6M reiser4-parted-3.2m.tar.bz2 @
> http://metztli.it/readOnlyEphemeral/reiser4-parted-3.2m.tar.bz2
> SHA256SUM:
> http://metztli.it/readOnlyEphemeral/reiser4-parted-3.2m.tar.bz2.SHA256SUM
>
>

Just to thank all of you for your insightful input on my quest to
create a Debian-Installer (d-i) network ISO image --hacked to natively
partition, format, and install in/to Reiser4 regular and/or
flash-based media.

As mentioned before, I hacked GNU Parted 3.2 to provide Reiser4
*string probe* support only. Subsequently generated appropriate UDEBs:

libparted2-udeb_3.2-10_amd64.udeb
parted-udeb_3.2-10_amd64.udeb
libparted-fs-resize0-udeb_3.2-10_amd64.udeb

By including the above in d-i, I would not get the weird gibberish
when selecting to format root (/) partition in Reiser4 during expert
installation. Notwithstanding, I encountered subsequent error and
thus...

I modified partman-reiser4-1, (yes again) last evening -- since I was
getting something similar to: "debian-installer: Installation freezes
with "The attempt to mount a files system with type ext4 in SCSI1 (0,
0, 0), partition #1 (sda) at / failed." <
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779922 > but, of
course, with reiser4 instead of ext4. Afterwards, I generated another
partman-reiser4_1_all.udeb

At this very moment the native Reiser4 installation is proceeding in a
VirtualBox instance. I did not have to do any unusual hacks to make
the Reiser4-based installation to proceed. Hence my quest seems over
-- as I attained my objective:

Here is an initial splash screenshot of the custom d-i installer:

< https://pbs.twimg.com/media/CU5exc0UcAAZmd4.png:large >

Needless to say, this is only a working instance and I will respect
the Debian logo by removing it from the image-generating template.

And here is the /etc/fstab that was created by the installer at the
/target/etc/fstab ephemeral installation location:

< https://pbs.twimg.com/media/CU5euw6VEAA8ZGz.png:large >

d-i partman component recognized and honored Reiser4! :D

This native Reiser4 Debian-Installer simplifies my 

Bug#804351: installation-reports: Stretch installer-armel (2015-10-23) does not see storage devices on Dreamplug

[Ian Campbell]

On Thu, 2015-11-12 at 06:50 -0500, James Valleroy wrote:

Hi James,

I think this should be fixed in the latest dailies from
http://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/marvell/
or at least my dreamplug is OK in recovery mode with the one from 2 days ago.

This will then propagate to Stretch with the next d-i alpha/beta.

Ian

Processed: Re: Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 grub-installer 1.117
Bug #806164 [installation-reports] installation-reports: jessie install on dell 
xps 13 9350 (grub-installer issues)
Bug reassigned from package 'installation-reports' to 'grub-installer'.
Ignoring request to alter found versions of bug #806164 to the same values 
previously set
Ignoring request to alter fixed versions of bug #806164 to the same values 
previously set
Bug #806164 [grub-installer] installation-reports: jessie install on dell xps 
13 9350 (grub-installer issues)
Marked as found in versions grub-installer/1.117.
> severity -1 important
Bug #806164 [grub-installer] installation-reports: jessie install on dell xps 
13 9350 (grub-installer issues)
Severity set to 'important' from 'normal'
> retitle -1 grub-installer: too much hardcoding of device names, fails with 
> /dev/nvme*
Bug #806164 [grub-installer] installation-reports: jessie install on dell xps 
13 9350 (grub-installer issues)
Changed Bug title to 'grub-installer: too much hardcoding of device names, 
fails with /dev/nvme*' from 'installation-reports: jessie install on dell xps 
13 9350 (grub-installer issues)'

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

Processed: reassign 806332 to task-french-kde-desktop, reassign 806457 to installation-reports

[Debian Bug Tracking System]

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

> reassign 806332 task-french-kde-desktop
Bug #806332 [] Bug: task-french-kde-desktop
Warning: Unknown package ''
Bug reassigned from package '' to 
'task-french-kde-desktop'.
No longer marked as found in versions last.
Ignoring request to alter fixed versions of bug #806332 to the same values 
previously set
> reassign 806457 installation-reports
Bug #806457 [jessie] Jessie Installation Error
Warning: Unknown package 'jessie'
Bug reassigned from package 'jessie' to 'installation-reports'.
No longer marked as found in versions 8.2.0.
Ignoring request to alter fixed versions of bug #806457 to the same values 
previously set
> thanks
Stopping processing here.

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

Bug#804351: marked as done (installation-reports: Stretch installer-armel (2015-10-23) does not see storage devices on Dreamplug)

[Debian Bug Tracking System]

Your message dated Sat, 28 Nov 2015 22:39:28 +
with message-id <1448750368.13926.55.ca...@debian.org>
and subject line Re: Bug#804351: installation-reports: Stretch installer-armel 
(2015-10-23) does not see storage devices on Dreamplug
has caused the Debian Bug report #804351,
regarding installation-reports: Stretch installer-armel (2015-10-23) does not 
see storage devices on Dreamplug
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.)


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

When I run Jessie installer, I can see the USB stick (which the
installer was loaded from), and the internal microSD.

With current Stretch installer, neither storage device is visible.

I'm attaching screen and installer logs for both cases.

The installers were downloaded from:
http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/netboot/marvell/dreamplug/
http://ftp.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/netboot/marvell/dreamplug/

Marvell>> version

U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 21:53:14)
Marvell-DreamPlug
gcc (Debian 4.9.2-10) 4.9.2
GNU ld (GNU Binutils for Debian) 2.25

--
James


jessie-install-dreamplug.tar.gz
Description: application/gzip


stretch-install-dreamplug.tar.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
On Sat, 2015-11-28 at 14:40 -0500, James Valleroy wrote:
> On 11/28/2015 07:04 AM, Ian Campbell wrote:
> > On Thu, 2015-11-12 at 06:50 -0500, James Valleroy wrote:
> >
> > Hi James,
> >
> > I think this should be fixed in the latest dailies from
> > http://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/mar
> vell/
> > or at least my dreamplug is OK in recovery mode with the one from 2
> days ago.
> >
> > This will then propagate to Stretch with the next d-i alpha/beta.
> >
> > Ian
> 
> Hi Ian,
> 
> Yes, it's working now with the daily image. I'm able to complete the
> install and boot into the system.

Super, closing the bug with this mail, thanks!

Ian.

> 
> Thanks for your help!
> 
> James
> --- End Message ---

Bug#804351: installation-reports: Stretch installer-armel (2015-10-23) does not see storage devices on Dreamplug

[James Valleroy]

On 11/28/2015 07:04 AM, Ian Campbell wrote:
> On Thu, 2015-11-12 at 06:50 -0500, James Valleroy wrote:
>
> Hi James,
>
> I think this should be fixed in the latest dailies from
> http://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/marvell/
> or at least my dreamplug is OK in recovery mode with the one from 2 days ago.
>
> This will then propagate to Stretch with the next d-i alpha/beta.
>
> Ian

Hi Ian,

Yes, it's working now with the daily image. I'm able to complete the
install and boot into the system.

Thanks for your help!

James



signature.asc
Description: OpenPGP digital signature