1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Jac4 alternative file system for data

Discussion in 'Cisco/Linksys Network Storage Devices' started by Treah, Oct 29, 2009.

  1. Treah

    Treah Addicted to LI Member

    Hey I attempted to search the thread that you posted jac about your version4 firmware but I was unable to find anything regarding this. Is the kernel in your firmware able to support ext3 on the data partition of the drive. I know it will support booting from a ext3 root file system but I was wondering if I can use ext3 on my data partition instead of ext2 or XFS. I really like ext3 over XFS because I am more familiar with it.

    Again I apologize if this has been mentioned before.
  2. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    It's a good question and I don't think it's been asked before.

    It really all depends on how /usr/sbin/rc.bootbin does the mount. In the early days when ext2 was not supported out of the box but there was a Beta firmware that did, I installed that Beta firmware and reformatted one of my drives with ext2.

    I installed my own kernel with ext2 support and switched back to the old root filesystem with Telnet/SSH mod. I could mount the ext2 hard disk myself, and the mount command recognized the file system without problems, so no need to force it. But no matter how I tried, I couldn't mount the disk in its usual location and make it visible on the network: apparently rc.bootbin DID force the file system to be whatever it thought it should be and it gave up if the file system was already mounted or if it couldn't mount it with XFS.

    I ended up simply mounting one disk under a directory inside the other one so I had only a "DISK 1" share but there was a "DISK 1/disk2" directory where I could go to the data on the second disk.

    Bottom line: you won't know until you try. You would have to reformat your data partition (partition 1) to ext3 and see if it gets mounted automatically when you restart (make sure your configuration is already set to Journaled before you reformat).

    Regardless of whether that works, the following should definitely work: Use fdisk to delete and re-create partition 1, and make it as small as you can (1 cylinder). Create a 4th partition on the space you freed up. Format partition 1 with XFS and partition 4 with ext3, then write an rc.d script to mount partition 4 (/dev/sda4 or /dev/sdb4) under a subdirectory on partition 1 (like I did). The only problem with this is that quotas probably won't work and neither will the automatic disk-full detection.

  3. Treah

    Treah Addicted to LI Member

    Ahh so its not necessarily a problem with the kernel not able to see the device but with how the nas works with the partitions internally I take it. Hmm I was hoping to try this by just converting my ext2 partition into ext3 and if it dident work reconverting it back to ext2. I know this can be done with regular linux file system tools but Im guessing they are not included in the NAS firmware package by default. I may try just porting them over. To compile programs for the NAS200 do I need to create a separate tool chain or will the default one work? I saw somewhere where it said to create one and then another place where it said that you can just compile and it works ( they were referring to the firmware not software tho). I am assuming that the answer to this is yes since its a i486 and not a i686 but I was not sure since the archs are both x86.

    FYI: I have only ever setup a different toolchain when working with 64bit and dont remember how I did it :p guess I may have some reading to do.
  4. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    Yep the kernel will see it just fine and you can mount it manually just fine too... The problem is that the on-board tools will need to understand and agree with what you want to do...

    This may be possible in theory but no, not with the onboard tools. You could take your disks out to another Linux machine or a PC with a live Linux disk of course. Either way, you should still make a backup because if something goes wrong, your files are gone...

    Both statements are more or less true. Yes, this is just a headless 486sx and it just runs Linux, and it's easy to compile programs for i486 because you won't need to cross-compile (well... not if your Linux distro is an i386 distro i.e. not specialized for i686). But the dynamic link libraries and the kernel on the NAS are getting old, and because you're not really compiling on the NAS, tools like autoconfig will mis-detect the environment and you will have to deal with a lot of details that you may not be prepared for.

    The easiest way to avoid incompatibility problems is to compile with the toolchain that's included in the source distribution but you will have to coax autoconfig into using the compiler from there instead of the default compiler on your system. The same thing goes for the linker and other tools. This will take a lot of learning. If you can figure out a sure-shot way to integrate a project with a configure script into the NAS200 source tree and run ./configure with parameters so it gets installed the right way, I would sure like to know.

    Cross-compiling is not easy, even if the target computer is based on the same computer as the host. Documentation is very scattered and it takes a lot of trial-and-error because it's possible that you end up with software that compiles just fine with a cross-compiler but doesn't work. Sorry I don't mean to discourage you, only to warn you that this may be more work than you think, at least if you do it right. Of course you can take some shortcuts like I did with dropbear: that was built inside a Tinygentoo chroot for i386 with static linking and just happens to work. But that's basically cheating...

  5. Treah

    Treah Addicted to LI Member

    LOL I never expected it to be an easy task and I still have nightmares from when I did it for 64bit. The LFS project has some details on cross compiling and I may look that up as a starting point. Its too bad we couldn't create some kinda of emulated environment like in bochs and get the native firmware to boot to test before potentially crashing our nas. I know you went thought the trouble of creating a JTAG connector me on the other hand cant understand electrical diagrams and would probably end up just soldering off something important :p. Ill keep you up to date if I can find a way to easily compile programs that works all the time.

    Ohh btw I have tried to compile new firmware once before and ended up making my nas unbootable. Since I dident open the box I got linksys to ship me a refurbished one.

    Also I have some old 486DX chips and motherboards sitting around the garage I may build a development box out of those old parts and see if i can scrounge up some old versions of the tools used for the NAS200 possibly put together my own distro. That way I could just compile stuff native and not deal with cross compile. That is if that would work of course
  6. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    There are only two things that are really significantly different from a regular emulated PC: the NAS200 has LEDs and buttons that are controlled via GPIO, and instead of a BIOS it has eCos/Redboot and Linux.

    I think it's probably possible to emulate most of a NAS200 in QEMU or similar systems; it may be necessary to work around small incompatibilities but that shouldn't take much effort.

    You were lucky (or at least sneaky). I would expect them to void the warranty if you flash it with unbootable firmware...

    Anyway, with Jac4 it's easy to test firmware before you flash it, by putting the nas200_*.bin file on a USB stick. This will only test the root file system, it will still not load the kernel in the .bin file. Maybe I'll implement this later using kexec. But for now, it should provide all the necessary functionality for most people to test firmware without risking bricking the box.

    Yes that will probably work; an emulator such as QEMU, VMware or VirtualBox would be less work, though. You will have to work around the differences between the NAS and a PC.

  7. Treah

    Treah Addicted to LI Member

    Yeah I was unaware of redboot when I did the bad flash the last time. And I was rather sneeky with my telephone call to linksys to get a new one :p.

Share This Page