On 4 May 2006 at 12:03, Steffen Winterfeldt wrote:

yast & checkmedia show you the md5sum of the final iso, which, given the current state of cryptography and computing power can not be stored in the iso itself, (...)

I always wondered where K3B finds the checksum to check an ISO image against... "Normal" images (by mkisofs) don't seem to have such a checksum, do they? Is there a kind of standard? Regards, Ulrich

On Thu, 2006-05-04 at 12:12 +0200, Ulrich Windl wrote:

On 4 May 2006 at 12:03, Steffen Winterfeldt wrote:

...

yast & checkmedia show you the md5sum of the final iso, which, given the current state of cryptography and computing power can not be stored in the iso itself, (...)

I always wondered where K3B finds the checksum to check an ISO image against...

It doesn't get it from anywhere, it creates one from the iso file that -you- are supposed to check against the one supplied by the maker of the iso. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On Thu, May 04, 2006 at 12:03:56PM +0200, Steffen Winterfeldt wrote:

On Thu, 4 May 2006, houghi wrote:

...

SUSE uses tagmedia to check the media. I used the following command (and outcome) houghi@penne : tagmedia --md5 --pad 150 --check \ ~/iso/10.1_RC3/DVD_DIR/SUSE-10.1-0-DVD.iso md5sum=99b7d0c508d213aa0c9ab6edfad56ef1 pad=150 check=1

tagmedia shows you the tags stored in the iso.

It also places them there. root@penne : tagmedia usage: tagmedia [options] iso Add/remove tags to SUSE installation media.

...

However when I boot, YaST is looking for: 508ed5a962cc236da9e141df99c33386

yast & checkmedia show you the md5sum of the final iso, which, given the current state of cryptography and computing power can not be stored in the iso itself, so the md5sum tagmedia stores is _not_ identical to the md5sum of the iso. See docs in the checkmedia package.

I looked at /usr/share/doc/packages/checkmedia/README and what I think is happening is that the pad=150 makes it so that the MD5SUM itself is not also calculated

...

What am I doing wrong?

This was the most important question.

...

The next thing is when I do a`checkmedia ~/iso/10.1_RC3/DVD_DIR/SUSE-10.1-0-DVD.iso` I get: not an iso

I'd say you don't have read permissions for that file.

I DO have read permission. I have even tried making it the same permission as the SUSE iso and still get the same answer. So what must I do to get YaST look for the same MD5SUM as there I place on the ISO. You tell me that it is not possible with the current calculation power. How does YaST then look for it? How is the MD5SUM placed on the ISO? houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On Thu, May 04, 2006 at 05:22:15PM +0200, Steffen Winterfeldt wrote:

Try strace if you don't believe me.

It is not so much as not believing you. It is wanting to know how to get it done correctly. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On 5 May 2006 at 4:20, houghi wrote:

I would love to have the tagmedia included into makeSUSEdvd, but I have NO idea how to do that. I can't read perl. :-(

Actually it's a lot like C, and I use it where I used C before. I basically learned (the essentials of) Perl in one week-end using some O'Reilly book. I prefer Perl ove shell scripts a lot, because it has much more power, not to talk of the debugger. Documentation ("man perlfunc" just for example) is quite good. Regards Ulrich

On Fri, May 05, 2006 at 08:58:12AM +0200, Ulrich Windl wrote:

On 5 May 2006 at 4:20, houghi wrote:

...

I would love to have the tagmedia included into makeSUSEdvd, but I have NO idea how to do that. I can't read perl. :-(

Actually it's a lot like C, and I use it where I used C before. I basically learned (the essentials of) Perl in one week-end using some O'Reilly book.

And you think that I understand C? :-)

I prefer Perl ove shell scripts a lot, because it has much more power, not to talk of the debugger. Documentation ("man perlfunc" just for example) is quite good.

I know it has a lot more power. It is just that I can't do it. I am not even good at Bash. :-) houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On Fri, May 05, 2006 at 02:32:34PM +0200, Steffen Winterfeldt wrote:

...

I know it has a lot more power. It is just that I can't do it. I am not even good at Bash. :-)

perl comes with an extensive amount of documentation. Try 'man perl' for an overview. And it is a language that is easy to get started with.

I tried it and I just can't get the hang of it. 'man perl' confuses me more then that it helps me. It is me that can not do it. Some people are good at perl, I am good at thinking up solutions for people who know even less about SUSE or Linux then I do. I am also a person who just has to type in and see what happens, instead of reading and realy learning it. I never could learn from a book and I doubt that will change. So what I mostly do is social engineer my code together. :-) e.g. you see a HOWTO like http://en.opensuse.org/Making_a_DVD_from_CDs#Manually_build_a_DVD_from_the_C... and that you put in a bash script. Then I started to put in a "for" for the booting and copying and started to make it more generic. A bit later added some features. And all this thanks to the many people contributing and sending me correcting code. Thanks. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

On Fri, May 05, 2006 at 04:12:10PM +0200, Peter Jakobi wrote:

The Good:

Not for me.

- saying 1 means there are many idiomatic conventions to use Perl. Say just rewrite a C program 1:1 in perl, upto C's for and while statements, and your convention for translation a case cascade.

I don't rewrite C, becaue I can't do C.

Say just rewrite a shell script using awk.

I can't do awk either.

In both cases, perl's syntax allows you to retain most of the syntactic and semantic structure of say C or AWK. Perl even supports awk's BEGIN blocks, so you've to peek that the #! line on top to be sure you're reading perl...

That is nice. Well, if you know what people are talking about. I don't know what a BEGIN block is.

Or lisp. Perl has lists, and map (plus shortcuts like pop,unshift, grep, ...). cdr is missing, but you just use shift.

Chnese to me. I don't do Lisp.

Lambda objects are function refs, etc. Everything's there, except the visual appeal of being able to have a syntactically necessary lines finishing with a block of 20+ closing parantheses.

Sounds interesting. Although I have no idea what it means.

Saner persons than RMS however cite this as the sole reason to avoid lisp :).

I heard him speak unfortunatly at FOSDEM. Everybody is saner then RMS. After listening to him I had an urge to walk into a store, buy XP Pro and install it.

perl baby talk's fine.

Or a decide later an idiomatic open or die stanza followed by a schwartzian transform-resort of file data. What on the commandline would be something like map|sort|map. Functional programming and lisp also comes to mind.

Uhm. OK. (Or as they say in Germany "Ich verstehe nur Bahnhof."

- obfuscation is easy. also unintentional obfuscation. So self-discipline is a bit more important than in more restrictive - or crippled - environments elsewhere.

For me reading somebody elses bash code looks already as if it was obfuscationized code.

- perl5 has support to create your own OO-"Language" on top of it. However it is decidedly no object-oriented language. [ok, this is opionated, but unless one has a SINGLE RIGHT one way to use e.g. inheritance and overload my parent's functions within a well-defined oo interface, the language just isn't oo. Just like C. Not if every one develops his/her own OO inheritance conventions. Heck, you can never be sure of object itself: does the modul I'd like to reuse use a scalar or a blessed hash as base for his objects??

Saying1 vs. Perl5 = 1 : 0, Perl5 standing, but with hole shot in foot.]

Python wins here, as well as that rumoured new language to be called perl 6. being able to _BREAK_ any perl5 syntactic rules.

Well, I don't do Python either.

...

Then I started to put in a "for" for the booting and copying and started to make it more generic. A bit later added some features.

Which is just fine when using perl for small, single-authored scripts...

Sure it is, if you know what you are doing and know perl. I am sure my code would be better written in perl. If I would understand perl, I would have just taken create_package_descr and edited it. It would have been a lot easier, because makeSUSEdvd is nothing more then a wrap around it. It would be also a lot easier to include tagmedia in it, instead of leaving it as a seerate program. However, I am not a programmer, nor will I ever be one. If at most I am a mediocre scriptwriter. Again, perl will be a great langage, it is just not for me. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau

houghi wrote: ...

#TAGMEDIA : Add MD5SUM to the iso if tagmedia is available. TAGMEDIA () { if [ -e `type -p tagmedia` ] then

... Replace if [ -e `type -p tagmedia` ] then by if type -p tagmedia &>/dev/null; then Will avoid "type" giving an error message on stderr when tagmedia is not found in the PATH ;) (type -p returns 1 (error) when it cannot find and 0 (ok) when it can find what is specified behind it) cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels

On Fri, 5 May 2006, houghi wrote:

On Thu, May 04, 2006 at 01:54:48AM +0200, houghi wrote:

...

SUSE uses tagmedia to check the media. I used the following command (and outcome) houghi@penne : tagmedia --md5 --pad 150 --check \ ~/iso/10.1_RC3/DVD_DIR/SUSE-10.1-0-DVD.iso md5sum=99b7d0c508d213aa0c9ab6edfad56ef1 pad=150 check=1

OK. I figured out why it did not work several times and why it suddenly worked. The answer is not in the README but is in the /usr/bin/tagmedia script: # md5sum is calculated assuming all spaces in that area.

So what happend was the first time I did just `tagmedia --md5` and that was not good. I then did a `tagmedia --md5 --pad 150 --check` wwhich is the correct command, but I had not removed (all of) the tags, so it was not all spaces.

That, again, is not true either. ;-) You don't have to remove any tags or such. It is ok to re-run tagmedia with any combination of tags you want.

No idea what the --pad does, but it seems to work. The SUSE iso's have it, so why not mine. :-)

So now we are at the heart of the problem. You should have mentioned that earlier. :-) --pad=150 says to _NOT_ verify the last 150 sectors (that is, 300k) of the iso. Instead, checkmedia assumes them to be all zero without actually reading them. The reason is that many CD-drives have problems reading the last sectors of an iso. So, our CDs are created with an additional padding (= extra sectors) at the end of the iso (150 sectors, as you might have guessed at this point). You need to match the --pad given to tagmedia with what you give to mkisofs and things should be fine. If not, checkmedia will return an md5sum error. Steffen

On Fri, 5 May 2006, houghi wrote:

On Fri, May 05, 2006 at 02:22:26PM +0200, Steffen Winterfeldt wrote:

<snip>

...

You need to match the --pad given to tagmedia with what you give to mkisofs and things should be fine. If not, checkmedia will return an md5sum error.

As far as I see I don't give mkisofs anything:

You better should.

mkisofs -V $VOLID -r -J -l -allow-leading-dots -publisher "$PUBLI" -b \ "$BOOT_IMAGE/isolinux.bin" -c "$BOOT_IMAGE/boot.cat" -no-emul-boot \ -boot-load-size 4 -boot-info-table -graft-points -o $DVD_DIR/$ISO .

Oh well, it now works. Thanks for the explanation.

Steffen

On Fri, 5 May 2006, houghi wrote:

On Fri, May 05, 2006 at 02:39:13PM +0200, Steffen Winterfeldt wrote:

...

On Fri, 5 May 2006, houghi wrote:

...

On Fri, May 05, 2006 at 02:22:26PM +0200, Steffen Winterfeldt wrote:

<snip>

...

You need to match the --pad given to tagmedia with what you give to mkisofs and things should be fine. If not, checkmedia will return an md5sum error.

As far as I see I don't give mkisofs anything:

You better should.

Ah. From the manpage: To avoid problems with I/O error on the last file on the filesystem, the -pad option has been made the default.

Just to be sure, I added -pad. I also tried with -no-pad and get the same result. So now I do not know which one is the correct one to use. :-(

I would like to add that so that those peopel who have the wrong setting still are able to get it right.

So wich should I use? -pad or -no-pad. For me there is no difference, but that might not be true for everybody.

use -pad. And what exactly is 'the same result'? Steffen

--pad=150 says to _NOT_ verify the last 150 sectors (that is, 300k) of the iso. Instead, checkmedia assumes them to be all zero without actually reading them.

The reason is that many CD-drives have problems reading the last sectors of an iso.

This is bordering on nonsense, sorry. The problem is in the Linux kernel, which tries to read blocks past the end of the last recorded block on the media, resulting in endless kernel I/O errors, and a permanently disabled DMA for this IDE device (yet another serious bug). My guess is Linux doesn't set up its DMA properly and reads the disk in N-block chunks, failing miserably when the total recording size has a chunk less than size N at the end. Any teenager can work out it's going to go bust on the last chunk. When you must read problematic disk like this, turn off DMA on that drive, it usually helps. You can do this when the reading is close to the end, to avoid reading the whole disk with your computer turned into a 80186 (mouse cursor movements: sometimes). As this problem has been around for over a decade and obviously nothing has changed, the same workarounds still apply. Option 1: make the ISO filesystem several blocks too large by adding zero-filled blocks at the end. As these blocks will never be accessed by the filesystem, you're save reading all your files. It's a pain in the arse though as soon as you read the whole ISO size back, eg for making md5 comparisons. The problem is that these additonal empty blocks still belong to the filesystem, so reading the whole filesystem is like very annoying again.

So, our CDs are created with an additional padding (= extra sectors) at the end of the iso (150 sectors, as you might have guessed at this point).

Looks like SUSE has chosen option 1.

You need to match the --pad given to tagmedia with what you give to mkisofs and things should be fine. If not, checkmedia will return an md5sum error.

See, you then also need to know how many blocks to ignore at the end for your precious checksums to work out, as you can't just look it up in the filesystem's size info. Indeed, SUSE-Linux-10.1-GM-x86_64-CD1.iso ends with 150 null-blocks, which are all part of the filesystem. The downloadable file has exactly the size of the filesystem, same goes for the md5 with it. Option 2: When you burn, make sure you burn additional null blocks AFTER THE END OF THE FILESYSTEM. You can a) dd bs=2048 count=150 if=/dev/zero >>yourimage.iso, or b) cdrecord padsize=150 -pad. With growisofs, you're onto a), unless you use a pipe/stdin construction. This 150%-reliably fixes up any Linux kernel-introduced trouble. One can argue about the 150, at some stage that was definitely not enough. Since I was so fed up with this rubbish I went to 2048 and haven't had trouble since. Of course, when you (or someone else) burn on Mickeysoft, you're sunk again. Option 3: actually fix the kernel. Perhaps in 2016 ;) Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.

On 9 May 2006 at 4:32, Eberhard Moenkeberg wrote:

Hi,

On Tue, 9 May 2006, Volker Kuhlmann wrote:

...

Option 1: make the ISO filesystem several blocks too large by adding zero-filled blocks at the end.

Right. ISO-9660 says "two seconds silence" at EOM, and that is equivalent to a padding of 300 kBytes (75 frames per second of 2048 klbytes each.

This goes back to the audio CDs, right? Maybe the idea behind was not Linux kernel read ahead, but switching from emphasis to de-emphasis might take some time. Maybe also the padding is needed to lock the RPMs to the current track after a "skip track", or it helps the CD player to detect a new track in "fast forward" mode. I really do not know. Regards, Ulrich

So the current kernel still does read-ahead past the end of the device? I had reported that for SuSE 9.0 I think, and the blabla was that I would be using an uncertified DVD/CD-RW drive.

While I don't want to argue about kernel developer's knowledge, this does sound like buck-passing to me. Turning DMA off usually allows to read a few more blocks, sometimes to the end. But when turning off read-ahead (hdparm -a0) and suddenly all iso fs blocks become readable, then my finger points at the kernel, not the drive. This was SuSE 9.2.

Definitely padding the iso will help as long as noone tries raw-reading the iso back.

Ehh, I am reading ISOs back all the time and insist on continuing to do so. Ignore Eberhard and pad after the ISO when burning. Btw in SuSE 9.2 150 blocks = 300k was not enough padding for DVDs. Of course this doesn't help with disks already burnt.

That bug should be fixed in the kernel, and exactly there.

Ack. I've had Redmond-burnt CDs with 2 empty blocks after the last non-null block, and 9.2 failed to read the last file on the CD. I doubt this CD would have been unreadable under the other OS. It's probably difficult to fix because the kernel block I/O layer doesn't know anything about isofs (and mustn't - could be reiserfs on the CD), and the whole CD technology doesn't supply the information of what the last recorded block is, or something like that. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.

So if I "dd if=/dev/cdrom", will the kernel stop accessing the device when the first read error appears?

Sometimes. And some other times, it will keep on reading, on each block producing huge timeouts and "hangs". And sometimes, it will read the last block fine (cat /dev/dvdrom), but of course to get EOF, you need one more read attempt - and instead of EOF, you get a kernel panic. Admittedly this was 1997 or 98 I tink, but it was a very definite reason why I made my ISO handling scripts.

I thought every block device has a readable block limit (determined by drive firmware).

Dunno, it might not work reliably for CDs. I don't think SCSI was made for CDs, so what happens if you demand info which isn't there? From the firmware of a couldn't-care-less commodity item? But turning off read-ahead makes it work, so I don't think that's the problem. Fact is Linux doesn't hack it, whatever the exact reason. Engage workaround(s). Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.