Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Wed May 23, 2018 3:54 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 3 posts ] 
Author Message
 Post subject: U-boot and e2fsck
PostPosted: Sun Feb 23, 2014 12:02 am 
Offline
Newbie

Joined: Sun Mar 28, 2010 6:09 pm
Posts: 17
Some points, which I may add to the wiki at some point:

The ls-chl partitions are represented by one mtd device, mtd0. In Debian, you can use fw_printenv and fw_setenv to set u-boot environment variables for this device by using the following, saved as '/etc/fw_env.config'

Code:
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.

# MTD device name   Device offset   Env. size   Flash sector size
/dev/mtd0           0x3F000         0x1000     0x1000


If you mess these settings up, you can add a serial port to the device and reset them within u-boot. I think the resetenv even makes this quite easy.

Using this, I can now get Debian's initramfs to not show up as corrupt on boot :) The settings I updated (new values shown) are:

Code:
bootargs_root=root=/dev/sda2 rw initrd=0x00800040 panic=5
(from bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5)

bootcmd=ide reset; ext2load ide 0:1 0x00100000 /$(kernel); ext2load ide 0:1 0x00800000 /$(initrd); setenv bootargs $(bootargs_base) $(bootargs_root) $(bootargs_func) $(bootargs_debug) $(buffalo_ver); bootm 0x00100000 0x00800000

(I changed occurrences of 'ide 1:1' to 'ide 0:1', so that it loaded from the (first) disk's second partition, you may need something different!)



fw_setenv allows you to set a whole bunch of variables at the same time using a file. I have used the following file ('env.txt') to successfully update u-boot settings on my second ls-chl. This box runs Debian and has a similar partition layout (boot, root, swap, data), meaning the file was safe to use on it:

Code:
bootargs $(bootargs_base) $(bootargs_root)
baudrate 115200
loads_echo 0
ipaddr 192.168.11.150
serverip 192.168.11.1
rootpath /nfs/arm
cpuName 926
CASset min
MALLOC_len 4
bootargs_end :::DB88FXX81:eth0:none
ethact egiga0
stdin serial
stdout serial
stderr serial
enaMonExt no
enaFlashBuf yes
enaCpuStream no
ethprime egiga0
buffalo_ver BOOTVER=1.22
buffalo_minor_ver BOOT_MINOR_VER=1.00
build_time 14:54:28
initrd initrd.buffalo
kernel uImage.buffalo
bootargs_base console=ttyS0,115200
bootargs_root root=/dev/sda2 rw initrd=0x00800040 panic=5
bootcmd ide reset; ext2load ide 0:1 0x00100000 /$(kernel); ext2load ide 0:1 0x00800000 /$(initrd); setenv bootargs $(bootargs_base) $(bootargs_root) $(bootargs_func) $(bootargs_debug) $(buffalo_ver); bootm 0x00100000 0x00800000
def_tftp tftp 0x00100000 $(kernel); tftp 0x00800000 $(initrd); setenv bootargs $(bootargs_base) $(bootargs_root) $(buffalo_ver) tftpboot=yes; bootm 0x00100000 0x00800000
bootdelay 3
disaMvPnp no
overEthAddr no
usb0Mode host
usb1Mode host


This is flashed with:

Code:
sudo fw_setenv -s env.txt


---

Finally, I have had problems when I unplug my device, plug it in and power cycle. I think the root cause is the rtc on the device has no battery. The hardware clock will be wrong after removing power, so ntpd should be used. If it's wrong very far in the future, then the filesystem mount time will be in the future and when you next restart, fsck will halt and want you to intervene because of this, resulting in the device not booting. This can be fixed by taking the drive out and running fsck on it... but then you've removed power so might run into the same thing again....

As a solution (for Debian at least), I have added '/etc/e2fsck.conf' with:

Code:
[options]
    broken_system_clock = 1


I have also added '/etc/initramfs-tools/hooks/e2fsck', which must be executable (chmod +x):

Code:
#!/bin/bash
PREREQ=""
prereqs()
{
     echo "$PREREQ"
}

case $1 in
prereqs)
     prereqs
     exit 0
     ;;
esac

. /usr/share/initramfs-tools/hook-functions
copy_exec /etc/e2fsck.conf /etc/e2fsck.conf

exit 0


This script adds the config file to Debian's initramfs when it is rebuilt, allowing the initramfs to deal with these problems on its own (hopefully!!!). You can rebuild the initramfs with:

Code:
sudo update-initramfs -u


Top
   
 Post subject: Re: U-boot and e2fsck
PostPosted: Sun Feb 23, 2014 10:50 am 
Offline
Moderator

Joined: Fri Jun 29, 2007 10:39 am
Posts: 2604
ash87 wrote:
...
I think the root cause is the rtc on the device has no battery. The hardware clock will be wrong after removing power, so ntpd should be used. If it's wrong very far in the future, then the filesystem mount time will be in the future and when you next restart, fsck will halt and want you to intervene because of this, resulting in the device not booting. This can be fixed by taking the drive out and running fsck on it... but then you've removed power so might run into the same thing again....
...

Nice finding.
It is a reasonable explanation for some boxes fail to boot
suddenly, after a long time running without any trouble
(beside the already "known" problem of power outages
corrupting the boot filesystem).
And it matches the other "design flaws" of Buffalos boxes.
So they would be consistent, at least in some way. :(

_________________
Please do not use private mail (PN/M) to ask questions. Use the proper forum instead. (me)

If there is no verified backup of a dataset, the dataset, by definition, is unimportant. (c't 2012)

RAID (no matter which level) never ever substitutes a backup. (me)


Top
   
 Post subject: Re: U-boot and e2fsck
PostPosted: Sat Oct 10, 2015 10:30 pm 
Offline
Newbie

Joined: Sun Mar 28, 2010 6:09 pm
Posts: 17
More u-boot points for the ls-chl:

I recently upgraded an ls-chl to a 3TB drive. Drives larger than 2TB really need a GPT partition, rather than an MBR/msdos one. Unfortunately u-boot version on ls-chl doesn't support gpt, so to get this to work you need to create a hybrid table. See here... http://www.rodsbooks.com/gdisk/hybrid.html. Create the partitions required as normal using gpt, then do a conversion.

Another u-boot limitation is that it looks like it only supports an ext2 inode size of 128. I think this is a well known problem with older u-boots, but I only came across it recently, as I think my mkfs was using this size by default until recently. This only affects sda1, where initrd.buffalo and the kernel are kept, the boot partition. Also, I'm using a block size of 1024 for this partition, where by default for me they are now being created with a block size of 4096.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 3 posts ] 

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 1 guest


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:
Powered by phpBB® Forum Software © phpBB Limited