Re: i386 and amd64 snapshots - kernel SHA256 mismatch
On Sat, 16 Oct 2010 07:09:03 +0200 roberth rob...@openbsd.pap.st wrote: On Fri, 15 Oct 2010 21:46:41 -0700 patrick keshishian pkesh...@gmail.com wrote: as this, where -- the mortal is accused to be a whiner. (...) the key words were every time this happens ... if you find an error or something strange, most likely you aren't the first to have encountered it. what's the first step? do your homework. homework comes before posting. this includes searching the mailinglist-archives. this discussion has happend before. repeating it, is what's annoying. Well it hasn't happened in ages probably since I had a bog standard router and windows when I was 16 or something but sometimes the whole file doesn't download. Does the gzip part of .tgz check the download was complete anyway as it will fail on unpack. You can also cross reference the checksums to check mirrors and so they have their uses when they're right, obviously not meaning they always need to be right. Are we talking about the sums in bsd.rd and SHA256 or just bsd.rd. Maybe a message in bsd.rd could say after the checksum incorrect message: == Note: This is likely perfectly normal for snapshots. Please do not report this to the developers. Maybe a message after install completed successfully could say: = If you have a question please check the mailing list archives at one of the following. This ensures developers can concentrate on things that matter to us all and not decide to change the language on your windows box remotely. http://marc.info ... ... Though maybe it would be better in the mail to root (maybe dmesg report section) because putting it at the end of the install tells everyone there is somewhere to ask questions and not just the ones willing to do some reading.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
Marco Peereboom wrote: On Sat, Oct 16, 2010 at 01:08:25AM +, JC Choisy wrote: That being out of the way, you got me wondering what good is any integrity check which failure is OK. It is only meant to help uptight people having some sort of false sense of integrity/security. It really is for release only because snapshots are a moving target. In my opinion the whole check is a giant waste of time because every damn time the snaps are out of sync for a reason or another people come whining to the list about something that is irrelevant. Am I correct in assuming that the code before this integrity check is not able to distinguish between release and snapshot?
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
* Scott McEachern sc...@blackstaff.ca [2010-10-16 05:31]: I sometimes see the snaps (or X) haven't been built for a few or more days, and I was just wondering why that is? plenty of possibilities. theo (or todd when it comes to X) was gone or had better stuff to do a problem with copying snaps out tree horribly broken (ok, doesn't happen, of course) ... Is the build automated, or manually run? manual If I see a snap hasn't been built for a while, I'll usually hold off on updating the source because something major might be only part way complete. I'll wait until a new snap, install (or update) it, then update the source and build. Is this silly? a bit, yeah -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
From: Theo de Raadt deraadt () cvs ! openbsd ! org Date: 2010-10-16 0:29:52 I should have actually shown how much was mismatched...and it's more than just the kernel: ---(fine details skipped)-- JC Choisy(tin...@tinono.com)@Fri, Oct 15, 2010 at 08:58:49PM +: Hi, The kernel in latest i386 and amd64 snapshots has a sha256 checksum that doesn't match what's listed in the SHA256 file. bsd.rd complains about this when trying to upgrade. This is with the snapshots of Oct. 14th With snapshots, this will happen from time to time. If people start not understanding why the install media does this check, and that failure is OK, then I will remove the code on the install media. Adjust your expectations. A hash failure can be OK. Another alternative is that I only do snapshot builds about every 2 weeks. How's that idea? As I say, adjust your expectations. A simple technique for the perplexed would be to wait for snapshots that have a matching hash. Skipping one or two snapshots is unlikely to cause cancer in laboratory animals. -- Ed Ahlsen-Girard Ft. Walton Beach FL
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
Frank Bax wrote: Marco Peereboom wrote: On Sat, Oct 16, 2010 at 01:08:25AM +, JC Choisy wrote: That being out of the way, you got me wondering what good is any integrity check which failure is OK. It is only meant to help uptight people having some sort of false sense of integrity/security. It really is for release only because snapshots are a moving target. In my opinion the whole check is a giant waste of time because every damn time the snaps are out of sync for a reason or another people come whining to the list about something that is irrelevant. Am I correct in assuming that the code before this integrity check is not able to distinguish between release and snapshot? Imagine the fungames when the snapshots work and the release does not. Do people bother to think anymore?
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
hmm, on Sat, Oct 16, 2010 at 07:09:03AM +0200, roberth said that On Fri, 15 Oct 2010 21:46:41 -0700 patrick keshishian pkesh...@gmail.com wrote: as this, where -- the mortal is accused to be a whiner. (...) the key words were every time this happens ... if you find an error or something strange, most likely you aren't the first to have encountered it. what's the first step? do your homework. homework comes before posting. this includes searching the mailinglist-archives. and FAQ entry could help in this case as well.. -f -- often the test of courage is not to die but to live.
i386 and amd64 snapshots - kernel SHA256 mismatch
Hi, The kernel in latest i386 and amd64 snapshots has a sha256 checksum that doesn't match what's listed in the SHA256 file. bsd.rd complains about this when trying to upgrade. This is with the snapshots of Oct. 14th Thanks, -jc
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
I should have actually shown how much was mismatched...and it's more than just the kernel: (SHA256) bsd: FAILED (SHA256) bsd.mp: FAILED (SHA256) bsd.rd: OK (SHA256) cd48.iso: FAILED (SHA256) cdboot: FAILED (SHA256) cdbr: FAILED (SHA256) cdemu48.iso: FAILED (SHA256) comp48.tgz: FAILED (SHA256) etc48.tgz: FAILED (SHA256) floppy48.fs: FAILED (SHA256) floppyB48.fs: FAILED (SHA256) floppyC48.fs: FAILED (SHA256) game48.tgz: FAILED (SHA256) man48.tgz: FAILED (SHA256) misc48.tgz: FAILED (SHA256) pxeboot: FAILED (SHA256) install48.iso: FAILED (SHA256) xbase48.tgz: OK (SHA256) xetc48.tgz: FAILED (SHA256) xfont48.tgz: FAILED (SHA256) xserv48.tgz: FAILED (SHA256) xshare48.tgz: FAILED JC Choisy(tin...@tinono.com)@Fri, Oct 15, 2010 at 08:58:49PM +: Hi, The kernel in latest i386 and amd64 snapshots has a sha256 checksum that doesn't match what's listed in the SHA256 file. bsd.rd complains about this when trying to upgrade. This is with the snapshots of Oct. 14th Thanks, -jc
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
I can also confirm this on 2 different US ftp servers. JC Choisy(tin...@tinono.com)@Fri, Oct 15, 2010 at 08:58:49PM +: Hi, The kernel in latest i386 and amd64 snapshots has a sha256 checksum that doesn't match what's listed in the SHA256 file. bsd.rd complains about this when trying to upgrade. This is with the snapshots of Oct. 14th Thanks, -jc
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
I should have actually shown how much was mismatched...and it's more than just the kernel: (SHA256) bsd: FAILED (SHA256) bsd.mp: FAILED (SHA256) bsd.rd: OK (SHA256) cd48.iso: FAILED (SHA256) cdboot: FAILED (SHA256) cdbr: FAILED (SHA256) cdemu48.iso: FAILED (SHA256) comp48.tgz: FAILED (SHA256) etc48.tgz: FAILED (SHA256) floppy48.fs: FAILED (SHA256) floppyB48.fs: FAILED (SHA256) floppyC48.fs: FAILED (SHA256) game48.tgz: FAILED (SHA256) man48.tgz: FAILED (SHA256) misc48.tgz: FAILED (SHA256) pxeboot: FAILED (SHA256) install48.iso: FAILED (SHA256) xbase48.tgz: OK (SHA256) xetc48.tgz: FAILED (SHA256) xfont48.tgz: FAILED (SHA256) xserv48.tgz: FAILED (SHA256) xshare48.tgz: FAILED JC Choisy(tin...@tinono.com)@Fri, Oct 15, 2010 at 08:58:49PM +: Hi, The kernel in latest i386 and amd64 snapshots has a sha256 checksum that doesn't match what's listed in the SHA256 file. bsd.rd complains about this when trying to upgrade. This is with the snapshots of Oct. 14th With snapshots, this will happen from time to time. If people start not understanding why the install media does this check, and that failure is OK, then I will remove the code on the install media. Adjust your expectations. A hash failure can be OK. Another alternative is that I only do snapshot builds about every 2 weeks. How's that idea? As I say, adjust your expectations.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
Theo de Raadt deraadt at cvs.openbsd.org writes: With snapshots, this will happen from time to time. If people start not understanding why the install media does this check, and that failure is OK, then I will remove the code on the install media. Adjust your expectations. A hash failure can be OK. Another alternative is that I only do snapshot builds about every 2 weeks. How's that idea? As I say, adjust your expectations. OpenBSD-current is most of the times an excellent quality system, better and more reliable than most other 'stable' systems. This may alter one's ability to keep his expectations where they should be. That being out of the way, you got me wondering what good is any integrity check which failure is OK. Thanks, -jc
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
OpenBSD-current is most of the times an excellent quality system, better and more reliable than most other 'stable' systems. This may alter one's ability to keep his expectations where they should be. That being out of the way, you got me wondering what good is any integrity check which failure is OK. Do you not want it to be there for official releases? How about if I remove the code now. Then 10 minutes before we make a release, we put it back in, find out that it makes the media not fit or some other issue has showed up
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
On Sat, Oct 16, 2010 at 01:08:25AM +, JC Choisy wrote: Theo de Raadt deraadt at cvs.openbsd.org writes: With snapshots, this will happen from time to time. If people start not understanding why the install media does this check, and that failure is OK, then I will remove the code on the install media. Adjust your expectations. A hash failure can be OK. Another alternative is that I only do snapshot builds about every 2 weeks. How's that idea? As I say, adjust your expectations. OpenBSD-current is most of the times an excellent quality system, better and more reliable than most other 'stable' systems. This may alter one's ability to keep his expectations where they should be. That being out of the way, you got me wondering what good is any integrity check which failure is OK. It is only meant to help uptight people having some sort of false sense of integrity/security. It really is for release only because snapshots are a moving target. In my opinion the whole check is a giant waste of time because every damn time the snaps are out of sync for a reason or another people come whining to the list about something that is irrelevant. Thanks, -jc
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
Okey dokey...now I know. Hmmm...I've followed snaps for years and always check sums...and I can't remember a time that they failed. Well no worries...I'll roll with it, thanks for the reality check. Theo de Raadt(dera...@cvs.openbsd.org)@Fri, Oct 15, 2010 at 06:29:52PM -0600: Snipped... With snapshots, this will happen from time to time. If people start not understanding why the install media does this check, and that failure is OK, then I will remove the code on the install media. Adjust your expectations. A hash failure can be OK. Another alternative is that I only do snapshot builds about every 2 weeks. How's that idea? As I say, adjust your expectations.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
Marco Peereboom slash at peereboom.us writes: It is only meant to help uptight people having some sort of false sense of integrity/security. It really is for release only because snapshots are a moving target. In my opinion the whole check is a giant waste of time because every damn time the snaps are out of sync for a reason or another people come whining to the list about something that is irrelevant. Understood and noted. I hope this didn't sound like whining. I really was just reporting on what looked like a problem in the builds. Forgive the noise.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
On 10/15/10 20:29, Theo de Raadt wrote: Another alternative is that I only do snapshot builds about every 2 weeks. How's that idea? A little off-topic, but now's as good a time as any to ask: I sometimes see the snaps (or X) haven't been built for a few or more days, and I was just wondering why that is? Is the build automated, or manually run? I see the times are usually ~2pm and ~10pm, Mountain time. If I see a snap hasn't been built for a while, I'll usually hold off on updating the source because something major might be only part way complete. I'll wait until a new snap, install (or update) it, then update the source and build. Is this silly? Don't get me wrong, I'm not complaining, I'm just wondering.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
On Fri, Oct 15, 2010 at 6:18 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: OpenBSD-current is most of the times an excellent quality system, better and more reliable than most other 'stable' systems. This may alter one's ability to keep his expectations where they should be. That being out of the way, you got me wondering what good is any integrity check which failure is OK. Do you not want it to be there for official releases? How about if I remove the code now. Then 10 minutes before we make a release, we put it back in, find out that it makes the media not fit or some other issue has showed up On one hand mortals are asked to run snapshots or -current because that's how issues are found and fixed, on the other hand -- cases such as this, where -- the mortal is accused to be a whiner. It is tough being mere mortal. --patrick
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
On Fri, Oct 15, 2010 at 6:18 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: OpenBSD-current is most of the times an excellent quality system, better and more reliable than most other 'stable' systems. This may alter one's ability to keep his expectations where they should be. That being out of the way, you got me wondering what good is any integrity check which failure is OK. Do you not want it to be there for official releases? How about if I remove the code now. Then 10 minutes before we make a release, we put it back in, find out that it makes the media not fit or some other issue has showed up On one hand mortals are asked to run snapshots or -current because that's how issues are found and fixed, on the other hand -- cases such as this, where -- the mortal is accused to be a whiner. It is tough being mere mortal. That is not our problem.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
I sometimes see the snaps (or X) haven't been built for a few or more days, and I was just wondering why that is? The person who does builds has a life. Is the build automated, or manually run? The builds are not done automated. Automated build structures don't work. The tree does not compile 100% of the time. It compiles about 98% of the time, and it varies architecture to architecture. I see the times are usually ~2pm and ~10pm, Mountain time. The base builds are done by me. It sounds like you are looking at one architecture. If I see a snap hasn't been built for a while, I'll usually hold off on updating the source because something major might be only part way complete. I'll wait until a new snap, install (or update) it, then update the source and build. Is this silly? It is very smart. By doing builds for the snapshots manually, I run into most of the build problems before other developers do. If snapshot builds are bad, I don't copy them out. Or... I try not to. The hope is that I notice. Sometimes I can't notice. I don't install them -- you guys do.
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
On Fri, 15 Oct 2010 21:46:41 -0700 patrick keshishian pkesh...@gmail.com wrote: as this, where -- the mortal is accused to be a whiner. (...) the key words were every time this happens ... if you find an error or something strange, most likely you aren't the first to have encountered it. what's the first step? do your homework. homework comes before posting. this includes searching the mailinglist-archives. this discussion has happend before. repeating it, is what's annoying.
