Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - phenigma

Pages: 1 ... 57 58 [59] 60 61 ... 99
871
Or upgrade your core, and then run /usr/pluto/bin/Diskless_CreateTBZ.sh as root. Delete your MD and create it again.

L3mce, could we not just hit the 'Rebuild Image' button which removes the dir in /diskless/XX and re-extracts from the diskless image created by /usr/pluto/bin/Diskless_CreateTBZ.sh back to the same diskless/XX location?  This way I keep any devices that were configured on that MD but still get the benefit of the update without deleting the MD completely.

BTW, I have a GT210, same as in your example, I have been assuming you don't need the data from it as it is identical to your example. - [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)

J.

872
Feature requests & roadmap / Re: Bloated MDs
« on: August 18, 2012, 07:51:33 pm »
Hi, great topic!  Figure I'll put my 2 cents in here as I understand things as I am working on an alternate MD right now.

I don't really think the MDs are bloated.  That will depend on you point of view I suppose but many appreciate the functionality.  My MDs occupy 2.7GB of space each on my core (without Game_Player).  Even with 5 MDs I only consume 22GB of space on my core.  I can't even buy an HD of less than about 30GB (20GB for SDD) these days and can even get an SSD for $50 in that size.  My personal feeling is to leave the stuff in place and don't hit the 'Start KDE' button unless you want to.  Removing KDE entirely would not quite save ~1GB per MD.  I don't see a space concern/savings.  I don't see significant 'bloat'.

Since I tossed this out there I will be the one to have a first crack at it and will submit what I come up with for everyone to review.  Typically I overthink things but in this case I might be thinking its too easy of a change.  The DVD installer adds some desktop applications on the hybrid/core.  It was odd to me then that the Diskless_Setup by default actually creates more desktop applications and programs.  If there is discussion about the usefulness of a desktop environment lets keep it to media director only.  The core/hybrid has a desktop now and if you want to add little progs or apps then put them there or work on changing the primary installer.

The difference in applications is more about where the packages come from than what is intentionally being installed.  The hybrid/core packages are taken directly from a kubuntu live cd, the MD files are built through package installation.  The liveCD has packages removed, by the kubuntu team, to allow for it to live within the small space of a single CD.  The MD diskless image is created and the package 'kubuntu-desktop' is installed from repository, which installs all of kubuntu and all of the packages you see on an MD.  In my recollection of the setup procedures this is the primary difference in the packages available on the core and on an MD.  This also causes some services to be started on MDs that are not run on the core, iirc.

My proposal and the task I believe I am up to involved the Diskless_Setup only, it is something I think I have the ability to change myself with my limited programming ability.  Correct me if I am completely off the wall but this is how I think the process works.

A new device is plugged into the network and looks for a DHCP to point it towards a bootloader.
DCErouter (specifically tftpboot.cfg) creates a few new directories based on its MAC address and points it to initrd and vnlinuz
The new device uses these as kernel= and boot=, and builds its image in root=<core>/?/nfs
Based on the content of vnlinuz and initrd, combined with polled info from various scripts the MD image is created just as it would install itself on a computer with a ubuntu install cd.
-add my changes
Because bootloaders can have options in the menu.1st file (sorry I know grub best, even though lmce I think uses something else because of the APPEND options) I believe I can add options here that will point to alternative initrd and vnlinuz versions.
Default option = just like it is now
Option1 = load initrd and vnlinuz that install different applications
Option2 = load initrd and vnlinuz that install different applications
Option3 = load initrd and vnlinuz that install different applications

There are options in the web-admin and warnings about kernel version on MDs so that part I don't think I have any control over.  I have tinkered though and adjusted the bootloader on the core to point a specific MAC address to a custom folder which booted TinyCore, DSL, 12.04 LTS and openWRT on different machines around my house.  I never got my own custom dsl+squeezebox configuration to boot however and is what led me to the idea of taking LMCE's setup and changing it to my desire.

I believe that I can take all of the source code needed to compile LMCE diskless, change and remove certain components and then compile and make options in the bootloader menu to select that version.  Is that an accurate statement?  Obviously I would need to debug and repeat a lot of effort but because I am only altering working source code, I would assume I am only looking at minor necessary work.  The years of hard work and coding behind current LMCE remains and I am just the jack-wagon that stripped some off.

If some off-the-shelf hardware doesn't quite fit the bill for a full MD, why not have the option to boot as audio only MD?  If an MD is going on the bedroom wall where a keyboard will never touch it why not have the ability to boot it without a desktop?  If I want to build a minimal media MD for use as an intercom outdoors, why can't I load a boot template designed for just that?  These are all just pipe-dreams of mine at this time as I haven't done yet any modification or compiling of lmce code.  I have just booted other pre-compiled kernels using lmce tftpboot. 

Issues/Challenges I see:
There is no 'bootloader' per se.  PXE loads kernel/initrd (common if the MAC is not found, from diskless/XX if the device exists) which bootstraps the running kernel from the diskless/XX directory.  Grub is not used on the MDs as they are PXE booted, which occurs before grub would have a chance to run.  This behaviour cannot be changed without significant user interaction to install grub on the MD before attempting the first boot.  This would significantly detract from the 'plug and play' nature of the system.

Your statements about adding bootloader options and "If an MD is going on the bedroom wall where a keyboard will never touch it why not have the ability to boot it without a desktop?" are contradictory.  Remember that an MD is not intended to have a keyboard and mouse connected and as such there is likely no interaction between the user and the bootloader on an MD.  This is desired behaviour and likely how it should remain.  There is a reason that there is no user interaction with the MD until the AVWizard which allows for many different input devices to manipulate it, including game controllers and IR remotes, which cannot interact with a bootloader.  Adding a bootloader is going to significantly add to the boot time of the media director everytime it boots.  This, to me, is not desireable and would degrade the experience significantly.

What you are trying to achieve IS doable though... The 'right' way to approach this???:
"If some off-the-shelf hardware doesn't quite fit the bill for a full MD, why not have the option to boot as audio only MD?" - This is exactly what device templates are for.  All MDs are currently built on the 'Generic PC as MD' device template.  That doesn't have to be the case.  Device templates could, *should*, be created for different devices that cannot act as a full MD.  This give you the ability to add that device and have an lmce core create the device (and associated diskless folders, etc.) within its' capabilities.  This could be as simple as the device being recognized under the alternate device template on first PXE boot, or if the device is capable of a Full MD but you want less, you could add the 'less of a MD' device template manually and enter the MAC address into the webadmin.  As you have already discovered the nfsboot folders can be altered/changed to accomodate any device.  Those folders can be setup properly (and automatically) through the use of device templates.

Existing functionality of MDs, and the current method of Diskless_Setup, should be left entirely intact as it is desireable for many.  New DTs that create new (different) directory structures under /diskless/XX/ at the moment the DT is added would be my recommendation.  This will require changes to Diskless_Setup as well, but would leave existing MD generation the way it is.  This is what I am attempting with the Raspberry Pi. I haven't made it to the DT/autosetup part yet.

Hopefully this novel of a comment clears up what I plan to do and how I plan to do it.  After everyone has a laugh at my ignorance please feel free to correct me. :)

No laughing.  I don't intend to sound too critical either, I tend to over-analyze and point out down-sides, it's a back character trait of mine.  But I understand what you are trying to do and think it could be very useful if applied in a way that is consistent with the mechanics of the existing system.

J.

873
Users / Re: We have a 1004 beta
« on: August 16, 2012, 07:01:23 pm »
Those trying 1004 for the first time, please be aware of the fact that on the snapshots, you do NOT need to run Diskless_CreateTBZ.sh as it is embedded. Network installs will still require it. From snap install you just have to plug an MD in and roll.

Great news!  This will make setup sooo much easier for people!

J.

874
Users / Re: We have a 1004 beta
« on: August 15, 2012, 03:02:07 pm »
Great stuff!  Congrats Everyone!

J.

875
Feature requests & roadmap / Re: raspberry pi
« on: July 26, 2012, 04:24:26 am »
Early stages yet but good progress on database updates so far.  Lots still to do for this to be usable. 

Thanks to golgo for qOrbiter and to coley for porting it to Qt5 on the RPi, that is what could really make the RPi a viable (usable) device.

J

876
Users / Re: Dianemo S - Control 3D functions on LG TV via Serial
« on: July 25, 2012, 04:04:37 am »
My panasonic vierra has similar types of settings, it's in use right now but I recall it that it has options for side by side and frame sequential settings, can't recall about checkerboard or top bottom.

J.

877
Developers / Re: Raspberry Pi builder
« on: July 24, 2012, 06:04:03 pm »
I setup a wiki page with some basic steps, issue list etc for following/post documenting porting to raspbian, please add/remove/comment as you see issues arise and fall.

http://wiki.linuxmce.org/index.php/Porting_Raspbian

J.

878
Developers / Re: Raspberry Pi builder
« on: July 24, 2012, 04:18:59 pm »
Database changes are the first step.  New builder conf files to add the new distro and arch information are also required.  I have this working here.  I've finally got some time and I'll jump into -devel and see if I can get on the database changes.

J.

879
Developers / Re: Raspberry Pi omxplayer device
« on: July 24, 2012, 04:10:21 pm »
More importantly, this can be adapted so that MakeRelease can build arm packages for linuxmce. (I would suggest this as an exercise, to be able to run the Ubuntu_Helpers_NoHardCode scripts under such an environment.)

-Thom

I am using MakeRelease and the Ubuntu_Helpers_NoHardCode scripts to build for the Pi within both a chroot/qemu environment AND a scratchbox cross-compile environment.  The qemu environment is by far and away simpler and easier to setup compared to the cross-compile method.

J.

880
Developers / Re: Raspberry Pi omxplayer device
« on: July 23, 2012, 09:45:18 pm »
I agree that a qemu chroot enironment it is by far the easiest to setup and use initially.

J.

881
Developers / Re: Raspberry Pi omxplayer device
« on: July 22, 2012, 07:15:27 pm »
can you send me your .config files please, for hard and soft.
I had looked at crosstool and buildroot when I started on this - but when I could just get the bcm toolchain from git I parked it.

Sure.  They should be attached.  I'm installing the raspian build on my pi now to see if everything works there or not.  The squeeze build was already tested on the pi so it works.  The squeeze build was done with crosstool-ng 1.13.3 and the raspian build was created with crosstool-1.15.3.

J.

882
Feature requests & roadmap / Re: raspberry pi
« on: July 20, 2012, 02:01:35 am »
Wow, I had actually picked up most of that already from working with the build scripts and database already.  I'm happy to know my understanding is not flawed.

I'm assuming this needs to be done with a clean install on a CORE?  Then sqlCVS submitted.  Likely in stages, distro first, sqlcvs, add packages, sqlcvs.

I'll drop into -devel on IRC.

J.

883
Developers / Re: Raspberry Pi omxplayer device
« on: July 20, 2012, 01:54:45 am »
armel for now - AFAIR I need 64bit host for bcom toolchain cross to hfp. I didn't dig too far.
I did download the new rasbian image today so might take that for a whirl.

Ah, yes the pi foundation tools.  You can compile under qemu in a raspian chroot.  I rolled an armel and armhf set for i386 with crosstool-ng.  I'm building armhf in a cross compiled and a qemu compiled version right now to compare any differences afterwards.  I can provide any of the pluto libs you may need for armel or armhf.  It's been easy enough I may try an amd64 cross compile as well.  That could mostly be built with a stock database.

I may go back and stick with armel for now - unless I compile my own qt5 _again_ for hardfp. And I feel that would involve getting dirty with some some qt config options. Although you can pass in Bsquask as a distro option, might be worth investigating... must add to list of things to do.

My list always seems to grow faster than it shrinks.  Let me know if I can be of any assistance.

J.

884
Feature requests & roadmap / Re: raspberry pi
« on: July 18, 2012, 07:57:07 pm »
Perhaps some meeting here would be beneficial to set up an official build server for ARM packages, as a starting point.

-Thom

Good idea Thom.  As a start, so that it could be built by others: Do you have any suggestions/insights/recommendations as to how best to add a new distro to the database?  I know you have been involved (or perhaps the primary) in adding ubuntu 1004 to the database.  I know there is a move away from the database to a simpler build system but it looks a little ways off to be usable just yet.

J.

885
Feature requests & roadmap / Re: raspberry pi
« on: July 18, 2012, 07:44:41 pm »
Thanks for pointing valent to that Coley.  I'll be happy to try and answer questions.

The biggest challenge to building the system was the database, the entire build system (as is) relies on the database knowing all the required packages and distro specific information.  My initial build is a hack at the database, I manually altered an existing distro in the database to reflect the values I needed to build the system on debian squeeze.  This of course is not something I can sqlCVS submit to the central database as it would bork current builds.  If I could walk the database a little better with a visual tool of somekind then I could 'duplicate' an existing distro, alter values where required and submit through sqlCVS.  This has been done for each upgrade of LMCE so far 0710->0810->1004, etc...  I'm just not very fluent in database administration.  Perhaps someone who has done this in the past would have some insights into how best to approach this.  I managed to do most of the setup/database/and build in about 2 weeks, solid evenings and a long weekend.

It *should* be 'easier' to build using a newer build system, I believe possy is working on one, but I'm not sure how far that is away.  So for now the database is still required.

I find the build system is fairly easy to work with and manipulate once you understand the relevant portions of the packaging portion of it.  It would be easier with a tool to edit the build database on a builder.

J.

Pages: 1 ... 57 58 [59] 60 61 ... 99