3a) reboot in EM mode3b) 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 wiki3e) I think that here I telnetted to the box at this time, still in EM mode3f) reboot, takes a long time, the box is still in EM mode3g) reboot, the box is still in EM mode, mount /dev/sda2, it seems it has freelink in it3h) probably a big mistake: rm /boot/hddrootmode, reboot, still in EM mode3i) saw my mistake, touch /boot/hddrootmode, reboot3j) 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 panicking3l) connect everything to the network (up until now I used a direct connection), see that the dhcp server assigned an address to the linkstation3m) ssh to that address, success

3b) mkswap /dev/sda5, mkfs.xfs /dev/sda6 (maybe this step is not necessary, I don't know, the wiki is not clear

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

pippolippi wrote:

3d) use the updater to install freelink and panic, since the message doesn't correspond to what's explained in the wiki

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.

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).

1) "Change Partition Type of Extended Partition to W95 Ext'd (LBA)" - as I said earlier it wasn't necessary here2) 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 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]

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.

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".

Who is online

Users browsing this forum: No registered users and 14 guests

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