PDA

View Full Version : U5 Hacked HDVR2 30K ft Boot Process flow



tivomaster
08-11-2003, 08:01 AM
From a 30,000 foot level is the the right boot process?

1. Boots the Prom
2. Brings in the U5 kernal
3. Fires off the Hacked initrd
4. Fires off rc.sysinit which fires off TiVo progams
5. Fires off /var/hack/hackinit.... (put in via bootpage)

If so is all of the above serial or does any of the steps occurn simultaneously?

mrblack51
08-11-2003, 10:28 AM
if you are talking about bash_env, then you never fire off a hacked initrd, because that would cause the kernel to fail the prom's hash and not boot.

1. prom boots
2. kernel booted by prom
3. initrd booted by kernel
4. hackinit spawned
5. rc.sysinit and related stuff spawned.

4 & 5 run pseudo concurrently. if you put stuff early in the hackinit, you can have it run before the rc.sysinit starts doing its thing. if you throw in delays in rc.sysinit, then you will be waiting for parts of rc.sysinit to finish before your commands after the sleep commands are run.

tivomaster
08-11-2003, 10:49 AM
Originally posted by mrblack51


4 & 5 run pseudo concurrently. if you put stuff early in the hackinit, you can have it run before the rc.sysinit starts doing its thing. if you throw in delays in rc.sysinit, then you will be waiting for parts of rc.sysinit to finish before your commands after the sleep commands are run.

Thanks. Excellent explaination. That makes sense. I was talking about the bash_env mod...
When does the rc.sysinit get rewritten with TiVo's default? It would have to be prior to it firing off but if so seems like if you put the rc.sysinit reload in hackinit that the rebuild could step on your hacked version.

Thanks again. I am trying my best to understand this process without giving up an declaring it "magic"....

mrblack51
08-11-2003, 11:44 AM
Originally posted by tivomaster
Thanks. Excellent explaination. That makes sense. I was talking about the bash_env mod...
When does the rc.sysinit get rewritten with TiVo's default? It would have to be prior to it firing off but if so seems like if you put the rc.sysinit reload in hackinit that the rebuild could step on your hacked version.

Thanks again. I am trying my best to understand this process without giving up an declaring it "magic"....

the boot process for a bash_env'd unit where you change anything on the root partition is actually two boots, one after the other.

the first boot runs, and the initrd will see any stuff that you changed, and delete it, then if it has a copy, it will put its copy as the replacement.

if any files on the root had been modified, the unit will reboot. at that point, since the initrd checks should pass, the unit will kick off the bash_env stuff and you're off to the races.

i think that answers your question.

tivomaster
08-11-2003, 12:54 PM
Originally posted by mrblack51
the boot process for a bash_env'd unit where you change anything on the root partition is actually two boots, one after the other.

the first boot runs, and the initrd will see any stuff that you changed, and delete it, then if it has a copy, it will put its copy as the replacement.

if any files on the root had been modified, the unit will reboot. at that point, since the initrd checks should pass, the unit will kick off the bash_env stuff and you're off to the races.

i think that answers your question.

Thanks for your patience but I am still a little confused.. With the process you outlined above wouldn't the replace rc.sysinit/reboot that you said initrd does if it detects tampering wipe out any "modifications" that you just put in to prevent updates?

Thanks for your patience.... But I am still confused.

Would the process then be..
1. prom boots
2. kernel booted by prom
3. initrd booted by kernel
3a. initrd detects modified rc.sysinit
3b. initrd replaces rc.sysinit with "clean" copy
4. reboot

I know when the light go's on it going to be one of those "Dooooh" moments.

mrblack51
08-11-2003, 04:22 PM
hmmm, i guess tivomaster wasn't such an appropriate nick for ya, eh =) ah well, must be anticipation.

ok, so like i said, there are possibly two boots. if you havent changed anything on the root partition, then it will only have the straight boot, otherwise, it will have to reboot to "fix" a file htat has been changed. if you replace your rc.sysinit via your hackinit, then you unit would reboot when it wiped the modified copy before allowing you to get in via bash_env.

ok, so to put this in pseudo-code (which may not help)



1) boot prom
1.1) if (prom checksum != stored checksum in prom)
then reboot
1.2) if (kernel checksum != kernel stored checksum)
then reboot
1.3) load kernel
1.4) load & run initrd

2) in initrd...
2.1) for each file on root partition {
2.2) if (file checksum in initrd != file checksum)
attempt to delete, and attempt to replace if replacement available
}
2.3) if (any files failed checksum)
then reboot

3) execute boot parametersn (including bash_env)
3.1) execute hackinit
3.2) execute rc.sysinit


so, everything in steps 1.x and 2.x are required, unless you hack your prom. if you have changed your rc.sysinit via hackinit, then check 2.2 will cause the deletion, and 2.3 will cause the reboot. on the reboot, 2.2 will not be triggered, because the file that was modified won't exist or will have been replaced with a good version.

tivomaster
08-11-2003, 04:55 PM
If hackinit and rc.sysinit run "psuedo concurrently" couldn't it cause a race condition on the second boot where rc.sysinit is running before hackinit put the modified version in place? This is puzzling to me because your rc.sysinit replacement code is at the end of your hackinit.

On the tivomaster monicker.. I picked it out of aspiration. After all you will never attain your goals without someting to shoot for...

Thanks....

mrblack51
08-11-2003, 05:00 PM
Originally posted by tivomaster
If hackinit and rc.sysinit run "psuedo concurrently" couldn't it cause a race condition on the second boot where rc.sysinit is running before hackinit put the modified version in place? This is puzzling to me because your rc.sysinit replacement code is at the end of your hackinit.

On the tivomaster monicker.. I picked it out of aspiration. After all you will never attain your goals without someting to shoot for...

Thanks....

just givin you crap on the nick thing =)

as for the race condition, yeah, its possible. however, my hackinit had no delays in it, and it worked fine for me. however, if you have the delays in there, then you probably want to replace the rc.sysinit right away

tivomaster
08-11-2003, 05:16 PM
Originally posted by mrblack51
just givin you crap on the nick thing =)

as for the race condition, yeah, its possible. however, my hackinit had no delays in it, and it worked fine for me. however, if you have the delays in there, then you probably want to replace the rc.sysinit right away

I figured you were just given me heck over the nick. I expected it when I picked it ;-).... But then if we can't take a joke we live in the wrong world.

I understand the hacked rc.sysint boot process fully now.....
or at least enough to be dangeous ;-)

Thanks for the patient explaination....
You Da Man!!!!!

David Bought
08-12-2003, 06:18 PM
Originally posted by tivomaster
If hackinit and rc.sysinit run "psuedo concurrently" couldn't it cause a race condition on the second boot where rc.sysinit is running before hackinit put the modified version in place? This is puzzling to me because your rc.sysinit replacement code is at the end of your hackinit.

There are ways around this that do not involve hacking rc.sysinit. For instance, "switcherstart -w" (with the appropriate env vars set) may help you postpone various hacks until MFS has been started. You may also be able to satisfy certain dependencies from your hackinit so that you don't have to wait for rc.sysinit to take care of them (in particular, a lot of users will insmod several kernel modules from hackinit so that they can start an illegally modified dssapp in /var from hackinit instead of running it from rc.arch).

TiVoByte
10-14-2003, 09:26 PM
Why not delete the /tvlib/tcl/updateSoftware.tcl from hackinit??

My understanding is it's ok if the file isn't there.

??

RS