Re: Sparc removal
On Fri, 2015-07-31 at 04:34 +0200, Cyril Brulebois wrote: > I'm a bit unsure. If sparc ever comes back as sparc64, it might make > sense to reuse some bits. They can always be recovered from the VCS history or the attic. Ian. -- 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/1438327881.28924.57.ca...@debian.org
Bug#791794: UUID not found for root
On Thu, 2015-07-30 at 12:02 -0400, Martin Michlmayr wrote: * Ian Campbell [2015-07-22 09:10]: > I think it is the DEBIAN_FRONTEND which is supposed to work for the > installer case, which you added back in 2008. in-target appears to have > set DEBIAN_FRONTEND=passthrough since 2005, but perhaps something has > gotten into (or out of) the middle in the meantime? > > Or perhaps something has changed to using in-target which wasn't > before? > > In any case, perhaps the answer is to check for DEBIAN_FRONTEND either > noninteractive or passthrough? Or maybe even just for it being set at > all, since even if it were =text or =newt or whatever echo+read doesn't > seem like the right answer... I've no idea what would be best. I was hoping Colin would comment. Unless someone has an alternative suggestion I think I'll make the flash-kernel initramfs-hook gate its waiting for Ctrl-C on failure behaviour on either DEBIAN_FRONTEND or DEBIAN_HAS_FRONTEND being non -empty. Today the DEBIAN_FRONTEND check is explicitly for "noninteractive" which omits at least "passthrough" as another problematic case. It seems to me that few of the other possible options would benefit from being made to wait here (graphical ones surely not, likewise newt, maybe text would be ok, but lets not bother special casing it). I found an old branch where I tried to get the initramfs-hook to use debconf if it appears to be already running. I don't think I ever got it working, and it looks like I was having trouble arranging for flash -kernel's templates to be loaded (since we are running in the context of some other packages debconf invocation), which matches my vague recollection. I've pasted the key hunk below in case any one has any ideas how to make this work correctly. Ian. # Script is called from update-initramfs which in term can be # called manually by the admin from the CLI or via various # postinst and trigger hooks or from the installer. # - # If debconf appears to be running then it is important that - # we do not block on stdin since this would hang the - # installer. + # If debconf appears to be running then use it to notify the + # user. This is particularly important if the error occurs + # during the installer. if [ "$DEBIAN_HAS_FRONTEND" ]; then echo "Unable to abort; system will probably be broken!" >&2 + # No need to worry about confmodule re-execing the + # script since we check $DEBIAN_HAS_FRONTEND + # immediately above + . /usr/share/debconf/confmodule + # Make sure our templates are loaded + db_x_loadtemplatefile $(dpkg-query --control-path flash-kernel templates) flash-kernel + db_title flash-kernel + db_subst flash-kernel/$template ROOTDEV $rootdev + db_input critical flash-kernel/$template + db_go + #db_get flash-kernel/$template else + echo "" >&2 echo "Press Ctrl-C to abort build, or Enter to continue" >&2 read _ignored fi -- 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/1438327721.28924.55.ca...@debian.org
Re: Sparc removal
On Fri, 2015-07-31 at 04:34 +0200, Cyril Brulebois wrote:
[...]
> I'm a bit unsure. If sparc ever comes back as sparc64, it might make
> sense to reuse some bits. But I'm not sure whether both archs would be
> close enough for that to happen, or if they would be different beasts
> like arm{el,hf} and arm64 are. I suppose the former might be true since
> it might just be about the number of bits in kernel/user-space, rather
> than a completely new arch.
[...]
We haven't supported actual 32-bit SPARCs for a long time; the last
release with 32-bit kernel images was etch. So "only" userland would
change, and I believe the 32-bit and 64-bit modes for userland are not
that different.
Ben.
--
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.
signature.asc
Description: This is a digitally signed message part
Bug#794265: flash-kernel subsequent actions result in segfault
Package: flash-kernel Version: 3.45 Severity: important Dear Maintainer, Durin a dist-upgrade flash-kernel was run. apt-get stopped. Any subsequent action resulted in segfault. After rebooting running flash-kernel resulted in the same behavior. I booted with an older kernel 3.16 and the problem war gone. Rebooting with the curren kernel resulted in the segfault behavior. Not sure if this is a flash-kernel or kernel issue. Best regards Mike -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 3.16.0-4-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.57 ii devio 1.2-1+b1 ii initramfs-tools0.120 ii linux-base 3.5 ii ucf3.0030 Versions of packages flash-kernel recommends: ii u-boot-tools 2015.04+dfsg1-2 flash-kernel suggests no packages. -- debconf information: flash-kernel/linux_cmdline: quiet -- 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/20150731191108.1633.4820.reportbug@tempestus.Belkin
Bug#794265: flash-kernel subsequent actions result in segfault
* Michele Cane [2015-07-31 21:11]: > Durin a dist-upgrade flash-kernel was run. apt-get stopped. Any subsequent > action resulted in segfault. > After rebooting running flash-kernel resulted in the same behavior. > I booted with an older kernel 3.16 and the problem war gone. > Rebooting with the curren kernel resulted in the segfault behavior. Is this with a QNAP? I read about a similar issue from a QNAP user. -- Martin Michlmayr http://www.cyrius.com/ -- 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/20150731193944.ga19...@jirafa.cyrius.com
Bug#794265: flash-kernel subsequent actions result in segfault
Hi Martin, It was me on the qnap forum. So yes It is on a qnap TS-419P II. Cheers Mike On Fri, Jul 31, 2015 at 9:39 PM Martin Michlmayr wrote: > * Michele Cane [2015-07-31 21:11]: > > Durin a dist-upgrade flash-kernel was run. apt-get stopped. Any > subsequent action resulted in segfault. > > After rebooting running flash-kernel resulted in the same behavior. > > I booted with an older kernel 3.16 and the problem war gone. > > Rebooting with the curren kernel resulted in the segfault behavior. > > Is this with a QNAP? > > I read about a similar issue from a QNAP user. > > -- > Martin Michlmayr > http://www.cyrius.com/ > -- Michele Cane, Ph.D.
