[Live] Linux file changes are not saved but XBMC changes are
#1
I'm running a Acer Aspire Revo 3600. I've installed 9.11B1 and 9.11B2 via unetbootin and toporesize and detailed by l.capriotti in the post below. I've had the results talked about below with both Beta 1 and Beta 2.

http://forum.xbmc.org/showthread.php?tid=62488&page=1

The install went great. XBMC ran good for me with a few minor sound issues. I opened alsamixer and un-muted everything. I issued a "sudo alsactl store" command and rebooted. When I went back in, the changes I made to alsamixer were gone and it was back to its default. I tried this again logged in as root. Same results. I gave up on that and moved on to trying to get my machine to resume from standby with a USB remote.

I used the echo USB0 > /proc/acpi/wakeup command and then double checked it with cat /proc/acpi/wakeup. I then tested it by putting it to sleep and resuming it with the remote. It worked great. I finished that up by modifying the rc.local file. I saved it and rebooted. When I checked it after reboot, the file was back to it's default and my changes were gone. I tried the same thing again as root. Same results.

I was then recommended I try a "touch test.txt" test to create an empty text file in the root (using putty). I rebooted and the file was gone. I tried this logged in as root. Same results. All changes made inside XBMC remain. I was also recommended to try installing B1 and B2 from the Live CD. This install seems to go well, until I try to boot from the created USB. I get a grub error 17 every time.

Do I have to install Live to the hard drive to get it to allow my to make any linux file changes? Does anyone have any ideas how to make this work?

Thanks in advance.
Reply
#2
htrodscott Wrote:I'm running a Acer Aspire Revo 3600. I've installed 9.11B1 and 9.11B2 via unetbootin and toporesize and detailed by l.capriotti in the post below. I've had the results talked about below with both Beta 1 and Beta 2.

http://forum.xbmc.org/showthread.php?tid=62488&page=1

The install went great. XBMC ran good for me with a few minor sound issues. I opened alsamixer and un-muted everything. I issued a "sudo alsactl store" command and rebooted. When I went back in, the changes I made to alsamixer were gone and it was back to its default. I tried this again logged in as root. Same results. I gave up on that and moved on to trying to get my machine to resume from standby with a USB remote.

I used the echo USB0 > /proc/acpi/wakeup command and then double checked it with cat /proc/acpi/wakeup. I then tested it by putting it to sleep and resuming it with the remote. It worked great. I finished that up by modifying the rc.local file. I saved it and rebooted. When I checked it after reboot, the file was back to it's default and my changes were gone. I tried the same thing again as root. Same results.

I was then recommended I try a "touch test.txt" test to create an empty text file in the root (using putty). I rebooted and the file was gone. I tried this logged in as root. Same results. All changes made inside XBMC remain. I was also recommended to try installing B1 and B2 from the Live CD. This install seems to go well, until I try to boot from the created USB. I get a grub error 17 every time.

Do I have to install Live to the hard drive to get it to allow my to make any linux file changes? Does anyone have any ideas how to make this work?

Thanks in advance.

That is absolutely normal.

You have to understand the basis of what you are doing, as follows.

By putting your xbmc iso in a usb you are using a USB as a CDROM, unless the special file you created for XBMC storage. When you load it you load this usb at startup two different things happen:

1.- A temporary version of linux is loaded into memory. That is the reason why everything linux get lost

2.- XBMC changes are directed to the special file, therefore these changes are persistent.

I you want your XBMC live changes to be persistent I would suggest the following procedure.

1.- Get two pendrives (quite unexpensive nowadays)
2.- Install a pendrive as per l.capritti. Start your box with both pendrives
3.- Choose install to a hard disk option. Follow the procedure and choose your second pendrive as your target harddisk. That will install a real version of linux on it (not an image to be loaded onto memory) and your XBMC. Now al changes will be persistent.

Regards
Reply
#3
or simply create a live USB using instructions in the sticky, paying attention to the permanent storage file.
Reply
#4
I've always installed xbmc live from a CD unto my USB stick. Then selected to have a permanent storage file during the install.

Never had any problems of it not saving changes. Both in the Linux system and in xbmc it works fine.
Reply
#5
what you are referring to is the old install method, recently deprecated.
Reply
#6
Yes you're right it was changed in the latest releases. I still install from a CD and it has no problems saving whatsoever :-)
Reply
#7
l.capriotti Wrote:or simply create a live USB using instructions in the sticky, paying attention to the permanent storage file.

l.capriotti,

The method I proposed is complementary to your isntallation package, that is absolutely right, and I take advantage of the opportunity to thank you for your good work, especially since the last beta.

The scenario I was thinking was a ion platform without CD, and usb created under windows with your procedure.

By doing what I suggest you do not need a permanent storage file in your usb, since it can be ext3, ext4, reiserfs, etc.

Furthermore, changes to underlying ubuntu would be permanent, like alsa driver update, nvidia driver update, further package installation, etc. No need to alter any previous OS in the box.

I insist that it is only possible because al of your good work, that is where al the merit should lie. My proposition is just a workaround.

Regards,
Reply
#8
l.capriotti Wrote:...paying attention to the permanent storage file.

l.capriotti-
Could you explain what you mean by this? Are you referring to the section where you use toporesize to create the "live-rw" file? I've created this and there is a 4GB file on the root of the drive called "live-rw.img." Is this incorrect?

Also, I've tried installing it from the CD to the USB drive, and then when it gets to the grub install, I install grub to the USB drive as well. That all goes well. When I boot off of that drive, it gives me an error 17 (which has to do with partition order as best as I can tell). If there's something I'm missing here, I'd love to know. l.capriotti's install method is much simpler if it can store changes.

Thanks to everyone who responded. I'm learning a lot here and I appreciate all the people willing to help.
Reply
#9
htrodscott Wrote:l.capriotti-
Could you explain what you mean by this? Are you referring to the section where you use toporesize to create the "live-rw" file? I've created this and there is a 4GB file on the root of the drive called "live-rw.img." Is this incorrect?

Also, I've tried installing it from the CD to the USB drive, and then when it gets to the grub install, I install grub to the USB drive as well. That all goes well. When I boot off of that drive, it gives me an error 17 (which has to do with partition order as best as I can tell). If there's something I'm missing here, I'd love to know. l.capriotti's install method is much simpler if it can store changes.

Thanks to everyone who responded. I'm learning a lot here and I appreciate all the people willing to help.

Error 17 is probably due to a problem missinterpreting disks. Sorry for my poor english. What can happen (it has happened to me in the past with Suse) is that during installation your usb drive was drive 1 (aka disk 0), but when you try to boot it is drive 2 (aka disk 1) because the hard disk took priority and became drive 1. Therefore, it does not find the file menu.lst on your usb and load grub menu (the boot sector of the usb is read for sure, since you get a grub message)
Reply
#10
horserider Wrote:Error 17 is probably due to a problem missinterpreting disks. Sorry for my poor english. What can happen (it has happened to me in the past with Suse) is that during installation your usb drive was drive 1 (aka disk 0), but when you try to boot it is drive 2 (aka disk 1) because the hard disk took priority and became drive 1. Therefore, it does not find the file menu.lst on your usb and load grub menu (the boot sector of the usb is read for sure, since you get a grub message)

Do you know what file to modify so it can find menu.lst? Should I be installing Grub in a different place (onto a different device) when I install from the CD?
Reply
#11
htrodscott Wrote:Do you know what file to modify so it can find menu.lst? Should I be installing Grub in a different place (onto a different device) when I install from the CD?

Google "map hd0 hd1 grub" and that might possibly help.

Just one question. ¿Have you got a grub prompt after the error?
Reply
#12
I got 9.11 B2 to install from the CD without issue today. It loads properly, and my linux system files save properly. Awesome! Thanks for all the help everyone.

My rc.local file that I am modifying now properly saves. Unfortunately, the reason I am modifying it is so that XBMC will wakeup from standby with a remote. I can get XBMC to wakeup from resume with remote using the echo USB0 command. If I reboot it, USB0 is no longer enabled (checked by cat /proc/acpi/wakeup). The rc.local file is still correct with its changes, but the file doesn't seem to be changing anything (calling out the echo USB0 command). In the file, it talks about enabling and disabling the script by changing the execution bits. I don't know what this means. Is this why the file is not executing and calling out the echo USB0 command?
Reply
#13
htrodscott Wrote:I got 9.11 B2 to install from the CD without issue today. It loads properly, and my linux system files save properly. Awesome! Thanks for all the help everyone.

My rc.local file that I am modifying now properly saves. Unfortunately, the reason I am modifying it is so that XBMC will wakeup from standby with a remote. I can get XBMC to wakeup from resume with remote using the echo USB0 command. If I reboot it, USB0 is no longer enabled (checked by cat /proc/acpi/wakeup). The rc.local file is still correct with its changes, but the file doesn't seem to be changing anything (calling out the echo USB0 command). In the file, it talks about enabling and disabling the script by changing the execution bits. I don't know what this means. Is this why the file is not executing and calling out the echo USB0 command?

I have a similar problem. Every time after reboot I have to reenter the echo USB0 command or else I can"t wake up with the remote.
Any Ideas how to solve this problem so that it will be permanent ?
Reply
#14
bump
Reply

Logout Mark Read Team Forum Stats Members Help
[Live] Linux file changes are not saved but XBMC changes are0