Bug 116664

Summary:	YaST2 dies on install with system error code -3030
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Jeff Warnica <jeff>
Component:	Installation	Assignee:	Thomas Fehr <fehr>
Status:	RESOLVED FIXED	QA Contact:	Klaus Kämpf <kkaempf>
Severity:	Normal
Priority:	P5 - None
Version:	RC 1
Target Milestone:	---
Hardware:	i586
OS:	All
Whiteboard:
Found By:	Beta-Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	y2logs

Description Jeff Warnica 2005-09-12 23:27:00 UTC

Not much more to say. The only moderatly unusual thing about the system is that
its a network install, but I cant see how that would mess up partitioning/formating.

Will attach logs.

Comment 1 Jeff Warnica 2005-09-12 23:27:43 UTC

Created attachment 49703 [details]
y2logs

Comment 2 Lukas Ocilka 2005-09-13 06:41:17 UTC

Thanks a lot for logs

Volume.cc(checkDevice):803 checkDevice:/dev/hda1 ret:-3030
...
Disk.cc(commitChanges):1399 ret:-3030
...
Storage.cc(commitPair):2755 ret:-3030
...
Storage.ycp:2694 CommitChanges sint ret -3030

Comment 3 Thomas Fehr 2005-09-13 09:07:37 UTC

No idea why the device node /dev/hda1 is missing in you installation environment.
In installation environment all device nodes should be available.

Did you use parted, fdisk or sfdisk to manually repartition the disk before or
while YaST2 was started?

Comment 4 Jeff Warnica 2005-09-13 18:47:42 UTC

Hmm.. Actually, that log is from the secon attempt. The first attempt gave the
same error number, though possibly a different text description. Before the
attempt of these logs, I had manually partitioned the disk, mkswap/mkreiserfs's
it.. This attempt, it should have been just a nice clean disk with partitions
and filesystems ready to go.

Comment 5 Thomas Fehr 2005-09-14 09:43:25 UTC

It is a known problem that manual repartitioning without a reboot removes
device nodes from the installation environment (since udevd removes the device
nodes when it gets remove events for lock devices). YaST2 has so far no capability
to recreate them if it creates new partitions (from the log I can see that you
created /dev/hda1 as a new partitions), therfore one has to reboot into a 
clean installation environment after manual removal of partitions.

Actually the log from the first attempt runs into another problem as the one
described in comment#2. libstorage is currently not handling an existing label
correctly when the fs type is changed. In your case this causes libstorage to
try to set a label for the swap partiton which of course fails. I fixed this
problem now but I doubt this fix will still make it into goldmaster.

Comment 6 Thomas Fehr 2005-09-14 10:36:42 UTC

Fix will be in RC4.

Comment 7 Jeff Warnica 2005-09-14 19:19:14 UTC

Well, at least some itch was scratched :)