64-bit SCSI extensions identical to 32 bit?

[qopit]

I'm having trouble getting the 64-bit SCSI drivers in scsi-3.0.21-tinycore64,tcz
to work.  I've remastered core64.gz to include the files, but they don't seem to work.  On reboot, `fdisk -l` is empty.

When I remaster the normal 32-bit core.gz to use the files in scsi-3.0.21-tinycore.tcz (using the exact same method) the remaster works really well, so I don't think it is my remastering method.

Digging further, when I unsquash the 32-bit and 4-bit scsi extensions and compare them, they seem identical.  Below is a log of this comparison from a fresh cmdline-only core.iso boot:

tc@box:~$ tce-load -wi scsi-`uname -r`
Downloading: scsi-3.0.21-tinycore.tcz
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
scsi-3.0.21-tinycore 100% |*********************************************************************************************************************************************|  1824k  0:00:00 ETA
scsi-3.0.21-tinycore.tcz: OK
tc@box:~$ tce-load -wi scsi-`uname -r`64
Downloading: scsi-3.0.21-tinycore64.tcz
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
scsi-3.0.21-tinycore 100% |*********************************************************************************************************************************************|  1832k  0:00:00 ETA
scsi-3.0.21-tinycore64.tcz: OK
tc@box:~$ tce-load -wi squashfs-tools-4.x
Downloading: squashfs-tools-4.x.tcz
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
squashfs-tools-4.x.t 100% |*********************************************************************************************************************************************|   100k  0:00:00 ETA
squashfs-tools-4.x.tcz: OK
tc@box:~$ unsquashfs -f -d scsi_files /tmp/tce/optional/scsi-`uname -r`.tcz
Parallel unsquashfs: Using 8 processors
96 inodes (502 blocks) to write

[=============================================================================================================================================================================|] 502/502 100%
created 96 files
created 38 directories
created 0 symlinks
created 0 devices
created 0 fifos
tc@box:~$ unsquashfs -f -d scsi_files64 /tmp/tce/optional/scsi-`uname -r`64.tcz
Parallel unsquashfs: Using 8 processors
80 inodes (496 blocks) to write

[=============================================================================================================================================================================|] 496/496 100%
created 80 files
created 38 directories
created 0 symlinks
created 0 devices
created 0 fifos
tc@box:~$ diff -u -r scsi_files scsi_files64
tc@box:~$

Should these extensions be identical?  I'm not sure if I've done the remaster incorrectly (don't think so), if I've done the compare incorrectly (don't think so), or if it is just that the 64-bit extension is accidentally the same as the 32 bit one (seems unlikely?).

[curaga]

Your diff command doesn't tell you what you think

You asked it to compare files, but there exist no files with the same paths. Add the -N option to diff so that it will tell you when only one dir has a file.



As for your scsi issue, compare lsmod and dmesg outputs from the two boots.

[genec]

Consider this:

Code: [Select]

for i in tinycore tinycore64;do
  wget http://repo.tinycorelinux.net/4.x/x86/tcz/scsi-3.0.21-$i.tcz.list
  sed 's_\./usr/local/lib/modules/3.0.21-'$i'/kernel/drivers/__' scsi-3.0.21-$i.tcz.list |sort > scsi-3.0.21-$i.tcz.list.s
done
diff scsi-3.0.21-tinycore.tcz.list.s scsi-3.0.21-tinycore64.tcz.list.s


[qopit]

Aha... sorry guys.  I knew it was something dumb on my side.

After further investigation, I'm quite certain my problem was/is that the depmod for the remastering failed because I was remastering core64.gz while running a 32-bit kernel (vmlinuz vs vmlinuz64).

Trying to resolve this I found depmod's -F option which will let you specify the symbol table to use, which I thought would avoid the problem of it consulting the currently running kernel.  This led to extracting vmlinux from vmlinuz64 [1], trying to pull symbol tables out with this [2] magic:

Code: [Select]

nm -n vmlinux | grep -v '\( [aNUw] \)\|\(__crc_\)\|\( \$[adt]\)' > System.map

... that failed in a few ways ('no symbols' when experimenting with vmlinuz, bad file format when working with vmlinux), and then I realized that the depmod available in tc has no -F option anyways.

Then I realized I was spinning my wheels for hours and was out of my depth.

So... short question:  Is it possible to remaster core64.gz when running inside a 32-bit tinycore?  If so, what's the trick?

[1] http://www.ehow.com/how_12187456_vmlinux-vmlinuz.html
[2] http://lxr.free-electrons.com/source/scripts/mksysmap

[genec]

iirc, System.map is deprecated.

For alternate arch, "sudo depmod -a -b ~/core_files 3.0.21-tinycore64" instead of "sudo depmod -a -b ~/core_files" may work but quite possibly not.

[curaga]

Depmod works fine for any arch, you just need to correctly specify the kernel version.