Debian install

[Brian W]

I had the recent release of Alt-F installed...and went with the Debian install through the admin pages on Alt-F.  the activity light is "fluttering" but nothing on lights on either side.

Anyone time the install?   can't seem to get back to the NAS with the prior IP address.

TIA

[Brian W]

Unplugged NAS rebooted without problems to Alt-F...deleted Debian. Need to get a further understanding about linux commands....

[hal...@gmail.com]

Didn't time it but it locks up the box upon attempt to execute Debian from Alt-F panels.

Using RC3 in a DNS-321 Debian install via the Alt-F panels, the Debian install starts, initial disk usage is:

 Filesystem Size Used Available Use% Mounted on
rootfs 30.0M 1.3M 28.7M 4% /
tmpfs 30.0M 1.3M 28.7M 4% /rootmnt
/rootmnt/dev/loop0 6.3M 6.3M 0 100% /rootmnt/ro
aufs 30.0M 1.3M 28.7M 4% /
tmpfs 52.0M 1.9M 50.1M 4% /tmp
/dev/sda2 186.4G 194.1M 186.3G 0% /mnt/sda2

climbs to :

/dev/sda2 186.4G 539.3M 185.9G 0% /mnt/sda2

then settles down after Debian install fetches Alt-F from sourceforge to  ( which Alt-F is the script fetching ( 323, 321 Chopper) ? ) :

/dev/sda2 186.4G 441.2M 186.0G 0% /mnt/sda2

Upon  attempt to execute Debian from Alt-F panels, it finds Debian installed, click on execute and the following appears:

Executing Debian...
failed.

Once this happens, the 321 is not accessible until power is removed and it reboots. The center blue led is flashing steady and the drive light is on solid.

After removing power and powering back on Alt-F is accessible again.  Same thing happens when attempting to start Debian after the reboot, total lockup.

Is the Debian 'install' log which disappears from the web interface once Debian is installed stored somewhere ?

Phil

[João Cardoso]

On Saturday, May 25, 2013 12:11:26 AM UTC+1, hal...@gmail.com wrote:

On Monday, May 6, 2013 11:41:13 PM UTC-5, Brian W wrote:

I had the recent release of Alt-F installed...and went with the Debian install through the admin pages on Alt-F.  the activity light is "fluttering" but nothing on lights on either side.

Anyone time the install?   can't seem to get back to the NAS with the prior IP address.

TIA

Didn't time it

It tooks 25 minutes for me, but that depends on the selected mirror.

 

but it locks up the box upon attempt to execute Debian from Alt-F panels.

Try using the command line debian command  first to chroot it, e.g.,

 

debian -chroot ls

if that works, try just

debian -chroot

you should now be using debian rootfs but running Alt-F kernel; type 'exit' to return to Alt-F.

If it works, see if a valid kernel  and initramfs (vmlinuz  and initrd.img) exists in the base of the partition where debian was installed.

 

Using RC3 in a DNS-321 Debian install via the Alt-F panels, the Debian install starts, initial disk usage is:

 Filesystem Size Used Available Use% Mounted on
rootfs 30.0M 1.3M 28.7M 4% /
tmpfs 30.0M 1.3M 28.7M 4% /rootmnt
/rootmnt/dev/loop0 6.3M 6.3M 0 100% /rootmnt/ro
aufs 30.0M 1.3M 28.7M 4% /
tmpfs 52.0M 1.9M 50.1M 4% /tmp
/dev/sda2 186.4G 194.1M 186.3G 0% /mnt/sda2

climbs to :

/dev/sda2 186.4G 539.3M 185.9G 0% /mnt/sda2

then settles down after Debian install fetches Alt-F from sourceforge to  ( which Alt-F is the script fetching ( 323, 321 Chopper) ? )

The general, fit-it all version. Specific versions are needed only to be accepted by the vendor firmware for flashing.

It can be found under /boot in the filesystem where Debian was installed

 

:

/dev/sda2 186.4G 441.2M 186.0G 0% /mnt/sda2

Upon  attempt to execute Debian from Alt-F panels, it finds Debian installed, click on execute and the following appears:

Executing Debian...
failed.

hmmm, I have to try this myself (again)...

 

Once this happens, the 321 is not accessible until power is removed

Yes, it it fails there is currently no fallback.

 

and it reboots. The center blue led is flashing steady and the drive light is on solid.

After removing power and powering back on Alt-F is accessible again.  Same thing happens when attempting to start Debian after the reboot, total lockup.

Is the Debian 'install' log which disappears from the web interface once Debian is installed stored somewhere ?

Unfortunately not. Have thinking on storing it, but keep forgotting...

 

Phil

[hal...@gmail.com]

On Friday, May 24, 2013 7:12:15 PM UTC-5, João Cardoso wrote:

On Saturday, May 25, 2013 12:11:26 AM UTC+1, hal...@gmail.com wrote:

but it locks up the box upon attempt to execute Debian from Alt-F panels.

Try using the command line debian command  first to chroot it, e.g.,

 

debian -chroot ls

if that works, try just

debian -chroot

you should now be using debian rootfs but running Alt-F kernel; type 'exit' to return to Alt-F.

Yes, all that works.

 

If it works, see if a valid kernel  and initramfs (vmlinuz  and initrd.img) exists in the base of the partition where debian was installed.

Linked to actual files in boot directory:

# ls -l /mnt/sda2
total 132
-rw-rw-rw- 1 root root 32822 May 25 12:46 alt-f.log
drwxr-xr-x 2 root root 4096 May 24 21:57 bin
drwxr-xr-x 2 root root 4096 May 24 22:04 boot
drwxr-xr-x 4 root root 4096 May 24 22:00 dev
drwxr-xr-x 48 root root 4096 May 25 13:02 etc
drwxr-xr-x 2 root root 4096 Feb 18 20:45 home
lrwxrwxrwx 1 root root 32 May 24 21:55 initrd.img -> boot/initrd.img-2.6.32-5-orion5x
drwxr-xr-x 10 root root 12288 May 24 21:52 lib
drwx------ 2 root root 16384 May 24 21:19 lost+found
drwxr-xr-x 2 root root 4096 May 24 21:47 media
drwxr-xr-x 3 root root 4096 May 25 12:52 mnt
drwxr-xr-x 2 root root 4096 May 24 21:47 opt
drwxr-xr-x 2 root root 4096 Feb 18 20:45 proc
drwx------ 2 root root 4096 May 25 12:54 root
drwxr-xr-x 2 root root 4096 May 24 21:52 sbin
drwxr-xr-x 2 root root 4096 Jul 21 2010 selinux
drwxr-xr-x 2 root root 4096 May 24 21:47 srv
drwxr-xr-x 2 root root 4096 Mar 27 2012 sys
drwxrwxrwt 2 root root 4096 May 24 22:17 tmp
drwxr-xr-x 10 root root 4096 May 24 21:47 usr
drwxr-xr-x 13 root root 4096 May 24 21:47 var
lrwxrwxrwx 1 root root 29 May 24 21:55 vmlinuz -> boot/vmlinuz-2.6.32-5-orion5x
# ls -l /mnt/sda2/boot
total 14600
-rwx------ 1 1000 users 6385664 Mar 22 22:14 Alt-F-rootfs.arm.sqmtd
-rwxr-xr-x 1 1000 users 1383060 Mar 22 22:14 Alt-F-zImage
-rw-r--r-- 1 root root 982559 Feb 16 13:37 System.map-2.6.32-5-orion5x
-rw-r--r-- 1 root root 83244 Feb 16 13:37 config-2.6.32-5-orion5x
-rw-r--r-- 1 root root 4789086 May 24 22:00 initrd.img-2.6.32-5-orion5x
-rw-r--r-- 1 root root 1317500 Feb 16 13:36 vmlinuz-2.6.32-5-orion5x
#

 

Executing Debian...
failed.

hmmm, I have to try this myself (again)...

 

Is the Debian 'install' log which disappears from the web interface once Debian is installed stored somewhere ?

[João Cardoso]

I can, at least partly, confirm that there are issues with Debian when installing on a degraded RAID. But not on an ordinary filesystem.

First I installed Debian on an ordinary filesystem, just to be sure that it works. It did works fine.

Then I installed in a RAID partition; like you 'debian -chroot' worked fine, but 'debian -kexec' didn't.

As I have a serial console, I could watch Debian booting, and it stopped waiting for the root (RAID) device, that didn't appears.

That was due to the fact that I'm on a degraded RAID, and for that reason the Debian installation script didn't add support for booting from RAID.

I executed

debian -chroot
/usr/sbin/update-initramfs -u
exit

After fixing the 'debian' script to also support a degraded RAID, I was able to start 'debian -kexec' from my serial console and from a telnet and a ssh session (as the 'root' user, of course).

The box has the same IP under Debian as before. If Alt-F has a static IP, the 'debian' script sets Debian to use that IP; if Alt-F is using DHCP, then the Debian script sets Debian to also use DHCP (not necessarily using the same IP!).

Then, within Debian I was able to "return" to Alt-F by executing the 'alt-f' command (faster then a reboot)

[hal...@gmail.com]

On Sunday, May 26, 2013 11:41:32 AM UTC-5, João Cardoso wrote:

On Saturday, May 25, 2013 2:40:05 PM UTC+1, hal...@gmail.com wrote:

 Executing Debian...
failed.

 

hmmm, I have to try this myself (again)...

 

I can, at least partly, confirm that there are issues with Debian when installing on a degraded RAID. But not on an ordinary filesystem.

First I installed Debian on an ordinary filesystem, just to be sure that it works. It did works fine.

I installed on the 2TB drive as well, still no go.  Used United States repository.  Noticed squeeze flash by on one of the lines during the last portion, but could see everything toward the end as it 'disappears' ;)

 

Then I installed in a RAID partition; like you 'debian -chroot' worked fine, but 'debian -kexec' didn't.

As I have a serial console, I could watch Debian booting, and it stopped waiting for the root (RAID) device, that didn't appears.

Haven't made a serial connection yet as haven't located a good plug for the on-board jack.  Have the CA42/52 ? cable with the level shift built-in.  Anyone have a good idea for a plug source that fits the jack ?  The SS4000-e serial jack was a cinch as I had a jumper cable with the header that fits.

 

That was due to the fact that I'm on a degraded RAID, and for that reason the Debian installation script didn't add support for booting from RAID.

I executed

debian -chroot
/usr/sbin/update-initramfs -u
exit

After fixing the 'debian' script to also support a degraded RAID, I was able to start 'debian -kexec' from my serial console and from a telnet and a ssh session (as the 'root' user, of course).

The box has the same IP under Debian as before. If Alt-F has a static IP, the 'debian' script sets Debian to use that IP; if Alt-F is using DHCP, then the Debian script sets Debian to also use DHCP (not necessarily using the same IP!).

Then, within Debian I was able to "return" to Alt-F by executing the 'alt-f' command (faster then a reboot)

 

Thinking perhaps 2 drives with swap space might help I put the previously formated 200MB drive in the left side and tried again.  debian -chroot works but debian -kexec fails like so:

root@DNS-323:/# which chroot
/usr/sbin/chroot
root@DNS-323:/# exit
exit
# debian -kexec
# nohup: appending output to nohup.out
Connection closed by foreign host.

and the DNS-321 is locked up after this.

Not knowing what I am doing at this point I try :

# debian -chroot
root@DNS-323:/# which update-initramfs
/usr/sbin/update-initramfs
root@DNS-323:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-orion5x
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
W: mdadm: no arrays defined in configuration file.
root@DNS-323:/# exit
exit
#

which still locks the box after debian -kexec is attempted.

There must be something different between the 323 and the 321 which is killing loading the Debian kernal.

Philb

[João Cardoso]

On Monday, May 27, 2013 2:06:17 AM UTC+1, hal...@gmail.com wrote:

On Sunday, May 26, 2013 11:41:32 AM UTC-5, João Cardoso wrote:

On Saturday, May 25, 2013 2:40:05 PM UTC+1, hal...@gmail.com wrote:

 Executing Debian...
failed.

 

hmmm, I have to try this myself (again)...

 

I can, at least partly, confirm that there are issues with Debian when installing on a degraded RAID. But not on an ordinary filesystem.

First I installed Debian on an ordinary filesystem, just to be sure that it works. It did works fine.

I installed on the 2TB drive as well, still no go.  Used United States repository.  Noticed squeeze flash by on one of the lines during the last portion, but could see everything toward the end as it 'disappears' ;)

 

Then I installed in a RAID partition; like you 'debian -chroot' worked fine, but 'debian -kexec' didn't.

As I have a serial console, I could watch Debian booting, and it stopped waiting for the root (RAID) device, that didn't appears.

Haven't made a serial connection yet as haven't located a good plug for the on-board jack.

soldering the wires directly?

 

 Have the CA42/52 ? cable with the level shift built-in.  Anyone have a good idea for a plug source that fits the jack ?  The SS4000-e serial jack was a cinch as I had a jumper cable with the header that fits.

 

That was due to the fact that I'm on a degraded RAID, and for that reason the Debian installation script didn't add support for booting from RAID.

I executed

debian -chroot
/usr/sbin/update-initramfs -u
exit

After fixing the 'debian' script to also support a degraded RAID, I was able to start 'debian -kexec' from my serial console and from a telnet and a ssh session (as the 'root' user, of course).

The box has the same IP under Debian as before. If Alt-F has a static IP, the 'debian' script sets Debian to use that IP; if Alt-F is using DHCP, then the Debian script sets Debian to also use DHCP (not necessarily using the same IP!).

Then, within Debian I was able to "return" to Alt-F by executing the 'alt-f' command (faster then a reboot)

 

Thinking perhaps 2 drives with swap space might help I put the previously formated 200MB drive in the left side and tried again.  debian -chroot works but debian -kexec fails like so:

root@DNS-323:/# which chroot
/usr/sbin/chroot
root@DNS-323:/# exit
exit
# debian -kexec
# nohup: appending output to nohup.out

Depending on your current directory when executing the command (the filesystem with the Debian install is a hood place) , the 'nohup.out' file it might be on disk, and you can read it (until a certain point)

 

Connection closed by foreign host.

and the DNS-321 is locked up after this.

Not knowing what I am doing at this point I try :

# debian -chroot
root@DNS-323:/# which update-initramfs
/usr/sbin/update-initramfs
root@DNS-323:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-orion5x
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
W: mdadm: no arrays defined in configuration file.
root@DNS-323:/# exit
exit
#

which still locks the box after debian -kexec is attempted.

There must be something different between the 323 and the 321 which is killing loading the Debian kernal.

Ah, must be that!

Alt-F has kernel support for the DNS-323, that the Debian kernel seems to not have.

Only someone with a serial console can verify this.

 

Philb

[hal...@gmail.com]

On Sunday, May 26, 2013 8:42:20 PM UTC-5, João Cardoso wrote:

Depending on your current directory when executing the command (the filesystem with the Debian install is a hood place) , the 'nohup.out' file it might be on disk, and you can read it (until a certain point)

Yes, but it isn't enough to see what happens after Debian takes over.

# cat /mnt/sda2/etc/default/nohup.out
Now leaving Alt-F...
root: Stopping user: OK.
root: Stopping ffp: No ffp instalation found.
root: Stopping vsftpd: OK.
root: Stopping dropbear: OK.
root: Stopping smbd: OK.
Stopping nmbd: OK.
root: Stopping rpc.statd: OK.
root: Stopping nfsd: OK.
Stopping rpc.statd: OK.
Stopping rpc.mountd: OK.
root: Stopping inadyn: OK.
root: Stopping ntpd: OK.
root: Stopping dnsmasq: OK.
root: Stopping stunnel: OK.
root: Stopping portmap: OK.
root: Stopping cleanup: OK.
root: Stopping backup: OK.
root: Stopping mdadm: OK.
root: Stopping smartd: OK.
root: Stopping atd: OK.
root: Stopping crond: OK.
root: Stopping urandom: OK.
root: Stopping sslcert: OK.
mount: mounting /dev/sda2 on /mnt/sda2 failed: Device or resource busy
Stopping sysctrl: OK.
Executing Debian now...

Have attached messages where both attempts to execute Debian logged boot messages.  Maybe you can see something in them.

[João Cardoso]

I don't understand: how was you able to get those  kernel boot messages if you don't have a serial console? How exactly?

Ah, you chroot to Debian afterwards and examined /var/log/... stupid of me!

You have lots of logs there, try seeing the faillog, syslog, daemon.log... they are the result of concatenating all the logs from previous attempts, so you could remove all them and then do a new -kexe test, followed by a -chroot -- then you have the logs from only the last failed boot. Archive them.

Also post the /etc/network/interfaces file. Are you on DHCP or with a static fixed IP on Alt-F?

Also, add the following lines to the end of /etc/rc.local:

runlevel >> /var/log/user.log
ps -ef >> /var/log/user.log
ifconfig >> /var/log/user.log
exit 0

And watch/post '/var/log/user.log' after an -kexec

Anyhow, the dmesg shows that the Debian kernel has no DNS-321 support, it is identical to the first attempts that Matt did when he flashed Alt-F on his DNS-321 (see the "So I flashed Alt-F to a DNS-321... :)" topic).

Otherwise, the boot proceeds normally, the rootfs is mounted and udev is even started. But no other user level process is shown.

The network does not seems to be initialized (the MAC wasn't read) but that didn't avoided Alt-F to continue booting in the same circumstances.

However it seems that a fake MAC is used later...

Relevant lines, showing that it is booting:

net eth0: port 0 with MAC address 00:22:b0:51:98:79

eth0: link up, 100 Mb/s, full duplex, flow control disabled

Adding 524280k swap on /dev/sda1.

EXT4-fs (sda2): mounted filesystem with ordered data mode

udev[165]: starting version 164

[Joao Cardoso]

Correction: replace the last exit with

>
> runlevel >> /var/log/user.log
> ps -ef >> /var/log/user.log
> ifconfig >> /var/log/user.log
> exit 0
>
>
> And watch/post '/var/log/user.log' after an -kexec
>
> Anyhow, the dmesg shows that the Debian kernel has no DNS-321 support, it is identical to the first attempts that Matt did when he flashed Alt-F on his DNS-321 (see the "So I flashed Alt-F to a DNS-321... :)" topic).
> Otherwise, the boot proceeds normally, the rootfs is mounted and udev is even started. But no other user level process is shown.
> The network does not seems to be initialized (the MAC wasn't read) but that didn't avoided Alt-F to continue booting in the same circumstances.
> However it seems that a fake MAC is used later...
>
> Relevant lines, showing that it is booting:
>
> net eth0: port 0 with MAC address 00:22:b0:51:98:79
> eth0: link up, 100 Mb/s, full duplex, flow control disabled
>
> Adding 524280k swap on /dev/sda1.
> EXT4-fs (sda2): mounted filesystem with ordered data mode
> udev[165]: starting version 164
>
>

> --
> You received this message because you are subscribed to the Google Groups "Alt-F" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.
> To post to this group, send email to al...@googlegroups.com.
> Visit this group at http://groups.google.com/group/alt-f?hl=en.
> To view this discussion on the web visit https://groups.google.com/d/msgid/alt-f/760b77f6-5903-4fb2-83ac-1d941faa2271%40googlegroups.com?hl=en.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

[hal...@gmail.com]

On Monday, May 27, 2013 12:43:40 PM UTC-5, João Cardoso wrote:

 

I don't understand: how was you able to get those  kernel boot messages if you don't have a serial console? How exactly?

Ah, you chroot to Debian afterwards and examined /var/log/... stupid of me!

It was probably accidental.  Did a google search for Linux boot log and saw some post about there might be some info in /var/log/messages.  Didn't chroot to grab it, just direct from Alt-F /mnt/sda2/var/log/xxx . 

You have lots of logs there, try seeing the faillog, syslog, daemon.log... they are the result of concatenating all the logs from previous attempts, so you could remove all them and then do a new -kexe test, followed by a -chroot -- then you have the logs from only the last failed boot. Archive them.

Reformatted 200MB drive, installed Debian, executed a 'debian -kexec'.  Hardly any logs had anything in them and the ones that did wouldn't display with a 'cat faillog' for example has stuff in the file but nothing displays.

Unpluged, rebooted, tried execute Debian from the panels.  This time several files have data.  Example before panel execute of debian messages was 0 after the panel execute it is 15680.

There must be some more setup in the panel than in the 'debian -kexec' command line execution. 

 

Also post the /etc/network/interfaces file. Are you on DHCP or with a static fixed IP on Alt-F?

Alt-F file:

 

# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
client udhcpc
mtu 1500
address 192.168.0.103
hostname DNS-323

Debian files

--------------------------------------------

# cat etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

---------------------------------------------

# cat etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

runlevel >> /var/log/user.log
ps -ef >> /var/log/user.log
ifconfig >> /var/log/user.log
exit 0

------------------------------------------

# ls -l etc/rc.local
-rwxr-xr-x 1 root root 393 May 27 15:20 etc/rc.local

 

Also, add the following lines to the end of /etc/rc.local:

runlevel >> /var/log/user.log
ps -ef >> /var/log/user.log
ifconfig >> /var/log/user.log
exit 0

And watch/post '/var/log/user.log' after an -kexec

user.log still has 0 bytes after both the 'debian -kexec' and the panel exeuction of debian.

 

Anyhow, the dmesg shows that the Debian kernel has no DNS-321 support, it is identical to the first attempts that Matt did when he flashed Alt-F on his DNS-321 (see the "So I flashed Alt-F to a DNS-321... :)" topic).

Otherwise, the boot proceeds normally, the rootfs is mounted and udev is even started. But no other user level process is shown.

The network does not seems to be initialized (the MAC wasn't read) but that didn't avoided Alt-F to continue booting in the same circumstances.

However it seems that a fake MAC is used later...

Relevant lines, showing that it is booting:

net eth0: port 0 with MAC address 00:22:b0:51:98:79

eth0: link up, 100 Mb/s, full duplex, flow control disabled

Adding 524280k swap on /dev/sda1.

EXT4-fs (sda2): mounted filesystem with ordered data mode

udev[165]: starting version 164

I'll have to go back and re-read the flash 321 post, but IIRC the MAC address is in a different place than the 323.

Another post on the internet shows similar boot sequence with VFP (?) the next line after the one where the 321 stops logging.  Perhaps floating-point support in the two different processors 500mhz 323 vs 400mhz 321 (can't remember the actual processor models) may be a culprit if VFP stands for Virtual Floating Point.

Again, I am at a loss as to what is actually going on.

Attached is entire var/log directory 

[hal...@gmail.com]

On Monday, May 27, 2013 4:10:38 PM UTC-4, Joao Cardoso wrote:

>Also, add the following lines to the end of /etc/rc.local:

Correction: replace the last exit with

>
> runlevel >> /var/log/user.log
> ps -ef >> /var/log/user.log
> ifconfig >> /var/log/user.log
> exit 0

Our posts crossed, but had already done the above properly I think.

> Anyhow, the dmesg shows that the Debian kernel has no DNS-321 support, it is identical to the first attempts that Matt did when he flashed Alt-F
on his DNS-321 (see the "So I flashed Alt-F to a DNS-321... :)" topic).

Some searching this morning confirms no support for DNS-321 in kernel, so guess kexec isn't going to work at all for the 321 currently.  From:

http://www.cyrius.com/debian/orion/d-link/dns-323/faq/

"Are other D-Link models, such as the DNS-321 or DNS-325, supported?

No, only the D-Link DNS-323 is supported. I'm not planning to add support for other D-Link devices but you're welcome to contribute patches to the debian-arm list."

http://hezmatt.org/~mpalmer/blog/2008/10/23/porting-d-i-to-the-dns-323.html

"For the DNS-323, I had a few kernel problems (which I'd been warned about by Martin before I started) -- the NIC wasn't initialised with it's MAC address, which meant it was running around my Ethernet screaming "I am 00:00:00:00:00:00! Ph33r m3!", and the SATA controller just didn't seem to exist at all. These were kinda critical to doing an install, so it was time to get hacking to make those work."
 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503172

"It reads the MAC address for the on-board NIC out of flash, and uses it in

  the NIC initialisation (all DNS-323 models);"

and in the patch for the kernel itself this:

"+    /* MAC address is stored as a regular ol' string in /dev/mtdblock4
+     * (0x007d0000-0x00800000) starting at offset 196480 (0x2ff80).
+     */
+    mac_page = ioremap(DNS323_NOR_BOOT_BASE + 0x7d0000 + 196480, 1024);"

Then there is also the SATA patch:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=dns323_sata.patch;att=1;bug=503172

Which has stuff like:

"+    if (machine_is_dns323()) {
+        if (dev != MV88F5182_DEV_ID) {
+            /* The 5182 doesn't really use it's PCI bus, so
+             * we don't initialise it.
+             */
+            pci_common_init(&dns323_pci);"

and

"     orion5x_eth_init(&dns323_eth_data);
+    /* The 5182 has it's SATA controller internally, and it needs it's own
+     * little init routine.
+     */
+    if (dev == MV88F5182_DEV_ID)
+        orion5x_sata_init(&dns323_sata_data);
 }
 
 /* Warning: D-Link uses a wrong mach-type (=526) in their bootloader */"

This last part looks like it might be where the 321 is stopping but without fixes for other than the specific 323 patches in the kernel doubt that other than the DNS-323 will work natively with Debian.

Then again I'm out of my depth here.

[João Cardoso]

On Monday, May 27, 2013 9:22:36 PM UTC+1, hal...@gmail.com wrote:

On Monday, May 27, 2013 12:43:40 PM UTC-5, João Cardoso wrote:

 

I don't understand: how was you able to get those  kernel boot messages if you don't have a serial console? How exactly?

Ah, you chroot to Debian afterwards and examined /var/log/... stupid of me!

... 

 

There must be some more setup in the panel than in the 'debian -kexec' command line execution. 

No, the web page script just calls 'debian -kexec', that's all

 ...

# ls -l etc/rc.local
-rwxr-xr-x 1 root root 393 May 27 15:20 etc/rc.local

 

Also, add the following lines to the end of /etc/rc.local:

runlevel >> /var/log/user.log
ps -ef >> /var/log/user.log
ifconfig >> /var/log/user.log
exit 0

And watch/post '/var/log/user.log' after an -kexec

user.log still has 0 bytes after both the 'debian -kexec' and the panel exeuction of debian.

If it has 0 bytes then user.log was executed, or it wouldn't be created -- you haven't done it yourself, have you?

...

Relevant lines, showing that it is booting:

net eth0: port 0 with MAC address 00:22:b0:51:98:79

eth0: link up, 100 Mb/s, full duplex, flow control disabled

Adding 524280k swap on /dev/sda1.

EXT4-fs (sda2): mounted filesystem with ordered data mode

udev[165]: starting version 164

Debian *is booting*, kernel has completed, called init, swap is attached, the rootfs is mounted, the initscripts start executing, but somewhere they stop midway... device enumeration?

You need a serial port.

 

I'll have to go back and re-read the flash 321 post, but IIRC the MAC address is in a different place than the 323.

I know all that.

But read Matt's first post: Alt-F started and the web page was even usable. His box was identified as a rev-C1 board. The fact that the MAC was a fake one didn't avoid the network to start.

AND this all happens with NO DNS-321 support in the Alt-F kernel. The only issues was the flash chip and the real MAC.

So Debian is in the same situation: it identifies the box as a DNS-323 rev-C1 and proceeds as such.

Another post on the internet shows similar boot sequence with VFP (?) the next line after the one where the 321 stops logging.  Perhaps floating-point support in the two different processors 500mhz 323 vs 400mhz 321 (can't remember the actual processor models) may be a culprit if VFP stands for Virtual Floating Point.

I think this is irrelevant, both the 321 and 323 uses the same SoC

 

Again, I am at a loss as to what is actually going on.

My attempt of using rc.local to try to diagnose what is happening failed, don't know why.

You have to find the right log or to increase the initscripts verbosity to find which one is failing, or activate some other initscript (an early network console, or making syslog log through the network to another computer)

Remember that you can always "debian -chroot' to examine files and change initscripts after a -kexec. You can also install extra Debian packages, if needed. It has a slow turnaround, but it is feasible.

Or you can use a serial port.

I'm convinced that it is a minor issue that avoids Debian to *complete* the boot; you can then use it, even if with a fake MAC or a usable flash memory (it's not needed, Debian stores everything on disk).

I could send a patch with support for the DNS-321 to either the kernel or Debian mailing lists, but I'm not going to do that.

The code/patch is available, if anybody wants to do that that's OK with me.

[hal...@gmail.com]

On Tuesday, May 28, 2013 1:46:01 PM UTC-4, João Cardoso wrote:

That I need a serial console.

Something that I was wanting to avoid like the plague.

Agree that it must be something minor stopping Debian from running native.  SYSLOG has a few more lines than the previous message I posted:

"May 27 19:48:07 DNS-323 kernel: [   11.472593] lm75 0-0048: hwmon0: sensor 'lm75'
May 27 19:48:07 DNS-323 kernel: [   12.403082] Adding 524280k swap on /dev/sda1.  Priority:-1 extents:1 across:524280k
May 27 19:48:07 DNS-323 kernel: [   17.086625] eth0: link up, 100 Mb/s, full duplex, flow control disabled
May 27 19:48:08 DNS-323 /usr/sbin/cron[537]: (CRON) INFO (pidfile fd = 3)
May 27 19:48:08 DNS-323 /usr/sbin/cron[538]: (CRON) STARTUP (fork ok)
May 27 19:48:08 DNS-323 /usr/sbin/cron[538]: (CRON) INFO (Running @reboot jobs)
May 27 19:48:09 DNS-323 kernel: [   25.868234] NET: Registered protocol family 10
May 27 19:48:20 DNS-323 kernel: [   36.806282] eth0: no IPv6 routers present"

Regarding Alt-F being able to continue despite MAC address issue, it was a earlier LINUX kernel than the Debian native currently available.  Since Mat Palmer (?) mentioned it running in circles trying to find the net perhaps it is only the MAC problem now that Debian is hanging on ( IPV6 in particular).

If the interd or vmlinuz were editable files, one might be able to change only the MAC location in them and see what happens.  I don't know if that is possible or not since they are compressed images themselves and can not directly searched for the value to change it.

Just so I can see what it should look like, can you post the archive of syslog where kexec successfully runs on your 323 ?

[João Cardoso]

On Tuesday, May 28, 2013 9:53:49 PM UTC+1, hal...@gmail.com wrote:

On Tuesday, May 28, 2013 1:46:01 PM UTC-4, João Cardoso wrote:

That I need a serial console.

Something that I was wanting to avoid like the plague.

Agree that it must be something minor stopping Debian from running native.  SYSLOG has a few more lines than the previous message I posted:

"May 27 19:48:07 DNS-323 kernel: [   11.472593] lm75 0-0048: hwmon0: sensor 'lm75'
May 27 19:48:07 DNS-323 kernel: [   12.403082] Adding 524280k swap on /dev/sda1.  Priority:-1 extents:1 across:524280k
May 27 19:48:07 DNS-323 kernel: [   17.086625] eth0: link up, 100 Mb/s, full duplex, flow control disabled
May 27 19:48:08 DNS-323 /usr/sbin/cron[537]: (CRON) INFO (pidfile fd = 3)
May 27 19:48:08 DNS-323 /usr/sbin/cron[538]: (CRON) STARTUP (fork ok)
May 27 19:48:08 DNS-323 /usr/sbin/cron[538]: (CRON) INFO (Running @reboot jobs)
May 27 19:48:09 DNS-323 kernel: [   25.868234] NET: Registered protocol family 10
May 27 19:48:20 DNS-323 kernel: [   36.806282] eth0: no IPv6 routers present"

Regarding Alt-F being able to continue despite MAC address issue, it was a earlier LINUX kernel than the Debian native currently available.

Alt-F runs under 2.6.35, while Debian runs under 2.6.32

According to the logs, Debian is using a fake MAC, but that only should make a difference is you have a NIC with that MAC in your network. 

 

  Since Mat Palmer (?) mentioned it running in circles trying to find the net perhaps it is only the MAC problem now that Debian is hanging on ( IPV6 in particular).

If the interd or vmlinuz were editable files, one might be able to change only the MAC location in them and see what happens.

Not feasible and not the way I work. I put hypotheses, make tests to verify its validity, then fix the bug. I don't guess ;-).

Well, sometimes I make educated guesses because there must not exists data enough to prove the hypothesis -- happens often :-(

  I don't know if that is possible or not since they are compressed images themselves and can not directly searched for the value to change it.

Just so I can see what it should look like, can you post the archive of syslog where kexec successfully runs on your 323 ?

Not at hand.

You can try to increase the log verbosity, edit /etc/default/rcS and set VERBOSE=yes.

Don't know if it works, I don't  use Debian, I just glimpse http://www.debian.org/doc/debian-policy/ch-opersys.html#s-/etc/init.d  and http://wiki.debian.org/LSBInitScripts

[hal...@gmail.com]

On Wednesday, May 29, 2013 7:05:25 PM UTC-5, João Cardoso wrote:

On Tuesday, May 28, 2013 9:53:49 PM UTC+1, hal...@gmail.com wrote:

On Tuesday, May 28, 2013 1:46:01 PM UTC-4, João Cardoso wrote:

That I need a serial console.

Something that I was wanting to avoid like the plague.

Really didn't want to touch the serial console stuff as the DNS-321 connection is not in the same place as the DNS-323.  On the 321 it is on the underside of the circuit board.  The WIKI mentions CON4 for the 323 but CON4 on the 321 is an empty set of 10 solder holes.  CON3 has the 4 pin connector jack in place on the 321.  They are so small that any attempt by me to attach wires directly would probably ruin the thing.  My preparations for having the CA-42 cable was in case I bricked the thing and had to use the serial console.

Currently parts are on order for the connector and may be here in 5 or 6 days.

 

Agree that it must be something minor stopping Debian from running native.  SYSLOG has a few more lines than the previous message I posted:

"May 27 19:48:07 DNS-323 kernel: [   11.472593] lm75 0-0048: hwmon0: sensor 'lm75'
May 27 19:48:07 DNS-323 kernel: [   12.403082] Adding 524280k swap on /dev/sda1.  Priority:-1 extents:1 across:524280k
May 27 19:48:07 DNS-323 kernel: [   17.086625] eth0: link up, 100 Mb/s, full duplex, flow control disabled
May 27 19:48:08 DNS-323 /usr/sbin/cron[537]: (CRON) INFO (pidfile fd = 3)
May 27 19:48:08 DNS-323 /usr/sbin/cron[538]: (CRON) STARTUP (fork ok)
May 27 19:48:08 DNS-323 /usr/sbin/cron[538]: (CRON) INFO (Running @reboot jobs)
May 27 19:48:09 DNS-323 kernel: [   25.868234] NET: Registered protocol family 10
May 27 19:48:20 DNS-323 kernel: [   36.806282] eth0: no IPv6 routers present"

Regarding Alt-F being able to continue despite MAC address issue, it was a earlier LINUX kernel than the Debian native currently available.

Alt-F runs under 2.6.35, while Debian runs under 2.6.32

According to the logs, Debian is using a fake MAC, but that only should make a difference is you have a NIC with that MAC in your network. 

 

Sorry, my other NAS, SS4000-E, installed 3.2.0 without a hitch.  Have put the other NAS aside until this is investigated further.

 

  Since Mat Palmer (?) mentioned it running in circles trying to find the net perhaps it is only the MAC problem now that Debian is hanging on ( IPV6 in particular).

If the interd or vmlinuz were editable files, one might be able to change only the MAC location in them and see what happens.

Not feasible and not the way I work. I put hypotheses, make tests to verify its validity, then fix the bug. I don't guess ;-).

Well, sometimes I make educated guesses because there must not exists data enough to prove the hypothesis -- happens often :-(

Perhaps more feasible to alter the location where it is actually looking for the MAC address, 323 location, if nothing vital is there in the 321 version.  I have to guess as don't have the knowledge to ascertain that it shouldn't be this or that.

 

  I don't know if that is possible or not since they are compressed images themselves and can not directly searched for the value to change it.

Just so I can see what it should look like, can you post the archive of syslog where kexec successfully runs on your 323 ?

Not at hand.

You can try to increase the log verbosity, edit /etc/default/rcS and set VERBOSE=yes.

Don't know if it works, I don't  use Debian, I just glimpse http://www.debian.org/doc/debian-policy/ch-opersys.html#s-/etc/init.d  and http://wiki.debian.org/LSBInitScript

Box currently disassembled due to going around locally to see if parts available to attach serial console cable.

Was going to attach photo of top and bottom of DSN-321 PCB but have run into size issue.

 

[João Cardoso]

Just so I can see what it should look like, can you post the archive of syslog where kexec successfully runs on your 323 ?

Not at hand.

OK, here it is.

You can see that /etc/rc.local is the last script to be executed, so other way of logging what is happening is needed.

 

[hal...@gmail.com]

It looks like etc/init.d/rc.local is what is actually executing, so I put the 3 lines you had posted earlier there and got a user.log with info in it.

 N 2
UID PID PPID C STIME TTY TIME CMD
root 1 0 7 21:41 ? 00:00:01 init [2]
root 2 0 0 21:41 ? 00:00:00 [kthreadd]
root 3 2 0 21:41 ? 00:00:00 [ksoftirqd/0]
root 4 2 0 21:41 ? 00:00:00 [watchdog/0]
root 5 2 0 21:41 ? 00:00:00 [events/0]
root 6 2 0 21:41 ? 00:00:00 [cpuset]
root 7 2 0 21:41 ? 00:00:00 [khelper]
root 8 2 0 21:41 ? 00:00:00 [netns]
root 9 2 0 21:41 ? 00:00:00 [async/mgr]
root 10 2 0 21:41 ? 00:00:00 [sync_supers]
root 11 2 0 21:41 ? 00:00:00 [bdi-default]
root 12 2 0 21:41 ? 00:00:00 [kintegrityd/0]
root 13 2 0 21:41 ? 00:00:00 [kblockd/0]
root 14 2 0 21:41 ? 00:00:00 [kseriod]
root 15 2 0 21:41 ? 00:00:00 [khungtaskd]
root 16 2 0 21:41 ? 00:00:00 [kswapd0]
root 17 2 0 21:41 ? 00:00:00 [ksmd]
root 18 2 0 21:41 ? 00:00:00 [aio/0]
root 19 2 0 21:41 ? 00:00:00 [crypto/0]
root 22 2 0 21:41 ? 00:00:00 [mtdblockd]
root 72 2 0 21:41 ? 00:00:00 [khubd]
root 73 2 0 21:41 ? 00:00:00 [ata/0]
root 74 2 0 21:41 ? 00:00:00 [ata_aux]
root 76 2 0 21:41 ? 00:00:00 [scsi_eh_0]
root 78 2 0 21:41 ? 00:00:00 [scsi_eh_1]
root 89 2 0 21:41 ? 00:00:00 [flush-8:0]
root 117 2 0 21:41 ? 00:00:00 [jbd2/sda2-8]
root 118 2 0 21:41 ? 00:00:00 [ext4-dio-unwrit]
root 163 1 1 21:41 ? 00:00:00 udevd --daemon
root 222 2 0 21:41 ? 00:00:00 [mv_crypto]
root 452 1 0 21:41 ? 00:00:00 dhclient -v -pf /var/run/dhclien
root 487 1 1 21:41 ? 00:00:00 /bin/sh /etc/init.d/rc 2
root 490 487 2 21:41 ? 00:00:00 startpar -p 4 -t 20 -T 3 -M star
root 505 1 8 21:41 ? 00:00:00 /usr/sbin/rsyslogd -c4
root 533 1 1 21:41 ? 00:00:00 /usr/sbin/cron
root 548 1 0 21:41 ? 00:00:00 /sbin/mdadm --monitor --pid-file
root 559 163 1 21:41 ? 00:00:00 udevd --daemon
root 560 163 1 21:41 ? 00:00:00 udevd --daemon
root 561 1 1 21:41 ? 00:00:00 /usr/sbin/sshd
root 567 490 1 21:41 ? 00:00:00 startpar -p 4 -t 20 -T 3 -M star
root 569 567 1 21:41 ? 00:00:00 /bin/sh /etc/init.d/rc.local sta
root 576 569 0 21:41 ? 00:00:00 ps -ef
eth0 Link encap:Ethernet HWaddr 00:22:b0:51:98:79
inet addr:192.168.0.108 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::222:b0ff:fe51:9879/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1252 (1.2 KiB) TX bytes:774 (774.0 B)
Interrupt:21

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

And perhaps a few more lines ( or not ) from the end of syslog:

Jun 1 21:41:57 DNS-323 kernel: [ 42.632143] eth0: link up, 100 Mb/s, full duplex, flow control disabled
Jun 1 21:41:58 DNS-323 /usr/sbin/cron[532]: (CRON) INFO (pidfile fd = 3)
Jun 1 21:41:58 DNS-323 /usr/sbin/cron[533]: (CRON) STARTUP (fork ok)
Jun 1 21:41:58 DNS-323 /usr/sbin/cron[533]: (CRON) INFO (Running @reboot jobs)
Jun 1 21:41:59 DNS-323 kernel: [ 50.572348] NET: Registered protocol family 10
Jun 1 21:42:09 DNS-323 kernel: [ 61.146045] eth0: no IPv6 routers present

[João Cardoso]

the DHCP client is running

 

root 487 1 1 21:41 ? 00:00:00 /bin/sh /etc/init.d/rc 2

runlevel 2 reached

 

root 490 487 2 21:41 ? 00:00:00 startpar -p 4 -t 20 -T 3 -M star
root 505 1 8 21:41 ? 00:00:00 /usr/sbin/rsyslogd -c4
root 533 1 1 21:41 ? 00:00:00 /usr/sbin/cron
root 548 1 0 21:41 ? 00:00:00 /sbin/mdadm --monitor --pid-file
root 559 163 1 21:41 ? 00:00:00 udevd --daemon
root 560 163 1 21:41 ? 00:00:00 udevd --daemon
root 561 1 1 21:41 ? 00:00:00 /usr/sbin/sshd

ssh server running

 

root 567 490 1 21:41 ? 00:00:00 startpar -p 4 -t 20 -T 3 -M star
root 569 567 1 21:41 ? 00:00:00 /bin/sh /etc/init.d/rc.local sta
root 576 569 0 21:41 ? 00:00:00 ps -ef
eth0 Link encap:Ethernet HWaddr 00:22:b0:51:98:79
inet addr:192.168.0.108

the box is using the IP 192.168.0.108

Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::222:b0ff:fe51:9879/64 Scope:Link

 

It even has ipv6 configured

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000
RX bytes:1252 (1.2 KiB) TX bytes:774 (774.0 B)

and even received 774 bytes and sent 1.2KB in 3 packets, probably the DHCP lease request

Debian is working!

You mean that you did not even consulted your router to see if a new IP was assigned to the box?!!!

[hal...@gmail.com]

The same IP address shows up in the router log after Debian is executed in the panel, but the 321 is non-responsive at that address.  Only thing happening is rapid blinking of main blue LED similar to the way it is when 321 is 1st powered on.  There is disk activity after the LED starts blinking quickly but even waiting until the seek sounds are over the only method to regain control is to pull the power plug.

 

[hal...@gmail.com]

I take that back.  Debian is working and can be accessed via SSH into the above address.

I had been attempting to telnet into the box thinking that was the method to connect, but just like the HTML panel access, telnet access is not active in native Debian ( I guess ).  The LED controls aren't working and don't guess the fan control is either ( expected if one thinks about it in a native Debian execution without loading any modules to activate control of them ).

After sign in on native Debian, there is a message which mentions you are on your own and to return to alt-f enter alt-f.  That works as well and returns the 321 back to running alt-f after a reboot (?). 

The Alt-F panel where you click 'EXECUTE' still shows 'failed' but on firefox it shows a series of things stopping on alt-f and finally executing Debian now, even though the 'failed' is still present at the top of the screen.  Opera doesn't show this series of messages unless you click the stop on the browser then they show up.

You have spoiled me and perhaps others by getting Alt-F to manage the LEDs and Fan which is the only outward appearance that an OS is working.

Sorry to have taken so long to try SSH, it isn't installed in the CYGWIN environment on the WIN2K laptop I had been using for testing.

[João Cardoso]

On Monday, June 3, 2013 1:38:20 PM UTC+1, hal...@gmail.com wrote:

...

I take that back.  Debian is working and can be accessed via SSH into the above address.

I had been attempting to telnet into the box thinking that was the method to connect, but just like the HTML panel access, telnet access is not active in native Debian ( I guess ). 

Yes, telnet is considered insecure, as all data (your password included) will be transmitted in plain form.

 

The LED controls aren't working and don't guess the fan control is either

Yes, there is a script that you have to create and activate. It was posted in this forum, so search for it.

 

( expected if one thinks about it in a native Debian execution without loading any modules to activate control of them ).

After sign in on native Debian, there is a message which mentions you are on your own and to return to alt-f enter alt-f.

Yes, the message of the day was edited by the Alt-F installer, so don't make Debian related questions here :-)

 

  That works as well and returns the 321 back to running alt-f after a reboot (?). 

No a reboot, a 'kexec'.

The current Alt-F kernel and initramfs are installed under debian, and the 'alt-f' command kexec them. (the same mechanism used by Alt-F to "launch" Debian)

The Alt-F panel where you click 'EXECUTE' still shows 'failed' but on firefox it shows a series of things stopping on alt-f and finally executing Debian now, even though the 'failed' is still present at the top of the screen.  Opera doesn't show this series of messages unless you click the stop on the browser then they show up.

Fixed that now, thanks.

 

You have spoiled me and perhaps others by getting Alt-F to manage the LEDs and Fan which is the only outward appearance that an OS is working.

Sorry to have taken so long to try SSH, it isn't installed in the CYGWIN environment on the WIN2K laptop I had been using for testing.

All is well when it ends well.

And now we have the confirmation that Alt-F installs and starts Debian on a DNS-321, so it was not a complete loss of time