Here's a JWM-707 pet that I made, seems to work okay.jamesbond wrote:Billtoo, thanks for the pets.
Fatdog64-620beta2
Fatdog64-620beta2
- Attachments
-
- jwm707screen.jpg
- (38.81 KiB) Downloaded 1600 times
-
- jwm-707-x86_64.pet
- (83.78 KiB) Downloaded 465 times
Fatdog64-620beta2
I made a pet of a small memory game named lpairs, it doesn't have a
high scores feature so you'll have to remember your high score
It should create a menu entry in the fun section of the menu but it
can be started with grun or alt-f2 which brings up gexec.
high scores feature so you'll have to remember your high score
It should create a menu entry in the fun section of the menu but it
can be started with grun or alt-f2 which brings up gexec.
- Attachments
-
- lpairs.jpg
- (31.6 KiB) Downloaded 1369 times
dm-crypt save file
Need some help here, I'm stuck.
I used the fatdog64-620b2-cd to make an install on a sdcard, with bootloader syslinux. All works fine but I can not use a dm-crypt save file.
At first boot I made an encrypted save file, and rebooted.
I booted without boot parameters, choose the new savefile on the sdcard and this is the error after typing my passphrase:
device mapper: reload ioctl on temporary-cryptsetup-1900 failed, etc.
failed to setup dm-crypt key mapping for devices /aufs/devsave/fd64save_dmcrypt_.ext4 , etc.
I checked and the dm-crypt module is not loaded, so I tried the boot parameter
boot: fatdog loadmodules=dm-crypt
But no change so I tried this addition to extlinux.conf next:
append loadmodules=dm-crypt
I can load the module with modprobe dm-crypt, so it exists.
Am I on the wrong track here?
I used the fatdog64-620b2-cd to make an install on a sdcard, with bootloader syslinux. All works fine but I can not use a dm-crypt save file.
At first boot I made an encrypted save file, and rebooted.
I booted without boot parameters, choose the new savefile on the sdcard and this is the error after typing my passphrase:
device mapper: reload ioctl on temporary-cryptsetup-1900 failed, etc.
failed to setup dm-crypt key mapping for devices /aufs/devsave/fd64save_dmcrypt_.ext4 , etc.
I checked and the dm-crypt module is not loaded, so I tried the boot parameter
boot: fatdog loadmodules=dm-crypt
But no change so I tried this addition to extlinux.conf next:
append loadmodules=dm-crypt
I can load the module with modprobe dm-crypt, so it exists.
Am I on the wrong track here?
Using FATDOG, I started Pburn>Menu>Help>Dependency check.
I saw this and thought it might be of note. (I dont consider this a bug.) I don't use or make vCDs, but, others may. Would the missing item affect use?Here to help
I saw this and thought it might be of note. (I dont consider this a bug.) I don't use or make vCDs, but, others may. Would the missing item affect use?
Code: Select all
R E Q U I R E D
bash [OK]
coreutils, awk, sed [OK]
gtkdialog >= 0.8.3 [OK]
cdrtools [OK]
dvd+rw-tools [OK]
cddetect [OK]
O T H E R S
ffmpeg (audio/video) [OK]
pFilesearch (filesearch) [OK]
dvdauthor (burning video-DVD) [OK]
vobcopy (copy video-DVD) [OK]
vamps (shrinking video-DVD) [OK]
vcdimager (burning video-CD) [MISSING]
normalize (volume-setting on Audio-CD) [OK]
nrg2iso (burn Nero images) [OK]
Re: dm-crypt save file
@Hans,
Let's try to narrow the problems.
1. How does the machine access the SD card? Is it via in-built reader, or do you use external card reader connected via USB?
2. In any case, once you booted Fatdog, what is the name of the device - do you see it just as a disk ("sdb1", or "sdc2" etc) or do you see if as "mmcblk0p1" or something like that?
3. Boot your Fatdog as usual, mount your SD card and then open terminal, and check what's the type of the savefile by typing "file fd64save_dmcrypt_.ext4". You should get something like this:
fd64save_dmcrypt_.ext4: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 7a6d815c-8454-4ca3-abf6-600aa470350c
Anything else means somehow the savefile is corrupt.
4. Try booting with the original Fatdog ISO with the SD-card in it, but during boot, when the menu shows, press "tab" to show the boot command line (near the bottom of the screen), and append "waitdev=5" so that the boot process will wait for the SD card to be recognised. Then press Enter. Watch carefully, see what "drives" that it scans for. Hopefully your SD card is also scanned.
And then see whether it gets used.
I just tested creating and booting with encrypted savefile (boot with original ISO with savefile on USB flash drive), and all works as expected, with dm-crypt loaded automatically. No extra loadmodules is needed.
@gcmartin,
This is a known issue - smokey01 reported this to me late last year, but I decided not to do anything because:
a) it is optional (ie pburn works fine without it)
b) nobody makes or use vcd anymore - everyone has switched to dvd by now.
cheers!
Let's try to narrow the problems.
1. How does the machine access the SD card? Is it via in-built reader, or do you use external card reader connected via USB?
2. In any case, once you booted Fatdog, what is the name of the device - do you see it just as a disk ("sdb1", or "sdc2" etc) or do you see if as "mmcblk0p1" or something like that?
3. Boot your Fatdog as usual, mount your SD card and then open terminal, and check what's the type of the savefile by typing "file fd64save_dmcrypt_.ext4". You should get something like this:
fd64save_dmcrypt_.ext4: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 7a6d815c-8454-4ca3-abf6-600aa470350c
Anything else means somehow the savefile is corrupt.
4. Try booting with the original Fatdog ISO with the SD-card in it, but during boot, when the menu shows, press "tab" to show the boot command line (near the bottom of the screen), and append "waitdev=5" so that the boot process will wait for the SD card to be recognised. Then press Enter. Watch carefully, see what "drives" that it scans for. Hopefully your SD card is also scanned.
And then see whether it gets used.
I just tested creating and booting with encrypted savefile (boot with original ISO with savefile on USB flash drive), and all works as expected, with dm-crypt loaded automatically. No extra loadmodules is needed.
@gcmartin,
This is a known issue - smokey01 reported this to me late last year, but I decided not to do anything because:
a) it is optional (ie pburn works fine without it)
b) nobody makes or use vcd anymore - everyone has switched to dvd by now.
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]
NVidia 64-bit driver
Hi.
I recently bought a new 64-bit laptop/netbook which has a Nvidia Gefore GT 650M graphics card (2MB).
I booted up Fatdog64 via USB stick and then installed this version (Fatdog64-620 beta2) onto sda1, reboot the netbook and works brilliant! Then from there I went on the pet install manager and downloaded/installed nvidia 304-64 driver, expecting that after reboot it would detect the graphics card ready for use.
When I rebooted the netbook, I got the following log:
In the Choose driver dialog I chose "new Nvidia driver (KMS)", because before installing the nvidia pet I checked the hardware kernal which stated "nouveau"... assuming this is the right one.
On the next dialogs I chose "1366x768" and 32-bit colour depth.
on the next screen it says that the screen is not listed in supported resolutions. This confuses me because the RAM boot-up from USB stick detected them fine. I tried testing this selection but it failed the test (15 seconds)
The conclusion seems to be that I have messed up the fatdog64 configuration by installing the nvidia 64-bit driver pet. I'm not sure if it's also to do with the savefile, as I installed the pet BEFORE making a savefile on reboot.
Can anyone (or the guys who wrote this distro) help me with this problem?
Thank you. p.s. I'm fairly new to linux, so I hope I made sense and not being too slow.
I recently bought a new 64-bit laptop/netbook which has a Nvidia Gefore GT 650M graphics card (2MB).
I booted up Fatdog64 via USB stick and then installed this version (Fatdog64-620 beta2) onto sda1, reboot the netbook and works brilliant! Then from there I went on the pet install manager and downloaded/installed nvidia 304-64 driver, expecting that after reboot it would detect the graphics card ready for use.
When I rebooted the netbook, I got the following log:
- Starting X desktop...
/usr/X11R7/bin/xinit: giving up
/usr/X11R7/bin/xinit: unable to connect to X server: No such file or directory
/usr/X11R7/bin/xinit: server error
To restart desktop, type "xwin".
To shutdown, type "poweroff", to reboot, type "reboot".
If desktop failed to start, type "xorgwizard" to setup.
#
In the Choose driver dialog I chose "new Nvidia driver (KMS)", because before installing the nvidia pet I checked the hardware kernal which stated "nouveau"... assuming this is the right one.
On the next dialogs I chose "1366x768" and 32-bit colour depth.
on the next screen it says that the screen is not listed in supported resolutions. This confuses me because the RAM boot-up from USB stick detected them fine. I tried testing this selection but it failed the test (15 seconds)
The conclusion seems to be that I have messed up the fatdog64 configuration by installing the nvidia 64-bit driver pet. I'm not sure if it's also to do with the savefile, as I installed the pet BEFORE making a savefile on reboot.
Can anyone (or the guys who wrote this distro) help me with this problem?
Thank you. p.s. I'm fairly new to linux, so I hope I made sense and not being too slow.
If you go to Nvidia's website you'll find that card uses the 310.xx version. For beta2 that would be this one:I recently bought a new 64-bit laptop/netbook which has a Nvidia Gefore GT 650M graphics card
http://distro.ibiblio.org/fatdog/pets/6 ... 3.7.10.pet
310.32 is Nvidia's major.minor version
3.7.10 is the kernel version used in beta2 (this will change for beta3)
The ATI/Nvidia packages have to be made for whatever kernel version is being used.
You'll probably want to make a new savefile, that's where any changes you made are stored, including the wrong Nvidia pet package.
Hopefully we'll have beta3 out soon. That should be our last release before final. It will have a different kernel. I'm not sure we'll make new ATI/Nvidia pets for beta3, but we certainly will for final. So for beta3 don't use the same Nvidia pet that you used for beta 2.
-
- Posts: 597
- Joined: Thu 13 Nov 2008, 13:45
I don't know if this has been talked about in this thread, but I found a super-strange bug.
I was simply copying large files, nothing special, from the hard drive to a USB drive, but nothing to or from the linux filesystem part (not root, usr, bin, etc).
Slowly, the save file got smaller and smaller until it filled up and showed a red message at that top that it's full.
I tried the exact same thing with 6.0.1 and it did not fill the save file at all, so I think the problem may be with this beta.
I was simply copying large files, nothing special, from the hard drive to a USB drive, but nothing to or from the linux filesystem part (not root, usr, bin, etc).
Slowly, the save file got smaller and smaller until it filled up and showed a red message at that top that it's full.
I tried the exact same thing with 6.0.1 and it did not fill the save file at all, so I think the problem may be with this beta.
dm-crypt save file
Hello Jamesbond
The answers to your query:
1. How does the machine access the SD card? Is it via in-built reader, or do you use external card reader connected via USB?
in-built
2. In any case, once you booted Fatdog, what is the name of the device - do you see it just as a disk ("sdb1", or "sdc2" etc) or do you see if as "mmcblk0p1" or something like that?
mmcblk0p1
3. Boot your Fatdog as usual, mount your SD card and then open terminal, and check what's the type of the savefile by typing "file fd64save_dmcrypt_.ext4". You should get something like this:
fd64save_dmcrypt_.ext4: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 7a6d815c-8454-4ca3-abf6-600aa470350c
Anything else means somehow the savefile is corrupt.
not corrupted
4. Try booting with the original Fatdog ISO with the SD-card in it, but during boot, when the menu shows, press "tab" to show the boot command line (near the bottom of the screen), and append "waitdev=5" so that the boot process will wait for the SD card to be recognised. Then press Enter. Watch carefully, see what "drives" that it scans for. Hopefully your SD card is also scanned.
And then see whether it gets used.
Yes, it is used
Furthermore:
1- it loads from sdcard when I use the cd, no problemo, just not when booting from sdcard
2- It detects another encrypted save file fd64saveSDA3_crypt_.ext4 of mine(not LUKS), this loads fine when booting from the sdcard
The error I get when choosing the LUKS encrypted file is:
failed to setup dm-crypt key mapping for devices /aufs/devsave/fd64save_dmcrypt_.ext4 so is it not there where it goes wrong?
Normal not-encrypted savefiles and not-LUKS-encrypted savefiles load fine, no problem.
I tried putting the save file on an ext2 usb-disk, the save file is found on this disk and even mounted but the error is still the same(read something about encrypted savefiles need to be on ext2, my sdcard is ext3)
So what is this error about setting up 'dm-crypt key mapping for devices /aufs/devsave/fd64save_dmcrypt_.ext4'?
I tried finding out but can't find anything on save files regarding dm-crypt device mapping.
I tried this as last line in extlinux.conf
append savefile=direct:device:mmcblk0p1:/fd64save_dmcrypt_.ext4
The save file is found, I also think the file is opened with the passphrase because it is mounted but the error stays the same.
And I seem to be the only one with this problem, why?
I will try grub instead of syslinux when I find some time.
If anyone has some input, I would love to hear it.
cheers,
Hans
The answers to your query:
1. How does the machine access the SD card? Is it via in-built reader, or do you use external card reader connected via USB?
in-built
2. In any case, once you booted Fatdog, what is the name of the device - do you see it just as a disk ("sdb1", or "sdc2" etc) or do you see if as "mmcblk0p1" or something like that?
mmcblk0p1
3. Boot your Fatdog as usual, mount your SD card and then open terminal, and check what's the type of the savefile by typing "file fd64save_dmcrypt_.ext4". You should get something like this:
fd64save_dmcrypt_.ext4: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 7a6d815c-8454-4ca3-abf6-600aa470350c
Anything else means somehow the savefile is corrupt.
not corrupted
4. Try booting with the original Fatdog ISO with the SD-card in it, but during boot, when the menu shows, press "tab" to show the boot command line (near the bottom of the screen), and append "waitdev=5" so that the boot process will wait for the SD card to be recognised. Then press Enter. Watch carefully, see what "drives" that it scans for. Hopefully your SD card is also scanned.
And then see whether it gets used.
Yes, it is used
Furthermore:
1- it loads from sdcard when I use the cd, no problemo, just not when booting from sdcard
2- It detects another encrypted save file fd64saveSDA3_crypt_.ext4 of mine(not LUKS), this loads fine when booting from the sdcard
The error I get when choosing the LUKS encrypted file is:
failed to setup dm-crypt key mapping for devices /aufs/devsave/fd64save_dmcrypt_.ext4 so is it not there where it goes wrong?
Normal not-encrypted savefiles and not-LUKS-encrypted savefiles load fine, no problem.
I tried putting the save file on an ext2 usb-disk, the save file is found on this disk and even mounted but the error is still the same(read something about encrypted savefiles need to be on ext2, my sdcard is ext3)
So what is this error about setting up 'dm-crypt key mapping for devices /aufs/devsave/fd64save_dmcrypt_.ext4'?
I tried finding out but can't find anything on save files regarding dm-crypt device mapping.
I tried this as last line in extlinux.conf
append savefile=direct:device:mmcblk0p1:/fd64save_dmcrypt_.ext4
The save file is found, I also think the file is opened with the passphrase because it is mounted but the error stays the same.
And I seem to be the only one with this problem, why?
I will try grub instead of syslinux when I find some time.
If anyone has some input, I would love to hear it.
cheers,
Hans
kirk wrote:If you go to Nvidia's website you'll find that card uses the 310.xx version. For beta2 that would be this one:I recently bought a new 64-bit laptop/netbook which has a Nvidia Gefore GT 650M graphics card
http://distro.ibiblio.org/fatdog/pets/6 ... 3.7.10.pet
310.32 is Nvidia's major.minor version
3.7.10 is the kernel version used in beta2 (this will change for beta3)
The ATI/Nvidia packages have to be made for whatever kernel version is being used.
You'll probably want to make a new savefile, that's where any changes you made are stored, including the wrong Nvidia pet package.
Hopefully we'll have beta3 out soon. That should be our last release before final. It will have a different kernel. I'm not sure we'll make new ATI/Nvidia pets for beta3, but we certainly will for final. So for beta3 don't use the same Nvidia pet that you used for beta 2.
Hi Kirk, cheers for your reply.
Okay... I deleted the save file and that fixed the screen problem (i.e. back to RAM mode and list of screen resolutions are back).
Unfortunately, I tried the nvidia-310.32-3.7.10.pet and it brings the same problem back up after reboot. So for now I've deleted the save file and just using fatdog64 without the nvidia driver.
I think this is something to do with my hardware. Do you want a full hardware spec of my netbook?
@Hans,
Thanks for the reply. When you installed to SD-Card, did you use the "small initrd" option?
@wjaguar,
That's odd. What immediately comes to mind is that your USB flash drive failed to mount, so when you copy files to it you're actually copying to your savefile.
cheers!
Thanks for the reply. When you installed to SD-Card, did you use the "small initrd" option?
@wjaguar,
That's odd. What immediately comes to mind is that your USB flash drive failed to mount, so when you copy files to it you're actually copying to your savefile.
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]
Thanks Hans,
I think you have found a bug.
EDIT: here is the fixed split-initrd. Please give it a try and see if that works for you.
Note: the attached is a real gzipped file. So gunzip first, then chmod +x, then run it.
cheers!
I think you have found a bug.
Exactly. Let me have a look at this in more details.Hans wrote:Or to be more specific, dmcrypt needs something that should be in de small initrd but got split off in the fd64-620.sfs?
EDIT: here is the fixed split-initrd. Please give it a try and see if that works for you.
Note: the attached is a real gzipped file. So gunzip first, then chmod +x, then run it.
cheers!
- Attachments
-
- fatdog-split-initrd.sh.gz
- gunzip, then chmod +x, then run.
- (1.77 KiB) Downloaded 490 times
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]
-
- Posts: 597
- Joined: Thu 13 Nov 2008, 13:45
It didn't seem like it. I had the USB drive's directory open in a window, I could see the files.jamesbond wrote:That's odd. What immediately comes to mind is that your USB flash drive failed to mount, so when you copy files to it you're actually copying to your savefile.
cheers!
It certainly copied to BOTH the USB drive and save file. I just used the standard GUI method of copying, dragging the file and choosing "copy" from the menu.
Well done Jamesbond!
I ran your script without errors, the big initrd got split into a small initrd and the fd64-620.sfs, I copied them to the root of the sdcard and rebooted. Entered the passphrase of the fd64save_dmcrypt_.ext4, no errors this time. I changed the wallpaper, rebooted and the changed wallpaper was still there, so the savefile keeps the changes. It works.
Thanks for the excellent guidance!
The bug is squashedjamesbond wrote: EDIT: here is the fixed split-initrd. Please give it a try and see if that works for you.
I ran your script without errors, the big initrd got split into a small initrd and the fd64-620.sfs, I copied them to the root of the sdcard and rebooted. Entered the passphrase of the fd64save_dmcrypt_.ext4, no errors this time. I changed the wallpaper, rebooted and the changed wallpaper was still there, so the savefile keeps the changes. It works.
Thanks for the excellent guidance!
No worries Hans.
Thanks for testing and finding that bug too
The fix will be in beta3 too.
@mini-jaguar,
Next time it happens, do you mind opening a terminal, and typing "mount" there, and paste the output here?
cheers!
Thanks for testing and finding that bug too
The fix will be in beta3 too.
@mini-jaguar,
Next time it happens, do you mind opening a terminal, and typing "mount" there, and paste the output here?
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]