Bug 354546

Summary:	changes in yast2 disk lead to enabling of boot.crypto in runlevel B if using an encrypted partition
Product:	[openSUSE] openSUSE 10.3	Reporter:	Justus Koerber <QTXGPZGTVMXJ>
Component:	YaST2	Assignee:	Thomas Fehr <fehr>
Status:	RESOLVED WONTFIX	QA Contact:	Jiri Srain <jsrain>
Severity:	Normal
Priority:	P3 - Medium	CC:	QTXGPZGTVMXJ
Version:	Final
Target Milestone:	---
Hardware:	All
OS:	openSUSE 10.3
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Justus Koerber 2008-01-17 19:05:26 UTC

Changes in yast2 disk lead to enabling of boot.crypto in runlevel B if using an encrypted partition. This even happens when not changing the encrypted partition at all.
Whay this is bad:
A) Yast2 does something I do not ask for and I can't stop it from doing it.
B) If you have a computer which can only be accessed viy ssh and reboot it, you will not be able to boot the computer any more, as it will stay in runlevel B and wait for a password.

Comment 1 Justus Koerber 2008-01-18 16:58:07 UTC

c) Behavior in previous opensuse versions was different. boot.crypto was not enabled magically by the partition manager

Comment 2 Thomas Fehr 2008-01-21 16:35:23 UTC

YaST2 calling insserv during update from 10.2 to 10.3 was necessary due to
some repackaging between 10.2 and 10.3. See bug #305105 for description why 
this was needed. The alternative would have been all system would have 
deactivated boot.crypto after update which would be more severe than your 
problem.

The insserv call is only done when updating from 10.2 so YaST2 will not touch
insserv state of boot.crypto with any future updates.