Buffalo NAS-Central Forums

So, to sum up, the "correct" steps with a virgin linkstation are:

1) install the modified initrd
2) boot to EM mode to resize the partitions without touching sda1
3) reboot and install freelink

yes?

I think you got the steps down.

_________________
http://www.opifer.net

Ok, step 3 gave me some problems, the real sequence has been:

3a) reboot in EM mode
3b) mkswap /dev/sda5, mkfs.xfs /dev/sda6 (maybe this step is not necessary, I don't know, the wiki is not clear)
3c) reboot (maybe unnecessarily)
3d) use the updater to install freelink and panic, since the message doesn't correspond to what's explained in the wiki
3e) I think that here I telnetted to the box at this time, still in EM mode
3f) reboot, takes a long time, the box is still in EM mode
3g) reboot, the box is still in EM mode, mount /dev/sda2, it seems it has freelink in it
3h) probably a big mistake: rm /boot/hddrootmode, reboot, still in EM mode
3i) saw my mistake, touch /boot/hddrootmode, reboot
3j) box isn't reachable at 192.168.11.150 (tried also 192.168.11.151), no ping, no telnet, no ssh, I'm panicking (again )
3k) turn off, turn on various time, still panicking
3l) connect everything to the network (up until now I used a direct connection), see that the dhcp server assigned an address to the linkstation
3m) ssh to that address, success

It's only necessary if you want to have a separate data partition. sda6, sda7, ... are really up to the user to decide.


After the repartitioning is complete, the freelink-rootfs install can be done either by downloading/untarring the rootfs via the ramdisk, or by using the updater. This should be made clear in the article. For user that wish to install via the updater, the user should follow the FreeLink-GL wiki install instructions. The initrd-only step isn't necessary for users that already have their boot_options file modded for freelink. Users that have a brand-new box, or if they are unsure....should follow every step including the initrd-only step.

Good job pippolippi for working through the confusion.

@anyone with time + knowledge of the process (i.e. mindbender ), can you re-organize the article please to make things clearer? Thanks.

_________________
http://www.opifer.net

i will rework the article now.

but again i want to mention that the log which the article is based on definitely was taken while doing it in EM Mode.

i am absolutely sure.

but i do not remember why this worked....and what i have missed...

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!

First of all I have to remark that you all folks did an excellent work, these procedures are tedious and error prone, and even if you take notes you can miss some little detail (heck, I don't even remember the error message that the updater gave me in step 3d, and, no, I'm not going to try it again ).
Probably my problems are due that I combined the 2 procedures: repartitioning and afterwards installing freelink, maybe if I just did one or the other everything would have gone according to each respective article (anyway I didn't touch /dev/sda1).

well...thx

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!

A side note: in my linkstation the id of the original extended partition was 5, so I didn't bother to change it to f after creating it.

please review the reworked article:
http://buffalo.nas-central.org/index.php?title=Custom_Partitions_on_the_LS_Pro#Create_the_custom_partitions

i even checked all the Start/End/Block-stuff....so noone gets confused.

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!

A couple of notes

1) "Change Partition Type of Extended Partition to W95 Ext'd (LBA)" - as I said earlier it wasn't necessary here
2) how to confirm that the "firmware-update" step worked in spite of the error message that the firmware updater gives. My box took a long time to reboot (untarring freelink to /dev/sda2?) and remained in EM mode, so I wasn't sure that the firmware upgrade worked. Eventually I managed to get out of EM mode and boot freelink, but I'm still not sure that everything is in its place.

I'd add these details myself but, especially for 2, I don't know the correct answer.

feel free to apply the changes....even anonymous edits are allowed in our wiki.

untarring freelink is completely different to flashing.
i myself have no clue how to manually get out of EM Mode.

someone can enlighten us?

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!

I just thought that, after the firmware updater did its job, the long time to reboot was due to the untarring of freelink.

As on how to get out of EM mode I simply touched /boot/hddrootmode while in EM mode, though I was expecting the box to come out from EM mode by itself once the firmware updater ran (maybe it would have on next reboot if I didn't mistakenly remove it in step 3h above , if this is the case I would have liked to know beforehand how many reboots are necessary to complete the process )

linuxrc:
1) if one of the *.updated files in /boot is present, do the update by rebooting into EM-Mode, there fwupdate.sh is called which does the update and reboots afterwards.
2) testrootfs looks for /mnt/etc/hddrootmode (created by touch /etc/hddrootmode) and /mnt/etc/rootfs_ok (date > /mnt/etc/rootfs_ok), where /mnt is the mounted rootfs.

[untested]
--> To get out of EM-mode it should be sufficient to touch /etc/hddrootmode and 'date > /etc/rootfs_ok' for the rootfs
[/untested]


fwupdate.sh
Update is done by simply copying the files filename.buffalo.updated to filename.buffalo, hddrootfs gets formatted before untaring the hddrootfs.buffalo, u-boot additionally gets copied into /dev/mtd0

So to update the box simply move the unziped files (do not untar the rootfs ) to /boot and do a reboot. Wrote a script that does that for stock firmwares - works! Want to test it further and include the possiblity to use a tarball or a directory with the files for easier development process. Further there should be a testsum checking - just to be sure everything is fine.

pippolippi was not only faster with the answer, he is also correct.
If rootfs_ok is missing linuxrc complaints, writes into /mnt/etc/rootfs_booting, tries to read the file and if that works it continues booting. So rootfs_ok is not really necessary.

_________________
acp_commander users note: from ver. 0.4 on the correct ACP authentication method is used, avoiding possible side effects.
Download: http://sourceforge.net/project/showfile ... _id=167037

anyway (and drifting away a bit from the topic of this thread), in case you're using freelink this is necessary only at the beginning, then the updates (minus the kernel) are managed via apt-get, right? (at least until urpmi is ported to debian :p ...)

Yes, it is a bit offtopic here The lines above descirbe in very - maybe too - short form what the script fwupdate.sh does. The LSUpdater copies the update files into /boot/*.buffalo.updated after reboot linuxrc findes them and goes into EM-mode, where fwupdate.sh is started, which does the copying/formating/untaring and reboots.
So yes, it's a description of the standard update process, especially to be used for the kernel, initrd and u-boot - and of course in EM-mode you could also do the copying "manually".

_________________
acp_commander users note: from ver. 0.4 on the correct ACP authentication method is used, avoiding possible side effects.
Download: http://sourceforge.net/project/showfile ... _id=167037