Bug 141949

Summary:	/dev/loop* suggestion by Yast2 does not care about already used /dev/loop* devices.
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Olli Artemjev <grey-olli>
Component:	YaST2	Assignee:	Thomas Fehr <fehr>
Status:	RESOLVED FIXED	QA Contact:	Klaus Kämpf <kkaempf>
Severity:	Major
Priority:	P3 - Medium	CC:	dmueller, grey-olli, suse-beta
Version:	Final	Keywords:	Bad_Design, easy_fix, Install, security, UI, Usability
Target Milestone:	SUSE Linux 10.1
Hardware:	i686
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Olli Artemjev 2006-01-07 19:22:02 UTC

Nither at install time while doing partitioning (custom expert mode) nor after system has been already installed (running yast2-> System -> Partitioner) the corresponding yast2 module does not care about devices already busy doing their work. Say, you have two or 5 encrypted partitions ready and mounted, correctly des cribed in cryptotab (since them're mounted by boot.crypto start - them are correct). If you then will try in Partitioner (or while system setup in expert -> custom partitioning) to use ¨Crypt File¨ option -> ¨Create Crypt File¨", then independently to that /dev/loop1 is already in use the yast2 will suggest /dev/loop1 for the new entry. If this is an issue of installation - later this will lead to ¨Error occured¨ with returning back to package selection. It is quite annoying. Please do not ask me to give you logs. Just reproduce - it is quite easy to get this on the system - just create _several_ encrypted
partitions (at least two) and try to add an encrypted loop file.

Obviousely to easily fix this the code should count used loopback devices, but also the trick - the code should be aware of ´options loop max_loop=VALUE´ for the system. Default value of 8 loop devices is _NOT_ enouɡh for custom secure system.

The bug is though a bad design also, since expert should be able to fill exact /dev/loop devices involved. Though there´s not way to do that in Partitioner w/ yast2 .

Comment 1 Michael Gross 2006-01-09 15:35:49 UTC

Jiri: The PDB does no longer list you as the maintainer of yast2-disk, in fact it lists nothing. Has something changed here? If yes, please reassign. The described cabability should be implemented, you decide. Making this an enhancement.

Comment 3 Thomas Fehr 2006-01-09 16:06:10 UTC

Tried to reproduce the problem here and failed.
YaST2 correctly used /dev/loop1 after i set up a crypto loop on /dev/loop0.

Please attach y2log files from /var/log/YaST2/y2log* and the output of
losetup -a and the content of /etc/cryptotab.

Comment 5 Olli Artemjev 2006-01-12 11:46:29 UTC

Could you please try to make your 1st loop 'a partition'. Say /dev/hdaXX
(whatever is possible on your system) as your loop device? I didn't check
how it works w/ setting up file loops from start. Mebbe OK. Though I'm about
the case when you've crypted _partitions_. I had them 1st, then tried to
setup a crypto loop.

olli@skylab:~> cat /etc/cryptotab
/dev/loop0      /dev/hdb5                      /tmp              ext3
twofish256 data=ordered,acl,user_xattr
/dev/loop1      /dev/hdb7                      /var/spool        ext3
twofish256 data=journal,acl,user_xattr
/dev/loop2      /dev/hdb8                      /srv              ext3
twofish256 data=journal,acl,user_xattr
/dev/loop3      /dev/hdb9                      /home             ext3
twofish256 data=journal,acl,user_xattr
/dev/loop4      /dev/hdb10                     /usr/src          ext3
twofish256 data=journal,acl,user_xattr
/dev/loop5      /dev/hdb11                     /usr/include      ext3
twofish256 data=journal,acl,user_xattr
/dev/loop6      /dev/sda3                      /video            ext3
twofish256 data=journal,acl,user_xattr
/dev/loop7      /dev/sda2                      /var/cache        ext3
twofish256 data=journal,acl,user_xattr
#/dev/loop8      /media/ntfs/test/suse10cryptofs /media/smallcryptoloop ext2
twofish256
olli@skylab:~> su -
Password:
skylab:~ # losetup -a
/dev/loop0: [000d]:4136 (/dev/hdb5) encryption=CryptoAPI/twofish-cbc
/dev/loop1: [000d]:4114 (/dev/hdb7) encryption=CryptoAPI/twofish-cbc
/dev/loop2: [000d]:4094 (/dev/hdb8) encryption=CryptoAPI/twofish-cbc
/dev/loop3: [000d]:4172 (/dev/hdb9) encryption=CryptoAPI/twofish-cbc
/dev/loop4: [000d]:4151 (/dev/hdb10) encryption=CryptoAPI/twofish-cbc
/dev/loop5: [000d]:4121 (/dev/hdb11) encryption=CryptoAPI/twofish-cbc
/dev/loop6: [000d]:4514 (/dev/sda3) encryption=CryptoAPI/twofish-cbc
/dev/loop7: [000d]:4480 (/dev/sda2) encryption=CryptoAPI/twofish-cbc
skylab:~ #

PS: I won't attach yast logs. It's huge waste of time to dig there & for us
all. It's easier to reproduce.

PPS: And again for those who'll fix that. There's a bug related I submitted - the default install supports only 8 loop devices. Also the user may change 'options loop max_loop=XX' & reccompile the kernel to support loop devices as a module. Thus the avaliable maximum should be checked somehow.

Comment 6 Christian Boltz 2006-01-12 13:27:37 UTC

AFAIK you can specify   max_loop=XX   as boot option also - no need to recompile ;-)

Comment 7 Olli Artemjev 2006-01-12 13:41:38 UTC

Yes. The question is to assign request to the right maintaner. =) And read - I said user _MAY_ recompile & get trapped by default value. It's just a possible user beheviour. For it'd be nice to support user by adding the option in BOTH places, since 'em 'ren't conflicting.

Comment 8 Dirk Mueller 2006-01-13 13:59:32 UTC

any idea why this is at enhancement level? Its for sure a bug for me if I'm unable to create crypto loops with yast.

Comment 9 Dirk Mueller 2006-01-13 15:44:52 UTC

*** Bug 143036 has been marked as a duplicate of this bug. ***

Comment 10 Olli Artemjev 2006-01-14 14:48:44 UTC

As for me this is definitely a bug. The ehancement would be if yast 'll be able to customize /dev/loopXX while configuring loops. Changing level of bug once to a Major state. Though if SuSE team 'll reassign it back - I'dn't touch it again - it's their tasklist, not mine. =)

Comment 11 Thomas Fehr 2006-01-25 15:58:10 UTC

Problem will be fixed in SL 10.1 beta#3