LinHES Forums
http://forums.linhes.org/

LinHES Frontend on a USB Memory Stick - Discussion
http://forums.linhes.org/viewtopic.php?f=22&t=20922		 Page 2 of 2
Author:  Martian [ Thu Mar 18, 2010 7:36 am ]
Post subject: 
With 15TB of disk space I'm guessing you have seen Serenity. Can we call you Mr. Universe?
Author:  christ [ Thu Mar 18, 2010 7:53 am ]
Post subject: 
Martian wrote:
With 15TB of disk space I'm guessing you have seen Serenity. Can we call you Mr. Universe?

LMAO. I'll have to mention that to my lovebot. Damn shame that series got canned but I'm glad that movie was able to wrap it up.
Author:  djb61230 [ Thu Mar 18, 2010 10:38 am ]
Post subject: 
Nice amount of space!!

However...the way the script is set up it will put the client file systems in a directory off of root called I believe /tftproot (or something similar I don't have my machine here to verify :)

Sooooo, if at install time if your root partition was only 5gb (the LinHES default I believe) then you have to be aware that you might need to mount another partition on /tfptroot before running the script to setup your clients...

I'll time a boot tonight...I have similar hardware, a little bit slower core2 machines but I have upgraded to gigabit networking.
Author:  Greg Frost [ Thu Mar 18, 2010 2:20 pm ]
Post subject: 
/tftproot is only for the tftp'd files. The actual NFS root which takes a few Gig can be anywhere you want. By default it is in /nfsroot/frontend_name, but there is no reason it coulnt be somewhere else. using the /myth partition has been problematic because as someone has already mentiond, it doesnt always have enough inodes for a root filesystem.
Author:  Big boy stan [ Thu Mar 18, 2010 3:09 pm ]
Post subject: 
The biggest problem with keeping the nfsroot on the / partition is that it gets clobbered by the install script. Of course pacman may solve this problem but if you ever need to upgrade from the iso, you loose all the set up work on the diskless frontend. I still think that a 3rd partition just for frontends is the way to go.
Author:  Greg Frost [ Fri Mar 19, 2010 2:30 am ]
Post subject: 
The current diskless frontend scrip allows you to have a tweaker script in /root/diskless_tweak.${frontend_name} which is run in chroot of the new nfs root. An example of such a script is below. Using scripts like this has allowed me to test installations of new versions (from iso) on my production box whilst still being able to quickly restore my diskless FEs.
Code:
#!/bin/bash

# Change the X resolution for the frontend.
sed -i 's/^[[:space:]]*Modes.*$/\tModes "1440x900"/g' /etc/X11/xorg.conf

# Disable the use of mythwelcome.
sed -i 's/UseMythWelcome="1"/UseMythWelcome="0"/g' /etc/systemconfig

cat > /etc/asound.state << EOF
contents of asound.state removed for brevity.
EOF
Author:  iscraigh [ Sun Mar 21, 2010 2:29 pm ]
Post subject: 
Not to get back to the usb stick idea but I do run a front end on a usb stick. Why you ask....

Could not get the SIS video drivers to work properly in mythbuntu or linhes.

I used a usb distribution called dpup wich is based on puppy linux.

I then installed the myth frontend .deb's from debian-multimedia.org

spent a little while in dependency hell, installed all listed dep I could find using the puppy package manager then tracked down deb's for the ones I couldn't find. Started it from a command prompt, found a few more missing libs and voila, a mythfrontend on a usb stick that remembers your settings.

Craig
Author:  poflynn [ Mon Mar 22, 2010 4:12 pm ]
Post subject: 
christ wrote:
1) set up complexity and ongoing maintenance and updates of each front end image. Once you set up an image, how much process is it to up date to the latest packages, themes, etc.


No different than on a real HD, as mentioned by others.

christ wrote:
2) Boot up performance (initial discovery can take about 10s)


It's faster than I expected but not as fast as a real HD. Discovery probably takes about 4s. Booting is surprisingly fast considering it's over the network. But as I said, it is slower, I should time it for you... But I generally leave my FE running for a long time, it's not like it's using much power or making much noise (thx to the lack of a HD). I once had a cron job run every night at 1am that did a shutdown, just in case I forgot to shut it down.

christ wrote:
3) potential complexity in my environment which is networked with 3 backends running virtualized on my main server.


Well this is curious. Why would one virtualize 3 BEs? Unless maybe they have direct access to your tuners, I guess they must? Anyway, I have one virtualized MBE from which 2 FEs & 1 SBE boot in a diskless fashion. I take a snapshot of my VM & I have my entire system instantly backed up - sweet. You can read more here http://www.knoppmythwiki.org/index.php?page=WakeSBEOnly
Author:  christ [ Mon Mar 22, 2010 5:27 pm ]
Post subject: 
poflynn wrote:
christ wrote:
3) potential complexity in my environment which is networked with 3 backends running virtualized on my main server.


Well this is curious. Why would one virtualize 3 BEs? Unless maybe they have direct access to your tuners, I guess they must? Anyway, I have one virtualized MBE from which 2 FEs & 1 SBE boot in a diskless fashion. I take a snapshot of my VM & I have my entire system instantly backed up - sweet. You can read more here http://www.knoppmythwiki.org/index.php?page=WakeSBEOnly

Indeed. One of the perks of VM. I run my recorders and scheduler on the MBE. All commercial flagging and transcoding I do on SBEs to keep it from bogging down the MBE. I run each BE as a single processor guest across 4 cores on the host. Each SBE will allow only one job at a time. This allows ideal loading on the host and optimal performance of the MBE. When I use to run it all on the MBE it used to bog down and I had to serialize a the flagging and transcoding.

Part of the issue with load is my daughters record everything in sight that they might want to watch and then cherry pick what they actually want. Thus the two HD PVRs are almost running continuously! I currently show 133 shows to be recorded in the next two weeks. yikes.

Of course all of my shows have higher priority. :lol:
Author:  mihanson [ Mon Mar 22, 2010 10:33 pm ]
Post subject: 
christ wrote:
I run each BE as a single processor guest across 4 cores on the host. Each SBE will allow only one job at a time. This allows ideal loading on the host and optimal performance of the MBE. When I use to run it all on the MBE it used to bog down and I had to serialize a the flagging and transcoding.


christ: Have you tried irqbalance? It's in the extra repo.
Author:  christ [ Tue Mar 23, 2010 6:53 pm ]
Post subject: 
mihanson wrote:
christ: Have you tried irqbalance? It's in the extra repo.

Nope. Not sure it would help my situation for the virtual machines as the issue has more to do with current vm architectures. I don't use multi-core VMs because they will always need to schedule the number of cores you configure it to be. Ie. if you designate a VM to be dual-core then it will always schedule two cores even if it needs one. Hence with a typical myth scenario you are over allocating resource and potentially under performing as you have to wait for two cores to become available.

By running three uni-proc VM's instead, the idle VM's sit idle and when they have work they will get evenly distributed across the cores.
Author:  poflynn [ Wed Mar 24, 2010 12:53 pm ]
Post subject: 
christ wrote:
if you designate a VM to be dual-core then it will always schedule two cores even if it needs one.


I get your concept of spreading the load but I'm slightly confused by what you mean by "scheduling" the cores. You mean that the VM will somehow lock both cores (if it was assigned two) but possibly only use one or something? I have 2 (of 4) cores allocated to my MBE which runs commercial flagging etc & I have noticed it never seems to keep more than one core busy (but I do very little recording). I am using VirtualBox with AMD's h/w VM extensions turned on.
Author:  christ [ Fri Mar 26, 2010 12:32 pm ]
Post subject: 
poflynn wrote:
christ wrote:
if you designate a VM to be dual-core then it will always schedule two cores even if it needs one.


I get your concept of spreading the load but I'm slightly confused by what you mean by "scheduling" the cores. You mean that the VM will somehow lock both cores (if it was assigned two) but possibly only use one or something?


it's possible Virtualbox has this solved. But with many VM solutions including VMWare, a dual-proc guest needs to run as a dual proc system. So what happens is whenever the guest has work to do it schedules in to the OS requesting two cores. When two cores are free they are then allocated and the guest is run. While the guest is running these two cores will not be allocated to other tasks. So if your guest really only needs one core then it will use the one core but it will also keep the other core reserved and idle.

If your system is lightly loaded it is not a big deal though it could cause the occasional jitter of your MBE having to wait for two free cores.

I keep my box pretty busy and with two HD-PVRs myth alone can keep 3 cores quite busy. It is not unusual for my box to have all four cores rocking.
Author:  silentaccord [ Wed Jul 28, 2010 8:25 am ]
Post subject: 
I found this thread as I was searching for help installing LinHES to a USB flash drive and though it didn't really help, I eventually got it working. It seems like there are two main issues when installing to a USB drive. One is that grub isn't setup properly. The other is that the USB hook is missing from mkinitcpio.conf (http://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key#USB_Support). Here are the instructions to fix these for anyone else who's still interested in booting from USB.

1) Install LinHES to your USB drive. At the end of the installation, do not reboot or shutdown.
2) Type Ctrl-Alt-F3 to get a console. Login as root (no password necessary).
3) Run grub.
Code:
grub
Enter the following commands in grub.
Code:
find /boot/grub/stage1
This will return something like "(hd1,0)". Your number may be a different. Whatever it is, enter it in the next command.
Code:
root (hd1,0)
Now drop the ",0" for the next command (e.g., hd1,0 becomes hd1)
Code:
setup (hd1)
Quit grub.
Code:
quit

4) Find out which partition is the root of the USB drive.
Code:
df | grep usb-sd.1 | awk '{ print $1 }'
You should see something like this:
Quote:
/dev/sdb1
In this example, the partition is /dev/sdb1

5) Change root
Code:
mount -t ext3 /dev/sdb1 /new_boot
This assumes you selected ext3 during the installation. If you selected another format, enter that instead. If your partition in the previous step was something other than /dev/sdb1, enter that. It's ok if you get an error saying it's already mounted.
Code:
cd /new_boot
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/
chroot . /bin/bash

6) Add the USB hook to /etc/mkinitcpio.conf
Code:
nano /etc/mkinitcpio.conf
Page down (Ctrl-V) to the end of the file. The last line should look like this:
Quote:
HOOKS="base udev autodetect pata scsi sata filesystems"
Insert "usb" after udev so it looks like this:
Quote:
HOOKS="base udev usb autodetect pata scsi sata filesystems"

7) Regenerate the initrd image
Code:
mkinitcpio -p kernel26

8) Reboot
Code:
reboot


Notes:
You'll need a flash drive that's at least 4GB to install LinHES. I made the root partition 3GB, selected no swap (flash media will deteriorate after too many write operations), and used the rest for /myth (though that partition won't be used in a frontend-only installation).

The LinHES installer setup grub on the internal HDD of my test machine even though I did not install to that drive. You should probably disconnect any other drives during the installation to prevent this.

To avoid unnecessary writes to flash media, you may want to look into Ramlog (http://www.tremende.com/ramlog). I haven't tested this yet but I plan to do so.
Page 2 of 2 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/