Re: SATA+ IDE DVD-Writer crash, and missing /dev/fd0
"J. Grant" <jg@jguk.org> writes:
> [please include my email address in any replies]
>
> Hi,
> Thanks for your help, its working, read on for the details and one
> final question.
>
> testing, and unstable both have the same kernel in "stable" which am
> already running:
>
> http://packages.debian.org/unstable/base/kernel-image-2.6-k7
There is also a 2.6.10 and 2.6.11. The kernel-image-2.6-* will at some
point point to those newer versions.
>>> would a newer kernel use something other than ide-scsi for SATA drive
>>> access? I am not sure how my root would be mountable if I remove
>>> ide-scsi from initrd, or if etch/sid remove ide-scsi from their initrd.
>> SATA never used ide-scsi.
>
> ok, I will try and remove it. initrd.img-2.6.8-2-k7 contains:
>
> # cat loadmodules
> modprobe -k vesafb > /dev/null 2>&1
> modprobe -k fbcon 2> /dev/null
> modprobe -k unix 2> /dev/null
> modprobe -k sata_via
> modprobe -k sg
> modprobe -k sd_mod
> modprobe -k ide-scsi
> modprobe -k sr_mod
>
>
> What is the -k mode? This is not listed on any man page. or is the
> initrd modprobe a different program?
Beats me.
> are sg, sd_mod and sr_mod not also for scsi? What do they do in
> particular please? I see details of sr_mod and sg being used for "cdrom"
> when booting up, whereas sd_mod is used for "disc".
sg is for scsi generic. Only needed to burn with a scsi CD burner
afaik. sr_mod is the normal scsi CDROM support iirc.
sd_mod is for scsi disk. You need that for the SATA.
> This is how I mounted it, but I could not write to it, it said the
> cramfs file was read-only. Is there a doc on how I can modify the initrd?
cramfs can't be altered, only created. It is better to use mkinitrd
though to recreate the image the same way it was originaly created. If
you configure mkinitrd correct the next kernel-image you install will
automatically get the initrd build right.
> # cdrecord dev=ATA: -scanbus
> Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004
> J�g Schilling
> NOTE: this version of cdrecord is an inofficial (modified) release of
> cdrecord
> and thus may have bugs that are not present in the original version.
> Please send bug reports and support requests to
> <cdrtools@packages.debian.org>.
> The original author should not be bothered with problems of this
> version.
>
> cdrecord: Warning: Running on Linux-2.6.8-2-k7
> cdrecord: There are unsettled issues with Linux-2.5 and newer.
> cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
> cdrecord: Warning: Linux-2.6.8 introduced incompatible interface changes.
> cdrecord: Warning: SCSI transport does no longer work for suid root
> programs.
> cdrecord: Warning: if cdrecord fails, try to run it from a root account.
> scsidev: 'ATA:'
> devname: 'ATA'
> scsibus: -1 target: -1 lun: -1
> Warning: Using badly designed ATAPI via /dev/hd* interface.
> Linux sg driver version: 3.5.27
> Using libscg version 'schily-0.8'.
> scsibus0:
> 0,0,0 0) '_NEC ' 'DVD_RW ND-2500A ' '1.06' Removable CD-ROM
> 0,1,0 1) *
> 0,2,0 2) *
> 0,3,0 3) *
> 0,4,0 4) *
> 0,5,0 5) *
> 0,6,0 6) *
> 0,7,0 7) *
>
>
> Is there a fix which will work as a normal user?
Since you are not using the SCSI transport (which was the point of all
this) you are not affected by this.
I've burned tons of dvds this way and never had a problem.
> I used growisofs and that burned fine! :)
>
> btw, is there a way I can burn in "verified" mode? I would like the
> program to read back each sector at the end and check it matches what
> was burnt etc.
>
> Kind regards
> JG
I use the following:
export NUM=1; ( echo "dvd$NUM"; find dvd$NUM -type f -exec ls -ld "{}" \; ; ) >>DVD-list; mkisofs -v -R -J -U -V "data - DVD$NUM" -o dvd$NUM.iso dvd$NUM && cdrecord dev=ATA:1,0,0 -v speed=4 fs=64m -eject driveropts=burnfree -dao dvd$NUM.iso && eject -t && ( cd dvd$NUM; find . -type f -exec md5sum "{}" \; ; cd ..; ) | ( mount /cdrom && cd /cdrom && md5sum -c -v; cd; umount /cdrom ); eject
This makes the iso, burns it and compares the md5sum of all files
against the original.
MfG
Goswin
Reply to: