Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I just started getting the following screen every time I login:
"Click Next to begin formatting the replacement drive. Re-synch will take place after the restart.
This just started happening -- and I don't believe that I made any (recent) changes to cause this. In particular, I have not removed either of the drives nor have I had any crashes that would cause that.
I have 2 1TB drives in RAID 1 configuration.
In fact, running "mdadm --detail /dev/md0" shows that the RAID1 array is working properly and is clean.
Somehow, though the web interface thinks that I added a new drive and is trying to format it.
Any suggestions on what may be wrong and how to fix it?
Offline
Check your raidtab, raidtab2web, and hd_magic_num files.
Offline
All 4 copies of the hd_magic_num files (on mtdblock0, mtdblock1, HD_a4, HD_b4) seem to be the consistent and unchanged from previously.
Similarly the 5 copies of raidtab (/etc, mtd1, mtd2, HD_a4, HD_b4) all seems fine and are identical
Interestingly the file /etc/tmp_raid_table/raidtab shows an additional non-existent /dev/md1 raid device on non-existent /dev/sda3 and /dev/sdb3 devices. Not sure whether this means anything or whether it is just a dummy temp file.
Note that mdadm --detail /dev/md0 still shows everything clean
The 5 raidtab2web files that I found (in /etc, and on HD_a4, HD_b4, mtd1, mtd2) are interesting in that the one in /etc (and the copies in flash memory mtd1, mtd2) lists the filesystem as EXT2 while the ones on HD_a4/HD_b4 list the filesystem as EXT3 (which is correct since I used tune2fs originally to set the filesystem to EXT3). It is also interesting to note that these files are partially in DOS format (have ^M at the end of most but not all lines
- the person constructing these files may just have been sloppy in editing part of it on a windows machine)
This is likely connected with the problem that I am now having whereby my /dev/md0 ext3 filesystem gets remounted as an ext2 filesystem (and indeed cannot even be forcibly mounted with -t ext3 as an ext3) eventhough running tune2fs shows the journal is still there. See http://dns323.kood.org/forum/t3202-WIER … issue.html for details.
Indeed changing the entry in etc/raidtab2web to EXT3 allows me to remount the filesystem as ext3 without having to rerun tune2fs. The reason that previously setting tune2fs only lasted until the next reboot is presumably because I need to make the change also in the non-volatile /sys/mtd1 and /sys/mtd2 copies.
However, the original problem of this thread remains in that the web interface keeps telling me ""Click Next to begin formatting the replacement drive. Re-synch will take place after the restart." even after rebooting -- which was the original subject of this thread.
I noticed that running the web interface creates the following EMPTY files in /tmp:
web_format_dev
web_format_dev_sda
web_format_dev_sdb
Perhaps they have something to do with my problem.
However I still don't know what is triggering the problem even now that the hd_magic _num files and the raidtab2web files are all seemingly correct and in sync.
Offline
OK THIS IS INTERESTING.
The problem only occurs when I reboot the kernel with usb (rather than ramfs) as the root fs.
I am using the *exact* same initrd -- but just using a real disk fs rather than a ram fs.
The only (relevant) differences between the ramfs and the usb mounted root fs are the following:
usb root fs only has the following /tmp files:
web_format_dev
web_format_dev_sda
web_format_dev_sdb
web_chk
scsi.log
The first four files are empty (generated by touch). While the last one contains the model and serial numbers of the HDs (which are correct and consistent with the hd_magic_num files).
These files get written by /usr/sbin/write_hd_info which runs every time I login with the usb root fs but doesn't run when I login with the ramfs.
(though obviously I can generate thes files on the root ramfs by running write_hd_info manually from the commandline)
However, the presence or absence of these files doesn't seem to be the cause of the problem.
Because on the rootfs, generating the files doesn't cause the format message. And conversely, creating a wrapper around /usr/sbin/write_hd_info to delete the files doesn't prevent the reformatting message on the usb-fs.
Rather it seems, that the running of write_hd_info is the effect of something else which is the primary cause of the reformat message. Because, write_hd_info seems to only...
So I need to trace back somehow to see what is triggering the calling of write_hd_info and what else is different between the usb and ram root fs system cases that is causing this problem.
Offline
BINGO - after a couple of hours of walking through the web server source code, I figured out the problem.
On login, the web_api.c file runs a couple of checks:
- The first check is ChkDiskIsFormat which tries to open the following files for reading:
/web/swap (should exist if both swap_a and swap_b exist)
/web/swap_a
/web/swap_b
/web/non_HD (present if no hard-drives detected)
- If the first file is readable (which it should be)
then it calls the function ChkDiskNumber which tries to open the following files for reading:
/web/hddok (should exist if both hddok_a and hddok_b exist)
/web/hddok_a
/web/hddok_b
/web/hd_verify_warning (if present run "hd_verify -w")
/web/hd_exchange (present if disks appear to be switched)
In a "normal" 2-disk situation, you are supposed to have:
/web/swap
/web/swap_a
/web/swap_b
/web/hddok
/web/hddok_a
/web/hddok_b
The bottom line is that I was missing /web/hddok and /web/hddok_b
Soon as I "touched" those files, then it all went back to working...
Also, as I mentioned in previous thread, if you are using ext3 with v1.05 then every time you go to the login page you will be warned to convert to ext2. If you want to eliminate this warning, then remove the file: /tmp/warning_ext3
(note you will need to remove this on every reboot -- so you might want to put this statement in /etc/fun_plug.local)
Offline