http://bugzilla.suse.com/show_bug.cgi?id=922308
--- Comment #14 from Stefan Hundhammer ---
One working day of analyzing the logs and the code later it looks like it's not
the calculations of any limits that are to blame, but a missing call to
StorageProposalClass::PostProcessor:
The missing
"userdata":$["/":"snapshots"]
section in the target map is added in PostProcessor::modify() in
StorageProposal.rb:4443 . This is called via either
PostProcessor::process_partitions() or via PostProcessor::process_targets().
There are multiple entry points to create storage proposals:
(1) StorageProposal.rb:3888: get_proposal()
(2) StorageProposal.rb:4491: get_inst_proposal()
(3) StorageProposal.rb:5603: get_inst_prop_vm() ("VM" for "Volume Manager")
(4) StorageProposal.rb:5985: get_proposal_vm()
(5) StorageProposal.rb:6131: get_inst_prop() (calls one of the others)
(1), (2) and (3) each create a new instance of PostProcessor and call one of
its process_...() functions at the end (followed by an unconditional
y2milestone() logging that leaves a clear trace in the log).
(4) does not do this. Yet this is what is called after the proposal is changed:
2015-03-13 09:15:46 <1> 10.0.2.15(2721) [Ruby] modules/StorageProposal.rb:5989
get_proposal_vm ddev:/dev/sda vg:system home:false lvm:true encrypt:false
So it looks like that PostProcessor calls is simply missing in that case.
--
You are receiving this mail because:
You are on the CC list for the bug.