Bug#791794: UUID not found for root

[Ian Campbell]

On Tue, 2015-11-10 at 11:46 +0100, Cyril Brulebois wrote:
> Ian Campbell  (2015-11-10):
> > On Tue, 2015-11-10 at 11:14 +0100, Cyril Brulebois wrote:
> > > (As usual: you can safely pretend I didn't follow or fully
> understand f-k
> > > things.)
> > > 
> > > Given the size of the fix and the fact the comment right above
> the code
> > > being fixed is explicit about the initial intent makes me want to
> > > cherry-pick it right away. It might be a good idea to let it go
> through
> > > a bit of testing before doing so, just in case something breaks.
> > > 
> > > What do you think?
> > 
> > I was thinking to at least wait for it to hit testing first (should
> do so
> > at the end of the week) and then probably giving it a little more
> time
> > (just a week or so) to bake there too, but I may be being too
> conservative.
> 
> Seems fair to me; feel free to prod me in two weeks if you saw no
> breakages by then, so that I can push/ask SRM for an upload.

I've not seen any complaints so far, the fix has been in Stretch for
about three weeks now.

Ian.

Bug#791794: UUID not found for root

[Cyril Brulebois]

Hi,

Ian Campbell  (2015-12-05):
> I've not seen any complaints so far, the fix has been in Stretch for
> about three weeks now.

Thanks for the prod; pu filed accordingly: #807129.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#791794: UUID not found for root

[Cyril Brulebois]

Martin Michlmayr  (2015-11-09):
> * Ian Campbell  [2015-11-06 16:03]:
> > I've just pushed this change to flash-kenrel.git, so it will be in the
> > next upload.
> 
> Thanks!
> 
> Can we also get this into a stable update?  I believe some of the
> reports were about stable.

(As usual: you can safely pretend I didn't follow or fully understand f-k
things.)

Given the size of the fix and the fact the comment right above the code
being fixed is explicit about the initial intent makes me want to
cherry-pick it right away. It might be a good idea to let it go through
a bit of testing before doing so, just in case something breaks.

What do you think?

(In the meanwhile I'll be preparing a stable branch for it and adding
this to my “next point release” todo list.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#791794: UUID not found for root

[Ian Campbell]

On Tue, 2015-11-10 at 11:14 +0100, Cyril Brulebois wrote:
> Martin Michlmayr  (2015-11-09):
> > * Ian Campbell  [2015-11-06 16:03]:
> > > I've just pushed this change to flash-kenrel.git, so it will be in
> > > the
> > > next upload.
> > 
> > Thanks!
> > 
> > Can we also get this into a stable update?  I believe some of the
> > reports were about stable.
> 
> (As usual: you can safely pretend I didn't follow or fully understand f-k
> things.)
> 
> Given the size of the fix and the fact the comment right above the code
> being fixed is explicit about the initial intent makes me want to
> cherry-pick it right away. It might be a good idea to let it go through
> a bit of testing before doing so, just in case something breaks.
> 
> What do you think?

I was thinking to at least wait for it to hit testing first (should do so
at the end of the week) and then probably giving it a little more time
(just a week or so) to bake there too, but I may be being too conservative.

> (In the meanwhile I'll be preparing a stable branch for it and adding
> this to my “next point release” todo list.)

Thanks, saves me a job!

Ian.

Bug#791794: UUID not found for root

[Cyril Brulebois]

Ian Campbell  (2015-11-10):
> On Tue, 2015-11-10 at 11:14 +0100, Cyril Brulebois wrote:
> > (As usual: you can safely pretend I didn't follow or fully understand f-k
> > things.)
> > 
> > Given the size of the fix and the fact the comment right above the code
> > being fixed is explicit about the initial intent makes me want to
> > cherry-pick it right away. It might be a good idea to let it go through
> > a bit of testing before doing so, just in case something breaks.
> > 
> > What do you think?
> 
> I was thinking to at least wait for it to hit testing first (should do so
> at the end of the week) and then probably giving it a little more time
> (just a week or so) to bake there too, but I may be being too conservative.

Seems fair to me; feel free to prod me in two weeks if you saw no
breakages by then, so that I can push/ask SRM for an upload.

I had this kind of timeframe in mind…

> > (In the meanwhile I'll be preparing a stable branch for it and adding
> > this to my “next point release” todo list.)
> 
> Thanks, saves me a job!

… then discovered the fix was from July! But only released a few days
ago. :)

No problem, that really was a no-brainer.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#791794: UUID not found for root

[Martin Michlmayr]

* Ian Campbell  [2015-11-06 16:03]:
> I've just pushed this change to flash-kenrel.git, so it will be in the
> next upload.

Thanks!

Can we also get this into a stable update?  I believe some of the
reports were about stable.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#791794: UUID not found for root

[Ian Campbell]

On Fri, 2015-07-31 at 08:28 +0100, Ian Campbell wrote:
> 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've just pushed this change to flash-kenrel.git, so it will be in the
next upload.

commit 6cfc6f13261e2fe02fd1a54a02ca37ee132166b4
Author: Ian Campbell 
Date:   Fri Jul 31 08:24:03 2015 +0100

Avoid waiting for Ctrl-C if any debconf frontend is in use

not just non-interactive.

diff --git a/debian/changelog b/debian/changelog
index 7c2835a..bf87bd2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,10 @@ flash-kernel (3.48) UNRELEASED; urgency=medium
   * Update wandboard and cubox-i boot scripts to improve distro_bootcmd
 support.
 
+  [ Ian Campbell ]
+  * Avoid waiting for Ctrl-C if any debconf frontend is in use, not just
+non-interactive. (Closes: #791794)
+
  -- Vagrant Cascadian   Wed, 04 Nov 2015 13:33:08 -0800
 
 flash-kernel (3.47) unstable; urgency=medium
diff --git a/initramfs-tools/hooks/flash_kernel_set_root 
b/initramfs-tools/hooks/flash_kernel_set_root
index 201b7bd..af948c3 100755
--- a/initramfs-tools/hooks/flash_kernel_set_root
+++ b/initramfs-tools/hooks/flash_kernel_set_root
@@ -34,7 +34,7 @@ pause_error() {
    # If debconf appears to be running then it is important that
    # we do not block on stdin since this would hang the
    # installer.
-   if [ "$DEBIAN_HAS_FRONTEND" ] || [ "$DEBIAN_FRONTEND" = 
"noninteractive" ]; then
+   if [ "$DEBIAN_HAS_FRONTEND" ] || [ "$DEBIAN_FRONTEND" ]; then
    echo "Unable to abort; system will probably be broken!" >&2
    else
    echo "Press Ctrl-C to abort build, or Enter to continue" >&2

Bug#791794: UUID not found for root

[Ian Campbell]

On Thu, 2015-07-30 at 12:02 -0400, Martin Michlmayr wrote:
* Ian Campbell i...@debian.org [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

Bug#791794: UUID not found for root

[Martin Michlmayr]

* Ian Campbell i...@debian.org [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.

-- 
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/20150730160207.gd9...@jirafa.cyrius.com

Bug#791794: Detecting a d-i context from within /target? (was: Bug#791794: UUID not found for root)

[Steve McIntyre]

On Thu, Jul 16, 2015 at 04:50:35PM +0200, Cyril Brulebois wrote:
Hi,

If adding support for a variable looks like a good idea, how should we
name it?

Using sources.debian.net, looking for DEBIAN_INSTALLER returns 3 hits:
 - obs-build
 - live-build
 - libdebian-installer

live-build actually uses longer variable names, so not an issue:
| LB_DEBIAN_INSTALLER
| LB_MIRROR_DEBIAN_INSTALLER
| LB_PARENT_DEBIAN_INSTALLER
| LB_PARENT_MIRROR_DEBIAN_INSTALLER

obs-build uses the same variables.

libdebian-installer uses DEBIAN_INSTALLER__* for define/#include guards,
plus a LIBDEBIAN_INSTALLER_MAP_REAL #define.

So DEBIAN_INSTALLER shouldn't be an issue. Maybe something more specific
would make it easier to check for later…

We could use DEBIAN_INSTALLER_STEP or similar to pass on information
about what the state of the installer is, even. Or maybe that's more
detail than we need right now. :-)

DEBIAN_INSTALLER_RUNNING=y for a sensible default to check?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


-- 
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/20150722152833.ga5...@einval.com

Bug#791794: UUID not found for root

[Martin Michlmayr]

* Colin Watson cjwat...@debian.org [2015-07-16 15:27]:
 The copy operation was removed from partman because parted 3 no longer
 supports filesystem operations.  However, I can't find any references to
 it in partman code any more.  Is this perhaps coming from a preseeded
 partman recipe or something?  Do you have a more complete syslog,
 preferably with DEBCONF_DEBUG=developer?

It also happens with stretch.  Here's another log, again thanks to
Marco Basso.

  On a related note, flash-kernel waits for user input when the UUID of
  root is not found, which makes sense in an installed system, but not
  in d-i -- for the user, d-i will just hang with no obvious error.  Is
  there a good way to solve this?  In particular, is there a way for a
  postinst in /target to detect that it's run from within d-i?  KiBi
  doesn't know a way.  I guess a debconf prompt is the way to go?
 
 I think trying to add debconf prompting to an initramfs hook would
 probably be unwise.  flash-kernel already seems to check for
 DEBIAN_FRONTEND=noninteractive, so you could just set that in
 flash-kernel-installer.postinst when calling flash-kernel.

I was going to ask how I can set DEBIAN_FRONTEND=noninteractive when
in-target explicitly sets DEBIAN_FRONTEND=passthrough.

But then I looked at flash-kernel and found bug #721485 about
flash-kernel hanging d-i (i.e. this issue), which was fixed in 3.12,
and #753059 which fixed a problem with the patch in 3.12 (in 3.23).

But I'm getting a lot of reports of flash-kernel hanging d-i, so
clearly this is not working.  The code is:

# 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 [ $DEBIAN_HAS_FRONTEND ] || [ $DEBIAN_FRONTEND = 
noninteractive ]; then
echo Unable to abort; system will probably be broken! 2
else
echo Press Ctrl-C to abort build, or Enter to continue 2
read _ignored
fi

in-target sets DEBIAN_FRONTEND=passthrough, so $DEBIAN_FRONTEND=noninteractive
is not true.

Is $DEBIAN_HAS_FRONTEND supposed to be set when d-i runs in-target?
Ian, do you know what's going on?  It seems the fixes you applied are
not working.

-- 
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/20150722070242.ga5...@jirafa.cyrius.com

Bug#791794: UUID not found for root

[Ian Campbell]

On Wed, 2015-07-22 at 00:02 -0700, Martin Michlmayr wrote:
 Is $DEBIAN_HAS_FRONTEND supposed to be set when d-i runs in-target?

in-target (via chroot-setup.sh in debian-installer-utils) unsets it and
always has AFAICT from the git log.

From #721485 that clause is there to handle failure when running via a
new package install or dpkg-reconfigure on an installed system.

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...

 Ian, do you know what's going on?  It seems the fixes you applied are
 not working.

They were for other cases than d-i. Since the fixup to put the
DEBIAN_FRONTEND check back I don't think the behaviour under d-i has
changed for years.

It would be nice (tm) if that bit of code could actually use debconf if
it happens to be there, but maybe that's one for another time.

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/1437552614.407.14.ca...@debian.org

Bug#791794: UUID not found for root

[Martin Michlmayr]

* Colin Watson cjwat...@debian.org [2015-07-16 15:27]:
  Jul  1 10:22:45 kernel: [ 8083.996693] EXT4-fs (md0): mounted filesystem 
  with ordered data mode. Opts: errors=remount-ro
  Jul  1 10:22:47 apt-install: Queueing package e2fsprogs for later 
  installation
  Jul  1 10:22:47 main-menu[1537]: (process:5300): 
  /lib/partman/choose_partition/60partition_tree/do_option: 
  Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
  Jul  1 10:22:47 main-menu[1537]: (process:5300): 
  /lib/partman/active_partition/copy/choices: not found
 
 The copy operation was removed from partman because parted 3 no longer
 supports filesystem operations.  However, I can't find any references to
 it in partman code any more.  Is this perhaps coming from a preseeded
 partman recipe or something?  Do you have a more complete syslog,
 preferably with DEBCONF_DEBUG=developer?

Attached is a log thanks to Marco Basso.

 I think trying to add debconf prompting to an initramfs hook would
 probably be unwise.  flash-kernel already seems to check for
 DEBIAN_FRONTEND=noninteractive, so you could just set that in
 flash-kernel-installer.postinst when calling flash-kernel.

Great points!  Thanks for pointing out the obvious solution when I had
something more complex in mind.

-- 
Martin Michlmayr
http://www.cyrius.com/


ts212p-install.log.bz2
Description: Binary data

Bug#791794: Detecting a d-i context from within /target? (was: Bug#791794: UUID not found for root)

[Cyril Brulebois]

Hi,

Colin Watson cjwat...@debian.org (2015-07-16):
 On Thu, Jul 16, 2015 at 10:05:48AM -0400, Martin Michlmayr wrote:
  On a related note, flash-kernel waits for user input when the UUID of
  root is not found, which makes sense in an installed system, but not
  in d-i -- for the user, d-i will just hang with no obvious error.  Is
  there a good way to solve this?  In particular, is there a way for a
  postinst in /target to detect that it's run from within d-i?  KiBi
  doesn't know a way.  I guess a debconf prompt is the way to go?
 
 I think trying to add debconf prompting to an initramfs hook would
 probably be unwise.  flash-kernel already seems to check for
 DEBIAN_FRONTEND=noninteractive, so you could just set that in
 flash-kernel-installer.postinst when calling flash-kernel.

I'm not aware of other use cases right now, but maybe we could or should
standardize on an environment variable we would set in { all | most |
a particular set of } calls to let scripts know they're being executed
within an installer context?

Right now, provided /proc is mounted within /target, looking at /proc/1
might help one figure out that one /might/ might running within d-i; or
looking for main-menu in ps; both approaches look very fragile.


If adding support for a variable looks like a good idea, how should we
name it?

Using sources.debian.net, looking for DEBIAN_INSTALLER returns 3 hits:
 - obs-build
 - live-build
 - libdebian-installer

live-build actually uses longer variable names, so not an issue:
| LB_DEBIAN_INSTALLER
| LB_MIRROR_DEBIAN_INSTALLER
| LB_PARENT_DEBIAN_INSTALLER
| LB_PARENT_MIRROR_DEBIAN_INSTALLER

obs-build uses the same variables.

libdebian-installer uses DEBIAN_INSTALLER__* for define/#include guards,
plus a LIBDEBIAN_INSTALLER_MAP_REAL #define.

So DEBIAN_INSTALLER shouldn't be an issue. Maybe something more specific
would make it easier to check for later…


Thoughts?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#791794: UUID not found for root

[Martin Michlmayr]

* Peter Nagel peter.na...@kit.edu [2015-07-08 15:12]:
 The problem seems to appear only when jessie is installed to RAID (e.g.
 RAID1)!
 Error message:
 flash-kernel-installer does not find UUID (see the two lines of syslog
 below):
   in-target: UUID eeb34bbe-375a-4dc1-939d-f56b801a4c75 doesn't exist in
 /dev/disk/by-uuid in-target:
   Warning: root device
 /dev/disk/by-uuid/eeb34bbe-375a-4dc1-939d-f56b801a4c75 does not exist

I received several reports about this recently.  I'm surprised because
this used to work just fine.

I didn't have time to investigate, but I noticed the following partman
errors in the syslog of those affected.  Colin, do you know what this
is about?

Jul  1 10:22:40 partman: mke2fs 1.42.12 (29-Aug-2014)
Jul  1 10:22:45 kernel: [ 8083.996693] EXT4-fs (md0): mounted filesystem with 
ordered data mode. Opts: errors=remount-ro
Jul  1 10:22:47 apt-install: Queueing package e2fsprogs for later installation
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/choose_partition/60partition_tree/do_option: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/active_partition/copy/choices: not found
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
Jul  1 10:22:47 main-menu[1537]: (process:5300): sh: 4194304: unknown operand
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/choose_partition/60partition_tree/do_option: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/active_partition/copy/choices: not found
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/choose_partition/60partition_tree/do_option: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/active_partition/copy/choices: not found
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/choose_partition/60partition_tree/do_option: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/active_partition/copy/choices: not found
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/choose_partition/60partition_tree/do_option: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/active_partition/copy/choices: not found
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/choose_partition/60partition_tree/do_option: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
/lib/partman/active_partition/copy/choices: not found
Jul  1 10:22:47 main-menu[1537]: (process:5300): 
Jul  1 10:25:35 main-menu[1537]: INFO: Menu item 'bootstrap-base' selected

On a related note, flash-kernel waits for user input when the UUID of
root is not found, which makes sense in an installed system, but not
in d-i -- for the user, d-i will just hang with no obvious error.  Is
there a good way to solve this?  In particular, is there a way for a
postinst in /target to detect that it's run from within d-i?  KiBi
doesn't know a way.  I guess a debconf prompt is the way to go?

 PROBLEM:
 When I shutdown the system and remove any (active) harddisk (from RAID1) the
 system has problems to boot again.
 Error message (from bootlog at serial console)

Just for the record, this was not d-i related and there's another bug
report about this.

-- 
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/20150716140548.gb19...@jirafa.cyrius.com

Bug#791794: UUID not found for root

[Colin Watson]

On Thu, Jul 16, 2015 at 10:05:48AM -0400, Martin Michlmayr wrote:
 * Peter Nagel peter.na...@kit.edu [2015-07-08 15:12]:
  The problem seems to appear only when jessie is installed to RAID (e.g.
  RAID1)!
  Error message:
  flash-kernel-installer does not find UUID (see the two lines of syslog
  below):
in-target: UUID eeb34bbe-375a-4dc1-939d-f56b801a4c75 doesn't exist in
  /dev/disk/by-uuid in-target:
Warning: root device
  /dev/disk/by-uuid/eeb34bbe-375a-4dc1-939d-f56b801a4c75 does not exist
 
 I received several reports about this recently.  I'm surprised because
 this used to work just fine.
 
 I didn't have time to investigate, but I noticed the following partman
 errors in the syslog of those affected.  Colin, do you know what this
 is about?
 
 Jul  1 10:22:40 partman: mke2fs 1.42.12 (29-Aug-2014)
 Jul  1 10:22:45 kernel: [ 8083.996693] EXT4-fs (md0): mounted filesystem with 
 ordered data mode. Opts: errors=remount-ro
 Jul  1 10:22:47 apt-install: Queueing package e2fsprogs for later installation
 Jul  1 10:22:47 main-menu[1537]: (process:5300): 
 /lib/partman/choose_partition/60partition_tree/do_option: 
 Jul  1 10:22:47 main-menu[1537]: (process:5300): line 88: 
 Jul  1 10:22:47 main-menu[1537]: (process:5300): 
 /lib/partman/active_partition/copy/choices: not found

The copy operation was removed from partman because parted 3 no longer
supports filesystem operations.  However, I can't find any references to
it in partman code any more.  Is this perhaps coming from a preseeded
partman recipe or something?  Do you have a more complete syslog,
preferably with DEBCONF_DEBUG=developer?

 On a related note, flash-kernel waits for user input when the UUID of
 root is not found, which makes sense in an installed system, but not
 in d-i -- for the user, d-i will just hang with no obvious error.  Is
 there a good way to solve this?  In particular, is there a way for a
 postinst in /target to detect that it's run from within d-i?  KiBi
 doesn't know a way.  I guess a debconf prompt is the way to go?

I think trying to add debconf prompting to an initramfs hook would
probably be unwise.  flash-kernel already seems to check for
DEBIAN_FRONTEND=noninteractive, so you could just set that in
flash-kernel-installer.postinst when calling flash-kernel.

Cheers,

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


-- 
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/20150716142722.gk23...@riva.ucam.org