June 24, 2017, 08:44:56 am
News:
Pages: [1] 2
Print
Author Topic: Solved!! Writable /etc/inittab  (Read 14566 times)
pfft2001
Sr. Member
****
Posts: 378



View Profile
« on: August 17, 2010, 04:40:39 pm »

Here's a cool hack to make this file writable (and to make the serial line automatically log in - BTW, the comment in the file about using "-r" should be ignored):

0) Log in on the serial console.  Of course, once you get this all working, you can put it in the rc.user script.
1) cp -p /etc/inittab /tmp
2) mount --bind /tmp/inittab /etc/inittab
3) vi /etc/inittab

4) Change the serial line to:

::respawn:/sbin/getty -n -l /tmp/mylogin 115200 ttyS0 vt100

5) Then create file: /tmp/mylogin, containing:
#!/bin/sh
exec login -f root

6) Finally, do: exec kill -1 1
to refresh the "init" process.  This also logs you out, after which you
should be immediately logged back in (as root).

P.S.  You can read up on the options to the various busybox "applet"s at:

http://www.busybox.net/downloads/BusyBox.html

P.P.S.  I've done a similar thing to make root's home directory writable (e.g., to set it up for ssh public key encryption login):
1) mkdir /tmp/root
2) mount --bind /tmp/root /root

The first thing you'll notice is that now /root has . and .. entries.
Logged
ChadV
Administrator
Hero Member
*****
Posts: 1611


View Profile WWW
« Reply #1 on: August 17, 2010, 11:26:39 pm »

Great work!  Simple, clean, all the best things in a good hack.

I'm going to sticky this for a while for anyone else that wants to do something similar.
Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #2 on: August 22, 2010, 04:41:28 pm »

That's excellent, thanks for posting this. I wish I knew this 4 years ago...
-G
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #3 on: August 22, 2010, 05:44:17 pm »

That's excellent, thanks for posting this. I wish I knew this 4 years ago...
-G

You're welcome.  I had already used "mount --bind" for directories (for example, to get "dropbear" working without running OSDng), but had never tried doing it for a single file (even though it's there in the man page...).  Then one day, I realized that the "single file" mode could be used to solve my inittab problem.  Ain't Linux great?!!

I'm curious - what problem did you have 4 years ago (with which this knowledge would have helped) ?
Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #4 on: August 23, 2010, 02:11:34 am »

It would've been very useful for when I wanted to change files on the read-only partition! It took Neuros a good while to allow certain files in /etc to be linked to /mnt/OSD so you could edit them. Before that, you had to be creative.

Also I made an LPKG of dropbear a while back, where I'd to hack it since root's directory was not writeable. This would've saved me the trouble.
-G
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #5 on: August 24, 2010, 09:14:32 am »

It would've been very useful for when I wanted to change files on the read-only partition! It took Neuros a good while to allow certain files in /etc to be linked to /mnt/OSD so you could edit them. Before that, you had to be creative.

Heh heh.  Now, I'm curious what you mean by "creative"?  It seems to me that lacking --bind, there's nothing you can do. (Other than rebuilding the firmware from source...)

Also I made an LPKG of dropbear a while back, where I'd to hack it since root's directory was not writeable. This would've saved me the trouble.
-G

Actually, for making root's home dir writable, a simpler solution is just to edit the password file (and point it at something under /mnt/OSD).  But the --bind solution is cooler.

Speaking of dropbear, the real problem that I hit was the fact that dropbear references files in /etc/dropbear - and there doesn't seem to be anyway to create that directory (short of shadowing all of /etc)
I suppose the right way to fix this is to fix the source (to use some other directory) and re-compile, but I didn't feel like going that route.  Or perhaps there is an environment variable to override the location of these files?

Instead, what I did was to take the binary from OSDng and hack it (in vi [!]), doing a global search-and-replace of "/etc/" with "/tmp/".  Note that this trick depends on the (very convenient) fact that "etc" and "tmp" have the same number of letters.
Logged
greyback
Administrator
Hero Member
*****
Posts: 1639


View Profile
« Reply #6 on: August 24, 2010, 03:00:54 pm »

Being creative was usually hacking the source to look for files in /mnt/OSD. It's what I did with dropbear[1]. When it came to linking with libraries, using the LD_LIBRARY_PATH variable also worked.

I did love the fact that I couldn't really break the OSD, since the filesystem was mainly read-only. I'm generally the bad sort of tinkerer, where I always manage to break stuff. My best was an install of Kubuntu, where I stopped it booting to a workable desktop within 6 mouse-clicks! I changed the theme to something lame like blue&yellow, which crashed the desktop, and then refused to start it. Quick delete of .kde fixed it, but still!

But read-only it did make hacking much harder. I could build my own firmware and add functionality, and played with getting OpenEmbedded or dd-wrt build scripts to take advantage of all their work. But then I tried a newer kernel & toolchain and managed to completely brick my OSD. Somehow compiling uboot with a newer compiler broke it. That's harder to fix[2] and I'll know for again Smiley Neuros were kind enough to get me a replacement, but I was a bit more wary from then on.

Then I got busy with work and hacking fell by the way-side. And sadly today I think the OSD is too old in the tooth to play with, it's just a bit too inflexible. I was looking forward to the OSD2 which sadly hasn't materialised. Then I moved country, and I travelled light so all that stuff is left behind. But I do miss having something to hack on.
-G


1. from hazy memories, I recall that /etc/dropbear was needed. But if you're tackling this now, just check in case the daemon has a command line switch to change this to somewhere else. Sadly all my old work is lost. I'm not sure, but I think an over-zealous Ubuntu installer formatted the partition I had all that stuff on - I'm 99% certain I told it not to.
2. I tried to make a JTAG but I'm no hardware hacker.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #7 on: September 29, 2010, 04:52:59 pm »

(A long time ago, I wrote...)

6) Finally, do: exec kill -1 1
to refresh the "init" process.  This also logs you out, after which you
should be immediately logged back in (as root).

An update to this.  I finally got around to putting this in my rc.user and testing it, and I found a little problem.  The "kill -1 1" doesn't work in the rc.user.  After a fair bit of testing (and several reboots), I determined that, like the hack that I use for setting the time on the OSD, the "kill -1 1" has to be executed *after* the rc.user script has exited.  If you inline it in rc.user, it has no effect - that is, init continues to run with its original, unchanged settings.

So, the last line of my rc.user is something like:

(sleep 30;kill -1 1) &

Note that also, the original getty continues to run, so to be 100% clean about it, one should do a "killall getty" somewhere in there, too.  But I didn't do that - so when I first hit the serial console, I have to do ^D or something to get rid of the leftover getty.  So it goes...
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 338



View Profile WWW
« Reply #8 on: April 24, 2012, 10:42:58 pm »

like the hack that I use for setting the time on the OSD,

Hi,

Sorry for resurrecting a long-ago thread, but I'd be interested in knowing how you keep your OSD's time in sync.


Best wishes,

Rick.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #9 on: April 25, 2012, 08:14:19 pm »

like the hack that I use for setting the time on the OSD,

Hi,

Sorry for resurrecting a long-ago thread, but I'd be interested in knowing how you keep your OSD's time in sync.


Best wishes,

Rick.


Hi there - and no problem.  I'm happy to tell my story.

I'm assuming that this is motivated by (or at least connected with) your recent post about replacing the battery on the OSD.  Let me say that I think the batteries on my OSDs are shot (and actually may never have worked), because my machines always seem to come up at "time 0".  That's OK because a) I keep them running all the time (boot infrequently) and I have reliable methods for keeping them on the right time.

First, I want to say that my methods are driven by a desire to install as little, in the way of servers and daemons and such, on the OSDs as possible, because I think these can interfere with the OSD's main function, which is error-free scheduled recordings of my TV shows.  I have direct evidence that running too many "extraneous" processes causes long recordings to fail (I may write this up in another thread - so I won't go into any more detail here).  Anyway, this is why I didn't go the usual Linux route, the one that everybody recommends, which is "Install ntpd".

Next, the task splits into two parts:
1) Getting the time set correctly on boot.
2) Keeping it in sync as time goes by.

The first is actually pretty easy - once you've gotten the right timezone file.  See my recent post on the subject (time sync - again!).  You just have to have a known reliable server that serves up the "rdate" protocol.  I have one from my ISP (but I probably shouldn't divulge it here).  I'm sure there are lots of them around the globe - I'm pretty sure "nist.gov" still runs their server, here in the States.

Anyway, the last line in your rc.user will be something like:

(sleep 30;set -- ...;date -D ...) &

Note, of course, that this all assumes that your OSD is network connected.  If that is not the case, then all bets are off.

The second task (keeping it up while the OSD is running) is more complicated.  Again, I did not want to run the cron daemon on the OSD, so I needed to do the "cron-ing" from outside the OSD.  I have documented my procedure and made available the needed scripts some time ago (like, I think in 2009 or 2010).  Search the forum; you will find it.  If you need further assistance, I will be glad to help.
« Last Edit: April 25, 2012, 08:23:16 pm by pfft2001 » Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 338



View Profile WWW
« Reply #10 on: April 25, 2012, 10:54:30 pm »

Hi,

My OSD is networked, but not to the outside world. However I noticed a post from you using something called "expect" to do the time update manually from a host computer (my machine is kept correct, so that'll be okay). I may (in time) write a little VB applet to telnet into the OSD and fiddle the time, with a bit more checking (ie it'll look to see if we're recording first). It's probably also not a help that my OSD is in a different timezone. I'll snarf the expect stuff and play around with it.

Does that, by the way, update the hardware clock, or just the soft copy?


I left the OSD unplugged for five minutes after setting the time since changing the battery and I've come across an interesting quirk. I was about to panic due to the OSD losing 10 seconds in five minutes, however the onboard clock is actually still on time. It's the UI clock down the bottom right that doesn't seem to update until ten seconds have elapsed. I wonder if this is specific to the UI or if the recording is also laggy? [firmware: OSDng]


Best wishes,

Rick.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #11 on: April 29, 2012, 07:54:12 am »

I may (in time) write a little VB applet to telnet into the OSD and fiddle the time,
I don't know why you'd want to fiddle around with VB when Expect is so much better for this sort of task, and is cross-platform (VB is, obviously, MS only).

It's probably also not a help that my OSD is in a different timezone. I'll snarf the expect stuff and play around with it.
Actually, the nice thing about the "telnet in" method is that timezones don't matter.  Since most of hte processing is done on the host side, you're just setting the OSD to whatever your local system says is the current time.  This is what makes the other side of it (setting it from the OSD side) more difficult - there, you do care about and have to worry about timezones (and DST).

Does that, by the way, update the hardware clock, or just the soft copy?

Now, there is an interesting question!  I'm guessing it is the soft copy only, which is a shame, but the funny thing is, I can't figure out a way to test it.  As it happens, the built-in version of busybox on the OSD does not have a "hwclock" command, so you can't use that to test.  However, I have compiled a newer, better (more commands) version of busybox (version 1.9.0) that does have "hwclock".  Unfortunately, I could not get it to work:

$ bin/busybox hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory

$ bin/busybox hwclock -r -f /dev/neuros_rtc
hwclock: RTC_RD_TIME: Invalid argument

To Chad, et al: I doubt there is much hope of getting this to work, is there?  Is there some other OSD-specific tool for accessing/changing the RTC?

I left the OSD unplugged for five minutes after setting the time since changing the battery and I've come across an interesting quirk. I was about to panic due to the OSD losing 10 seconds in five minutes, however the onboard clock is actually still on time. It's the UI clock down the bottom right that doesn't seem to update until ten seconds have elapsed. I wonder if this is specific to the UI or if the recording is also laggy? [firmware: OSDng]

The UI has always lagged in terms of updating the time.  I wouldn't read too much into this.
Logged
ChadV
Administrator
Hero Member
*****
Posts: 1611


View Profile WWW
« Reply #12 on: April 29, 2012, 09:29:40 am »

To Chad, et al: I doubt there is much hope of getting this to work, is there?  Is there some other OSD-specific tool for accessing/changing the RTC?

Sadly, I was hired in as support, not a dev, and never really got a chance to poke in the source or hw spec at all (yet)...
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 338



View Profile WWW
« Reply #13 on: April 29, 2012, 09:35:08 am »

I don't know why you'd want to fiddle around with VB

Because I can knock off a custom task fairly quickly.


Quote
Since most of hte processing is done on the host side, you're just setting the OSD to whatever your local system says is the current time.

No - my OSD and satellite receiver run to British time. Everything else is on local (French) time. So to set one from the other, corrections would be necessary, however it is done.


Quote
Now, there is an interesting question!  I'm guessing it is the soft copy only, which is a shame, but the funny thing is, I can't figure out a way to test it.

The way I tested my battery was to set the clock, unplug the thing for five minutes, and see what the time was when reconnected.


Quote
Unfortunately, I could not get it to work:

Not a surprise. It is a rather non-standard way of implementing a clock, using the MSP430 microcontroller instead of a dedicated RTC. This saves a chip because the MSP430 also deals in some way or other with the remote control. Unfortunately, the damn thing is in the realm of closed source binaries so it's anybody's guess as to how to actually talk to the clock.
There's a build of Debian that will run on the OSD, found it years ago. It works, but time is "frozen" because there's no driver that understands that sort of clock.


Quote
To Chad, et al: I doubt there is much hope of getting this to work, is there?  Is there some other OSD-specific tool for accessing/changing the RTC?

Try rebuilding this for the Arizona/OSDng firmware? [I don't have my dev enviro available right now]


Quote
The UI has always lagged in terms of updating the time.  I wouldn't read too much into this.

Okay, thanks for the confirmation.


Best wishes,

Rick.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 338



View Profile WWW
« Reply #14 on: April 29, 2012, 09:45:44 am »

$ bin/busybox hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory

$ bin/busybox hwclock -r -f /dev/neuros_rtc
hwclock: RTC_RD_TIME: Invalid argument

RTC "cooler" code here to show you how it is done by Neuros.


Best wishes,

Rick.

[edited to remember closing quote tag Wink ]
« Last Edit: April 29, 2012, 09:47:37 am by heyrick » Logged
Pages: [1] 2
Print
Jump to: