• 0

Change ramlog to direct log writing in kernel 3.4.107


apollon77
 Share

1 1

Question

Hi,

 

I'm using the 3.4.107 kernel at the moment and I have also attached an HDD.

 

Now I have the problem that the CUbietruck get's unresponsive once every 1-2 weeks and because of the ramlog I have no logs to see what the problem is.

All services stop working, but power is still "on".

 

My only idea is to replace ramlog solution by "normal" logfile writing (and because I use an HDD it's maybe better to directly write on HDD in any case) to have infos when the machine crashes the next time.

 

What I do need to do for that (I'm not really a linux expert ;-) ).

 

Thanks for help.

 

Ingo F

Link to post
Share on other sites

Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

And while fixing my kernel-update problems I installed the nand completely new from sd.SO it should be the correct one as in the 3.4.108 sd-image.

Does the rootfs on sata come into play somehow?

 

I use the Cubietruck for home automation. There are two node.js apps running and I installed ups-tools for my apc. I have set up some "Monitoring" where some ports and the IP itself are "Ping"ed every minute to detect if the port or machine goes offline.

But nothing more ...

Link to post
Share on other sites

  • 0

I am almost out of suggestions. Try two things:

 

- boot from SD and leave everything as is. SATA install yes but not boot from NAND. This part is critical in any case since it's based on some very old boot procedure.

- use rather kernel 4.x if you can use with your hardware

- change SD card, PSU

Link to post
Share on other sites

  • 0

How can I see if the boot was done by SD card?

 

I changed that line and recreated the scr-file and rebootet with sd-card in the slot.

Reboot was successfull, but /boot is mounted to /dev/nand1 ... ?! So this is not the correct place at latest when an update should be done, or ?!

Link to post
Share on other sites

  • 0

Yes I want to get away from nand, but I need rootfs on sata because the home-automation applicated make much i/o ... and ideally do not want to need to install everything new :-(

 

Before I changed the boot.scr it was always booted from sd when the card was inserted.

 

Then I changed the rootfs-location and generated new src file and rebooted as you said. Should cleaning /dev/nand1 (where boot is mounted on) bring an effect?

Or should I try to resize my sata to have a second partition sda2 and then use fresh sd-boot-image and install to sda2 with script and then change rootfs to sda1 ? Or installing anything new ...?!

Link to post
Share on other sites

  • 0

If SD is inserted and there is an u-boot on it than it will always start from SD card.

 

Forget about my install procedures. They are only good for fresh start.

 

1. Create SD card

2. Boot, wait that it finish first boot

3. Login and alter boot scripts to point root to /dev/sda1 

4. Copy /lib/modules/ to /dev/sda1 to make sure you have right modules

5. Reboot

 

 

I think that's all. 

Link to post
Share on other sites

  • 0

Ok,

 

1. Done

2. Done

3. first line of boot.cmd is now after change:

setenv bootargs console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reser
ve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1

After this:

root@cubietruck:/boot# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
Image Name:
Created:      Sat Aug  1 21:30:04 2015
Image Type:   ARM Linux Script (uncompressed)
Data Size:    1480 Bytes = 1.45 kB = 0.00 MB
Load Address: 00000000
Entry Point:  00000000
Contents:
   Image 0: 1472 Bytes = 1.44 kB = 0.00 MB

4. Were already there

5. Done

 

... result after reboot:

root@cubietruck:~# df
Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs         961433632 1819268 910776288   1% /
/dev/root      961433632 1819268 910776288   1% /
devtmpfs         1023328       0   1023328   0% /dev
tmpfs             131072     252    130820   1% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs             131072       0    131072   0% /run/shm
/dev/nand1         16334    6010     10324  37% /boot
tmpfs            1048576       0   1048576   0% /tmp

So effect as before ... Is there any way to check which files used to boot up?

 

Maybe the mountpoint for /boot is stored somewhere on sata and therefor I need to unmount /boot and mount to /boot on sd card one time so that correct files are used?

Link to post
Share on other sites

  • 0

Maybe the mountpoint for /boot is stored somewhere on sata and therefor I need to unmount /boot and mount to /boot on sd card one time so that correct files are used?

 

Yes it is  :unsure: Forgot about that, alter /etc/fstab on your hard drive and you are fine.

Link to post
Share on other sites

  • 0

But to the question from above: When my rootfs comes from sata and I boot from SD - what do I need to have in my /etc/fstab?

 

I thought that I need to mount the "/boot" directory from SD card as "/boot" in my system in order that the files are correctly used for booting AND also for the next kernel-updates or such that modify filesin the "/boot" on SD ...

 

Or do I missunderstand something completely?

Link to post
Share on other sites

  • 0

OK, for proper future updating you need to mount the media of your boot. But if you boot from SD it's a bit more complex. Under /boot you need to mount a directory /boot from SD card - device /dev/mmcblk0p1

/dev/mmcblk0p1        /media/mmc   ext4    defaults        0       0
/media/mmc/boot   /boot   none    bind        0       0
Link to post
Share on other sites

  • 0

Hm, still not visible when calling "mount" or "df" ... first ...

 

Then I created /media/mmc as direciry and rebooted again ...

 

now it seems to work:

root@cubietruck:~# df
Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs         961433632 1830376 910765180   1% /
/dev/root      961433632 1830376 910765180   1% /
devtmpfs         1023328       0   1023328   0% /dev
tmpfs             131072     256    130816   1% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs             131072       0    131072   0% /run/shm
/dev/mmcblk0p1  30687916  971196  28464012   4% /media/mmc
/dev/mmcblk0p1  30687916  971196  28464012   4% /boot
tmpfs            1048576       0   1048576   0% /tmp

So solved mow. You are great!! Thank you for all your help!!

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

1 1