Re: Debconf console-setup fails in Ubuntu Lucid
> Hi again! > > I have a problem setting the console-setup data to the correct values via > debconf. > > On row 85 i fai.log, task_debconf is called and sets all values as according > to the file > in debconf/LANG_SWEDISH. (I guess, at least) > Check back with your fai.log, I think it should tell (or attach fai.log). > Then on row 190 fai fetches package console-setup and on row 341 it replaces > and > unpacks the package. Then on row 461 it says "Setting up console-setup (1.34 > ...) > > Then on row 496: '$::Options::="--force-confold" install apt apt-utils > cfengine2 console-setup ...' > > I have some locales settings in the same debconf-file and they get set as > intended, > setting the locale to sv_SE.UTF-8 and all is well. > > The debconf-data for console-setup, however, seems to fall back to default > settings (us, Uni1, USA) > instead of (se, Lat15, SWEDEN). > > Any ideas what might go wrong? I didn't attach the files with the data since > they're on a > virtual machine inaccessible to me right now, but if you require them, i'll > give it a shot. > I don't know for sure about the console-* stuff in Ubuntu (Lucid), but most likely there is something wrong in your debconf/LANG_SWEDISH file. debconf is pretty picky about spacing and at which points you use tabs/spaces I think. For one thing, attaching debconf/LANG_SWEDISH could aid us in helping you debug this; on the other hand, it would be useful if you could check the debconf setting in the running client (using debconf-get-selections and grep) and see whether they match what you specified in LANG_SWEDISH. Best, Michael pgp2eMlLshBzg.pgp Description: PGP signature
Re: Still puzzled by setup-storage
Michael Tautschnig a écrit : Michael Tautschnig a écrit : [...] The much nicer approach is introducing something like preserve_lazy:1 (a tribute to lazyformat...; but hints for better names are welcome) which causes behaviour exactly as you described. Shouldn't be too much of a hassle, but I cannot tell whether it'll be done in a day or a week. Now that one took effectively nearly three months... Sorry for the delay. I've added a patch to the experimental builds, it's in version 3.3.4~beta1+experimental2. Testing of the new preserve_lazy option is much appreciated. Looks like I'm the first one again :-) . It works as expected on a partitionless disk, but fails if the LVM volume already exists (I just tried to install again the same host) : although setup-storage claims that '(volume) will be preserved', it runs parted to create the volume group. Debug log is at http://paste.debian.net/65875/. Unfortunately, I was too busy recently and didn't manage to fix it quick enough: The paste has timed out/is lost. Nicolas, could you do another try and paste the logs again? Sure, I've sent the same log again on http://paste.debian.net/67978/ -- Nicolas
Author network management books-Packt Publishing.
Hi Everybody, I am writing to you for Packt Publishing, the publishers of computer related books. We are planning to extend our catalogue of books on Open Source System and Network Administration softwares & are currently inviting experts to write for us. So, if you love FAI and fancy writing a book, please write to us with your book ideas at aut...@packtpub.com. Even if you don't have a book idea and are simply interested in writing, we are still keen to hear from you. More details about the opportunity can be read at: http://authors.packtpub.com/content/calling-open-source-system-and-network-administration-experts-write-packt Thanks Kshipra Singh Author Relationship Manager Packt Publishing www.PacktPub.com Skype: kshiprasingh15 Twitter: http://twitter.com/kshipras Interested in becoming an author? Visit http://authors.packtpub.com for all the information you need about writing for Packt.
Re: resizing an lvm volume with setup-storage
Michael Tautschnig a écrit : I believe resizing of logical volumes with ext2/ext3 should work as of 3.3.5+experimental1; for the moment, resize2fs will *not* be used on normal partitions as I'd need to take huge pains to make that work reliably, because resizing of the underlying partition cannot be done using parted *without* resizing the filesystem as well. Adding support for this is scheduled for some later release of parted (see first Q in resizing section of http://www.gnu.org/software/parted/faq.shtml). I'm afraid it doesn't, fai fails in task partition. fai.log is at http://paste.debian.net/68000/. I don't understand the difference you make here between "the underlying partition" and the "filesystem" : AFAIK we only need to resize the LVM volume, which has nothing to do with parted, and the filesystem. The volume group does not need to be resized. I surely missed something... -- Nicolas
Re: resizing an lvm volume with setup-storage
> Michael Tautschnig a écrit : > >I believe resizing of logical volumes with ext2/ext3 should work as of > >3.3.5+experimental1; for the moment, resize2fs will *not* be used on normal > >partitions as I'd need to take huge pains to make that work reliably, because > >resizing of the underlying partition cannot be done using parted *without* > >resizing the filesystem as well. Adding support for this is scheduled for > >some > >later release of parted (see first Q in resizing section of > >http://www.gnu.org/software/parted/faq.shtml). > > > > I'm afraid it doesn't, fai fails in task partition. fai.log is at > http://paste.debian.net/68000/. > I'll look into it... > I don't understand the difference you make here between "the > underlying partition" and the "filesystem" : AFAIK we only need to > resize the LVM volume, which has nothing to do with parted, and the > filesystem. The volume group does not need to be resized. I surely > missed something... > Oh, I believe I've mixed too many things in there. No, for LVM all this partition stuff doesn't matter and using resize2fs is just fine. It's just that I thought it would also be useful to use resize2fs for partitions with ext2/ext3, and not only for LVM. But that doesn't quite work (yet). And not just because of setup-storage being buggy... Best, Michael pgpH1XRbJihIS.pgp Description: PGP signature
Re: resizing an lvm volume with setup-storage
> > Michael Tautschnig a écrit : > > >I believe resizing of logical volumes with ext2/ext3 should work as of > > >3.3.5+experimental1; for the moment, resize2fs will *not* be used on normal > > >partitions as I'd need to take huge pains to make that work reliably, > > >because > > >resizing of the underlying partition cannot be done using parted *without* > > >resizing the filesystem as well. Adding support for this is scheduled for > > >some > > >later release of parted (see first Q in resizing section of > > >http://www.gnu.org/software/parted/faq.shtml). > > > > > > > I'm afraid it doesn't, fai fails in task partition. fai.log is at > > http://paste.debian.net/68000/. > > > > I'll look into it... > In this case, the problem is somewhat unrelated: The partitions don't seem to fit on disk in this way. That is, there isn't sufficient space for 512 * 1024 * 1024 bytes before sda2. Was that layout created using setup-storage? Probably yes. What I do suspect is some rounding issue, and, well this is the culprit: The partition has been created such as to end at a cylinder boundary, which is considered for the final disk layout, but not for intermediate checks. I'll try to fix this ASAP. Best, Michael pgpdY2VeoVqw5.pgp Description: PGP signature
Re: resizing an lvm volume with setup-storage
> > > Michael Tautschnig a écrit : > > > >I believe resizing of logical volumes with ext2/ext3 should work as of > > > >3.3.5+experimental1; for the moment, resize2fs will *not* be used on > > > >normal > > > >partitions as I'd need to take huge pains to make that work reliably, > > > >because > > > >resizing of the underlying partition cannot be done using parted > > > >*without* > > > >resizing the filesystem as well. Adding support for this is scheduled > > > >for some > > > >later release of parted (see first Q in resizing section of > > > >http://www.gnu.org/software/parted/faq.shtml). > > > > > > > > > > I'm afraid it doesn't, fai fails in task partition. fai.log is at > > > http://paste.debian.net/68000/. > > > > > > > I'll look into it... > > > > In this case, the problem is somewhat unrelated: The partitions don't seem to > fit on disk in this way. That is, there isn't sufficient space for 512 * 1024 > * > 1024 bytes before sda2. > > Was that layout created using setup-storage? Probably yes. What I do suspect > is > some rounding issue, and, well this is the culprit: The partition has been > created such as to end at a cylinder boundary, which is considered for the > final > disk layout, but not for intermediate checks. > > I'll try to fix this ASAP. > Well, it's a bit of a problem to fix this in setup-storage: The experimental version nowadays creates partitions that end in sector boundaries, but previous versions incl. mainline make partitions end in cylinder boundaries (on msdos disk labels). As sizes are rounded downwards, those 512MiB ended up being only 534610944B; using the new sector-alignment it would be 536870912B, which doesn't fit in the smaller free space. If that system is just a test server, it's probably best to drop the preserve* stuff for a moment and update sizes. If not, try 509 instead of 512, that should be fine. Thanks a lot, Michael pgpHCWcCIL2Dg.pgp Description: PGP signature
Re: resizing an lvm volume with setup-storage
In this case, the problem is somewhat unrelated: The partitions don't seem to fit on disk in this way. That is, there isn't sufficient space for 512 * 1024 * 1024 bytes before sda2. Was that layout created using setup-storage? Probably yes. What I do suspect is some rounding issue, and, well this is the culprit: The partition has been created such as to end at a cylinder boundary, which is considered for the final disk layout, but not for intermediate checks. My mistake, sorry. I built the filesystem with setup-storage, using version FAI version 3.3.4 and for sda1 a size of '512', with no unit. And then ran 3.3.5-experimental2 to resize /usr, with the same size of '512' for sda1, which seems to give a different result. I have done it again using a size of 512MiB, and it works as expected: the volume is resized, but the filesystem is not. -- Nicolas
Re: resizing an lvm volume with setup-storage
> > > > >In this case, the problem is somewhat unrelated: The partitions don't seem to > >fit on disk in this way. That is, there isn't sufficient space for 512 * > >1024 * > >1024 bytes before sda2. > > > >Was that layout created using setup-storage? Probably yes. What I do suspect > >is > >some rounding issue, and, well this is the culprit: The partition has been > >created such as to end at a cylinder boundary, which is considered for the > >final > >disk layout, but not for intermediate checks. > > > My mistake, sorry. > > I built the filesystem with setup-storage, using version FAI version > 3.3.4 and for sda1 a size of '512', with no unit. > And then ran 3.3.5-experimental2 to resize /usr, with the same size > of '512' for sda1, which seems to give a different result. > > I have done it again using a size of 512MiB, and it works as > expected: the volume is resized, but the filesystem is not. > Huch? Why is that expected behavior? Shouldn't everything be resized? Could you paste the logs? Thanks, Michael pgpZk4UzhdyAL.pgp Description: PGP signature
Re: resizing an lvm volume with setup-storage
Michael Tautschnig a écrit : In this case, the problem is somewhat unrelated: The partitions don't seem to fit on disk in this way. That is, there isn't sufficient space for 512 * 1024 * 1024 bytes before sda2. Was that layout created using setup-storage? Probably yes. What I do suspect is some rounding issue, and, well this is the culprit: The partition has been created such as to end at a cylinder boundary, which is considered for the final disk layout, but not for intermediate checks. My mistake, sorry. I built the filesystem with setup-storage, using version FAI version 3.3.4 and for sda1 a size of '512', with no unit. And then ran 3.3.5-experimental2 to resize /usr, with the same size of '512' for sda1, which seems to give a different result. I have done it again using a size of 512MiB, and it works as expected: the volume is resized, but the filesystem is not. Huch? Why is that expected behavior? Shouldn't everything be resized? Could you paste the logs? http://paste.debian.net/68014/ I really misunderstood your previous mail, where you said "resize2fs will *not* be used on normal partitions". I see you're using resize2fs in this case, but it fails. -- Nicolas
Re: resizing an lvm volume with setup-storage
> Michael Tautschnig a écrit : > >>>In this case, the problem is somewhat unrelated: The partitions don't seem > >>>to > >>>fit on disk in this way. That is, there isn't sufficient space for 512 * > >>>1024 * > >>>1024 bytes before sda2. > >>> > >>>Was that layout created using setup-storage? Probably yes. What I do > >>>suspect is > >>>some rounding issue, and, well this is the culprit: The partition has been > >>>created such as to end at a cylinder boundary, which is considered for the > >>>final > >>>disk layout, but not for intermediate checks. > >>> > >>My mistake, sorry. > >> > >>I built the filesystem with setup-storage, using version FAI version > >>3.3.4 and for sda1 a size of '512', with no unit. > >>And then ran 3.3.5-experimental2 to resize /usr, with the same size > >>of '512' for sda1, which seems to give a different result. > >> > >>I have done it again using a size of 512MiB, and it works as > >>expected: the volume is resized, but the filesystem is not. > >> > > > >Huch? Why is that expected behavior? Shouldn't everything be resized? Could > >you > >paste the logs? > > http://paste.debian.net/68014/ > > I really misunderstood your previous mail, where you said "resize2fs > will *not* be used on normal partitions". > I see you're using resize2fs in this case, but it fails. > Err, I should have looked at the resize2fs man page more closely. I somehow had assumed that 512 byte sectors was the default. Added the necessary "s" as unit in 3.3.5+experimental3. Could you please retry and report back whether it's fixed? Thanks a lot, Michael pgpGMEhL8u8yG.pgp Description: PGP signature
Re: resizing an lvm volume with setup-storage
In this case, the problem is somewhat unrelated: The partitions don't seem to fit on disk in this way. That is, there isn't sufficient space for 512 * 1024 * 1024 bytes before sda2. Was that layout created using setup-storage? Probably yes. What I do suspect is some rounding issue, and, well this is the culprit: The partition has been created such as to end at a cylinder boundary, which is considered for the final disk layout, but not for intermediate checks. My mistake, sorry. I built the filesystem with setup-storage, using version FAI version 3.3.4 and for sda1 a size of '512', with no unit. And then ran 3.3.5-experimental2 to resize /usr, with the same size of '512' for sda1, which seems to give a different result. I have done it again using a size of 512MiB, and it works as expected: the volume is resized, but the filesystem is not. Huch? Why is that expected behavior? Shouldn't everything be resized? Could you paste the logs? http://paste.debian.net/68014/ I really misunderstood your previous mail, where you said "resize2fs will *not* be used on normal partitions". I see you're using resize2fs in this case, but it fails. Err, I should have looked at the resize2fs man page more closely. I somehow had assumed that 512 byte sectors was the default. Added the necessary "s" as unit in 3.3.5+experimental3. Could you please retry and report back whether it's fixed? You will need one more try, as resize2fs is still complaining: (CMD) resize2fs /dev/vg0/usr 16777216s 1> /tmp/Hdv5kRmDAd 2> /tmp/FCrWPAlXCo Executing: resize2fs /dev/vg0/usr 16777216s Command resize2fs /dev/vg0/usr 16777216s had exit code 1 (STDERR) resize2fs 1.41.11 (14-Mar-2010) (STDERR) Please run 'e2fsck -f /dev/vg0/usr' first. The full log is at http://paste.debian.net/68019/. -- Nicolas
Re: resizing an lvm volume with setup-storage
> > >In this case, the problem is somewhat unrelated: The partitions don't > >seem to > >fit on disk in this way. That is, there isn't sufficient space for 512 * > >1024 * > >1024 bytes before sda2. > > > >Was that layout created using setup-storage? Probably yes. What I do > >suspect is > >some rounding issue, and, well this is the culprit: The partition has > >been > >created such as to end at a cylinder boundary, which is considered for > >the final > >disk layout, but not for intermediate checks. > > > My mistake, sorry. > > I built the filesystem with setup-storage, using version FAI version > 3.3.4 and for sda1 a size of '512', with no unit. > And then ran 3.3.5-experimental2 to resize /usr, with the same size > of '512' for sda1, which seems to give a different result. > > I have done it again using a size of 512MiB, and it works as > expected: the volume is resized, but the filesystem is not. > > >>>Huch? Why is that expected behavior? Shouldn't everything be resized? > >>>Could you > >>>paste the logs? > >>http://paste.debian.net/68014/ > >> > >>I really misunderstood your previous mail, where you said "resize2fs > >>will *not* be used on normal partitions". > >>I see you're using resize2fs in this case, but it fails. > >> > > > >Err, I should have looked at the resize2fs man page more closely. I somehow > >had > >assumed that 512 byte sectors was the default. Added the necessary "s" as > >unit > >in 3.3.5+experimental3. Could you please retry and report back whether it's > >fixed? > You will need one more try, as resize2fs is still complaining: > > (CMD) resize2fs /dev/vg0/usr 16777216s 1> /tmp/Hdv5kRmDAd 2> /tmp/FCrWPAlXCo > Executing: resize2fs /dev/vg0/usr 16777216s > Command resize2fs /dev/vg0/usr 16777216s had exit code 1 > (STDERR) resize2fs 1.41.11 (14-Mar-2010) > (STDERR) Please run 'e2fsck -f /dev/vg0/usr' first. > > The full log is at http://paste.debian.net/68019/. > Could you briefly hack a "-f" to the resize2fs calls in Commands.pm? The man page doesn't quite tell whether this will override this e2fsck requirement; if not, we'll really need to do so, which might be pretty time consuming. Thanks, Michael pgp0ktfseL2YV.pgp Description: PGP signature
Re: resizing an lvm volume with setup-storage
In this case, the problem is somewhat unrelated: The partitions don't seem to fit on disk in this way. That is, there isn't sufficient space for 512 * 1024 * 1024 bytes before sda2. Was that layout created using setup-storage? Probably yes. What I do suspect is some rounding issue, and, well this is the culprit: The partition has been created such as to end at a cylinder boundary, which is considered for the final disk layout, but not for intermediate checks. My mistake, sorry. I built the filesystem with setup-storage, using version FAI version 3.3.4 and for sda1 a size of '512', with no unit. And then ran 3.3.5-experimental2 to resize /usr, with the same size of '512' for sda1, which seems to give a different result. I have done it again using a size of 512MiB, and it works as expected: the volume is resized, but the filesystem is not. Huch? Why is that expected behavior? Shouldn't everything be resized? Could you paste the logs? http://paste.debian.net/68014/ I really misunderstood your previous mail, where you said "resize2fs will *not* be used on normal partitions". I see you're using resize2fs in this case, but it fails. Err, I should have looked at the resize2fs man page more closely. I somehow had assumed that 512 byte sectors was the default. Added the necessary "s" as unit in 3.3.5+experimental3. Could you please retry and report back whether it's fixed? You will need one more try, as resize2fs is still complaining: (CMD) resize2fs /dev/vg0/usr 16777216s 1> /tmp/Hdv5kRmDAd 2> /tmp/FCrWPAlXCo Executing: resize2fs /dev/vg0/usr 16777216s Command resize2fs /dev/vg0/usr 16777216s had exit code 1 (STDERR) resize2fs 1.41.11 (14-Mar-2010) (STDERR) Please run 'e2fsck -f /dev/vg0/usr' first. The full log is at http://paste.debian.net/68019/. Could you briefly hack a "-f" to the resize2fs calls in Commands.pm? The man page doesn't quite tell whether this will override this e2fsck requirement; if not, we'll really need to do so, which might be pretty time consuming. It does override the e2fsck requirement, resize2fs seems ok, but the result is well, unexpected :-) : Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg0-usr6159800 -1278720 7123948 - /target/usr After the end of the installation, the partition is still 6G wide. -- Nicolas
