Fatdog64-610 testing 20 Nov 2012 (finished)
Download Failure
Delete or ignore this message. Seems that its working now for some reason.
- Attachments
-
- DownloadFailure.png
- Download Failure
- (55.67 KiB) Downloaded 2519 times
kirk & jamesbond,
I have just made an sfs file of VirtualBox-4.2.4 but have been having trouble getting it to work with the fatdog sfs-loader. What I have discovered, and I do apologise it this has already been repeated somewhere else, the following:
When using the fatdog sfs loader it loads/mounts the sfs but VirtualBox or for that matter, wine, neither works. The reason being, some modules need to be loaded so a reboot or a modprobe of the modules is required.
This is not an ideal solution if running a live system.
I then tried shino's SFS-load-on-the-Fly and it worked fine without a reboot as it obviously loads the required modules.
After I had installed shino's SFS-load-on-the-Fly I notice it had clobbered the fatdog sfs loader because the desktop entries have the same name although the file names are different. It's easy enough to rename one so they can co-exist.
My questions are:
1. Will using shino's SFS-load-on-the-Fly cause any problems with fatdog?
2. Is it possible to use a pinstall.sh in the fatdog sfs loader to load the required modules?
I will place the VirtualBox-4.2.4-fd64_600.sfs here:
http://www.smokey01.com/software/Fatdog64-600/
Regards
I have just made an sfs file of VirtualBox-4.2.4 but have been having trouble getting it to work with the fatdog sfs-loader. What I have discovered, and I do apologise it this has already been repeated somewhere else, the following:
When using the fatdog sfs loader it loads/mounts the sfs but VirtualBox or for that matter, wine, neither works. The reason being, some modules need to be loaded so a reboot or a modprobe of the modules is required.
This is not an ideal solution if running a live system.
I then tried shino's SFS-load-on-the-Fly and it worked fine without a reboot as it obviously loads the required modules.
After I had installed shino's SFS-load-on-the-Fly I notice it had clobbered the fatdog sfs loader because the desktop entries have the same name although the file names are different. It's easy enough to rename one so they can co-exist.
My questions are:
1. Will using shino's SFS-load-on-the-Fly cause any problems with fatdog?
2. Is it possible to use a pinstall.sh in the fatdog sfs loader to load the required modules?
I will place the VirtualBox-4.2.4-fd64_600.sfs here:
http://www.smokey01.com/software/Fatdog64-600/
Regards
I didn't use grub2 myself and never tested that. But rcrsn51 uses grub2 and it shouldn't be problem.spandey wrote:Yes Linux mint 13 is using Grub2.
1,2,3 is all right, 4 is odd because it should be looking at /Fatdog/fd64save.ext4.I looked at error message and there are bunch of them, like:
1. can't stat /lib
2. aufs/kernel-modules/lib missing
3. HDIO_SET_DMA failed
4. can't find savefile /fd64save.ext4 in partitions.....
That is very all right, I do this all the time tooFor frugal install I just copied the contents of the ISO, to /Fatdog directory. Hope that's alright ?
Nah, this means that the savefile name or path should not contain a space or a colon. The colon in the savefile parameter itself is all right.spandey wrote:Just going thru Fatdog help documents and found something interesting under boot options:
savefile parameter has colon!!!Note 1: parameters are case sensitive. Most of them are in lower case, so if you specify them in upper case (capital letters), it won't work. Also remember that all parameters cannot include space or colon.
Try this: After you have finished booting, please type this in terminal: "cat /proc/cmdline" and tell me what you see. I'm expecting you to see the correct savefile parameters (with /Fatdog path), if you see anything different then it's your grub2 configuration that has problem.
==========
smokey01, spandey's line is all right. He doesn't use "direct" but he uses "ram" which means he is using the RAM layer (in other puppies, this is called PUPMODE=13).smokey01 wrote:spandey you appear to have omitted the word "direct" eg:
Yes, fatdog sfs loader just mounts the sfs. It doesn't do anything extra. This is a design decision - different SFS serves different purposes and may have different activation mechanisms; and the sfs loader doesn't try to guess what they are. You will to manually do what is required - e.g. "depmod" for extra modules, or "modprobe", or start-up services, or refresh menus, etc. (openbox menus btw is automatically updated, lxpanel isn't).smokey01 wrote:When using the fatdog sfs loader it loads/mounts the sfs but VirtualBox or for that matter, wine, neither works. The reason being, some modules need to be loaded so a reboot or a modprobe of the modules is required.
Yes, because shino's sfs has the smarts.I then tried shino's SFS-load-on-the-Fly and it worked fine without a reboot as it obviously loads the required modules.
Yes because shino's loader was the default sfs loader for Fatdog 500, and even for early betas of 600.After I had installed shino's SFS-load-on-the-Fly I notice it had clobbered the fatdog sfs loader because the desktop entries have the same name although the file names are different. It's easy enough to rename one so they can co-exist.
My questions are:
Yes, it probably will. Early in 600 beta we have Shino's SFS loader in the ISO, and we run into some obscure problems. Turns out that it was the interaction between shino's loader with Fatdog's layering system; we were forced to take it out.1. Will using shino's SFS-load-on-the-Fly cause any problems with fatdog?
Not at the moment, but I will consider that. Where is this pinstall.sh located? Is this supported by Shino's SFS loader too? We have to consider the effect when multiple SFS-es have pinstall.sh-es; we have to ensure that when one SFS is loaded, only its own pinstall.sh will be executed and not pinstall.sh from previously loaded SFS; thus the pinstall.sh must also be written carefully. Unlike pets, where the pinstall.sh is executed only once and then deleted (thus one pet's pinstall.sh is unlikely to affect other pets), this isn't true with SFS where its pinstall.sh will live forever.2. Is it possible to use a pinstall.sh in the fatdog sfs loader to load the required modules?
Thanks. I usually download Vbox and install it from the official website myself, but I do appreciate this isn't always possible for others (especially live session users).I will place the VirtualBox-4.2.4-fd64_600.sfs here:
http://www.smokey01.com/software/Fatdog64-600/
cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
jamesbond further investigation has revealed a reboot after loading the sfs with the fatdog loader does not fix the problem, even with a savefile.
A modprobe of each of the 4 modules is required such as:
modprob vboxdrv
modprob vboxnetadp
modprob vboxnetflt
modprob vboxpci
Providing you have a savefile it will work on subsequent boots.
It still doesn't fix the live boot option.
A simple script would fix the problem but how would people know to run it. Maybe your fatdog sfs loader could look for the script, if found, run it.
Nothing is ever easy
A modprobe of each of the 4 modules is required such as:
modprob vboxdrv
modprob vboxnetadp
modprob vboxnetflt
modprob vboxpci
Providing you have a savefile it will work on subsequent boots.
It still doesn't fix the live boot option.
A simple script would fix the problem but how would people know to run it. Maybe your fatdog sfs loader could look for the script, if found, run it.
Nothing is ever easy
smokey01
You could put a wrapper script in the sfs called from the DOTdesktop file that checks if the modules are loaded, if not loads them then runs virtual box. Would overcome your problem I think.
You could put a wrapper script in the sfs called from the DOTdesktop file that checks if the modules are loaded, if not loads them then runs virtual box. Would overcome your problem I think.
Puppy Linux Blog - contact me for access
Yeah that might work providing VB is called from the menu entry.01micko wrote:smokey01
You could put a wrapper script in the sfs called from the DOTdesktop file that checks if the modules are loaded, if not loads them then runs virtual box. Would overcome your problem I think.
I was thinking of putting a script in the sfs somewhere than could be run if required but it's not very intuitive.
I like your idea better.
Thanks
It does. I just tested it with your Virtualbox sfs. The SFS already have the right files in /etc/init.d; that will start the vbox services which will load the modules after your reboot.smokey01 wrote:jamesbond further investigation has revealed a reboot after loading the sfs with the fatdog loader does not fix the problem, even with a savefile.
The only missing thing is that you need to "depmod" after the SFS is loaded, and this needs to be done only once.
If you want to run this from a live session, you just need to "depmod" and then start the /etc/init.d/vboxdrv services ("/etc/init.d/vboxdrv start") or use the Service Manager. Like 01micko says, you can modify the VBox desktop button to point to your wrapper script to test for conditions launching the real VirtualBox, like this one:
Code: Select all
#!/bin/sh
! modinfo vboxdrv && depmod
! lsmod | grep -q vboxdrv && /etc/rc.d/rc.vboxdrv start
VirtualBox
Oops I thought you did test it with grub2. Sorryrcrsn51 wrote:No I don't. I was testing spandey's savefile argument in regular GRUB.
EDIT: add script.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Jamesbond,
Thank you so much. The revealed the culprit. There are some unprintable characters before word savefile. Hence entire savefile argument has become meaningless. Looks like they came up while copying and pasting Grub2 entries in the editor. A very good lesson for future !!!!
Thank you so much. The
Code: Select all
cat /proc/cmdline
Your fix is a lot more elegant than mine. I took Mick's advice and made a wrapper which checks to see if each module had been loaded, if not it loads them. The script also starts with a depmod.jamesbond wrote:It does. I just tested it with your Virtualbox sfs. The SFS already have the right files in /etc/init.d; that will start the vbox services which will load the modules after your reboot.smokey01 wrote:jamesbond further investigation has revealed a reboot after loading the sfs with the fatdog loader does not fix the problem, even with a savefile.
The only missing thing is that you need to "depmod" after the SFS is loaded, and this needs to be done only once.
If you want to run this from a live session, you just need to "depmod" and then start the /etc/init.d/vboxdrv services ("/etc/init.d/vboxdrv start") or use the Service Manager. Like 01micko says, you can modify the VBox desktop button to point to your wrapper script to test for conditions launching the real VirtualBox, like this one:
should do the trick.Code: Select all
#!/bin/sh ! modinfo vboxdrv && depmod ! lsmod | grep -q vboxdrv && /etc/rc.d/rc.vboxdrv start VirtualBox
Anyway I am uploading the sfs again as it now works fine while operating live. I probably could have trimmed it down a bit but didn't bother. Maybe next time.
http://www.smokey01.com/software/Fatdog ... 64_610.sfs
That's probably why they recommend that you not hand-edit the Grub2 config file.spandey wrote:There are some unprintable characters before word savefile. Hence entire savefile argument has become meaningless. Looks like they came up while copying and pasting Grub2 entries in the editor. A very good lesson for future !!!!
It's all there in http://puppylinux.org/wikka/Grub2. Anyway I am repeating it again.For the benefit of other Fatdog-Grub2 users, could you please post your 40-custom file along with some instructions on how you used it in Mint? Where do you put the file? What update command do you run? etc.
1. GRUB2 can't find frugal puppy install otherwise it picks up most other linux installed in the machine.
2. Just open the '/etc/grub.d/40_custom' with admin access and add the entries for puppy like lucid, fatdog etc.
3. Once done form terminal do 'sudo update-grub'. You are good to go.
Here are my sample '40_custom" file entries
Code: Select all
menuentry "Lucid Puppy 5.2.8" {
search --no-floppy --fs-uuid --set=root 672878ac-c0ca-453b-bc38-0de03ec38f63
linux /Luppuold/vmlinuz pmedia=atahd psubdir=Luppuold pfix=fsck
initrd /Luppuold/initrd.gz
}
menuentry "Precise 5.4.1" {
search --no-floppy --fs-uuid --set=root 672878ac-c0ca-453b-bc38-0de03ec38f63
linux /Precise/vmlinuz pmedia=atahd psubdir=Precise pfix=fsck
initrd /Precise/initrd.gz
}
menuentry "Fatdog 600" {
search --no-floppy --fs-uuid --set=root 672878ac-c0ca-453b-bc38-0de03ec38f63
linux /Fatdog/vmlinuz savefile='ram:device:sda5:/Fatdog/fd64save.ext4'
initrd /Fatdog/initrd
}
I had Linux Mint 13 on here until an update caused a boot failure, but grub2 is still working.
/etc/grub.d/41_custom reads like this.
So I place custom entries in /boot/grub/custom.cfg. With entries in that file it is unnecessary to update grub. Since Linux Mint doesn't boot anyway that is kind of handy.
Here is the entry for Fatdog64 610.
Here is one with no save file for Fatdog64 600
The UUID of a partition can be found by running the command:
One time I plugged in another hard drive and sda became sdb, but Fatdog64 still booted because grub2 read the UUID.
If entries are placed in /etc/grub.d/40_cutom instead of /boot/grub/custom.cfg, the command to update grub2 is:
Here is a link to a good tutorial on grub2:
http://ubuntuforums.org/showthread.php?t=1195275
Ubuntu has closed those types of how to's and now require them to go into there community wiki, so someday that link maybe dead.
/etc/grub.d/41_custom reads like this.
Code: Select all
#!/bin/sh
cat <<EOF
if [ -f \$prefix/custom.cfg ]; then
source \$prefix/custom.cfg;
fi
EOF
Here is the entry for Fatdog64 610.
Code: Select all
menuentry "Fatdog64 610" {
insmod part_msdos
insmod ext2
set root='(dev/sda,msdos2)'
search --no-floppy --fs-uuid --set=root 6fbee58b-cd48-4819-8d2b-ed06d7f00eea
linux /fatdog610/vmlinuz root=UUID=6fbee58b-cd48-4819-8d2b-ed06d7f00eea savefile=direct:device:sda2:/fatdog610/fd64save.ext4
initrd /fatdog610/initrd
}
Code: Select all
menuentry "Fatdog64 600 No Save" {
insmod part_msdos
insmod ext2
set root='(dev/sda,msdos2)'
search --no-floppy --fs-uuid --set=root 6fbee58b-cd48-4819-8d2b-ed06d7f00eea
linux /fatdog600/vmlinuz root=UUID=6fbee58b-cd48-4819-8d2b-ed06d7f00eea savefile=none
initrd /fatdog600/initrd
}
Code: Select all
blkid
If entries are placed in /etc/grub.d/40_cutom instead of /boot/grub/custom.cfg, the command to update grub2 is:
Code: Select all
sudo update-grub
http://ubuntuforums.org/showthread.php?t=1195275
Ubuntu has closed those types of how to's and now require them to go into there community wiki, so someday that link maybe dead.
Brief return to 64bit-land with an i3.4G. LiveCD, used my worst (p54) and best(zd1211) performing dongles along with a couple of others that rarely give problems. No problems finding base station, no problem connecting to ditto, but as soon as an attempt is made to use the connection for anything it drops out (message pops up in tray). e.g. load default browser, type in URL, - everything still stable - hit Enter and down it goes, new tray message pops up 'disconnected'. Few seconds later after stopping trying to access the connection, tray message often pops up with re-connect (but not always). This routine proceeds until patience runs out. Doesn't happen with any other distros on this machine or with those dongles on other machines/other distros, except, maybe, the Wistron which can be as much of a pig as Broadcoms. Didn't happen with FD600s. ???
Sage,
After it disconnects from your network, can you open a terminal and type:
and then attach those two files to this thread? I'm surprised it worked in 601 and quit working with 610. Thanks
After it disconnects from your network, can you open a terminal and type:
Code: Select all
lspci > /root/lspci.txt
dmesg > /root/dmesg.txt
Live media is NOT getting the session saved at Power-off
Hi all.
As has been traditional with my use of FATDOG since inception, I use its Live media feature for operations and management of the OS. Traditionally, after all tailoring is done and saved via saved session, the OS runs basically un-interrupted for in 1 case, year(s).
In testing the latest Beta; namely 610 I have run into an issue when trying to save the session back to the Live media. I do understand that there are several changes in the saved file(s) which represents the changes and the tailoring done while the system was running. I am positive on these changes as the architecture is very promising. But, unfortunately, I have run into some issues in trying to get my session saved.
To show the problem, here is a step by step that I followed which leads to the problem.
It surfaces as follows:
Also, my desktop configuration may be a little different from other desktops. There is no Floppy and there are 2 DVD burners on the system. And, as I may have mentioned, all local and remote mounts were umount'd prior to start of Power-off.
Here to help.
As has been traditional with my use of FATDOG since inception, I use its Live media feature for operations and management of the OS. Traditionally, after all tailoring is done and saved via saved session, the OS runs basically un-interrupted for in 1 case, year(s).
In testing the latest Beta; namely 610 I have run into an issue when trying to save the session back to the Live media. I do understand that there are several changes in the saved file(s) which represents the changes and the tailoring done while the system was running. I am positive on these changes as the architecture is very promising. But, unfortunately, I have run into some issues in trying to get my session saved.
To show the problem, here is a step by step that I followed which leads to the problem.
It surfaces as follows:
- Menu>Power-off
The Create Save File Window pops: click Yes (Do you want to create a savefile now?)
What follows is unexpected at end of desktop session - Create Save File windows text dialogue changes to set/reset the system hostname: Changed it to FATDOG610-testing and clicked Next
(this is unexpected because, all system changes including hostname changes should have occurred before reaching this point. Reason: Other system files and applications should have configured with hostname needs long before getting to this point in the system's use. This step really should be moved to system start and not at system end so that any tool that would utilize or need the final system hostname would have at their setups. But, I'm sure there are those who are going to argue this placement as a defensive.)
Again, the following, too, is unexpected at end of desktop session - Create Save File windows text dialogue changes to set/reset root's password: Changed it fatdog and clicked Next
(This also is unexpected placement. Shouldn't this be also done at system's initial start.)
Expected - Create Save File windows text dialogue changes to choose save session device: Changed it /dev/sr0 (where the Live media presently resides) clicked "Save as multisession" (this is an unknown for which there is no documentation or desktop help for this new shutdown parameter) and clicked Next
Expected - Create Save File windows text dialogue changes to show status of some prior entries for confirmation: Viewing shows my prior selections and clicked Next
Xdesktop is then exited and text terminal (console) continues with message that a fatdog ...sfs is being created. Immediately the system progresses with another message, then and within 15 seconds, the PC powers down without every saving of anything to the Live media.
Also, my desktop configuration may be a little different from other desktops. There is no Floppy and there are 2 DVD burners on the system. And, as I may have mentioned, all local and remote mounts were umount'd prior to start of Power-off.
Here to help.
Thank you, bug confirmed, I will look at it.gcmartin wrote:Xdesktop is then exited and text terminal (console) continues with message that a fatdog ...sfs is being created. Immediately the system progresses with another message, then and within 15 seconds, the PC powers down without every saving of anything to the Live media.
Procedure is correct.Could someone confirm the procedure
EDIT: Bug is fixed for the next release. Please note that even after you managed to save the session, at next boot you will have to type "fatdog savefile=direct:multi" if you boot from the first DVD drive. If you don't want to do this all the time you will need to remaster and ensure that you put this boot parameter into your customised isolinux.cfg.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]