Re: failing debootstrap

[John Paul Adrian Glaubitz]

Hi Yaroslav!

On 01/18/2017 04:09 AM, Yaroslav Halchenko wrote:
> followed https://wiki.debian.org/Sparc64
> and grabbed
> https://people.debian.org/~glaubitz/debian-cd/2016-12-13/debian-9.0-sparc64-NETINST-1.iso
> image.  After figuring out how to boot the beast off cd, went ahead with
> partitioning (software raid, lvm, ext3) and install base system.  That
> is the step which failed.  Log (4th screen) ends with:

We have had multiple reports that there are issues with the latest images.

Could you try this older image from May and report back?

> https://people.debian.org/~glaubitz/debian-cd/2016-05-04/

THanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[RFC] The PIE unholy mess

[Guillem Jover]

Hi!

I'd like to get some feedback from porters and package maintainers,
given that this affects at least both groups. Some background first.

One of the reasons PIE has in the past not been enabled by default in
dpkg-buildflags, is because it introduced some slowness on some arches,
although this has somewhat changed recently. But also because
unconditionally setting it, breaks at least PIC builds. So PIE got
enabled recently by default in gcc, as it could easily control when it
is relevant. Although this has been done only for release architectures.

At about the same time this was being considered, I realized that dpkg
could enable this "safely" by using gcc specs files. But this is in
any case also required to be able to disable PIE when it is implicitly
enabled by default in gcc. So we'll need specs files no matter what,
at least for now.

While adapting dpkg-buildflags to cover for the new gcc defaults, I
unintentionally enabled PIE by default on all architectures, and when
I noticed, it seemed to make sense to leave it like that, because:

  * All previous build flags from dpkg-buildflags have always been
enabled globally and only blacklisted completely when they have
been non-functional.
  * It's a more consistent interface for packages, as they get built
with the same flags everywhere. Otherwise we'd get PIE enabled by
default in release arches, disabled by default elsewhere, and
enabled or disabled depending on the package requesting so.
  * It will mean that PIE coverage reporting will be shadowed in
lintian, because the tags only cover i386 and amd64, so maintainers
will probably stop enabling them globally.

Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
requesting to not enable PIE globally from dpkg-buildflags, and pretty
much immediately added a patch into gcc [P] to ignore dpkg-buildflags
PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did
not enable PIE explicitly (I only fully understood the request after
seeing the gcc patch).

  [P] 


Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
does not even need to be exported from debian/rules, nor from the
dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
--export=configure or --export=cmdline. It's also a layer violation.
It also breaks unrelated stuff as now gcc emits notes when it thinks
the -specs option should not be passed. And while I could certainly
have started an arms-race by adding counter-measures by randomizing
the filenames or something similarly ugly, that'd be pretty much silly
and childish.

For better or worse, this does not affect the release architectures,
so by extension it should not affect the release, but it still sucks.

So, I'd like to know how people feel about the requested interface
(i.e. not enabling PIE globally from dpkg-buildflags). If there's
consensus that porters and maintainers want that, I'll just change
dpkg-buildflags to do this, even though I think it's a very
suboptiomal behavior.

Alternatively, porters could as well request PIE be enabled by default
in gcc on their port, which could make this also globally enabled.

Thanks,
Guillem

Fattura TIM linea Fissa - Gennaio 2017 - scadenza 12/01/2017

[Telecom Italia-TIM]

<<< text/html: Unrecognized >>>

failing debootstrap

[Yaroslav Halchenko]

Hi Sparc gurus,

I finally got a "new" sparc box to replace passed away previous one some
SunFire IIRC, which I use for upstream CI on big-endians.
I have got now an UltraSparc T2 with 48GB of RAM -- whoohoo

followed https://wiki.debian.org/Sparc64
and grabbed
https://people.debian.org/~glaubitz/debian-cd/2016-12-13/debian-9.0-sparc64-NETINST-1.iso
image.  After figuring out how to boot the beast off cd, went ahead with
partitioning (software raid, lvm, ext3) and install base system.  That
is the step which failed.  Log (4th screen) ends with:

... 
Jan 18 02:50:20 main-menu[228]: (process:3771): /lib/partman/fstab.d/zfs:   
Jan 18 02:50:20 main-menu[228]: (process:3771): line 49:
Jan 18 02:50:20 main-menu[228]: (process:3771): zpool: not found
Jan 18 02:50:20 main-menu[228]: (process:3771): 
Jan 18 02:50:20 main-menu[228]: (process:3771): /bin/block-attr:
Jan 18 02:50:20 main-menu[228]: (process:3771): line 33:
Jan 18 02:50:20 main-menu[228]: (process:3771): blkid: not found
Jan 18 02:50:20 main-menu[228]: (process:3771): 
Jan 18 02:50:20 main-menu[228]: (process:3771): /bin/block-attr:
Jan 18 02:50:20 main-menu[228]: (process:3771): line 33:
Jan 18 02:50:20 main-menu[228]: (process:3771): blkid: not found
Jan 18 02:50:20 main-menu[228]: (process:3771): 
Jan 18 02:50:23 main-menu[228]: DEBUG: resolver (libgcc1): package doesn't 
exist (ignored) 
 
Jan 18 02:50:23 main-menu[228]: INFO: Falling back to the package description 
for brltty-udeb 
  
Jan 18 02:50:23 main-menu[228]: INFO: Falling back to the package description 
for brltty-udeb 
  
Jan 18 02:50:23 main-menu[228]: INFO: Menu item 'bootstrap-base' selected   
Jan 18 02:51:13 debootstrap: mknod: /target/dev/null: No such file or directory 


if you try to rerun installation of the base system, it fails in other
miserable ways:

Jan 18 03:08:55 debootstrap: tar: can't open 
'./usr/share/doc/gcc-6-base/README.Debian.sparc64.gz': File exists

any clues on how to overcome or recommendations on another  image/release
to use on the beast

Thanks in advance and please keep me CCed
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik