Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Sat Dec 20, 2014 2:45 am

All times are UTC [ DST ]




Post new topic Reply to topic  [ 1 post ] 
Author Message
PostPosted: Mon Apr 16, 2007 8:33 pm 
Offline
Site Admin

Joined: Fri Aug 04, 2006 2:37 am
Posts: 1652
Location: United States of America
Hello,

I am writing this because I am becoming concerned about people getting confused with the initrd. I'd like to explain a few things, and propose a temporary standard (you'll understand in a moment).

First, for mindbender: You asked a while back about where the files for /boot are. Let me answer that. They are currently in the initrd.img for all lspro distros.

Second, let me explain a little how the custom initrd we have works. First, the actual initrd in all the custom distros (telnet-enabled/jtymod/freelink/genlink) uses the same initrd. There is absolutely nothing different with them in terms of the ramdisk image (initrd.buffalo). What is different among them is the setup file, i.e. boot_options.

The difference, for the initrd setup, between the stock based firmwares, and the gentoo/debian base ones is where the following files are looked for.

The first file is hddrootmode. This is an empty file the initrd looks for, to decide whether to boot to ramdisk or hddroot mode. When it is found, initrd then moves on to check for a second file.

The second is "rootfs_ok". This file contains a date of the last successful boot (date >> rootfs_ok). The relevant part, is if the initrd see three unsuccessful attempts to update the date in the file on boot, initrd decides that the rootfs is corrupt, and switches to ramdisk mode (EM-mode).

The third file is the linkstation_release.txt file. This file actually doesn't really serve a purpose anymore (other than for it's use with the Buffalo Updater), other than a place holder. The original initrd would verify the dates in the linkstation_release file, and would force the box to boot to ramdisk mode if the dates of the kernel/rootfs didn't match. This has since been circumvented, but the files is still looked for, so thus it's needed. All initrd's contain a dummy linkstation_release file that looks like this:

Code:
VERSION=1.00
SUBVERSION=HDD 0.42
PRODUCTID=0x00000009
BUILDDATE=2007/06/28 09:42:00


The values don't really matter.

Ok, now the differences. In the stock based firmwares (with OTHER_DISTRIBUTION commented out in boot_options), the 3 files above are searched for in /etc of the rootfs. In the debian/freelink versions, these files are not in /etc, but rather in /boot. What controls initrd's search of whether to look for is the combination of OTHER_DISTRIBUTION, and ROOTPATH in boot_options.

Now, the stock based firmwares can also make use of the "other disribution" options. If one was to set OTHER_DISTRIBUTION=yes and ROOTPATH=/boot in boot_options for stock based firmwares, the box would boot to hddrootfs mode fine, provided the 3 above files are located in /boot.

So, to save confusion, I recommend that ALL custom firmwares we release using this custom initrd, use the same setup. Here is how the boot_options file for now on (if other devs agree) should look like:

Code:
## Set to YES if not a stock box, comment out if stock box
OTHER_DISTRIBUTION=YES
## Define root path, comment out if stock box
ROOTPATH=/boot
## Advanced use only, specify system area format
SYSTEM_FORMAT="mkfs.xfs -d agcount=4 -l size=32m"
## Set menu timeout (secs), default is 4.  Disable, set to 0 or OFF. For
## EM mode set to EM
MENU_TIMEOUT=4
## Set to YES to delete hdd image following update or NO to leave it
REMOVE_HDDROOTFS=YES
## Reset fan as micocontroller does not do this after reboot
miconapl -a fan_set_speed stop
## Watch-dog reset to 250 secs
miconapl -a system_set_watchdog 250
## Clear error LED indication
miconapl -a led_set_code_information clear
## Indicate it ran
miconapl -a bz_imhere 1 b4 a4


Should others agree, all the stock based firmwares will need their boot_options files updated in the initrd.img (that's it bender, if you want to do this). Users with these stock based firmwares already installed can just edit boot_options, and make sure the three files above are included in boot.

I have uploaded a decrypted initrd.img so that users can easily add any missing files to boot. Also, for all those that don't know what the /boot dir is, it is where sda1 (the boot partition) is mounted to. If for whatever reason, if /boot is empty when you try to add missing files to it, just execute "mount /dev/sda1 /boot" to mount it.

Ok, thought I was done? :) Nope, got more to discuss. Currently, in the developmental planning stages, is an u-boot/initrd that will make use of linuxnotincludes kuro-style u-boot. First, a new and cleaner u-boot will be developed (jacques has volunteered for this) which will have a) a corrected MACH-ID for the kernel and b) the LNI style of booting. The style is to either boot directly to the rootfs from the kernel (skipping initrd all together) or booting to the ramdisk/initrd in the for of an EM-mode. This will be user selected. The subsequent initrd then, will be cleaned up, will all the unnecessary rootfs checks removed, and will provide only a simple debug environment for rescueing the boxes.

So, please stay tuned for more updates (from me, jacques, lb_worm, mindbender, and others).

Also, opinions on the proposed temporary initrd standard (files in /boot for every distro) prior to the new uboot/initrd is appreciated. I don't think this is worth a poll, but a simple vote here on the adoption of the standard would probably suffice.

Thanks every,

jonli447

_________________
http://www.opifer.net


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


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

Search for:

Protected by Anti-Spam ACP
Protected by Anti-Spam ACP Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group