====
Chris Seto
Admin of hackingthemediavault
====

> Just out of curiosity, how close is Debian to running on the MV2?

Pretty close. All the components are ready and just need to be
integrated into the Debian archive, which might take a week or two.

I blogged about it today at
http://www.cyrius.com/journal/debian/orion/hp/

I'll let you know when it works and when I have written instructions.

--
Martin Michlmayr
http://www.cyrius.com/

* Chris S. <blue765d@...> [2008-06-28 10:04]:
> Is there _any_ sort of Web UI there at all, or this a command line thing
> completely? Reason I ask is I have seen some developers put a basic web
> UI on the firmware, and was just curious...

Debian doesn't have a web UI by default, although I believe that there
are some you could install.

--
Martin Michlmayr
http://www.cyrius.com/

On Mon, Jun 23, 2008 at 1:36 PM, Chris S. <blue765d@...> wrote:
> Hi Marc,
>
> I am very impressed at just how much this device has been picked up by
> serious hackers. I'm fairly good with the MV2, since I am good with PHP, and
> it has a very large PHP based subsystem, but I'm not as serious as some
> people.

The Forceon architecture is impressively fast and capable.  I've done
a lot of hacking
with the NSLU2 including replacing the memory chips only to find that
the Xscale kernel
is incapable of using more than 64MiB--AFAICT, there has been no
progress on fixing
this limitation.   I have high hopes that the Forceon-based systems
device will prove to be more useful overall.  I've heard that there is
a 2GHz version
of the Forceon (IIRC) in the works--though now I'm not sure it is
Marvell or another
vendor working on that.

It helps that HP has been keen to encourage hacking on their hardware.
  They done
a lot to make our process easy.

> Just out of curiosity, how close is Debian to running on the MV2?

We figured out how the system boots and how the recovery procedure works
well enough to have a plan for upgrading without replacing u-boot.  I had hoped,
and was rewarded, with the fact that u-boot on this system can load a single
  uImage file that has both a kernel and the initrd.  This detail was
critical to making
the install of Debian easy.  Without it, we would have needed some
sort of shim to
do fixups to the kernel setup before booting.  Oddly,  the recovery
mode doesn't take advantage of this feature.  (Perhaps HP didn't know
it exists?)

So, I wrote the upgrade utility and we've worked though all of these
booting details to
the point that all we need to do isTurn-the-Crank (TM) and we should
be able to install
Debian on the device.I'm waiting for an initial test kernel and
installer.  There is
already an armel port available, so we expect that MV2 wiill run once
the installer
components are available.

Cheers.

====
Chris Seto
Admin of hackingthemediavault
====

On Mon, Jun 23, 2008 at 1:36 PM, Chris S. <blue765d@aol.com> wrote:
> Hi Marc,
>
> I am very impressed at just how much this device has been picked up by
> serious hackers. I'm fairly good with the MV2, since I am good with PHP, and
> it has a very large PHP based subsystem, but I'm not as serious as some
> people.

The Forceon architecture is impressively fast and capable. I've done
a lot of hacking
with the NSLU2 including replacing the memory chips only to find that
the Xscale kernel
is incapable of using more than 64MiB--AFAICT, there has been no
progress on fixing
this limitation. I have high hopes that the Forceon-based systems
device will prove to be more useful overall. I've heard that there is
a 2GHz version
of the Forceon (IIRC) in the works--though now I'm not sure it is
Marvell or another
vendor working on that.

It helps that HP has been keen to encourage hacking on their hardware.
They done
a lot to make our process easy.

> Just out of curiosity, how close is Debian to running on the MV2?

We figured out how the system boots and how the recovery procedure works
well enough to have a plan for upgrading without replacing u-boot. I had hoped,
and was rewarded, with the fact that u-boot on this system can load a single
uImage file that has both a kernel and the initrd. This detail was
critical to making
the install of Debian easy. Without it, we would have needed some
sort of shim to
do fixups to the kernel setup before booting. Oddly, the recovery
mode doesn't take advantage of this feature. (Perhaps HP didn't know
it exists?)

So, I wrote the upgrade utility and we've worked though all of these
booting details to
the point that all we need to do isTurn-the-Crank (TM) and we should
be able to install
Debian on the device.I'm waiting for an initial test kernel and
installer. There is
already an armel port available, so we expect that MV2 wiill run once
the installer
components are available.

Cheers.

Since I like the idea of using the removable disk as a backup, I've
compiled rsync for the MV1. Then it is posible to have a second
volume, not a RAID mirror neither a JBOD, but a regular one and to use
rsync to maintain a copy of the first volume.
For example you could run in a telnet session:

rsync -auvP --delete /shares/Volume1 /shares/Volume2

I've been testing the program for usual directory synchronizing and it
seems to work. I don't have a second disk, and it would be better that
other people test it. So far APBulletins is the only beta tester :)

What we have learn up to now:

* For the initial copy is better (faster) to simply use the cp
command: cp -aR, because no comparison is needed.

* The most negative feature of rsync is its intensive use of memory:
the official FAQ states it needs ~ 100 bytes per file (number of
files, the file size it's not relevant). Because of the small amount
of memory on MV1, as soon as the process starts swapping it will
become really slow. One possible solution is separate the
synchronization of different subdirectories, for example, if you have
3 subdirectories inside Volume1 (a, b and c):

rsync -auvP --delete /shares/Volume1/a/ /shares/Volume2/a
rsync -auvP --delete /shares/Volume1/b/ /shares/Volume2/b
rsync -auvP --delete /shares/Volume1/c/ /shares/Volume2/c

The executable is a stripped-down static one, so there is not
dependency issues. For using it, it is only needed to copy it to some
meaningful location (inside ShareApps/opt as suggested on Lee webpage
for example) and then run it on a telnet session. This is not an IPKG
binary.

I will upload the file so others can test it.
Cheers

Alberto

Chris,
      if you agree, I could upload the file. Or is it better I send it
as an attach?

A

--- In hackingthemediavault@yahoogroups.com, "Chris S." <blue765d@...>
wrote:
>
> As I know, you know, the source tree is up on hp.com.
>
This is what I found on hp.com

http://h10025.www1.hp.com/ewfrf/wc/document?
docname=c01487768&lc=en&cc=us&dlc=en&product=3660805

The link on that page does not work for me. Anybody with better luck,
or a better link?

PS: I looked around on the ftp server, and the closest thing was a .nas
(?) file. No idea what to do with it.

--- In hackingthemediavault@yahoogroups.com, "Chris S." <blue765d@...>
wrote:
>
> As I know, you know, the source tree is up on hp.com.
>
This is what I found on hp.com

http://h10025.www1.hp.com/ewfrf/wc/document?
docname=c01487768&lc=en&cc=us&dlc=en&product=3660805

The link on that page does not work for me. Anybody with better luck,
or a better link?

PS: I looked around on the ftp server, and the closest thing was a .nas
(?) file. No idea what to do with it.

--- In hackingthemediavault@yahoogroups.com, "Alberto" <acam1999@...>
wrote:
>
> Chris,
>      if you agree, I could upload the file. Or is it better I send it
> as an attach?
>
> A
>

I have uploaded Alberto's compiled binary to the Files section of this
Yahoo Group.  It is for the MV1 only.  Anyone wishing to use it should
consider this effort to be a beta test activity.

-Lee

Hi Chris,
          Lee uploaded it to the files section a couple of days ago.
Thank you

Alberto


--- In hackingthemediavault@yahoogroups.com, "Chris S." <blue765d@...>
wrote:
>
> Hi Alberto, sorry for the long response I didn;t see your message
unit now..
>
> What ever you liek is fine...
>
> Chris
>
>
> ====
> Chris S Seto
> Owner of Hackingthehpmediavault
> ====
>
>
> -----Original Message-----
> From: Alberto <acam1999@...>
> To: hackingthemediavault@yahoogroups.com
> Sent: Tue, 1 Jul 2008 7:18 am
> Subject: [hackingthemediavault] rsync executable
>
>
>
>
>
>
> Chris,
> if you agree, I could upload the file. Or is it better I send it
> as an attach?
>
> A
>

====
Chris Seto
Admin of hackingthemediavault
====

On Mon, Jun 23, 2008 at 1:36 PM, Chris S. <blue765d@aol.com> wrote:
> Hi Marc,
>
> I am very impressed at just how much this device has been picked up by
> serious hackers. I'm fairly good with the MV2, since I am good with PHP, and
> it has a very large PHP based subsystem, but I'm not as serious as some
> people.

The Forceon architecture is impressively fast and capable. I've done
a lot of hacking
with the NSLU2 including replacing the memory chips only to find that
the Xscale kernel
is incapable of using more than 64MiB--AFAICT, there has been no
progress on fixing
this limitation. I have high hopes that the Forceon-based systems
device will prove to be more useful overall. I've heard that there is
a 2GHz version
of the Forceon (IIRC) in the works--though now I'm not sure it is
Marvell or another
vendor working on that.

It helps that HP has been keen to encourage hacking on their hardware.
They done
a lot to make our process easy.

> Just out of curiosity, how close is Debian to running on the MV2?

We figured out how the system boots and how the recovery procedure works
well enough to have a plan for upgrading without replacing u-boot. I had hoped,
and was rewarded, with the fact that u-boot on this system can load a single
uImage file that has both a kernel and the initrd. This detail was
critical to making
the install of Debian easy. Without it, we would have needed some
sort of shim to
do fixups to the kernel setup before booting. Oddly, the recovery
mode doesn't take advantage of this feature. (Perhaps HP didn't know
it exists?)

So, I wrote the upgrade utility and we've worked though all of these
booting details to
the point that all we need to do isTurn-the-Crank (TM) and we should
be able to install
Debian on the device.I'm waiting for an initial test kernel and
installer. There is
already an armel port available, so we expect that MV2 wiill run once
the installer
components are available.

Cheers.

* Chris S. <blue765d@...> [2008-07-10 23:50]:
> Long time no talk! Has any more progress been made on Debian@MV2?

Almost everything has been integrated but we need to work for a new
release of debian-installer so it will actually work.  There'll
hopefully be a rc1 of debian-installer within a month or two.

--
Martin Michlmayr
http://www.cyrius.com/

====
Chris Seto
Admin of hackingthemediavault
====

* Chris S. <blue765d@aol.com> [2008-07-10 23:50]:
> Long time no talk! Has any more progress been made on Debian@MV2?

Almost everything has been integrated but we need to work for a new
release of debian-installer so it will actually work. There'll
hopefully be a rc1 of debian-installer within a month or two.

--
Martin Michlmayr
http://www.cyrius.com/

Cross-posting from the HPMediaVault group b/c I think this question is better suited to the expertise over here...

I've downloaded the mt-daapd nightly svn 1696 build for Unslung/Optware (Little-endian ARM) from http://nightlies.fireflymediaserver.org, copied it to my MV2, and installed it using ipkg.

Although I command ipkg to install the nightly build package from the file system, it overrides my request & downloads the stable build from the ipkg repository.  See here:

# /opt/bin/ipkg -V 3 install /mt-daapd_svn-1696-1_armeb.ipk
pkg_info_preinstall_check: updating arch priority for each package
Clearing state_want and state_flag for pkg=mt-daapd (arch_priority=0 flag=16 want=2)
pkg_info_preinstall_check: update file owner list
best installation candidate for mt-daapd
 adding mt-daapd to providers
  mt-daapd arch=arm arch_priority=10 version=0.2.4.2-1
  mt-daapd arch=armeb arch_priority=0 version=svn-1586-1
  mt-daapd arch=armeb arch_priority=0 version=svn-1696-1
 Found a valid candidate for the install: mt-daapd 0.2.4.2-1
arch arm (priority 10) supported for pkg mt-daapd
Installing mt-daapd (0.2.4.2-1) to root...
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/mt-daapd_0.2.4.2-1_arm.ipk

Am I doing something wrong?  Or is ipkg trying to tell me that the Unslung nightly build is no good on MV2?  Many thanks in advance.

The naming of the nightly ipk is causing the problem here.

From ipkg point of view,

     0.2.4.2-1 > svn-1696-1

If only the nightly was named something like 0.2.5+svn1696
Or better yet, create some release.

-Brian

--- In hackingthemediavault@yahoogroups.com, "chathamsq"
<cooper_s@...> wrote:
>
>
> Cross-posting from the HPMediaVault group b/c I think this question is
> better suited to the expertise over here...
>
> I've downloaded the mt-daapd nightly svn 1696 build for Unslung/Optware
> (Little-endian ARM) from http://nightlies.fireflymediaserver.org, copied
> it to my MV2, and installed it using ipkg.
>
> Although I command ipkg to install the nightly build package from the
> file system, it overrides my request & downloads the stable build from
> the ipkg repository.  See here:
> # /opt/bin/ipkg -V 3 install /mt-daapd_svn-1696-1_armeb.ipk
> pkg_info_preinstall_check: updating arch priority for each package
> Clearing state_want and state_flag for pkg=mt-daapd (arch_priority=0
> flag=16 want=2)
> pkg_info_preinstall_check: update file owner list
> best installation candidate for mt-daapd
>   adding mt-daapd to providers
>    mt-daapd arch=arm arch_priority=10 version=0.2.4.2-1
>    mt-daapd arch=armeb arch_priority=0 version=svn-1586-1
>    mt-daapd arch=armeb arch_priority=0 version=svn-1696-1
>   Found a valid candidate for the install: mt-daapd 0.2.4.2-1
> arch arm (priority 10) supported for pkg mt-daapd
> Installing mt-daapd (0.2.4.2-1) to root...
> Downloading
>
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/mt-da\
> apd_0.2.4.2-1_arm.ipk
>
<http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/mt-d\
> aapd_0.2.4.2-1_arm.ipk>
>
> Am I doing something wrong?  Or is ipkg trying to tell me that the
> Unslung nightly build is no good on MV2?  Many thanks in advance.
>

Im a bit surprised, cause on the NSLU2, just downloading the nightly
build and doing a ipkg on it installs the nightly and does not grab
the release.

I doubt there will be an official release soon of Firefly. The main
maintainer, Ron, has not done much in the past months or so.

Is there another workaround ?

Patrick S.

--- In hackingthemediavault@yahoogroups.com, "Brian Zhou"
<b88zhou@...> wrote:
>
> The naming of the nightly ipk is causing the problem here.
>
> From ipkg point of view,
>
>     0.2.4.2-1 > svn-1696-1
>
> If only the nightly was named something like 0.2.5+svn1696
> Or better yet, create some release.
>
> -Brian
>
> --- In hackingthemediavault@yahoogroups.com, "chathamsq"
> <cooper_s@> wrote:
> >
> >
> > Cross-posting from the HPMediaVault group b/c I think this question is
> > better suited to the expertise over here...
> >
> > I've downloaded the mt-daapd nightly svn 1696 build for
Unslung/Optware
> > (Little-endian ARM) from http://nightlies.fireflymediaserver.org,
copied
> > it to my MV2, and installed it using ipkg.
> >
> > Although I command ipkg to install the nightly build package from the
> > file system, it overrides my request & downloads the stable build from
> > the ipkg repository.  See here:
> > # /opt/bin/ipkg -V 3 install /mt-daapd_svn-1696-1_armeb.ipk
> > pkg_info_preinstall_check: updating arch priority for each package
> > Clearing state_want and state_flag for pkg=mt-daapd (arch_priority=0
> > flag=16 want=2)
> > pkg_info_preinstall_check: update file owner list
> > best installation candidate for mt-daapd
> >   adding mt-daapd to providers
> >    mt-daapd arch=arm arch_priority=10 version=0.2.4.2-1
> >    mt-daapd arch=armeb arch_priority=0 version=svn-1586-1
> >    mt-daapd arch=armeb arch_priority=0 version=svn-1696-1
> >   Found a valid candidate for the install: mt-daapd 0.2.4.2-1
> > arch arm (priority 10) supported for pkg mt-daapd
> > Installing mt-daapd (0.2.4.2-1) to root...
> > Downloading
> >
>
http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/mt-da\
> > apd_0.2.4.2-1_arm.ipk
> >
>
<http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/mt-d\
> > aapd_0.2.4.2-1_arm.ipk>
> >
> > Am I doing something wrong?  Or is ipkg trying to tell me that the
> > Unslung nightly build is no good on MV2?  Many thanks in advance.
> >
>

This is insightful Brian, thank you.

Is this an edit that I can make within the mt-daapd_svn-1696-
1_armeb.ipk package?  Need a bit of detailed guidance as I'm
inexperienced using ipkg.  Appreciate your help.


--- In hackingthemediavault@yahoogroups.com, "Brian Zhou" <b88zhou@...>
wrote:
>
> The naming of the nightly ipk is causing the problem here.
>
> From ipkg point of view,
>
>     0.2.4.2-1 > svn-1696-1
>
> If only the nightly was named something like 0.2.5+svn1696
> Or better yet, create some release.
>
> -Brian

Hi,

I got myself a MV2040 (a MV1) and I want to use ftp externally, but I
am concerned with the standard ftp that it provides.  How do I use sftp
or ftps with my MV2040?  Any help is greatly appreciated!

Hi,

Have you looked at IPKG? Look at Lee Devlin's website, under the IPKG
section.

Chris

====
Chris S Seto
Owner of Hackingthehpmediavault
====


-----Original Message-----
From: thelostcity2008 <thelostcity2008@...>
To: hackingthemediavault@yahoogroups.com
Sent: Fri, 11 Jul 2008 1:52 pm
Subject: [hackingthemediavault] Newbie to this






Hi,

I got myself a MV2040 (a MV1) and I want to use ftp externally, but I
am concerned with the standard ftp that it provides. How do I use sftp
or ftps with my MV2040? Any help is greatly appreciated!

Martin Michlmayr wrote:
>
> * Chris S. <blue765d@... <mailto:blue765d%40aol.com>> [2008-07-10
> 23:50]:
> > Long time no talk! Has any more progress been made on Debian@MV2?
>
> Almost everything has been integrated but we need to work for a new
> release of debian-installer so it will actually work. There'll
> hopefully be a rc1 of debian-installer within a month or two.
>











:-)  Martin knows the details on getting the install image ready.
There is one other thing, tho.  We've found that loading boot images
from the hard-drive can be slow.  Really slow.  We believe the
problem has been isolated to an issue with the format, but I'm not
positive we've found all of the gremlins.

So, I'm working on a port of APEX to the orion so that we can use
it to improve the boot time.  This may not be ready for the next Debian
release.

Hi Marc,

Nice to hear from you :). No big rush! Anything you can do is really
great!

Thanks for the work you have done!
Chris


====
Chris S Seto
Owner of Hackingthehpmediavault
====


-----Original Message-----
From: Marc Singer <eleventen@...>
To: hackingthemediavault@yahoogroups.com
Sent: Mon, 14 Jul 2008 7:42 pm
Subject: Re: [hackingthemediavault] uphpmvault, GNU/Linux program for
uploading recovery images to the media vault






Martin Michlmayr wrote:
>
> * Chris S. <blue765d@... <mailto:blue765d%40aol.com>> [2008-07-10
> 23:50]:
> > Long time no talk! Has any more progress been made on Debian@MV2?
>
> Almost everything has been integrated but we need to work for a new
> release of debian-installer so it will actually work. There'll
> hopefully be a rc1 of debian-installer within a month or two.
>

:-) Martin knows the details on getting the install image ready.
There is one other thing, tho. We've found that loading boot images
from the hard-drive can be slow. Really slow. We believe the
problem has been isolated to an issue with the format, but I'm not
positive we've found all of the gremlins.

So, I'm working on a port of APEX to the orion so that we can use
it to improve the boot time. This may not be ready for the next Debian
release.

# /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-daapd.conf
/opt/sbin/mt-daapd: 1: Syntax error: word unexpected (expecting ")")

I'm afraid the nightly binary is not appropriate for HP MV2.

If you "ipkg install binutils", you can use /opt/bin/readelf,
/opt/bin/file and /opt/bin/objdump to examine the binary. Try

   /opt/bin/file binary # tells you the endian

   /opt/bin/readelf -h /opt/sbin/mt-daapd | grep ^Flag
   /opt/bin/readelf -h /opt/bin/bash | grep ^Flags

The output for MV2 binary should be
   0x4000002, has entry point, Version4 EABI

The output for OABI arm (like debian) is
   0x2, has entry point, GNU EABI

I'm working on an optware mt-daapd-svn (svn rev 1696) package. The
build is basically working, so I've commited my recipe. I can even do
flac transcoding. But with certain flac files, mt-daapd is crashing.
That's why I have not promoted the binary packages to the feed yet. To
build the ipk, you can follow the instruction at
http://www.nslu2-linux.org/wiki/MSSII/HomePage (section starts with
"To build optware ipkg". Native build might work as well, now that
native toolchain is in the feed, but I haven't tried.

-Brian

--- In hackingthemediavault@yahoogroups.com, "chathamsq"
<cooper_s@...> wrote:
>
> Now I'm trying a different angle... never could get ipkg to install the
> Firefly nightly.
>
> So my new plan was to untar the ipk manually and drop the contents into
> /opt.  Then use ipkg to install each of the dependencies specified by
> the control file, & then run the ipk's postinst script.
>
> Hit an early snag when I tried to extract the ipk file: Invalid tar
> magic.  Tried another approach: installed tar from the ipkg repository.
> This was able to open the archive.
>
> So then, finally, we come to this:
>
> # /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-daapd.conf
> /opt/sbin/mt-daapd: 1: Syntax error: word unexpected (expecting ")")
>
> Stumped.  Between this & the ipkg issues I'm having doubts as to whether
> the Unslung build will run on the MV2120...?  Can anyone guess what's
> going on or suggest another approach?  I'm a bit out of my league &
> would appreciate the help.
>

Brian,

Thank you! I've been trying to set this up and it doesn't seem to want
to "stick."

I've got a successful startup.sh running as well and it loads VSFTPD
for me. However, I can't seem to get the logins to work.

the code I've got at the end of rcS is:

[ -e /opt/saves/passwd_saved ] && cp -f /opt/saves/passwd_saved
/etc/passwd
[ -e /opt/saves/group_saved ] && cp -f /opt/saves/group_saved /etc/group

Is that incorrect syntax?

B

--- In hackingthemediavault@yahoogroups.com, "Brian Zhou"
<b88zhou@...> wrote:
>
> After getting root ssh access, the Unix convention is to use a
> non-root and only su/sudo when necessary. Unfortunately, HP firmware
> generates /etc/passwd upon reboot, and sets invalid home and shell
> fields to prevent non-root user from logging in.
>
> Here is a workaround:
>
> 1) after you manually edit /etc/passwd and /etc/group and can login
> with non-root user, save these two files.
>
> You can use the following short script to save:
>
> #!/bin/sh
>
> save_to=/share/1000/Documents/saved-etc
> mkdir -p ${save_to}
> cp -pf /etc/passwd ${save_to}
> cp -pf /etc/group ${save_to}
>
> 2) restore saved files in /etc/init.d/rcS
>
> You can add the following lines to /etc/init.d/rcS before "exit 0"
>
> saved_etc=/share/1000/Documents/saved-etc
> [ -e ${saved_etc}/passwd ] && cp -f ${saved_etc}/passwd /etc/
> [ -e ${saved_etc}/group ] && cp -f ${saved_etc}/group /etc/
>
> If you use /opt/bin/bash from optware ipkg, don't forget to add an
> /etc/shells file. Mine has the following two lines:
>
> /bin/sh
> /opt/bin/bash
>
> Cheers,
>
> -Brian Zhou
>

Well, it is a hack but I figured this out:

Add the users via script!

I created a group called FTP that I will later make the group for my
/share/* directories and my /opt/* directories. This way I can use FTP
with easy permissions.

In "startup.sh" (which is called from rc.bootup as described elsewhere
on the hacking guide for MV2).

Addgroup FTP
Adduser XXXX -D -G FTP
Passwd -P XXXX password
chgrp -R XXXX opt
chgrp -R XXXX share

Now I can ftp in (assuming you have vsftpd or some other ftp server
running) as XXXX with password as my password (its not that of
course). Permissions are easily changeable and now I'm going to set up
Rsync! More on that if I have problems!

B


--- In hackingthemediavault@yahoogroups.com, "monkeybuddhist"
<bwlafleur@...> wrote:
>
> Brian,
>
> Thank you! I've been trying to set this up and it doesn't seem to want
> to "stick."
>
> I've got a successful startup.sh running as well and it loads VSFTPD
> for me. However, I can't seem to get the logins to work.
>
> the code I've got at the end of rcS is:
>
> [ -e /opt/saves/passwd_saved ] && cp -f /opt/saves/passwd_saved
> /etc/passwd
> [ -e /opt/saves/group_saved ] && cp -f /opt/saves/group_saved /etc/group
>
> Is that incorrect syntax?
>
> B
>
> --- In hackingthemediavault@yahoogroups.com, "Brian Zhou"
> <b88zhou@> wrote:
> >
> > After getting root ssh access, the Unix convention is to use a
> > non-root and only su/sudo when necessary. Unfortunately, HP firmware
> > generates /etc/passwd upon reboot, and sets invalid home and shell
> > fields to prevent non-root user from logging in.
> >
> > Here is a workaround:
> >
> > 1) after you manually edit /etc/passwd and /etc/group and can login
> > with non-root user, save these two files.
> >
> > You can use the following short script to save:
> >
> > #!/bin/sh
> >
> > save_to=/share/1000/Documents/saved-etc
> > mkdir -p ${save_to}
> > cp -pf /etc/passwd ${save_to}
> > cp -pf /etc/group ${save_to}
> >
> > 2) restore saved files in /etc/init.d/rcS
> >
> > You can add the following lines to /etc/init.d/rcS before "exit 0"
> >
> > saved_etc=/share/1000/Documents/saved-etc
> > [ -e ${saved_etc}/passwd ] && cp -f ${saved_etc}/passwd /etc/
> > [ -e ${saved_etc}/group ] && cp -f ${saved_etc}/group /etc/
> >
> > If you use /opt/bin/bash from optware ipkg, don't forget to add an
> > /etc/shells file. Mine has the following two lines:
> >
> > /bin/sh
> > /opt/bin/bash
> >
> > Cheers,
> >
> > -Brian Zhou
> >
>

I've added the mt-daapd-svn (1696) ipk to the feed, it conflicts with
mt-daapd (0.2.4.2) ipk. You want to disable the stock mt-daapd as well.

I did not have time to figure out when flac transcoding is working and
when it's not. I hope to get some feedback from people testing it.

Cheers,

-Brian

--- In hackingthemediavault@yahoogroups.com, "chathamsq"
<cooper_s@...> wrote:
>
> Now I'm trying a different angle... never could get ipkg to install the
> Firefly nightly.
>
> So my new plan was to untar the ipk manually and drop the contents into
> /opt.  Then use ipkg to install each of the dependencies specified by
> the control file, & then run the ipk's postinst script.
>
> Hit an early snag when I tried to extract the ipk file: Invalid tar
> magic.  Tried another approach: installed tar from the ipkg repository.
> This was able to open the archive.
>
> So then, finally, we come to this:
>
> # /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-daapd.conf
> /opt/sbin/mt-daapd: 1: Syntax error: word unexpected (expecting ")")
>
> Stumped.  Between this & the ipkg issues I'm having doubts as to whether
> the Unslung build will run on the MV2120...?  Can anyone guess what's
> going on or suggest another approach?  I'm a bit out of my league &
> would appreciate the help.
>

Brian - this is excellent news.  Will give it a go & try to provide
some useful feedback.  Thank you for your efforts.


--- In hackingthemediavault@yahoogroups.com, "Brian Zhou"
<b88zhou@...> wrote:
>
> I've added the mt-daapd-svn (1696) ipk to the feed, it conflicts with
> mt-daapd (0.2.4.2) ipk. You want to disable the stock mt-daapd as well.
>
> I did not have time to figure out when flac transcoding is working and
> when it's not. I hope to get some feedback from people testing it.
>
> Cheers,
>
> -Brian

I'm trying to figure out how to replace the stock (stable) mt-daapd
installation with the nightly build installed via ipkg.  I found this
in rc.bootup:

		 /* Starting iTunes */
		 $ret=daapdfunc_commit("start");

Does anyone know where the daapdfunc_commit function is defined, such
that the path to mt-daapd might be edited?

I suppose an alternative would be to have startup.sh killall mt-daapd,
then start the nightly, but that wouldn't be as clean.  Thanks in
advance for the help.