Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Tue Aug 14, 2018 2:16 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 17 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Tue Feb 02, 2016 1:12 am 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
I have just installed Debian 8.3 jessie on my HS-DH320GL (HS-DHGL) LinkStation Live (v1).

I had some issues with the installation, so I decided to describe the process here in case it helps anyone. Perhaps some of this can be incorporated into the Wiki. I do not feel confident enough to edit the Wiki myself.

It was not immediately obvious to me that the Debian project itself has installers for the latest versions of Debian specifically for a handful of Buffalo NAS devices, presumably based on groundwork done by this community.

I upgraded the HDD to 4TB, because the original 320GB is no longer a useful size for me. I chose a WD Red WD40EFRX, in large part because this has 512e sectors, which I'd read were necessary for the LinkStation.

Knowing what I know now, I would probably do it something like this:
  1. Install new blank drive in LinkStation.
  2. TFTP boot into stable relase LSPro Debian installer.
  3. Install Debian, partitioning drive appropriately. (2TB partition size limit requires attention.)
  4. Attempt to boot LinkStation. If it fails, TFTP boot into foonas to check U-boot environment. Make corrections if necessary.
  5. Boot Debian and configure it.

However, the rather roundabout and experimental process I actually followed was:
  1. Clone existing opened stock firmware onto new drive and partition it. Install it in LinkStation.
  2. Test; it worked. I could access the web interface and SSH in as before.
  3. Attempt to install Debian from within the stock firmware. Hack at it a bit to try and make it work. Fail to boot into the Debian installer.
  4. Remove HDD from LinkStation and, using laptop, replace uImage.buffalo with foonas one. Reattach HDD, fail to boot.
  5. Remove HDD from LinkStation and repeat clone from original drive, putting the new drive back into a known good state. Fail to boot. (Oh dear... no going back now!)
  6. Attempt to TFTP boot foonas; fail.
  7. Obtain USB to serial TTL adapter to read terminal output from LinkStation. Determine cause of failure to TFTP boot as user error setting up TFTP server.
  8. TFTP boot foonas. Attempt to install Debian from within foonas. Fail to boot Debian installer.
  9. Successfully TFTP boot the Debian installer. Install Debian, repartitioning drive as part of installation.
  10. Fail to boot new Debian installation.
  11. After much puzzling, determine that U-boot environment variable bootcmd was incorrect. Fix it.
  12. Successfully boot Debian.
  13. Configure Debian a little.
  14. Realise that I am running the testing release.
  15. TFTP boot the Debian installer for the stable release.
  16. Installer hangs while booting.
  17. Realise that there is a separate installer for the LSPro. Try that one. It works.
  18. Install Debian again.
  19. Boot Debian and configure it again.

Having said that it was unnecessary, cloning the original system and booting it from the new HDD was a useful test, because it ruled out the new HDD in later troubleshooting.


Debian installer

To summarise what I learned about ways of booting the Debian installer:
  • The config-debian script doesn't work properly on opened stock firmware.
  • The config-debian script does work in foonas.
  • The config-debian script is unnecessary if you TFTP boot the Debian installer, provided your U-boot environment is good.

In my stock firmware, it seemed that /boot was mounted from /dev/ls_disk1_1 and not from /dev/sda1, which prevented the config-debian script from working.

The links on the NAS-Central wiki and Debian's own installation guide both point to the testing release of the Kurobox Pro installer, even though that is the stable installation guide. If you want the stable version or the LSPro version, you need to get it from http://http.us.debian.org/debian/dists/stable/main/installer-armel/current/images/orion5x/network-console/buffalo/. Or, replace "stable" in that URI with the name of the specific release you want (e.g. "jessie").

The stable (jessie) installer for Kurobox (as opposed to the LS Pro) doesn't even boot successfully on my LS Live, while the testing (stretch) installer for Kurobox works but results in a system that takes one or two minutes during the boot process to scan flash blocks and spew the resultant errors to the console. Presumably this relates to the extra flash memory that Kuroboxes have. The stable (jessie) installer for LS Pro results in a system that doesn't do this scanning, and therefore boots much faster! I have not tested the LS Pro installer for the testing release.


TFTP booting

The easiest way to initiate a TFTP boot of the LinkStation, for me, was to put it into an unbootable state and try to boot it. Depending on the reason it cannot boot, it will either do an error beep or an Emergency Mode siren beep, but in both cases it will be attempting to TFTP boot. The error codes flashed by the red LED can be somewhat misleading. Mine suggested a fan problem or flash ROM error, neither of which related to the real problem. You can silence the beeping by pressing the power button briefly.

One way to make the LinkStation unbootable and initiate a TFTP boot is to install a blank HDD, or erase the HDD (if that's appropriate to what you are doing). Another is to rename the uImage.buffalo on /boot partition on the LinkStation's HDD to some other name (e.g. uImage.buffalo.disabled). When renaming the uImage.buffalo like this, I also renamed the initrd.buffalo for good measure, but that is probably unnecessary. Another way to make the system unbootable, but not one I recommend anyone to deliberately use, is for the U-boot environment to be incorrect. I only mention this because that is what happened unintentionally with my LinkStation.

You can also initiate a TFTP boot by using the serial terminal to interrupt the boot process. This is somewhat more involved.

Having initiated a TFTP boot, you need to connect the LinkStation to a network where it can access a TFTP server at the IP address 192.168.11.1 (by default). This would typically be a temporary, direct Ethernet connection to a laptop or similar, rather than a full-blown network. In its error state/Emergency Mode, the LinkStation will be repeatedly attempting to to download uImage.buffalo and initrd.buffalo from the TFTP server. When the TFTP server is accessible and has the appropriate files, the next download will succeed. Having downloaded the files, the LinkStation will stop beeping (if you hadn't already silenced it) and will boot from the files it downloaded. If it can't download the files after many, many attempts, the LinkStation gives up, beeps, and powers off. You can just power it back on again for more attempts.

If the TFTP boot does not appear to be working, double check that your TFTP server is working! Attempt to download the two required files from your TFTP server using a TFTP client, even if you do it on the same machine that is running the server. If I had bothered to do this, I could perhaps have avoided wiring up a serial terminal to the LinkStation!

If you are booting foonas, you need to provide an initrd.buffalo, but it is not used by foonas, so you can just use any initrd.buffalo, such as the one for the Debian installer or the stock firmware.

A suitable TFTP server to run on a Debian-derived system is provided by the package tftpd-hpa. Run sudo dpkg-reconfigure tftpd-hpa to configure it. Run sudo /etc/init.d/tftpd-hpa start to start the daemon. I'd recommend removing the package from your system when you've finished using it.


Other details

This is a collection of other things that might be useful for people to know.

Serial terminal

With hindsight, accessing the LinkStation's serial terminal was not strictly necessary, but it would certainly have taken me a lot longer to troubleshoot the problems I had without it. I purchased a USB to Serial TTL Cable with 3.3V signalling. There are many such devices available with various form-factors and connectors.

Since the serial connection was only going to be temporary, I laid the LinkStation on its side and used some bent, plastic-coated metal paper clips as springy solid-core wires to make the connection to the LinkStation's unpopulated serial header. Having stripped some plastic from each paperclip end, I hooked the paperclips into various parts of the metal chassis to hold them in position and used their springiness to press them against the sides of the through-holes in the PCB. I stuck them in place with some tape for good measure. My serial adapter was supplied with a single-pin header connector on the end of each wire, which fitted the free ends of the paperclips well.

TAKE CARE if you do this! There are reports of people shorting out their serial header with inappropriate connectors, and there are dangerous voltages in close proximity. Switch the LinkStation off and remove the power supply before rigging something like this up, to protect the LinkStation and yourself. Make sure the paper clips are not shorting out onto each other, the metal case or anything else, particularly the AC input jack! Don't forget they could touch each other on the other side of the PCB if you push them through too far. I covered the exposed AC input terminals with tape to avoid touching those.

If the serial adapter is USB-powered (as opposed to powered by the serial header), you do not need to attach the VCC terminal. RXD, TXD and GND are sufficient. I was not able to determine what voltage VCC should be on the LinkStation's serial header, so it was safer to leave VCC disconnected. (Most adapters provide 5V, even though the signalling is 3.3V.) Make sure the unused 5V terminal can't short onto anything!

minicom is a suitable program to use to access a serial terminal using a GNU/Linux system.


My incorrect U-boot environment

The reason my LinkStation would not boot after first attempting to run the Debian installer was that the "bootcmd" U-boot environment variable was incorrect. I suspect this was changed by the config-debian script when I ran it in the stock firmware, perhaps because it was the Kurobox version or perhaps because I was attempting to run on firmware it wasn't designed to run on. I was getting an error message, seen on the serial terminal, of "Wrong image type for bootm command". The offending environment variable was:
Code:
bootcmd=ide reset; ext2load ide 0:1 $(default_kernel_addr) /$(kernel); ext2load ide 0:1 $(default_initrd_addr) /$(initrd); setenv bootargs $(bootargs_base); bootm $(default_kernel_addr)


To see the value of this variable, it was necessary to boot into foonas and run fw_printenv. Even though you can interrupt the boot process through the serial terminal and issue the printenv command, directly within U-boot, this particular environment variable gets altered when you do that, so you never get to see its original value that way.

The problem with this bootcmd environment variable was that $(default_kernel_addr) and $(default_initrd_addr) were not defined anywhere. As a result, since this part of the command was not throwing an error, these non-existent variables were presumably both resolving to some nonsense address (perhaps 0x00000000). Since they were both resolving to the same nonsense address, U-boot was loading both the kernel and the initrd into that same nonsense memory location, one on top of the other. Then, when it tried to boot the kernel, it found the initrd, because that was the last thing to be loaded! Hence, "wrong image type". (It is nice that it has the intelligence to distinguish between kernels and intrds.)

My solution was simply to create the two extra environment variables that were missing, by running these two commands in foonas.
Code:
fw_setenv default_kernel_addr 0x00100000
fw_setenv default_initrd_addr 0x00800000


I copied the memory addresses from the def_tftp environment variable, where they are used for the same purpose of loading the kernel and initrd. I could have simply replaced the references to these variables with the actual addresses, but creating the two variables was easier.


Downloading things from the internet in foonas

If you boot foonas using TFTP, then there is a good chance it won't have a network connection while it boots up, because it's linked to your TFTP server instead of your normal network. If you haven't connected it to a network before it brings up the network interface, you can make it obtain an IP address using DHCP by simply bringing the interface up again in using ifup. (You might need to take it down first using ifdown.) This enables you to use wget to download things like the Debian installer from within foonas.


Partitioning

The LinkStation (or, more specifically, the version of U-boot it uses) requires an msdos partition table. msdos partition tables have a maximum partition size of 2TB.

To partition my 4TB drive, I ended up with this scheme:
Code:
#1    ext3    207MB     /boot
#2    ext4    10GB      /
#3    [extended partition; ~1.9TB]
├ #5  swap    10GB
└ #6  LVM     max (fill remaining space)
#4    LVM     2TB

I made the /boot partition exactly same size as it had been in the stock firmware. This is not necessary, but it was a convenient number to use.

You can configure LVM within the installer. I put both of my LVM physical volume partitions into the same volume group, and created a single ~3.9TB logical volume in that group, which I formatted as ext4 and mounted on /home.

The Debian installer does not seem to provide a way to explicitly define the size of an extended partition. Instead, you create logical partitions and it assumes you want them to go into an extended partition that fills the available space. Therefore, having defined partitions #1 and #2, if I attempted to define partition #5 next, I would receive an error about the extended partition being too large for the msdos partition table, because it was trying to create an extended partition almost as large as the entire disk. The way to avoid this was to create the partitions in the order #1, #2, #4, #5, #6. This way, when #5 is created, the extended partition #3 is implicitly required to fill the ~1.9TB space between #2 and #4, which is an acceptable size.


Top
   
PostPosted: Fri Feb 05, 2016 11:05 am 
Online
Moderator

Joined: Mon Apr 26, 2010 10:24 am
Posts: 2734
Thanks for the instructions.
I would be very happy if you could change the hardware to a new LS 400 series.


Top
   
PostPosted: Thu Feb 18, 2016 3:42 am 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
I would also be happy if I could change the hardware to a new one! However, I am unlikely to acquire any new NAS hardware for the foreseeable future.


Top
   
PostPosted: Fri May 27, 2016 7:33 pm 
Offline
Total Newbie

Joined: Fri May 27, 2016 7:07 pm
Posts: 1
Good to know that someone else is running debian on the old LS-GL/HS-DHGL boxes, too.

A long time ago, I followed this approach to install debian squeeze:
http://buffalo.nas-central.org/wiki/Ins ... n_Pro/Live
Running the install-script (config-debian) prevented having wrong U-Boot parameters. However, I had to install uboot-envtools manually.

Now, I have one LS-GL running debian jessie:
http://ftp.debian.org/debian/dists/jess ... alo/lspro/

and another one running debian wheezy.

Nowadays, I would definitely add a serial port first. Things are so much easier with that.
http://buffalo.nas-central.org/wiki/Add ... inkstation

Question:
On debian jessie, I still have problems with systemd-services. Especially after upgrading packages I cannot shutdown cleanly.
Do you have similar problems?

On wheezy this has never been an issue.

Regards,
l\lilpf3erd


Top
   
PostPosted: Sat Jul 16, 2016 3:45 pm 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
Nilpf3rd wrote:
Question:
On debian jessie, I still have problems with systemd-services. Especially after upgrading packages I cannot shutdown cleanly.
Do you have similar problems?

I have experienced some issues with shutdowns with Jessie on the HS-DHGL, but I haven't had time to troubleshoot it. Perhaps you have just given me a hint there about what could be causing it.

After many days of uptime, or periods of high CPU load (e.g. installing updates), it invariably fails to respond to shutdown commands and I have to manually power-cycle the unit. I have never tried another version of Debian on the box, so I don't know whether this is only a problem in Jessie.

I have also seen problems where the watchdog timer seems to time-out when the unit is under high CPU load for very long periods of time (tens of hours), which seems to suggest that the watchdog daemon needs a higher scheduling priority.

It's nice to know I'm not the only person still using one of these machines!


Top
   
PostPosted: Sun Jul 17, 2016 2:27 pm 
Offline
Newbie

Joined: Sun Jul 17, 2016 2:16 pm
Posts: 5
I'm still using one of these, but it's recently ceased functioning after I upgraded from Squeeze to Wheezy a few months back. The machine was still booting fine, but I could never get a network connection to work. I built a serial adapter to find out why. For some reason, some essential file in /run/... was missing, preventing it from bringing up the network. I just hacked /etc/init.d/networking to touch this file and it worked.

The problem now is that the machine switches itself off after about 5 minutes claiming that there is a problem with the hard disk. However, I have put the disk into another machine and it looks totally fine. I notice that the fan isn't spinning. I took the fan out and installed it in another machine and that still works, so it might be a network issue or it could be that the fan header on the device is no longer working. Anyone encountered this problem before?

Anyway, to rule out a software issue I want to clean install a new version of Debian -- probably Jessie, but if Wheezy is more stable I could use that. I removed the hard disk to force it to try and tftp boot, and this is what I see from the serial port:

Code:
=== BUFFALO LS-GL U-Boot. ===
 ** LOADER **
 ** BUFFALO BOARD: BUFFALO_BOARD_LS_GL LE (CFG_ENV_ADDR=fffff000)


U-Boot 1.1.1 (Apr 18 2007 - 18:35:44) Marvell version: 1.12.1 - TINY

DRAM CS[0] base 0x00000000   size 128MB
DRAM Total size 128MB
[256kB@fffc0000] [0kB@f8000000] ## Unknown FLASH at f8000000: Size = 0x00000000 = 0 MB
Flash: 256 kB
Addresses 20M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (20M - 16M): Done

Soc: 88F5182 A2
CPU: ARM926 (Rev 0) running @ 400Mhz
Orion 1 streaming disabled
SysClock = 200Mhz , TClock = 166Mhz


USB 0: host mode
USB 1: host mode
PCI 0: PCI Express Root Complex Interface
PCI 1: Conventional PCI, speed = 33000000
Net:   egiga0 [PRIME]
Using 88E1118 phy

Marvell Serial ATA Adapter
Integrated Sata device found

HDD is not found
<<can_not_mount>>
hit any key to switch tftp boot.
Hit any key to stop autoboot:  0
Hit any key to stop autoboot:  0

Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found

Using device ide0, partition 1
** Bad partition 1 **
Using device ide0, partition 1
** Bad partition 1 **
<<stop_sound>>
## Booting image at 00100000 ...
Bad Magic Number
bootm fail.
<<system_not_found>>
*** ERROR: `serverip' not set
*** ERROR: `serverip' not set
<<stop_sound>>
## Booting image at 00100000 ...
Bad Magic Number
bootm fail.
<<system_not_found>>
*** ERROR: `serverip' not set
*** ERROR: `serverip' not set


Any idea what is wrong?


Top
   
PostPosted: Sun Jul 17, 2016 4:03 pm 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
I am by no means experienced, but these are my immediate thoughts.
FlamingBee wrote:
The problem now is that the machine switches itself off after about 5 minutes claiming that there is a problem with the hard disk. However, I have put the disk into another machine and it looks totally fine. I notice that the fan isn't spinning. I took the fan out and installed it in another machine and that still works, so it might be a network issue or it could be that the fan header on the device is no longer working. Anyone encountered this problem before?

Do you have the micro-evtd or avr-evtd daemon running? I would imagine problems with that daemon not running or not running properly would cause symptoms like you describe.
If you're using LED flash error codes, they may be misleading. (I find them misleading -- they don't necessarily mean exactly what they seem to say. About the most you can be sure of is "error"!)

FlamingBee wrote:
Anyway, to rule out a software issue I want to clean install a new version of Debian -- probably Jessie, but if Wheezy is more stable I could use that. I removed the hard disk to force it to try and tftp boot, and this is what I see from the serial port:

Code:
<--- snip --->
*** ERROR: `serverip' not set
<--- snip --->


Any idea what is wrong?


I think serverip is a U-boot environment variable that normally contains the IP address where U-boot will look for a TFTP server to boot from. For some reason it appears not to be set.

I can't comment on any of the other output; I don't know/remember what U-boot's output normally looks like in these circumstances.

Have you tried hitting "any key to switch to tftp boot"? I expect you will have to do that if you can't force the machine to do a TFTP boot by removing the disk.

I am afraid my knowledge here is probably little more than what you could find by searching for yourself.

I believe you can get U-boot to print out a list of available commands for you. The main "gotcha" I know of is that the environment actually changes when you enter that TFTP booting mode by pressing a key. You might find that, in that mode, if you do printenv, then serverip might be set in that environment, even if it wasn't set in the standard one.

What I don't personally know and have never tested is, if you use this TFTP mode to TFTP boot into foonas, do the fw_printenv and fw_setenv commands in foonas operate on the special "hit any key" TFTP mode environment, or do they operate on the standard one? If they don't operate on the standard environment, then I'm not sure how you would fix the problems with the standard environment that are preventing the automatic TFTP boot from working. (It must be possible, though, since you are presumably able to write to the flash memory that contains it.) On the other hand, If these commands do operate on the standard environment even after booting from the TFTP environment, then fixing it ought to be relatively easy. (Provided that you know what you're doing and don't break it even more!)

And of course the usual warnings about bricking the device if you mess it up!

Perhaps a more experienced forum member will come along some months later, with a better answer to your question!


Top
   
PostPosted: Sun Jul 17, 2016 4:10 pm 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
stiltonsandwich wrote:
Nilpf3rd wrote:
Question:
On debian jessie, I still have problems with systemd-services. Especially after upgrading packages I cannot shutdown cleanly.
Do you have similar problems?

I have experienced some issues with shutdowns with Jessie on the HS-DHGL, but I haven't had time to troubleshoot it. Perhaps you have just given me a hint there about what could be causing it.

After many days of uptime, or periods of high CPU load (e.g. installing updates), it invariably fails to respond to shutdown commands and I have to manually power-cycle the unit. I have never tried another version of Debian on the box, so I don't know whether this is only a problem in Jessie. I have also seen problems where the watchdog timer seems to time-out when the unit is under high CPU load for very long periods of time (tens of hours), which seems to suggest that the watchdog daemon needs a higher scheduling priority.

Just to update on the above: It turns out my machine does respond to shutdown and restart commands, but they take a long time to take effect. (About ten or twenty seconds.) I was simply impatient on previous occassions and hit Ctrl+C before the command could complete, leaving the machine in a messed-up state, from which further shutdown commands could not be issued because half of the shutdown had already occurred!

I have also adjusted the niceness of micro-evtd. I will have to see if this makes any difference the next time I start a long-running process.


Top
   
PostPosted: Sun Jul 17, 2016 9:12 pm 
Offline
Newbie

Joined: Sun Jul 17, 2016 2:16 pm
Posts: 5
Thanks for the input. My guess is that the install only partly worked, leaving me without a micro-evtd. Once I boot it into uBoot mode, after a couple of minutes the fan comes on and it's happy to run for a long time.

I did as you suggested and pressed any key to get into the uBoot loader. From there, I hacked around and set the 'serverip' (remote tftpd server host) and 'ipaddr' (ip of this machine) variables using 'setenv' -- this brings up the network. From there I can run 'boot' which starts the tftp boot process. I was able to pick up the Jessie installer and tftp boot into it. I didn't have time to install it, but it looks like I should be able to revive it. Thanks for the help :)


Top
   
PostPosted: Sat Jul 30, 2016 12:47 am 
Offline
Newbie

Joined: Sun Jul 17, 2016 2:16 pm
Posts: 5
So I finally got some time to try and reinstall Debian again. I used the serial cable to initiate TFTP boot via a direct network connection. Once the Debian installer had started I switched the network cable to the router. I mounted /dev/sda1 as /boot (1gb partition, ext2), /dev/sda2 as / (10gb) and the installer went seemingly smoothly. Now when it attempts to boot I get the following:

Code:
Orion1   CPU =  Low 

=== BUFFALO LS-GL U-Boot. ===
 ** LOADER **
 ** BUFFALO BOARD: BUFFALO_BOARD_LS_GL LE (CFG_ENV_ADDR=fffff000)


U-Boot 1.1.1 (Apr 18 2007 - 18:35:44) Marvell version: 1.12.1 - TINY

DRAM CS[0] base 0x00000000   size 128MB
DRAM Total size 128MB
[256kB@fffc0000] [0kB@f8000000] ## Unknown FLASH at f8000000: Size = 0x00000000 = 0 MB
Flash: 256 kB
Addresses 20M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (20M - 16M): Done

Soc: 88F5182 A2
CPU: ARM926 (Rev 0) running @ 400Mhz
Orion 1 streaming disabled
SysClock = 200Mhz , TClock = 166Mhz


USB 0: host mode
USB 1: host mode
PCI 0: PCI Express Root Complex Interface
PCI 1: Conventional PCI, speed = 33000000
Net:   egiga0 [PRIME]
Using 88E1118 phy

Marvell Serial ATA Adapter
Integrated Sata device found
  Device 0: OK
Model: SAMSUNG HD103UJ                          Firm: 1AA01109 Ser#: S13PJDWQ312925     
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)

Using device ide0, partition 1

Loading from block device ide device 0, partition 1: Name: hda1
  Type: U-Boot  File:/initrd.buffalo

0 bytes read
Using device ide1, partition 1
** Bad partition 1 **
Lost all init_rd
hit any key to switch tftp boot.
Hit any key to stop autoboot:  0


My guess is that the bootcmd is not quite right. Any idea what the correct boot command should be? I can try editing it manually in uBoot and see if I can fix it that way. Also, where does it actually look for the bootcmd etc. from?


Top
   
PostPosted: Sat Jul 30, 2016 8:16 am 
Online
Moderator

Joined: Mon Apr 26, 2010 10:24 am
Posts: 2734
hda1 vs sda1


Top
   
PostPosted: Sat Jul 30, 2016 11:24 am 
Offline
Newbie

Joined: Sun Jul 17, 2016 2:16 pm
Posts: 5
I got a little further. My bootcmd was fine, but after trawling these forums I read somewhere (viewtopic.php?t=25563) that uBoot cannot boot off /boot partitions with an inode size of 256. Plugged my HDD into a PC and lo and behold the Debian installer had used an inode size of 256. To fix this I

- Mounted the /boot partition from the drive
- Copied the files off it
- Created a new partition with inode size of 128 using "sudo mkfs.ext2 -I 128 /dev/sdd1"
- Copied the files back onto the drive

This gets me further. The device now boots into Debian! But alas it is not quite real Debian, but some emergency mode:

Code:
Orion1   CPU =  Low 

=== BUFFALO LS-GL U-Boot. ===
 ** LOADER **
 ** BUFFALO BOARD: BUFFALO_BOARD_LS_GL LE (CFG_ENV_ADDR=fffff000)


U-Boot 1.1.1 (Apr 18 2007 - 18:35:44) Marvell version: 1.12.1 - TINY

DRAM CS[0] base 0x00000000   size 128MB
DRAM Total size 128MB
[256kB@fffc0000] [0kB@f8000000] ## Unknown FLASH at f8000000: Size = 0x00000000 = 0 MB
Flash: 256 kB
Addresses 20M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (20M - 16M): Done

Soc: 88F5182 A2
CPU: ARM926 (Rev 0) running @ 400Mhz
Orion 1 streaming disabled
SysClock = 200Mhz , TClock = 166Mhz


USB 0: host mode
USB 1: host mode
PCI 0: PCI Express Root Complex Interface
PCI 1: Conventional PCI, speed = 33000000
Net:   egiga0 [PRIME]
Using 88E1118 phy

Marvell Serial ATA Adapter
Integrated Sata device found
  Device 0: OK
Model: SAMSUNG HD103UJ                          Firm: 1AA01109 Ser#: S13PJDWQ312925     
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)

Using device ide0, partition 1

Loading from block device ide device 0, partition 1: Name: hda1
  Type: U-Boot  File:/initrd.buffalo

3184637 bytes read
Using device ide1, partition 1
** Bad partition 1 **
Booting from Device 0
hit any key to switch tftp boot.
Hit any key to stop autoboot:  0
Hit any key to stop autoboot:  0

Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found
  Device 0: OK
Model: SAMSUNG HD103UJ                          Firm: 1AA01109 Ser#: S13PJDWQ312925     
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)

Using device ide0, partition 1

Loading from block device ide device 0, partition 1: Name: hda1
  Type: U-Boot  File:/uImage.buffalo

1560000 bytes read
Using device ide0, partition 1

Loading from block device ide device 0, partition 1: Name: hda1
  Type: U-Boot  File:/initrd.buffalo

3184637 bytes read
<<stop_sound>>
## Booting image at 00100000 ...
   Image Name:   kernel 3.16.0-4-orion5x
   Created:      2016-07-29  22:53:14 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1559936 Bytes =  1.5 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 00800000 ...
   Image Name:   ramdisk 3.16.0-4-orion5x
   Created:      2016-07-29  22:53:15 UTC
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    3184573 Bytes =  3 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Starting kernel ...

arg:console=ttyS0,115200 root=/dev/sda2 rw panic=5 BOOTVER=1.10
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16.0-4-orion5x (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02)
[    0.000000] CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=a005317f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Buffalo Linkstation Pro/Live
[    0.000000] Clearing invalid memory bank 0KB@0xffffffff
[    0.000000] Clearing invalid memory bank 0KB@0xffffffff
[    0.000000] Clearing invalid memory bank 0KB@0xffffffff
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Ignoring unrecognised tag 0x41000403
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 rw panic=5 BOOTVER=1.10
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 122276K/131072K available (2834K kernel code, 244K rwdata, 1004K rodata, 144K init, 253K bss, 8796K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc03c7c7c   (3840 kB)
[    0.000000]       .init : 0xc03c8000 - 0xc03ec194   ( 145 kB)
[    0.000000]       .data : 0xc03ee000 - 0xc042b290   ( 245 kB)
[    0.000000]        .bss : 0xc042b290 - 0xc046a6ac   ( 254 kB)
[    0.000000] NR_IRQS:64
[    0.000021] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps every 25769803770ns
[    6.425171] Console: colour dummy device 80x30
[    6.425212] Calibrating delay loop... 264.70 BogoMIPS (lpj=529408)
[    6.460651] pid_max: default: 32768 minimum: 301
[    6.460961] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    6.460995] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    6.462707] Initializing cgroup subsys devices
[    6.462807] Initializing cgroup subsys freezer
[    6.462852] Initializing cgroup subsys net_cls
[    6.462927] Initializing cgroup subsys blkio
[    6.462992] Initializing cgroup subsys perf_event
[    6.463031] Initializing cgroup subsys net_prio
[    6.463185] CPU: Testing write buffer coherency: ok
[    6.463996] Setting up static identity map for 0x2ad650 - 0x2ad68c
[    6.466908] devtmpfs: initialized
[    6.469650] VFP support v0.3: not present
[    6.470444] pinctrl core: initialized pinctrl subsystem
[    6.471174] NET: Registered protocol family 16
[    6.472240] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    6.474107] Orion ID: MV88F5182-A2. TCLK=166666667.
[    6.487268] Switched to clocksource orion_clocksource
[    6.508653] NET: Registered protocol family 2
[    6.511171] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    6.511246] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    6.511364] TCP: Hash tables configured (established 1024 bind 1024)
[    6.511512] TCP: reno registered
[    6.511548] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    6.511610] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    6.512087] NET: Registered protocol family 1
[    6.512668] Unpacking initramfs...
[    7.364712] Freeing initrd memory: 3104K (c0801000 - c0b09000)
[    7.366589] futex hash table entries: 256 (order: -1, 3072 bytes)
[    7.366800] audit: initializing netlink subsys (disabled)
[    7.366930] audit: type=2000 audit(0.936:1): initialized
[    7.368917] VFS: Disk quotas dquot_6.5.2
[    7.369039] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    7.369307] msgmni has been set to 244
[    7.371425] alg: No test for stdrng (krng)
[    7.371671] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    7.372207] io scheduler noop registered
[    7.372661] io scheduler cfq registered (default)
[    7.373750] mv_xor mv_xor.0: Marvell shared XOR driver
[    7.391417] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[    7.411419] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[    7.412186] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    7.413793] console [ttyS0] disabled
[    7.433874] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3, base_baud = 10416666) is a 16550A
[    7.872901] console [ttyS0] enabled
[    7.897335] serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 4, base_baud = 10416666) is a 16550A
[    7.908015] physmap platform flash device: 00040000 at f4000000
[    7.914218] Found: SST 39LF020
[    7.917364] physmap-flash.0: Found 1 x8 devices at 0x0 in 8-bit bank
[    7.923772] number of JEDEC chips: 1
[    7.955621] mousedev: PS/2 mouse device common for all mice
[    7.962048] i2c /dev entries driver
[    7.969783] rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6
[    7.981370] rtc (null): invalid alarm value: 2016-7-30 45:85:0
[    7.987704] rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
[    7.994815] ledtrig-cpu: registered to indicate activity on CPUs
[    8.001662] TCP: cubic registered
[    8.005069] NET: Registered protocol family 17
[    8.010858] registered taskstats version 1
[    8.017554] rtc-rs5c372 0-0032: setting system clock to 2016-07-30 10:12:00 UTC (1469873520)
[    8.027950] Freeing unused kernel memory: 144K (c03c8000 - c03ec000)
Loading, please wait...
[    8.221077] systemd-udevd[49]: starting version 215
[    8.240826] random: systemd-udevd urandom read with 4 bits of entropy available
[    8.499716] SCSI subsystem initialized
[    8.606689] sata_mv sata_mv.0: cannot get optional clkdev
[    8.637942] sata_mv sata_mv.0: slots 32 ports 2
[    8.698988] scsi0 : sata_mv
[    8.716771] scsi1 : sata_mv
[    8.727103] ata1: SATA max UDMA/133 irq 29
[    8.731299] ata2: SATA max UDMA/133 irq 29
[    9.211378] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    9.239680] ata1.00: ATA-7: SAMSUNG HD103UJ, 1AA01109, max UDMA7
[    9.245739] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    9.259716] ata1.00: configured for UDMA/133
[    9.264882] scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HD103UJ  1109 PQ: 0 ANSI: 5
[    9.595365] ata2: SATA link down (SStatus 0 SControl 300)
[    9.675171] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    9.686200] sd 0:0:0:0: [sda] Write Protect is off
[    9.691528] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    9.731094]  sda: sda1 sda2 sda4 < sda5 sda6 sda7 >
[    9.745139] sd 0:0:0:0: [sda] Attached SCSI disk
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.25.2
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2
/dev/sda2: recovering journal
/dev/sda2: clean, 32445/642112 files, 271820/2568391 blocks
done.
[   11.364396] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
[   11.882200] random: nonblocking pool is initialized
[   11.947397] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
[   11.961355] systemd[1]: Detected architecture 'arm'.

Welcome to Debian GNU/Linux 8 (jessie)!

[   12.101941] systemd[1]: Inserted module 'autofs4'
[   12.158582] NET: Registered protocol family 10
[   12.165247] systemd[1]: Inserted module 'ipv6'
[   12.187746] systemd[1]: Set hostname to <debian>.
[   12.536821] systemd-gpt-auto-generator[109]: Failed to determine partition table type of /dev/sda: Input/output error
[   12.550745] systemd[108]: /lib/systemd/system-generators/systemd-gpt-auto-generator failed with error code 1.
[   13.158290] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[   13.182490] systemd[1]: Expecting device dev-ttyS0.device...
         Expecting device dev-ttyS0.device...
[   13.199769] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
[   13.208117] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[   13.216014] systemd[1]: Starting Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems (Pre).
[   13.231717] systemd[1]: Reached target Remote File Systems (Pre).
[   13.238234] systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
[   13.246901] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[   13.255112] systemd[1]: Starting Paths.
[  OK  ] Reached target Paths.
[   13.267722] systemd[1]: Reached target Paths.
[   13.272584] systemd[1]: Starting Arbitrary Executable File Formats File System Automount Point.
[  OK  ] Set up automount Arbitrary Executable File Formats F...utomount Point.
[   13.295723] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[   13.305468] systemd[1]: Starting Encrypted Volumes.
[  OK  ] Reached target Encrypted Volumes.
[   13.319714] systemd[1]: Reached target Encrypted Volumes.
[   13.325467] systemd[1]: Expecting device dev-disk-by\x2duuid-5b3317d8\x2dc422\x2d4a4c\x2d8469\x2d403a5d27d910.device...
         Expecting device dev-disk-by\x2duuid-5b3317d8\x2dc42...7d910.device...
[   13.347778] systemd[1]: Expecting device dev-disk-by\x2duuid-d2d44709\x2d38c5\x2d410b\x2d84d4\x2db9eb78b15e13.device...
         Expecting device dev-disk-by\x2duuid-d2d44709\x2d38c...15e13.device...
[   13.371760] systemd[1]: Starting Root Slice.
[  OK  ] Created slice Root Slice.
[   13.387710] systemd[1]: Created slice Root Slice.
[   13.392757] systemd[1]: Starting User and Session Slice.
[  OK  ] Created slice User and Session Slice.
[   13.407717] systemd[1]: Created slice User and Session Slice.
[   13.413790] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
[   13.431718] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[   13.439016] systemd[1]: Starting Delayed Shutdown Socket.
[  OK  ] Listening on Delayed Shutdown Socket.
[   13.455715] systemd[1]: Listening on Delayed Shutdown Socket.
[   13.461796] systemd[1]: Starting Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket (/dev/log).
[   13.479715] systemd[1]: Listening on Journal Socket (/dev/log).
[   13.486034] systemd[1]: Starting udev Control Socket.
[  OK  ] Listening on udev Control Socket.
[   13.503714] systemd[1]: Listening on udev Control Socket.
[   13.509513] systemd[1]: Starting udev Kernel Socket.
[  OK  ] Listening on udev Kernel Socket.
[   13.527702] systemd[1]: Listening on udev Kernel Socket.
[   13.533390] systemd[1]: Starting Journal Socket.
[  OK  ] Listening on Journal Socket.
[   13.547714] systemd[1]: Listening on Journal Socket.
[   13.553156] systemd[1]: Starting System Slice.
[  OK  ] Created slice System Slice.
[   13.567713] systemd[1]: Created slice System Slice.
[   13.573041] systemd[1]: Started File System Check on Root Device.
[   13.579440] systemd[1]: Starting system-systemd\x2dfsck.slice.
[  OK  ] Created slice system-systemd\x2dfsck.slice.
[   13.595714] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[   13.602314] systemd[1]: Starting system-getty.slice.
[  OK  ] Created slice system-getty.slice.
[   13.619711] systemd[1]: Created slice system-getty.slice.
[   13.625433] systemd[1]: Starting system-serial\x2dgetty.slice.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[   13.643712] systemd[1]: Created slice system-serial\x2dgetty.slice.
[   13.650466] systemd[1]: Starting Increase datagram queue length...
         Starting Increase datagram queue length...
[   13.674928] systemd[1]: Mounting POSIX Message Queue File System...
         Mounting POSIX Message Queue File System...
[   13.716648] systemd[1]: Starting Create list of required static device nodes for the current kernel...
         Starting Create list of required static device nodes...rrent kernel...
[   13.797831] systemd[1]: Starting Load Kernel Modules...
         Starting Load Kernel Modules...
[   13.824717] systemd[1]: Mounted Huge Pages File System.
[   13.841631] systemd[1]: Starting udev Coldplug all Devices...
         Starting udev Coldplug all Devices...
[   13.895876] systemd[1]: Mounting Debug File System...
         Mounting Debug File System...
[   13.975953] systemd[1]: Started Set Up Additional Binary Formats.
[   14.007869] systemd[1]: Starting Slices.
[  OK  ] Reached target Slices.
[   14.031822] systemd[1]: Reached target Slices.
[   14.043786] systemd[1]: Starting Remount Root and Kernel File Systems...
         Starting Remount Root and Kernel File Systems...
[  OK  ] Mounted Debug File System.
[   14.123775] systemd[1]: Mounted Debug File System.
[  OK  ] Mounted POSIX Message Queue File System.
[   14.147740] systemd[1]: Mounted POSIX Message Queue File System.
[  OK  ] Started Increase datagram queue length.
[   14.171051] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[   14.177480] systemd[1]: Started Increase datagram queue length.
[  OK  ] Started Create list of required static device nodes ...current kernel.
[   14.211672] systemd[1]: Started Create list of required static device nodes for the current kernel.
[  OK  ] Started Load Kernel Modules.
[   14.231713] systemd[1]: Started Load Kernel Modules.
[  OK  ] Started Remount Root and Kernel File Systems.
[   14.267768] systemd[1]: Started Remount Root and Kernel File Systems.
[  OK  ] Started udev Coldplug all Devices.
[   14.447717] systemd[1]: Started udev Coldplug all Devices.
[   14.872241] systemd[1]: Started Various fixups to make systemd work better on Debian.
[   14.880424] systemd[1]: Starting Load/Save Random Seed...
         Starting Load/Save Random Seed...
[   14.908225] systemd[1]: Starting Apply Kernel Variables...
         Starting Apply Kernel Variables...
[   14.945383] systemd[1]: Mounted FUSE Control File System.
[   14.964940] systemd[1]: Mounted Configuration File System.
[   14.974819] systemd[1]: Starting Create Static Device Nodes in /dev...
         Starting Create Static Device Nodes in /dev...
[   15.013050] systemd[1]: Starting Syslog Socket.
[  OK  ] Listening on Syslog Socket.
[   15.043737] systemd[1]: Listening on Syslog Socket.
[   15.055768] systemd[1]: Starting Journal Service...
         Starting Journal Service...
[  OK  ] Started Journal Service.
[   15.103962] systemd[1]: Started Journal Service.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started Create Static Device Nodes in /dev.
         Starting udev Kernel Device Manager...
[  OK  ] Reached target Local File Systems (Pre).
[  OK  ] Started udev K[   15.614398] systemd-udevd[145]: starting version 215
ernel Device Manager.
         Starting Copy rules generated while the root was ro...
[  OK  ] Started Copy rules generated while the root was ro.
[   16.290588] MV-CESA:Could not register sha1 driver
[   16.295478] MV-CESA:Could not register hmac-sha1 driver
[   16.312172] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[   16.443249] usbcore: registered new interface driver usbfs
[  OK  ] Found device /dev/ttyS0.
[   16.495473] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   16.519747] usbcore: registered new interface driver hub
[   16.565708] usbcore: registered new device driver usb
[   16.581016] libphy: orion_mdio_bus: probed
[   16.622483] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   16.671178] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:16:01:c5:12:cf
[   16.682590] ehci-orion: EHCI orion driver
[   16.735731] orion-ehci orion-ehci.0: EHCI Host Controller
[   16.760321] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
[   16.858622] orion-ehci orion-ehci.0: irq 17, io mem 0xf1050000
[   16.907447] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
[   16.923018] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   16.930035] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   16.937334] usb usb1: Product: EHCI Host Controller
[   16.942264] usb usb1: Manufacturer: Linux 3.16.0-4-orion5x ehci_hcd
[   16.948569] usb usb1: SerialNumber: orion-ehci.0
[   17.005683] hub 1-0:1.0: USB hub found
[   17.031046] hub 1-0:1.0: 1 port detected
[   17.076062] orion-ehci orion-ehci.1: EHCI Host Controller
[   17.131490] orion-ehci orion-ehci.1: new USB bus registered, assigned bus number 2
[   17.217032] orion-ehci orion-ehci.1: irq 12, io mem 0xf10a0000
[   17.312968] orion-ehci orion-ehci.1: USB 2.0 started, EHCI 1.00
[   17.358645] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[   17.365527] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   17.372800] usb usb2: Product: EHCI Host Controller
[   17.377729] usb usb2: Manufacturer: Linux 3.16.0-4-orion5x ehci_hcd
[   17.384034] usb usb2: SerialNumber: orion-ehci.1
[   17.468440] hub 2-0:1.0: USB hub found
[   17.503547] hub 2-0:1.0: 1 port detected
[  OK  ] Found device SAMSUNG_HD103UJ 5.
         Activating swap /dev/disk/by-uuid/5b3317d8-c422-4a4c...403a5d27d910...
[   17.959781] Adding 506012k swap on /dev/sda5.  Priority:-1 extents:1 across:506012k
[  OK  ] Activated swap /dev/disk/by-uuid/5b3317d8-c422-4a4c-8469-403a5d27d910.
[  OK  ] Created slice system-ifup.slice.
[  OK  ] Reached target Swap.
[ TIME ] Timed out waiting for device dev-disk-by\x2duuid-d2d...8b15e13.device.
[DEPEND] Dependency failed for /boot.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for File System Check on /dev/disk...4-b9eb78b15e13.
[  OK  ] Stopped Getty on tty1.
[  OK  ] Stopped Serial Getty on ttyS0.
[  OK  ] Stopped getty on tty2-tty6 if dbus and logind are not available.
[  OK  ] Stopped target Graphical Interface.
[  OK  ] Stopped target Multi-User System.
[  OK  ] Stopped Regular background program processing daemon.
[  OK  ] Stopped Deferred execution scheduler.
[  OK  ] Stopped OpenBSD Secure Shell server.
[  OK  ] Stopped /etc/rc.local Compatibility.
[  OK  ] Stopped Login Service.
[  OK  ] Reached target Login Prompts.
[  OK  ] Stopped LSB: exim Mail Transport Agent.
[  OK  ] Stopped LSB: Daemon for Linkstation/Kuro micro controller.
[  OK  ] Stopped D-Bus System Message Bus.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Stopped Permit User Sessions.
[  OK  ] Reached target Remote File Systems.
         Starting Trigger Flushing of Journal to Persistent Storage...
[  OK  ] Stopped System Logging Service.
[  OK  ] Stopped target Basic System.
[  OK  ] Reached target Timers.
[  OK  ] Stopped target System Initialization.
         Starting Create Volatile Files and Directories...
         Starting LSB: Raise network interfaces....
[  OK  ] Closed Syslog Socket.
[  OK  ] Reached target Sockets.
         Starting Emergency Shell...
[  OK  ] Started Emergency Shell.
[  OK  ] Reached target Emergency Mode.
[  103.739782] systemd-journald[143]: Received request to flush runtime journal from PID 1
[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
[  OK  ] Started Create Volatile Files and Directories.
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Started Update UTMP about System Boot/Shutdown.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.
[  104.964734] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[  104.973308] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  OK  ] Started LSB: Raise network interfaces..
         Starting ifup for eth0...
[  OK  ] Started ifup for eth0.
[  OK  ] Reached target Network.
[  OK  ] Reached target Network is Online.
         Starting LSB: RPC portmapper replacement...
[  OK  ] Started LSB: RPC portmapper replacement.
[  OK  ] Reached target RPC Port Mapper.
         Starting LSB: NFS support files common to client and server...
[  106.647920] RPC: Registered named UNIX socket transport module.
[  106.653914] RPC: Registered udp transport module.
[  106.658653] RPC: Registered tcp transport module.
[  106.663391] RPC: Registered tcp NFSv4.1 backchannel transport module.
[  106.731517] FS-Cache: Loaded
[  106.804374] FS-Cache: Netfs 'nfs' registered for caching
[  106.911581] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[  107.097310] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 100 Mb/s, full duplex, flow control disabled
[  107.109447] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  OK  ] Started LSB: NFS support files common to client and server.
Welcome to emergGive root password for maintenance
(or type Control-D to continue):


I can log into the emergency console using my root password. I can run commands and so on then, but after 5 minutes the device starts bleeping and shuts down. I guess that since the HDD never sends an 'OK' message to microevtd then the OS goes into panic and shuts down.

Any ideas on where to proceed from here? My /boot partition is etx2 w/ 128byte inode size. My / partition was a freshly formatted one, ext4. I didn't touch my JFS data partition.


Top
   
PostPosted: Sat Jul 30, 2016 1:42 pm 
Offline
Newbie

Joined: Sun Jul 17, 2016 2:16 pm
Posts: 5
Okay, well I have it all fixed and working :) I reformatted /boot as ext2, 128byte inode. Then I launched Debian installer via tftpboot and reinstalled again. This time everything just worked fine :)


Top
   
PostPosted: Wed Aug 10, 2016 2:11 pm 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
stiltonsandwich wrote:
Nilpf3rd wrote:
Question:
On debian jessie, I still have problems with systemd-services. Especially after upgrading packages I cannot shutdown cleanly.
Do you have similar problems?

I have experienced some issues with shutdowns with Jessie on the HS-DHGL, but I haven't had time to troubleshoot it. Perhaps you have just given me a hint there about what could be causing it.

After many days of uptime, or periods of high CPU load (e.g. installing updates), it invariably fails to respond to shutdown commands and I have to manually power-cycle the unit. I have never tried another version of Debian on the box, so I don't know whether this is only a problem in Jessie.

I have also seen problems where the watchdog timer seems to time-out when the unit is under high CPU load for very long periods of time (tens of hours), which seems to suggest that the watchdog daemon needs a higher scheduling priority.


An update on the above:
  1. Giving micro-evtd a higher scheduling priority appears to have prevented the watchdog timer from timing-out under high load.
  2. The system still regularly gets into a state where it variously rejects SSH connections, fails to renew its DHCP lease, causing it to become inaccessible on the network, or (once or twice) stops responding to pings.
  3. I switched from systemd to sysvinit in an attempt to rule out any part of systemd as the cause. This seemed to cause the unit to reliably enter this failed state overnight, every night. (In other words: more frequently.)
    However, under sysvinit a normal shutdown is recorded in the logs when initiated using the hardware power button when the unit is in such a state.
  4. I theorised that the symptoms could be caused by the Linux OOM Killer killing essential processes due to an out-of-memory condition.
  5. I set up a cron job to log memory usage by process each hour.
  6. The logs from this showed that the memory usage spikes every day some time around 6AM -- roughly the same time when cron has been running the scripts in /etc/cron.daily/.
    After these spikes, dhclient goes missing from the list of running processes, obviously causing the system to lose its DHCP lease.
  7. My working theory is that something in /etc/cron.daily/ is causing an OOM condition, and the OOM Killer selects dhclient as a candidate to be killed. I suspect the apt script is probably the culprit.
  8. I've also noticed that often aptitude will exit (from interactive mode) with "Ouch! Got SIGSEGV, dying...", which would seem to validate the idea that the system does not have sufficient memory to perform some package management operations. Having said that, I monitored the memory usage the last time I used aptitude, and got this message, and though swap usage rose from zero, it was nowhere near maximum.
  9. The daily spike in memory usage seems to be attributable mainly to buffer (as seen in the output of free) rather than any running process. This is presumably being caused by a process which finishes executing before my logging script runs, but which causes a lot of buffer usage. I have changed my cron job to run a few times at the same time when cron runs /etc/cron.daily/ in the hope of catching more useful information tomorrow morning.
  10. This seems to suggest that perhaps it was not so much high CPU usage that caused the box to fail (in my original diagnosis), but rather high IO usage, leading to high buffer or cache usage.
  11. I suspect that, under systemd, memory usage was slightly lower in some way, but still borderline, hence the problem occurred perhaps once every two or three days when it got pushed over the edge instead of reliably every day.
    Or perhaps one of systemd's processes got OOM-killed instead of dhclient, so the system remained accessible on the network. Perhaps this could explain some of the failures to shutdown or restart, if a process critical to that action was getting killed.

Working on the assumption that I am dealing with an out-of-memory situation here, I will continue my investigation and try to answer some of these questions:
  1. Specifically what runs every day that causes the failure? (Currently I suspect it's that apt script, but that's unconfirmed.)
  2. Does it need to? Can it be made to use less memory?
  3. Clearly, even if something is using up all of the memory, killing dhclient is not the solution, because then, without a serial terminal, I have to reboot the system in order to access it. What is the best way to configure the system such that dhclient has a low oom-score-adj value or alternatively a low niceness value, to prevent this?
  4. If I adjust dhclient's oom-score-adj without resolving the memory usage issue, something else will probably get killed instead. Which processes would get killed? Would it end up becoming a game of whack-a-mole until every process on the system has been manually adjusted, ultimately leaving the OOM Killer no options?
  5. Is Debian Jessie simply too memory hungry to run on this hardware?


Top
   
PostPosted: Sun Aug 21, 2016 1:54 pm 
Offline
Newbie

Joined: Sun Jan 31, 2016 8:10 pm
Posts: 9
Another update.
Following my previous post:
  • I have confirmed that dhclient was being killed just after 06:25 every morning; the time when my /etc/cron.daily/ scripts run.
  • I have run:
    Code:
    # echo 2 > /proc/sys/vm/overcommit_memory
    # echo 100 > /proc/sys/vm/overcommit_ratio
    in a root shell (sudo su).
    • This, as I understand it, effectively disables memory overcommitment until the next reboot.
    • This enabled me to obtain an uptime of over 4 days without dhclient being killed every morning at 06:25.
    • (It might have gone on longer if I hadn't rebooted for a separate reason.)
    • rsyslogd failed to start after the log rotation on the morning of the third day of uptime.
      • rsyslogd failing to start seems consistent with the idea that one of the /etc/cron.daily/ scripts was using up too much memory.
      • With another process using lots of memory and with overcommitment disabled, rsyslogd could likely not be promised enough memory to allow it to start.
  • I ran most of the scripts in /etc/cron.daily/ individually, while watching memory usage in top.
    • The apt script did not use much memory, so I don't think it can be blamed.
    • The mlocate script used a lot of memory, causing an increase in swap usage. I think it is the main culprit here.
    • Running the mlocate script alone didn't cause dhclient to get killed off, but perhaps running it in conjunction with all the other cron.daily scripts was enough to push the system over the edge.
  • The mlocate script updates a database for the mlocate tool, which provides a version of the locate program.
  • I don't use mlocate or locate on the LinkStation, so I removed the mlocate package using aptitude.
  • I reverted the memory overcommitment settings to the default and let the system run.
    • This time, without mlocate, the system survived 06:25 without killing dhclient or, seemingly, anything else. Problem solved?
    • I think I will leave memory overcommitment enabled for the time being.

So, in summary, the solution to my problems seems to have been: sudo aptitude remove mlocate!

Switching to sysvinit seems to have made shutdowns and reboots faster and more reliable, so I think I will stick with that for now. However, it looks like systemd uses less memory, so it could be seen as a better choice.

There are still some outstanding issues. The system struggles to run aptitude. Sometimes aptitude terminates abnormally at the point where the ncurses interface comes back up, after processing the changes to packages. With memory overcommitment enabled in the kernel, it usually says "Ouch! Got SIGSEGV, dying...". With memory overcommitment disabled, it usually says "*** stack smashing detected ***: sudo terminated". This would not be a huge problem except that it tends to bring down SSH as well, forcing me to physically access the hardware. But it only occurs when I choose to run aptitude in interactive mode, so I have control over when it happens and can therefore avoid doing it at inconvenient moments.

So, to answer my earlier questions:
stiltonsandwich wrote:
Working on the assumption that I am dealing with an out-of-memory situation here, I will continue my investigation and try to answer some of these questions:
  1. Specifically what runs every day that causes the failure? (Currently I suspect it's that apt script, but that's unconfirmed.)
    • A: Mainly /etc/cron.daily/mlocate, in combination with the other cron.daily scripts.
  2. Does it need to? Can it be made to use less memory?
    • A: No, it doesn't. I have removed it.
  3. Clearly, even if something is using up all of the memory, killing dhclient is not the solution, because then, without a serial terminal, I have to reboot the system in order to access it. What is the best way to configure the system such that dhclient has a low oom-score-adj value or alternatively a low niceness value, to prevent this?
    • A: The answer is probably "don't try". If you must stop the OOM Killer, disable memory overcommitment instead. Better still, find out what's using all the memory and make it use less.
  4. If I adjust dhclient's oom-score-adj without resolving the memory usage issue, something else will probably get killed instead. Which processes would get killed? Would it end up becoming a game of whack-a-mole until every process on the system has been manually adjusted, ultimately leaving the OOM Killer no options?
    • A: Probably. But it's irrelevant.
  5. Is Debian Jessie simply too memory hungry to run on this hardware?
    • A: No, but it's borderline!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 17 posts ]  Go to page 1 2 Next

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 10 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:
Powered by phpBB® Forum Software © phpBB Limited