I double checked, and the custom kernel recognizes two separate disks, with the same contents. I've got a second box here, with a similar configuration, and I've already seen the Simpsons episode that's on TV right now, so I'll try again More soon!

Just a "me too", the mindbender v6 kernel has this same problem...box boots but recognizes none of the RAID arrays. In EM mode it mounts /dev/root.old and /dev/ram1 and of course there's no sign of the kernel modules, etc. in /lib/modules. Recovery from this state has been to remove the disks from the box, zap the partitions, and rescue it via tftp.

I double checked, and the custom kernel recognizes two separate disks, with the same contents. I've got a second box here, with a similar configuration, and I've already seen the Simpsons episode that's on TV right now, so I'll try again More soon!

Just a "me too", the mindbender v6 kernel has this same problem...box boots but recognizes none of the RAID arrays. In EM mode it mounts /dev/root.old and /dev/ram1 and of course there's no sign of the kernel modules, etc. in /lib/modules. Recovery from this state has been to remove the disks from the box, zap the partitions, and rescue it via tftp.

Woohoo, followup to self.

I think what I missed is the importance of /proc/buffalo/firmware vs. /etc/linkstation_release being in synch as noted by herrBlaschke:

herrBlaschke wrote:

what I took care was to set the content of /etc/linkstation_release in terms of PRODUCTID and BUILDDATE equivalent to the content of /proc/buffalo/firmware, running the p7r1 kernel.

Probably this /proc/buffalo/firmware is static for the p7r1-kernel and my settings in /etc/linkstation_release work for you!

Tracing through the /linuxrc execution of my box when I load either prodigy7's kernel or mindbender's kernel shows that the boot stops due to the differences between those files. I haven't yet had a chance to fix /etc/linkstation_release and test again though.

I think what I missed is the importance of /proc/buffalo/firmware vs. /etc/linkstation_release being in synch as noted by herrBlaschke:

herrBlaschke wrote:

what I took care was to set the content of /etc/linkstation_release in terms of PRODUCTID and BUILDDATE equivalent to the content of /proc/buffalo/firmware, running the p7r1 kernel.

Probably this /proc/buffalo/firmware is static for the p7r1-kernel and my settings in /etc/linkstation_release work for you!

Tracing through the /linuxrc execution of my box when I load either prodigy7's kernel or mindbender's kernel shows that the boot stops due to the differences between those files. I haven't yet had a chance to fix /etc/linkstation_release and test again though.

Cheers!

Ok, so fixing up /etc/linkstation_release got me 99% of the way to a working linkstation -- it now happily boot's prodigy7's kernel, mounts arrays, and comes up in proper operational mode but there's still some confusion on the web UI part's about the disk layout (including a divide-by-zero somewhere in the PERL modules which kept me from logging in but was easy to fix).

So indeed to get prodigy7's kernel to run I had to put the following in /etc/linkstation_release:

Code:

VERSION=3.03SUBVERSION=HDD 0.05PRODUCTID=0x00003001

BUILDDATE=2008/05/29 15:32:08

Note that it's really a 3.05 / 0x00003004 (ie, LS Pro Duo v3 running 3.05-06 firmware before kernel replacement). I'm not sure if these little lies have anything to do with the confusion in the web UI re disks (I also wasn't able to mount a USB disk, but maybe that didn't work in the stock firmware either... just tried a USB stick for kicks); I'll try and get to the bottom of it over the next few days as I have some time here and there.

I wouldn't use the webui from buffalo, if you customize the linkstation somehow. You could make more wrong than right with the webui and modified environment.

At least in my case, the whole point of just replacing the kernel with a modded one (vs. installing FreeLink, etc.) was that I wanted to keep the stock UI and functionality, but wanted some extra functionality like NFS that I was happy to manage out-of-band.

If the kernels people have built from Buffalo sources aren't good enough for that, we should probably worry in other ways

9.) Enter "/opt/etc/init.d/S56unfsd" to restart UNFS3 - this is necessary to get the changes you made in /etc/exports When you make changes in /etc/exports you always need to restart the unfs3 with "/opt/etc/init.d/S56unfsd".

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum