unmount: disabled causes installation failure to exit silently
Bug #1764210 reported by
Michael Hudson-Doyle
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| curtin |
Fix Released
|
High
|
Unassigned | ||
| curtin (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Bug Description
from cmd_install:
finally:
if log_target_path:
if instcfg.
return
# unmount everything (including iscsi disks)
that 'return' means the function returns normally even in an error case. I think this needs to be changed into an if/else.
Related branches
~raharper/curtin:ubuntu/devel/newupload-20180418
- Server Team CI bot: Approve (continuous-integration)
- curtin developers: Pending requested
-
Diff: 321 lines (+106/-41)12 files modifiedcurtin/block/clear_holders.py (+4/-3)
curtin/block/mdadm.py (+3/-4)
curtin/commands/curthooks.py (+1/-1)
curtin/commands/install.py (+22/-23)
debian/changelog (+11/-0)
examples/tests/lvm.yaml (+21/-0)
tests/unittests/test_clear_holders.py (+6/-6)
tests/unittests/test_commands_install.py (+28/-0)
tests/vmtests/__init__.py (+1/-1)
tests/vmtests/test_lvm.py (+1/-1)
tests/vmtests/test_network_vlan.py (+6/-0)
tests/vmtests/test_pollinate_useragent.py (+2/-2)
~raharper/curtin:fix/lp-1764210
- Michael Hudson-Doyle: Pending requested
-
Diff: 39 lines (+29/-0)1 file modifiedtests/unittests/test_commands_install.py (+29/-0)
~mwhudson/curtin:lp-1764210
- Ryan Harper (community): Approve
- Scott Moser (community): Needs Information
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 94 lines (+50/-23)2 files modifiedcurtin/commands/install.py (+22/-23)
tests/unittests/test_commands_install.py (+28/-0)
| Changed in curtin: | |
| status: | New → In Progress |
Revision history for this message
| Ryan Harper (raharper) wrote | #1 |
| Changed in curtin: | |
| importance: | Undecided → High |
Revision history for this message
| Scott Moser (smoser) wrote | #2 |
| Changed in curtin: | |
| status: | In Progress → Fix Committed |
| Changed in curtin (Ubuntu): | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| status: | Confirmed → In Progress |
Revision history for this message
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in curtin (Ubuntu): | |
| status: | In Progress → Fix Released |
Revision history for this message
| Ryan Harper (raharper) wrote Fixed in curtin version 18.2. | #4 |
| Changed in curtin: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
My reading of the python3 docs suggests that this analysis is correct. If we issue a return, then the saved exception is discarded.
If finally is present, it specifies a ‘cleanup’ handler. The try clause is executed, including any except and else clauses. If an exception occurs in any of the clauses and is not handled, the exception is temporarily saved. The finally clause is executed. If there is a saved exception it is re-raised at the end of the finally clause. If the finally clause raises another exception, the saved exception is set as the context of the new exception. If the finally clause executes a return or break statement, the saved exception is discarded:
>>>
>>> def f():
... try:
... 1/0
... finally:
... return 42
...
>>> f()
42
https:/