[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#558686: Partition manager fails to update kernel partition table



On Monday 30 November 2009, Torsten Landschoff wrote:
> Looks correct. I don't know exactly which setup I used for Ubuntu.
> I think, I had /dev/sda1, 20GB ext4, and /dev/sda2, 16 GB swap.

s/sda2/sda5/; sda2 was the logical partition; sda5 the actual swap.

> I first wanted to use the whole disk as LVM on RAID, but figured that
> having /boot extra would be a good idea.
>
> > Create xGB primairy partition on disk a
> > - change mountpoint and select /boot
> > - change type to ext2
> > - mark bootable
> > - done
> > Select just created partition
> > - use as RAID
> > - done
>
> ... to have another boot partition on /dev/sdb.

Yes, guessed as much. You may want to mark /dev/sdb1 bootable...

> > I *can* reproduce the error by manually activating swap on /dev/hda5
> > from a debug shell just before starting partman, except that it
> > complains about /dev/hda1 instead of /dev/sda2.
>
> Does the installer by default use any swap partition it finds? I did not
> enable swap (hardly needed with that much RAM), but wasn't sure if d-i
> might auto configure it when finding a swap partition.

It should generally not use activate swap until after partitioning is done.
I did not see any indication of swap activation in your syslog, so I don't 
think *that* was the problem in your case.

> > If I then switch to a debug shell and do 'fdisk -l /dev/hda', I see
> > that - despite the error message - the partition table *has* been
> > changed, and if I check 'free' I see that swap is disabled. So AFAICT
> > your action to write the partition table again from fdisk was probably
> > redundant.
>
> I don't think so. I checked in the shell if /proc/partitions (did not
> know about fdisk -l) matched my expectations and it had the new setup
> for /dev/sdb but not for /dev/sda.

Hmm. I should probably have checked /proc/partitions as well. It's quite 
possible that fdisk shows the "changed but uncommitted" state. That would 
explain the corrupted dialog I mentioned in another post. And in later 
tests I noticed that fdisk does explicitly say that the layout has changed 
if I follow your workaround after an error.

> Nothing special. I think I dropped out of the standard sequence because
> I tried to get english texts with a german keyboard. I know this is bad
> for the localization but I often find myself translating back to english
> to be able to understand german messages.

That's something that's fully supported, especially after some very recent 
improvements in localechooser. Just select English as language, Germany as 
country and then any keyboard you like.

> > Some wild theories:
> > 1) this is a libparted bug; somehow it manages to confuse itself about
> > the state of the disk (busy or not busy)
>
> So far this is my guess. I think you showed that it is not (3). I would
> think that (2) also does not apply, since fdisk immediately got the
> tables reloaded. Perhaps I should try a few more times to see if this is
> reliable. I don't see how (4) could apply - the ext4 on /dev/sda1 was
> not mounted and what else should keep the disk busy? An MD or LVM
> device, sure, but nothing like that was configured.

I agree. At that point you hadn't yet started on RAID/LVM configuration, 
and nothing else was active or it would have shown in the logs in some 
way.

I doubt the cause was swap in your case. It looks like something internal 
between libparted and the kernel to me. I think that my deliberate 
activation of swap just happens to create a similar timing or queueing 
issue.

Thanks for the replies.



Reply to: