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.