Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Fri Nov 17, 2017 6:20 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 37 posts ]  Go to page Previous 1 2 3 Next
Author Message
PostPosted: Mon Mar 04, 2013 10:25 pm 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
Thank you very much for uploading them to pastebin! I just checked, if I quote your post, I can also copy and paste your patches with tabs instead of spaces... I think it's a phpBB2 bug/unwanted feature ;)

I saved them using the copy image. I tried dry-running them, this is what I get:

Quote:
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p1.lswvl
patching file kernel/module.c
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 2322 with fuzz 1.
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p2.lswvl
patching file arch/arm/mach-orion5x/common.c
patching file arch/arm/mach-orion5x/addr-map.c
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 76 with fuzz 1.
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p3.lswvl
patching file arch/arm/mach-dove/common.c
patching file arch/arm/mach-kirkwood/common.c
patching file arch/arm/mach-mv78xx0/common.c
patching file arch/arm/mach-orion5x/common.c
patching file arch/arm/plat-orion/common.c
patching file arch/arm/plat-orion/include/plat/common.h
patching file drivers/net/ethernet/marvell/mv643xx_eth.c
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 965 with fuzz 1.
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p5.lswvl
patching file arch/arm/mach-kirkwood/Kconfig
patching file arch/arm/mach-kirkwood/lswvl-setup.c
patching file arch/arm/mach-kirkwood/Makefile
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 18 with fuzz 2.
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p6.lswvl
patching file arch/arm/plat-orion/mpp.c
patching file drivers/spi/spi-orion.c
patch unexpectedly ends in middle of line
Hunk #4 succeeded at 390 with fuzz 1.
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p8.lswvl
patching file Makefile
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 620 with fuzz 2.
root@NAS:/usr/src/linux# patch -Np1 --dry-run -i ~/patch/p9.lswvl
patching file arch/arm/tools/mach-types
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 276 with fuzz 1.
root@NAS:/usr/src/linux#

They all give a 'patch unexpectedly ends in middle of line'-caution (or warning), but the succeed? I am going to try to compile this now, but I thought I should post this.


Top
   
PostPosted: Tue Mar 05, 2013 2:31 am 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
Since it didn't report any error, I think it should be OK. I'm not very good at those patch things, but I think it may be caused by the last extra empty line that generated when I copy the the content to the web page. I think the best is to package the patches in a archive then uploaded to somewhere. Anyway, the files you got should still be useful.


Top
   
PostPosted: Wed Mar 06, 2013 8:16 am 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
Thank you, I compiled the kernel with: no errors or whatsoever

Code:
make uImage modules
cp arch/arm/boot/uImage uImage.buffalo.debian
make modules_install INSTALL_MOD_PATH=./modules


The NAS boots, no red light but I cannot reach it anymore. Doesn't respond to ping and doesn't show up in the device list of my router. I am pretty sure I added ethernet support in makeconfig. I first did 'make defconfig'. That should be enough I think?

Next compile I will try your config. Why are we not supposed to use it, I don't understand the warning about u-boot.

Again, thanks for your time!

edit: here is my config. Any idea what's wrong with it?


Top
   
PostPosted: Wed Mar 06, 2013 3:48 pm 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
I'm not sure why your config didn't work. But remember to read my warning before you go with my configuration, especially pay attention to those configurations:

Code:
CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/sda2 rw"
CONFIG_CMDLINE_FORCE=y


It means the kernel will despite what the u-boot tell it, it will boot from /dev/sda2. So if your boot files are not there, the boot will fail.

P.S. Do you name your new kernel uImage.buffalo (a symbolic link will also work)? Also the initrd.buffalo is still needed (even if you DON'T need it. It could be empty, but it must be there).
Are you using a new disk to try?
Did you apply the 9th patch (for fixing the mach-type)?

P.P.S. What user space are you using? Debian? Original firmware will NOT work with the new kernel.
P.P.P.S. I noticed you didn't enable EFI partition table support. If you are using the disk partitioned by the original firmware, you must enable EFI support since the disk would use EFI partition (at least it's the case for my disk).
P.P.P.P.S Why were you using "CONFIG_ARCH_VERSATILE=y" instead of "CONFIG_ARCH_KIRKWOOD=y"?


Top
   
PostPosted: Wed Mar 06, 2013 9:15 pm 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
hato wrote:
I'm not sure why your config didn't work. But remember to read my warning before you go with my configuration, especially pay attention to those configurations:

Code:
CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/sda2 rw"
CONFIG_CMDLINE_FORCE=y


It means the kernel will despite what the u-boot tell it, it will boot from /dev/sda2. So if your boot files are not there, the boot will fail.

Thank you for pointing that out! I am now reverting my kernel by mounting it in another PC. I am using RAID1, so let me check where my root is

hato wrote:
P.S. Do you name your new kernel uImage.buffalo (a symbolic link will also work)? Also the initrd.buffalo is still needed (even if you DON'T need it. It could be empty, but it must be there).
Are you using a new disk to try?
Did you apply the 9th patch (for fixing the mach-type)?


I am not using a new disk. I started with Shonk's mod1.64a, on which I installed debian using this guide, in RAID1 config. Everything was working fine. I also applied the mach-type patch. I applied all the patches you provided. I believe initrd.buffalo is there, since I had a fully functioning NAS before I switched to the new kernel.

hato wrote:
P.P.S. What user space are you using? Debian? Original firmware will NOT work with the new kernel.

As stated before in this post, I installed debian.
hato wrote:
P.P.P.S. I noticed you didn't enable EFI partition table support. If you are using the disk partitioned by the original firmware, you must enable EFI support since the disk would use EFI partition (at least it's the case for my disk).

I don't know why I did not enable EFI partition table support. I used 'make defconfig' to make a .config file from which I could work from with 'make menuconfig'. I will enable it on the next try.
hato wrote:
P.P.P.P.S Why were you using "CONFIG_ARCH_VERSATILE=y" instead of "CONFIG_ARCH_KIRKWOOD=y"?

I don't know :cry: I will see if I can find this settings in 'make menuconfig'. If not, I assume I can alter the .config file? I replace VERSATILE=y with KIRKWOOD=y?

Edit:
Two questions, I installed the kernel with

Code:
su
mount -o remount,rw /boot

mv /boot/uImage.buffalo /boot/uImage.buffalo.old
cp uImage.buffalo.debian /boot/uImage.buffalo

cp -a modules/lib/modules/3.3.4 /lib/modules

mknod /dev/rtc c 254 0

reboot


Is this correct? I now want to revert back to the old kernel which was named 'uImage.buffalo.old'. I put the drive in another computer, and with knoppix I renamed uImage.buffalo to uImage.buffalo.debian and uImage.buffalo.old to uImage.buffalo. It's not starting up now. I have a RAID1 configuration, but only one drive using. I was planning on adding the second drive when the whole drive was working. Now I just have the rapid blinking light.

I suspect this is because of the modules I copied. I have a backup of the old modules directory. I am now putting those files back the same way I renamed the uImage.buffalo files. Do you think this will work?

Also, do you think I used a good kernel 3.3.4?


Top
   
PostPosted: Thu Mar 07, 2013 2:07 am 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
I don't understand what "a good kernel 3.3.4" means? Anyway, to make you old kernel work, you have to restore its corresponding kernel modules in addition to the kernel uImage itself. As long as your old kernel is not the same version as your new one, you don't have to remove the kernel module from /lib/modules when changing the kernel, they can be there all at the same time. And using symbolic link (aka. soft link) is better than removing/renaming the files every time, you just need to change what the link actually links to.

You mentioned you are using raid1, so its possible that you are using MD device as root device. In that case, your old configuration may be using initrd to assemble and mount the actual root partition. In that case, I can't help too much since I never used that configuration(you may need to update the initrd?), it's too complicated for me :lol: . Even when I need to use RAID 1 partition as root, I choose to directly change the kernel parameters to use the RAID partition as root (and of course let the kernel assemble the raid devices). That would be simpler, but not necessarily the best practice.

P.S. Directly edit .config is not a good idea because of the dependencies. The SOC type (KIRKWOOD) and board model (LSWVL) shall be in the "System Type"


Top
   
PostPosted: Thu Mar 07, 2013 9:42 pm 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
hato wrote:
I don't understand what "a good kernel 3.3.4" means? Anyway, to make you old kernel work, you have to restore its corresponding kernel modules in addition to the kernel uImage itself. As long as your old kernel is not the same version as your new one, you don't have to remove the kernel module from /lib/modules when changing the kernel, they can be there all at the same time. And using symbolic link (aka. soft link) is better than removing/renaming the files every time, you just need to change what the link actually links to.

I only copied the 3.3.4 modules to /lib/modules/3.3.4. I will doublecheck this, but as far as I know I have not removed the old modules. So putting the old kernel in place should do the trick right? I hope I am missing something, because the NAS is still not booting.. I hope I can fix this using another linux box, I really don't feel like re-installing the system AGAIN.. I've lost count so many times.

hato wrote:
You mentioned you are using raid1, so its possible that you are using MD device as root device. In that case, your old configuration may be using initrd to assemble and mount the actual root partition. In that case, I can't help too much since I never used that configuration(you may need to update the initrd?), it's too complicated for me :lol: . Even when I need to use RAID 1 partition as root, I choose to directly change the kernel parameters to use the RAID partition as root (and of course let the kernel assemble the raid devices). That would be simpler, but not necessarily the best practice.
[/quote[I am using RAID1 yes. I created a initrd using this, and I used this initrd for a while in debian user land (am I saying this right? ;) ). Do you think I have to update this, just for a kernel update?

edit:. I read up on initrd. It's a file which has the basic drivers to further load the OS (debian in this case), am I right? I read though the guide on creating an initrd file. I am having trouble seeing what files are changed when I perform a kernel upgrade. Also, I don't know how to upgrade said initrd file during kernel compilation process. I know it's not your 'speciality', but could you shed a light? :)
hato wrote:
P.S. Directly edit .config is not a good idea because of the dependencies. The SOC type (KIRKWOOD) and board model (LSWVL) shall be in the "System Type"

Noted! I will see if I can find it.

I am now downloading Debian Live so I can use that on a USB stick on my second computer. I was going absolutely mental with Knoppix. I couldn't figure out how I turned off the idiotic visuals. I will try to move things around tomorrow after work. If it's not working, I again have to re-install the NAS.. Happy moments!

Thanks for the help, I will call back in tomorrow with hopefully some news.

Ciao!


Top
   
PostPosted: Fri Mar 08, 2013 3:53 am 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
I had a quick glance at the guide you mentioned. As far as I can see, the initrd contains nothing that really needs to be updated when changing kernel. But debian's own kernel update procedure do update the initrd whenever the kernel updated (may concerned with the kernel header. But I myself normally directly update a vanilla kernel without updating the kernel header. In fact I never did that :oops: ).
The thing that confuses me is according to your description, you created your own initrd, and used it for a while, and you didn't update it when using the newest kernel - So when you reverted the kernel back, why the disk can't boot? Maybe it's something else.


Top
   
PostPosted: Fri Mar 08, 2013 11:00 pm 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
hato wrote:
I had a quick glance at the guide you mentioned. As far as I can see, the initrd contains nothing that really needs to be updated when changing kernel. But debian's own kernel update procedure do update the initrd whenever the kernel updated (may concerned with the kernel header. But I myself normally directly update a vanilla kernel without updating the kernel header. In fact I never did that :oops: ).

The only thing I did was copy the modules over, and the kernel (here).
hato wrote:
The thing that confuses me is according to your description, you created your own initrd, and used it for a while, and you didn't update it when using the newest kernel - So when you reverted the kernel back, why the disk can't boot? Maybe it's something else.

Exactly. I tried reverting the kernel with my freshly downloaded Debian Live Gnome, but no joy. I am now in the process of reinstalling everything.

I think it has something to do with raid device. Maybe if you mount a raid drive on another machine, the drive is not configured to be mounted on the previous system? I'm just saying, it's probably jabberish :+

Good night, will update tomorrow.. I've been battling this now for 2-3 months, and only for OpenVPN! I refuse to give up, I'm gonna kill this. Thanks, and have a good weekend!


Top
   
PostPosted: Sun Mar 10, 2013 4:39 pm 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
Hello again, what a beautiful day it is to mess around with kernels!

I am now compiling the kernel: Here is what I did:

Code:
apt-get install build-essential fakeroot uboot-mkimage debhelper python libncurses5-dev


Code:
root@NAS:~# cd /usr/src
root@NAS:/usr/src# wget http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.7.tar.bz2
--2013-02-11 10:45:21--  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.7.tar.bz2
Resolving www.kernel.org... 149.20.20.133
Connecting to www.kernel.org|149.20.20.133|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80186282 (76M) [application/x-bzip2]
Saving to: âlinux-3.4.7.tar.bz2â

100%[======================================>] 80,186,282   188K/s   in 7m 2s

2013-02-11 10:52:24 (186 KB/s) - âlinux-3.4.7.tar.bz2â

root@NAS:/usr/src# tar xjf linux-3.4.7.tar.bz2
root@NAS:/usr/src# ln -s linux-3.4.7 linux
root@NAS:/usr/src# cd linux
root@NAS:/usr/src/linux#


LS-WVL patches for LS-WVL kernel 3.4 (3.4.7 should also be OK) released by hato:
Code:
wget http://pastebin.com/download.php?i=j71499jJ -O patch1.lswvl
wget http://pastebin.com/download.php?i=TGsgjSiy -O patch2.lswvl
wget http://pastebin.com/download.php?i=w4kUTQX2 -O patch3.lswvl
wget http://pastebin.com/download.php?i=yDSBf7qY -O patch5.lswvl
wget http://pastebin.com/download.php?i=A4atvVH5 -O patch8.lswvl
wget http://pastebin.com/download.php?i=bjb2ghmb -O patch9.lswvl


I downloaded these patches in ~/. I did not patch 6 and 7. 6 gave errors and I am compiling it native, so the cross compilation patch was not needed.

Patching in /usr/src/linux

First a testrun:
Code:
patch -Np1 --dry-run -i ~/patch1.lswvl
patch -Np1 --dry-run -i ~/patch2.lswvl
patch -Np1 --dry-run -i ~/patch3.lswvl
patch -Np1 --dry-run -i ~/patch5.lswvl
patch -Np1 --dry-run -i ~/patch8.lswvl
patch -Np1 --dry-run -i ~/patch9.lswvl

I had a 'patch unexpectedly ends in middle of line' and a 'Stripping trailing CRs'. I think the last notice came from using 'wget pastebin -O file' instead of copy/pasting it. But I was lazy, and I suspect that this will not be my last try at compiling a kernel for the LS-WVL, so I needed quickers ways for future endeavours :P

Actual patching:
Code:
patch -Np1 -i ~/patch1.lswvl
patch -Np1 -i ~/patch2.lswvl
patch -Np1 -i ~/patch3.lswvl
patch -Np1 -i ~/patch5.lswvl
patch -Np1 -i ~/patch8.lswvl
patch -Np1 -i ~/patch9.lswvl

Same output as a dry-run.

Then I did 'make defconfig', 'make menuconfig'.

- Enable EFI GUID Partition table support
- System type to Marvel Kirkwood
- Marvel Kirkwood implementations (? Not sure, doing this from memory) set to Buffalo LS-WVL (That was kind of sweet to see, is it there because of the patch? Really happy moment haha)

And for my own purpose I enable 'Tun/Tap drivers'

Saved the .config file (here), and started compiling:

Code:
make uImage modules
cp arch/arm/boot/uImage uImage.buffalo.debian
make modules_install INSTALL_MOD_PATH=./modules


Installation:

Code:
su
mount -o remount,rw /boot

mv /boot/uImage.buffalo /boot/uImage.buffalo.old
cp uImage.buffalo.debian /boot/uImage.buffalo

cp -a modules/lib/modules/3.4.7 /lib/modules

mknod /dev/rtc c 254 0

reboot


Result? Endless reboots. I'm having a drink.


Last edited by VolleMelk on Thu Mar 14, 2013 10:01 pm, edited 1 time in total.

Top
   
PostPosted: Mon Mar 11, 2013 5:29 am 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
I don't understand why patch6 (for the mpp multiplex one, right?) gave error?

To debug the problem, since the kernel is not at least "booting", try to enable net console to get an idea of what's wrong? And I have to point out that maybe the kernel is actually working now. Maybe some user space program that's using old-buffalo-kernel-stuff needs to be removed/replaced to get the system work.

Would you please try to hook the disk to another machine to see whether the /var/log/dmesg gets updated after the endless reboot? So you can get to know why (or when) the system reboots.

And is "mknod /dev/rtc ..." realy needed?

P.S. I just realized one serious problem regarding using the new kernel when I was browsing on the web: If your disk was formatted as XFS, don't use this mainline kernel. The XFS code is still problematic (at least on arm SOC with vanilla kernel 3.4.). Refer to this thread for my experience.


Top
   
PostPosted: Thu Mar 14, 2013 8:10 pm 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
hato wrote:
I don't understand why patch6 (for the mpp multiplex one, right?) gave error?

Me neither, I'm sorry I didn't copy the error. I should've done that. I just read the patch again, and it says it's for kernel 3.2.4. My last try was with 3.4.7. I once tried to compile kernel 3.3.4, no error was given! I think that's the problem. My next try will be with 3.2.4.

hato wrote:
To debug the problem, since the kernel is not at least "booting", try to enable net console to get an idea of what's wrong? And I have to point out that maybe the kernel is actually working now. Maybe some user space program that's using old-buffalo-kernel-stuff needs to be removed/replaced to get the system work.

I will google on netconsole, but I assume it's a kernel module. I will enable it

hato wrote:
Would you please try to hook the disk to another machine to see whether the /var/log/dmesg gets updated after the endless reboot? So you can get to know why (or when) the system reboots.

Working on it now. Thanks!
hato wrote:
And is "mknod /dev/rtc ..." realy needed?

I don't know, I just copied it from the guide for Debian on LS-WXL. I guess it's not needed, I will install a NTP package anyway.
hato wrote:
P.S. I just realized one serious problem regarding using the new kernel when I was browsing on the web: If your disk was formatted as XFS, don't use this mainline kernel. The XFS code is still problematic (at least on arm SOC with vanilla kernel 3.4.). Refer to this thread for my experience.

This is how I install debian:
First I install it to a temporary partition, /dev/md2 (the big one with all the TBs), boot from it. Immediately after I format /dev/md1 to ext3 with
Code:
mkfs.ext3 /dev/md1
tune2fs -c0 -i0 /dev/md1

Mount it, and copy over the rootfs to /dev/md1. Reboot. Then I format /dev/md2 to ext3 using the same way. As far as I can see, everything is ext3.

Going again tonight, keep you posted!

Edit1: I just hooked up the drive to another PC, and I noticed that /dev/sda2 (I believe this is /dev/md1) has the label 'LS-WVL-EM077:1), and /dev/sda/6 (/dev/md10) is LS-WVL-EM077:10. I believe /dev/md10 is swap, and /dev/md1 is /

Edit2: I have obtained /var/log/dmesg. I have uploaded it here: http://pastebin.com/7u0MAfGe Apart from a lot of raid warnings/cautions I don't think it looks suspicious. I have 4 raid devices: http://pastebin.com/qd8gdpjN I also have dmesg.0, but it just says 'Nothing has been logged yet'.

Edit3: I really think it has something to do with the partitions:
Quote:
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 800c0910 to a partition!
mdadm: sending ioctl 800c0910 to a partition!
md: md2 stopped.
md: bind<sda6>
bio: create slab <bio-1> at 1
md/raid1:md2: active with 1 out of 2 mirrors
md2: detected capacity change from 0 to 2984830812160
md: md10 stopped.
md: bind<sda5>
md/raid1:md10: active with 1 out of 2 mirrors
md10: detected capacity change from 0 to 1024446464
md: md1 stopped.
md: bind<sda2>
md/raid1:md1: active with 1 out of 2 mirrors
md1: detected capacity change from 0 to 5119135744
md: md0 stopped.
md: bind<sda1>
md/raid1:md0: active with 1 out of 2 mirrors
md0: detected capacity change from 0 to 1024393216
md1: unknown partition table
kjournald starting. Commit interval 5 seconds
EXT3-fs (md1): using internal journal
EXT3-fs (md1): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 9:1.
Trying to move old root to /initrd ... /initrd does not exist. Ignored.
Unmounting old root
Trying to free ramdisk memory ... okay
Freeing init memory: 148K
md0: unknown partition table
md10: unknown partition table
md2: unknown partition table
Adding 1000432k swap on /dev/md10. Priority:-1 extents:1 across:1000432k
EXT3-fs (md1): using internal journal
kjournald starting. Commit interval 5 seconds
EXT3-fs (md0): using internal journal
EXT3-fs (md0): mounted filesystem with writeback data mode

Why does it say ext2 for root?

*mind exploded*
I can't tell if this will fix all my problems, but I just found out that I did not enable any RAID support.. Added it in menuconfig, compiling now

Here you can see what I've been doing up until now: http://pastebin.com/Et0fJhxF


Top
   
PostPosted: Fri Mar 15, 2013 9:09 am 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
Unfortunately, the dmesg log you posted is NOT generated by the new kernel, which means the new kernel didn't managed to reach the user space yet. Look at this line:

Code:
Machine: Feroceon-KW


If you booting from the new kernel, you should have seen:

Code:
Machine: Buffalo LS-WVL/E-AP NAS

Anyway you mentioned you didn't enable any MD support, so this result is expected.

But it's interesting to see the actually used kernel (I guess it came from the firmware mod?) was also 3.3.4. Does Buffalo use so "fresh" kernel for their firmware or you used another patched vanilla kernel?

One thing looks really weird:
Code:
cd /usr/src
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.3.4.tar.bz2
tar xjf linux-3.3.4.tar.bz2
ln -s linux-3.4.7 linux
cd linux


Why are you downloading 3.3.4, but using 3.4.7 instead?


Top
   
PostPosted: Fri Mar 15, 2013 9:18 am 
Offline
Newbie

Joined: Wed Dec 12, 2012 10:25 am
Posts: 72
I compiled and installed the kernel as here: http://pastebin.com/Et0fJhxF

I did the installation part remote, but I cannot reach the NAS anymore. I imagine it is constantly rebooting now, but I cannot get to the NAS until the afternoon.

I will hook up the disk again and get /var/log/dmesg, I did not understand how to get netconsole running. Any hints?


Top
   
PostPosted: Fri Mar 15, 2013 9:22 am 
Offline
Newbie

Joined: Fri Mar 21, 2008 3:04 am
Posts: 52
I'll get to you about two hours later. Could you pm me you email?

Edit: Information about netconsole can be found under the kernel Document directory:

<your kernel source dir>/Documentation/networking/netconsole.txt.


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

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