Re: Stable release 3.4.8 available
* Julien BLACHE [Tue Jun 14, 2011 at 09:16:31PM +0200]: Michael Tautschnig m...@debian.org wrote: Works for me(TM) just fine. Well, to be honest I found that fai-vol_id would sometimes fail on my test system, that will be fixed with the next commit to experimental. But no problems with alignment or overly large partitions. That's excellent news! I've added 3.4.8 to my TODO list, I hope to find some time to run it through our standard configurations in the near future. Please report back then so we can think about possible further steps again (thanks Michael for the release mail draft). I don't want to ping the release team without 100% ack and happiness regarding a release from our side. :) thx regards, -mika- -- http://michael-prokop.at/ || http://adminzen.org/ http://grml-solutions.com/ || http://grml.org/ signature.asc Description: Digital signature
Re: Stable release 3.4.8 available
Julien BLACHE jbla...@debian.org wrote: Hi, I can provide that tomorrow; basically having an extended partition that takes all the remaining disk space should trigger the bug. Attached. Works for me(TM) just fine. Well, to be honest I found that fai-vol_id would sometimes fail on my test system, that will be fixed with the next commit to experimental. But no problems with alignment or overly large partitions. Best, Michael pgpGJ9UwJjbd9.pgp Description: PGP signature
Re: Stable release 3.4.8 available
Michael Tautschnig m...@debian.org wrote: Hi, exceptions to this rule must also be noted: [bdfc127] introduced a new feature in setup-storage, enabling user-defined partition alignment. Yet we believe that I'd have to review test the current code (and lack time to do so at the moment) but I am encountering serious issues with that code and msdos disklabels (especially extended partitions). One issue I'm seeing is the end position for the last partition exceeding the device size when that last partition is an extended partition. I'm also still doubtful of backward-compatibility with previous FAI releases, again, when it comes to msdos disklabels. I attempted to fix this, but... it wasn't exactly pretty. Modifications were made since, so if someone can say for sure that: - it is compatible with previous releases when preserving msdos disklabels; - it doesn't break in corner cases like the above; Then fine. Otherwise, that code must not go anywhere near stable. As proposed already, let's just forget about alignment and msdos disklabel. It's not worth the hassle. It works superbly with GPT, though, no issue there. I'm swamped right now, I'm afraid won't find the time to dig into this for weeks if not months, otherwise I'd have raised the issue earlier with patches :/ JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: Stable release 3.4.8 available
Hi all and Julien in particular, [...] One issue I'm seeing is the end position for the last partition exceeding the device size when that last partition is an extended partition. Would you have a disk config available, where you've seen breakage? I'd then check it... If not, could you give a slightly more verbose description of the configuration such that I could try to come up with a supposedly broken one? I'm also still doubtful of backward-compatibility with previous FAI releases, again, when it comes to msdos disklabels. I attempted to fix this, but... it wasn't exactly pretty. Modifications were made since, so if someone can say for sure that: - it is compatible with previous releases when preserving msdos disklabels; The current code should ensure this. - it doesn't break in corner cases like the above; Can't say for sure, but would be willing to work on that :-) Then fine. Otherwise, that code must not go anywhere near stable. As proposed already, let's just forget about alignment and msdos disklabel. It's not worth the hassle. I'd love to be able to say that, but it seem that people insist on using msdos. Well, maybe all we have to do is make gpt the default? Well, but that shouldn't go in stable either :-) It works superbly with GPT, though, no issue there. I'm swamped right now, I'm afraid won't find the time to dig into this for weeks if not months, otherwise I'd have raised the issue earlier with patches :/ Well, you did raise the issue earlier on anyway and did provide patches! It's just that I tried to strive for a seemingly more general and beautiful solution. But obviously beauty is in the eye of the beholder. Best, Michael pgp6Ew5EIbIkY.pgp Description: PGP signature
Re: Stable release 3.4.8 available
Michael Tautschnig m...@debian.org wrote: Hi, Would you have a disk config available, where you've seen breakage? I'd then check it... If not, could you give a slightly more verbose description of the configuration such that I could try to come up with a supposedly broken one? I can provide that tomorrow; basically having an extended partition that takes all the remaining disk space should trigger the bug. - it is compatible with previous releases when preserving msdos disklabels; The current code should ensure this. I read the patches after the FAI meeting and at first glance I had my doubts. As I haven't put it to the test, I can't be affirmative; see below, though. As proposed already, let's just forget about alignment and msdos disklabel. It's not worth the hassle. I'd love to be able to say that, but it seem that people insist on using msdos. msdos is a fscking kludge, getting that to work all the while satisfying arbitrary alignment constraints *and* being backward-compatible with previous releases doesn't seem possible. The biggest issue here is extended partitions, but then any partition with a fixed size *will* come up with a different size with the alignment code. The previous/current code cannot be emulated by setting a fixed alignment value; primary and extended partitions have very different behaviours. Anybody still using msdos disklabels and requiring aligned partitions for performance should move to GPT *YESTERYEAR*. If the storage isn't distinct from the system volume and the system firmware refuses to boot without an msdos disklabel, then use gptsync and you'll be just fine (hello HP BIOS from the 80ies). Well, maybe all we have to do is make gpt the default? Well, but that shouldn't go in stable either :-) Well, maybe we should just leave stable alone? ;) I'm swamped right now, I'm afraid won't find the time to dig into this for weeks if not months, otherwise I'd have raised the issue earlier with patches :/ Well, you did raise the issue earlier on anyway and did provide patches! It's just that I tried to strive for a seemingly more general and beautiful solution. But obviously beauty is in the eye of the beholder. msdos, beauty: pick one ;) It's really nobody's fault if msdos-related code gets ugly. Though I recently had to dig into Sizes.pm and as soon as I'll have some time to dig into that again, I'm going to send a patch to clean up a bad case of variable reuse that had me go WTF??? :) Could be a good way to keep me busy on the train this week, although not sure digging into that code in the wee hours is a good idea %) Hmm. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: Stable release 3.4.8 available
Hi,
On Donnerstag, 12. Mai 2011, Michael Prokop wrote:
We'd¹ definitely love to see that in squeeze-{backports,updates}
after some further public testing over the next few days. But the
diff is pretty large and we're not sure whether the release team
will accept this release therefore. I'll definitely ping the release
team once we consider 3.4.8 safe for inclusion from our POV.
After reading just the changelog I doubt they let it in :-) (But do try!)
But, two of the closed important bugs (from the bts) still seem worthwhile
fixing in stable... (offline atm, so I cannot look up the numbers.)
cheers,
Holger
Re: Stable release 3.4.8 available
Hi, [...] After reading just the changelog I doubt they let it in :-) (But do try!) But, two of the closed important bugs (from the bts) still seem worthwhile fixing in stable... (offline atm, so I cannot look up the numbers.) I've only now reviewed the changelog myself and indeed the number of changes is pretty large with clearly not all of them being important or serious bugs, let alone them being reported to the Debian BTS as such. Yet still almost all changes are bugfixes, only get-config-dir-http and the align-at stuff in setup-storage are new features. But then again the former is non-intrusive (it won't change anything for setups not using http) and the align-at is important for current hardware to ensure efficient operation. I think the main problem for the release team will be that the changes are so wide-spread that reviewing could be pretty painful, especially for people not into FAI. We should clearly warn the release team about that, I don't want to waste their time, let alone annoy them. We should be ready to gently lend them a hand and possibly talk them through the changes. Best regards, Michael pgpgARbZQydF2.pgp Description: PGP signature
Re: Stable release 3.4.8 available
* Michael Tautschnig [Thu May 12, 2011 at 11:30:55AM +0100]: After reading just the changelog I doubt they let it in :-) (But do try!) But, two of the closed important bugs (from the bts) still seem worthwhile fixing in stable... (offline atm, so I cannot look up the numbers.) I've only now reviewed the changelog myself and indeed the number of changes is pretty large with clearly not all of them being important or serious bugs, let alone them being reported to the Debian BTS as such. Yet still almost all changes are bugfixes, only get-config-dir-http and the align-at stuff in setup-storage are new features. But then again the former is non-intrusive (it won't change anything for setups not using http) and the align-at is important for current hardware to ensure efficient operation. I think the main problem for the release team will be that the changes are so wide-spread that reviewing could be pretty painful, especially for people not into FAI. We should clearly warn the release team about that, I don't want to waste their time, let alone annoy them. We should be ready to gently lend them a hand and possibly talk them through the changes. Seconded. :) If anyone volunteers to prepare a mail to the release team please do so and share so we can join the party. :) regards, -mika- -- http://michael-prokop.at/ || http://adminzen.org/ http://grml-solutions.com/ || http://grml.org/ signature.asc Description: Digital signature
Re: Stable release 3.4.8 available
* Holger Levsen [Tue May 10, 2011 at 07:37:31PM +0200]:
On Dienstag, 10. Mai 2011, Michael Prokop wrote:
I just uploaded a new stable release of FAI, version 3.4.8 to
Debian/unstable.
kudos!
do you plan to also upload this to squeeze-backports or squeeze-updates?
We'd¹ definitely love to see that in squeeze-{backports,updates}
after some further public testing over the next few days. But the
diff is pretty large and we're not sure whether the release team
will accept this release therefore. I'll definitely ping the release
team once we consider 3.4.8 safe for inclusion from our POV.
¹ We as in 3x Michael and Thomas, discussing the issue at the last
developer meeting. :)
regards,
-mika-
--
http://michael-prokop.at/ || http://adminzen.org/
http://grml-solutions.com/ || http://grml.org/
signature.asc
Description: Digital signature
