Jeezus H. Here we go.....AGAIN!

[mikewalsh]

For the umpteenth time, I've taken a look at FatDog64. And, once again, it's made me throw up my hands in disgust, and just say "@UCK IT". (edited by moderator, no profanity please)

I'm not knocking FatDog itself; it's very professionally put together, and the team have obviously put a lot of hard work in. But, it's silly, niggling little issues, again & again (and again)...

This time, I dd'd it to a USB 3.0 64GB SanDisk Cruzer Ultra 'Fit'. Install went great; selected the boot device, fired it up.....perfect. So I changed a few settings, and went to power-off and create a save-file. I got to the point where it asks me to choose a partition to save to; I chose the very partition it's running from.....its 'root' partition.

'Unable to save to this partition. Please choose a different one'. Fine. So I click OK, and.....the message pops back up. It goes round and round in circles, again & again. It won't let me choose anything, I can't get out of it any other way than to force a hard power-off, losing the few changes I've made.

And you wonder why I keep giving up on it as a bad job, when it can't do summat basic like create a save-file?

Sorry, guys, but.....no. Puppy is SO much more forgiving. I keep trying FD64, and it just keeps spitting in my face..... It kinda reminds me of the old, veteran geeks snarling "RTFM..!!" As though they want to KEEP their little club "exclusive".

Don't you guys WANT to attract new users?


Mike.

[Wiz57]

Easy on the f-bombs, mike...thanks!

[JakeSFR]

Hey Mike,

There was a similar problem reported a couple of months ago: http://murga-linux.com/puppy/viewtopic.php?t=119068
Unfortunately, that user decided not to participate in debugging the issue, so there wasn't much I could do.
The thing is we don't face this problem, so there's nothing to fix, unless we'll be provided with a reliable way to reproduce it.

This time, I dd'd it to a USB 3.0 64GB SanDisk Cruzer Ultra 'Fit'. Install went great; selected the boot device, fired it up.....perfect. So I changed a few settings, and went to power-off and create a save-file. I got to the point where it asks me to choose a partition to save to; I chose the very partition it's running from.....its 'root' partition.

And this seems to be the culprit.
By dd'ing an ISO to a USB stick, you're essentialy making it read-only, so no wonder you couldn't create a savefile there.
But it's possble to reclaim the unused space in the form of a 3rd, read-write partition by using the 'fix-usb.sh' script.
On that partition you should be able to create a savefile.

Here's more info: http://distro.ibiblio.org/fatdog/web/fa ... drive.html

Btw, fix-usb.sh, after it's finished, says that:

"If you need to format it, after formatting type "sfdisk -R $1" to refresh
the drive icons."

but it's no longer valid, since the '-R' option has been dropped, apparently.
You can use "hdparm -z $1" instead.


Also, James recently came up with an alternative way of dd'ing FD onto USB drives.
Just download http://distro.ibiblio.org/fatdog/broken ... -v2.tar.xz, extract it somewhere (note that it expands to over 1GiB!) and read the README file.
It's still unofficial, though, so user discretion is advised.

Greetings!

[mikewalsh]

For the umpteenth time, I've taken a look at FatDog64. And, once again, it's made me throw up my hands in disgust, and just say "@UCK IT". (edited by moderator, no profanity please)

@rockedge :-

Sorry, mate; I'm having "one of those days". And the fact that we're in the middle of a boiling hot heatwave here in the UK is not helping.... Always makes me short-tempered.

-----------------------------------------------------

@ Jake:-

Uh-huh. Ri-ight. That actually makes sense, if I stop and think about it.

So; if I'm right, the procedure should be:-

- Boot into FD64 'live'.
- Navigate to the 'root' partition.

Run

Code: Select all

./fix-usb.sh /dev/sdx

....from the terminal.

- Shut down, and create the save-file.
- Boot back into FD64.....where I can now start setting it up. Yes?


Mike.

[JakeSFR]

@ Jake:-

Uh-huh. Ri-ight. That actually makes sense, if I stop and think about it.

So; if I'm right, the procedure should be:-

- Boot into FD64 'live'.

Yep.

- Navigate to the 'root' partition.

No need to, the script is also in /usr/sbin/.

Run

Code: Select all

./fix-usb.sh /dev/sdx

....from the terminal.

(or just 'fix-usb.sh /dev/sdx' to use the one in /usr/sbin)
Yes, provided that the device isn't mounted and FD is still installed there (you didn't delete it in the meantime).
And don't forget to actually format that new partition afterwards, as instructed by the 'fix-usb.sh' script.

- Shut down, and create the save-file.

Yes, just remember to choose sdx3 as a partition for the savefile.

- Boot back into FD64.....where I can now start setting it up. Yes?

Correct.

Everything is explained in a greater detail in the FAQ link I posted.
You can also get that info via the "Help" icon on the pinboard.

Btw, if the above won't work for some reason, you may want to try an easier method instead and just use 'Control Panel -> Utilities -> Fatdog64 Installer <or> Fatdog64 UEFI Installer'.
No dd'ing is involved in that case, just a regular installation (format, copying files, installing a boot loader).

And the fact that we're in the middle of a boiling hot heatwave here in the UK is not helping....

Yeah, the same unbearable weather down here for at least next week...

Greetings!

[mikewalsh]

@JakeSFR :-

Well, I tried reclaiming the space, but I could NOT make head or tail of the script instructions.....and when I DID try to follow it, it insisted that the partition I'd just created didn't exist! I'm a very atypical Linux user; the terminal is, by & large, "foreign territory" to me.....I use it as little as I can possibly get away with.

The whole concept of setting up something like Gentoo, or Linux from Scratch (I think FD is now based on that, isn't it?) - totally from the command-line! - is completely alien to me. It's a legacy of too many years of Windoze, I think; despite hating the OS itself with a vengeance, I do like my GUIs..!

So; I've cheated a bit.....and set up the save-file on a big partition of my secondary internal HDD. FD64 is on a 64GB USB 3.0 flash drive; I doubt it's going anywhere. I suppose I could have created another partition somewhere and dd'd to that, but it's that ISO9660 file-system that throws everything out; I prefer my Pups in sub-directories, but I don't think you can do that with the way this thing installs, can you?

Anyway, I'll have another play with it. Chrome is up and running, with a transplanted profile from my 'portable'-Chrome.....after chowning permissions in a few places, that is!

We shall see.....

(While I think of it, how d'you run this package conversion thingy? I have the same issue as on previous occasions; I right-click the item, choose "Convert to FatDog Package Format", annnnd.....absolutely nothing happens.

???? What am I doing wrong?

And sound, too; according to FD, my sound card doesn't exist. What's with that?

Scratch the last bit. I've re-selected the card again, and it's now working.....but I ain't used to having to set the volume control so high.....

Nope; the speaker test works, but sound in Chrome DOESN'T, for some reason. Hmm....)


Mike.

[JakeSFR]

I prefer my Pups in sub-directories, but I don't think you can do that with the way this thing installs, can you?

Sure you can. Just create a subdir on the device where you have other Pups, e.g. "Fatdog64-810" and copy initrd and vmlinuz from the ISO there.
Then add a specific entry to your bootloader config file. Here's an example for grub4dos:

Code: Select all

title Fatdog64-810
find --set-root --ignore-floppies /Fatdog64-810/initrd
kernel /Fatdog64-810/vmlinuz rootfstype=tmpfs savefile=direct:device:sda1:Fatdog64-810/fd64save.ext4
initrd /Fatdog64-810/initrd
boot

That is assuming you'll create a savefile inside that subdir and the device is sda1.
If you use a USB stick for that, use usb instead of device:sda1 and also add waitdev=5, what adds a delay to make sure the USB is ready.

More about boot options in FAQ (Help icon).

(While I think of it, how d'you run this package conversion thingy? I have the same issue as on previous occasions; I right-click the item, choose "Convert to FatDog Package Format", annnnd.....absolutely nothing happens.
???? What am I doing wrong?

I don't know. When I right-click any PET -> Convert..., it converts it to a TXZ package, every time.
But it's not a good idea to use PETs in FD: http://distro.ibiblio.org/fatdog/web/fa ... t-packages, unless we're talking about scripts, e.g. gtkdialog apps, however some of them may rely on some Puppy-specific features that are missing in Fatdog.

Nope; the speaker test works, but sound in Chrome DOESN'T, for some reason. Hmm....

Not sure about that one... What about Seamonkey or Firefox?

Greetings!

[user1111]

So; I've cheated a bit.....and set up the save-file on a big partition of my secondary internal HDD. FD64 is on a 64GB USB 3.0 flash drive; I doubt it's going anywhere. I suppose I could have created another partition somewhere and dd'd to that, but it's that ISO9660 file-system that throws everything out; I prefer my Pups in sub-directories, but I don't think you can do that with the way this thing installs, can you?

Hi Mike

I use multi-session saves. Works great, creates a new additional sfs file on HDD each time you save

I download the fatdog iso, click on it to open it up in rox and drag out the initrd, vmlinuz and fd64.sfs files to whichever folder/directory and then edit grub4dos menu.lst ...

Code: Select all

kernel /FATDOG810-FINAL/vmlinuz pkeys=uk basesfs=ram:uuid:4d054dbd-ff6f-48d7-94ac-e9023c62d0f1:/FATDOG810-FINAL/fd64.sfs savefile=direct:multi:uuid:4d054dbd-ff6f-48d7-94ac-e9023c62d0f1:/FATDOG810-FINAL/: 
initrd /FATDOG810-FINAL/initrd

where the uuid's can be found using the "blkid" command in a terminal window.

xscreenshot-20200811T013438.png (270.37 KiB) Viewed 1918 times

Sometimes I make a additional save, but then later want to drop that, so I just delete the last multi...sfs file. There are boot parameters you can use to skip loading of the last n files, but I just find it easier to delete (move) them out of that folder. When saves files have built up to a higher number, perhaps 10 or more, after booting you can delete them all, and run a 'Save' and it consolidates the current session into a single (actually a initial pair) of sfs files.

Same as the DVD multi-session style, but where the files are being loaded/saved on HDD.

For Chrome I just use the default version supplied by the Fatdog team and accessible via the Control Panel, Updates tab. Does take a while to download/build, coffee break type time. I suspect if you use that instead of your portable chrome that you may find that the sound works OK.

And the fact that we're in the middle of a boiling hot heatwave here in the UK is not helping.... Always makes me short-tempered.

Portable AC unit here Stick its out hose up the chimney in the living room (that was knocked through to combine both the dining and living rooms into one before we bought the place), so we have one largish very chilled room. Walking out into the hallway and its been like walking into a oven over the last few days. Cars AC has packed up though, blowers aren't running. Started taking the dashboard apart today to get to the part that needs replacing, but became distracted by other things.

[mikewalsh]

Hiya, ruffers.

Well, I'm not actually using the portable-Chrome, believe it or not! I am using the Chrome that FatDog downloads/builds myself, but I've transplanted the profile from the portable; essentially every browser I use is a portable these days. I've only done that mainly because I have a highly customised New Tab page extension, and it takes absolutely forever to set up the way I like it........and I'm basically getting lazy in my old age!

Audio - once I figured it out - works fine elsewhere in FD64.


Mike.

[mikewalsh]

Now then:-

Browser audio issues solved.

Using GSlapt to install libpng12, and tracking libpcre3 down over at pkgs.org (along with some inspired guess work, and a couple of judicious sym-links; it's the lib64 thing - like Slackware - and the fact that FD64 doesn't use a sym-link between /usr/lib and /usr/lib64), my portable-Chrome package is running A-OK. Just been watching an episode of Gotham on NetFlix, so....

.....that's "sorted". (Maybe not the 'approved' method, but hey! if it works.....)


Mike.

[step]

FD64 doesn't use a sym-link between /usr/lib and /usr/lib64

For a good reason because Fatdog64 can run 32-bit and 64-bit programs so /usr/lib is mostly used for 32-bit shared library files. If you load the 32bit-fd64.sfs (downloadable from Control Panel > System > SFS Manager) you will see all the 32-bit libraries compiled for Fatdog. The file names are the same as their 64-bit versions hence the need to keep /usr/lib and /usr/lib64 separated. One typical use for 32bit-fd64.sfs is running Windows applications through wine.

[bigpup]

Simple answer.
STOP USING dd TO DO INSTALLS TO USB FLASH DRIVES!!!

Use a program designed to specifically do USB installs, using iso's.

dd will do the install, the same as burning to a CD/DVD.
It makes the drive format ISO 9660, using all of drive, and this is a read only format.

[p310don]

but I've transplanted the profile from the portable

Why? If you use Chrome sync, it'll set itself up for you, just the way you have it everywhere else.

[mikewalsh]

but I've transplanted the profile from the portable

Why? If you use Chrome sync, it'll set itself up for you, just the way you have it everywhere else.

Granted! But I refuse to use the 'Sync' function; I have my reasons, personal though they are.....which date nearly all the way back to 2007, when Chrome was born.

I also find it's an absolute pain if you want to delete your Sync "setup", and set it all up again, to Sync from a much newer one. This is one reason I prefer to use a shared profile, wherever possible, and was one of the driving reasons behind my pursuing the 'portable-browser' format the way I have.

Although I make liberal use of the Google eco-system, I limit their access to my data to the nth degree.....and will continue to do so.

(*shrug*)


Mike.

[mikewalsh]

Simple answer.
STOP USING dd TO DO INSTALLS TO USB FLASH DRIVES!!!

Use a program designed to specifically do USB installs, using iso's.

dd will do the install, the same as burning to a CD/DVD.
It makes the drive format ISO 9660, using all of drive, and this is a read only format.

That I will agree with. I wasn't really aware of the ISO9660 formatting until after I'd installed it the first time..... I couldn't be bothered to do it again. After all, I'm still in the "experimenting with" stage, and haven't yet decided whether or not to commit myself.

If I DO decide to commit more fully, I'll want to re-set it all up again, and do things properly the second time around. It's just my way.


Mike.

[mikewalsh]

Y'know, I'm over-thinking this, guys.

With the exception of many specialised scripts for certain things - and a different package management system - FD64 is still like Puppy in so many ways, isn't it? It's now running from a sub-directory on my main Puppy partition on sda2, after modifying the Grub4DOS entry example that Jake provided earlier. Boots and runs fine, TBH.

Top & bottom of the matter, it boils down to this; since my last look at FD64, a couple of years ago, this old dog's learnt a LOT more "tricks"..!

I think I'm gonna have fun with this.


Mike.

[step]

Y'know, I'm over-thinking this, guys.

With the exception of many specialised scripts for certain things - and a different package management system - FD64 is still like Puppy in so many ways, isn't it? It's now running from a sub-directory on my main Puppy partition on sda2, after modifying the Grub4DOS entry example that Jake provided earlier. Boots and runs fine, TBH.

Top & bottom of the matter, it boils down to this; since my last look at FD64, a couple of years ago, this old dog's learnt a LOT more "tricks"..!

I think I'm gonna have fun with this.


Mike.

Well, thank you for your acknowledgement, Mike. You're an experienced Puppy Linux user with a long tradition. Your words matter. Where you will still find some differences between Puppy and Fatdog is because we, the dev team, designed new features with different functionality and usability objectives - keeping paramount reliability and consistency with the Fatdog experience. For instance, such features include user spot (Fatdog is a full-fledged Linux multi-user system), richness of boot methods and options (with more freedom comes some risk to go off the beaten path), the network manager, and several others. Nothing that you won't be able to master as you learn some new "tricks".
Since you have a strong record of packaging major applications, I think you'll enjoy reading about Fatdog's SFS and package systems in the Fatdog help (the question mark icon on the desktop). I can't remember if you also are into compiling. If that's the case, you'll probably also like to see how the Fatdog64 package build system works. This can be found in /usr/src/pkgbuild after loading the devx.sfs (available from Control Panel > System > SFS Manager).

Have fun!

--
step

[mikewalsh]

@step :-

Nah, it suddenly came to me. I mean, as a Puppy user of a few years standing now, I've learnt all sorts of wee short-cuts, and "off-the-wall" ways of doing things, and setting stuff up.....some of which I've already started 'modifying' FatDog with. (Ooh, I hope I haven't just spouted 'heresy'... ) Mostly, they just 'work'.

....Since you have a strong record of packaging major applications....

Erm...heh; well, yes, I guess you could say I've done "a few" in my time..!

I can't remember if you also are into compiling.

Mmm; not so much. I've played around with a few easy ones over the years, but it's not something I really seem to have a knack for. My forte seems to come more in having the patience to track down missing dependencies, many of which come from either the Ubuntu archive repos, or from pkgs.org; Canonical don't seem to throw anything out, and have stuff in there dating all the way back to the days of 'Warty Warthog' and 'Gutsy Gibbon'. Once you've mastered their indexing, numbering & dating systems, it's easy to track down age-related items that would have been used around the release date of any given package. Which makes my job a lot simpler!

I'll probably take a look at the build-system stuff at some point. Again, it can't be that difficult to master. Despite all the different package management systems in use across the Linux universe, at heart they're all manipulating the exact same items.....the bits that make programs/apps work. I tumbled to this one some time ago. You can manipulate any of this stuff manually; at worst, you simply bugger-up the package management record-keeping! It still does the same job.....

Coupla questions (if I may?)

- Having the same extension (txz) as Slackware stuff, does this mean you can install Slackware applications with an expectancy that it won't need too much modifying to get them running?

....and the one that's niggling me:-

- Where do I find the executable/script responsible for the 'right-click' package conversion thingy? I've a feeling I need to do some trouble-shooting, because in every version of FatDog I've ever looked at, this never works for me. Unless, of course, I'm using it wrong?

I'll get there.....eventually!

Mike.

[dr__Dan]

This should be the one:

/usr/bin/pet2txz

Dan

[mikewalsh]

This should be the one:

/usr/bin/pet2txz

Dan

Cheers, Doc! I've sussed this one out now.....and it's the very same "bug" I've discovered with a few other Puppy-based scripts over the years.

You have to run the script manually, the first time around.....from the terminal. After that, it'll work from the right-click context menu, every time. Don't have a clue why this should be the case, but, there ya go.....

In the Pups, I have a make-pet directory in /root; this works with Trio's Pet-Maker. So for FD64, I now have /root/make-txz. Having run the script once, manually, from this directory, it now appears to 'remember' that, and provided I use this same directory for the conversions each time, the right-click context item now does the honours.

Works for me.


Mike.

[step]

- Having the same extension (txz) as Slackware stuff, does this mean you can install Slackware applications with an expectancy that it won't need too much modifying to get them running?

No because Fatdog64 isn't Slackware somewhat like Puppy Linux isn't Ubuntu. More to the point, all 4000+ packages in the Fatdog64 repo are self-compiled from source, we don't repackage Slackware packages (with a few exceptions but those don't come from Slackware). Moreover, especially when it comes to system management and security, Fatdog64 and Slackware can make different choices. Therefore, a Slackware package may need Slackware dependencies that just aren't compatible with Fatdog64. What you can expect in installing a Slackware package downloaded from a Slackware repo is more or less similar to your experience installing Ubuntu packages into Puppy Linux: tracking down missing dependencies and fiddling with system configuration files.

Also, there's an old-forum thread for Fatdog64 user-contributed packages that you may be interested in. The "+Packages" link in my signature will lead you to my post in that overall thread.

[je55eah]

I have browsed the forum and this thread was the closest topic I found.

After installing fatdog on a usb using the dd method so that efi and mbr booting will theoretically work I booted the system.

Once booted I changed the background image and attempted to create a save file. This was impossible when using an sd card because the sd card was read only even though it wasn't when i installed the system. Apparently Linux doesn't reliably support sd cards. I read about a boot option that might help, but instead of fighting I switched to a usb drive. When using USB drive I was able to create an encrypted 4GB save file but when I boot the system and select load save file from usb then it asks for my password and goes no further.

I have used puppy and fatdog for many years to copy files and to run gparted, but I have never managed to use them for anything else because once I try to change anything something always breaks. Puppy seems to boot on everything, which is why I keep comming back. I love the lightweight systems, it's just a shame that they are so fragile.

What have I done wrong?

[JakeSFR]

I have browsed the forum and this thread was the closest topic I found.

Have you read this thread, at least first few replies?

After installing fatdog on a usb using the dd method so that efi and mbr booting will theoretically work I booted the system.

Once booted I changed the background image and attempted to create a save file. This was impossible when using an sd card because the sd card was read only even though it wasn't when i installed the system. Apparently Linux doesn't reliably support sd cards.

If you dd an ISO onto a USB stick or SD card, it becomes read-only, because the ISO format itself is read-only.
You can reclaim the unused space and make it writable again by using the fix-usb.sh script.
Detailed instructions are in FAQ: https://distro.ibiblio.org/fatdog/web/f ... drive.html (also the "Help" icon on desktop).

I read about a boot option that might help, but instead of fighting I switched to a usb drive. When using USB drive I was able to create an encrypted 4GB save file but when I boot the system and select load save file from usb then it asks for my password and goes no further.

Did you type in your password and press Enter?
The characters you type or even *'s are not displayed, for security reasons.

Or does the "goes no further" refer to after you typed the password?

Greetings!

[je55eah]

Yes, I read a lot yesterday.

I did not use the fix-usb script because the directions here say that it will ruin the installation.

https://distro.ibiblio.org/fatdog/web/f ... rive2.html

I also found the usb drive to be writeable, whereas, the sd card was not so I suspect it is an issue related to the drivers as discussed in another topic. I didn't dd from the iso. Rather, I dd from the usb-boot-mbr.img as described here.

https://distro.ibiblio.org/fatdog/web/f ... -boot.html

The note about the fix-usb.sh which you highlighted was read, but it didn't seem to be applicable in my case.

Yes, I did press enter after typing the password, but nothing happened. The light on the drive didn't flash and I waited for hours since it took a very long time to create the save file as well. I also attempted it multiple times after forcing a shutdown and reboot.

Since then I deleted the encrypted savefile and tried to create a multisession save. Two multisession files were created but when I rebooted and selected the multissession boot option they were not loaded. When I tried fatdog five or six years ago I did manage to create persistence, but this time I can't seem to get it to work.

Thanks for the ideas. I can try the fix-usb script even though it seems to be counterindicated.

[JakeSFR]

I didn't dd from the iso. Rather, I dd from the usb-boot-mbr.img as described here.

https://distro.ibiblio.org/fatdog/web/f ... rive2.html

Ok, so the fix-usb.sh has no use here.

Yes, I did press enter after typing the password, but nothing happened. The light on the drive didn't flash and I waited for hours since it took a very long time to create the save file as well. I also attempted it multiple times after forcing a shutdown and reboot.

Since then I deleted the encrypted savefile and tried to create a multisession save. Two multisession files were created but when I rebooted and selected the multissession boot option they were not loaded. When I tried fatdog five or six years ago I did manage to create persistence, but this time I can't seem to get it to work.

Hmm, try adding showerr and loglevel=7 bootloader options, maybe this will shed some light.

Greetings!

[je55eah]

Okay. I didn't learn much from those bootcodes but I did view the messages file.

After trying again on another system I learned some things. The issue with the password was that the 2012 macbook I was trying to use with fatdog must not be well supported. The keyboard works at grub, but keypresses are not captured when the dm crypt password is required. I plugged in a usb keyboard and then the password was accepted and the system loaded very slowly. Does cryptography on the save file cause the massive slowdown or is it a problem with the updates which I installed? I ran the fatdog updater and installed all 62 updates. I also updated or installed firefox, seamonkey, chrome, and google talkchat. Now fatdog is the slowest system I have ever used. Wifi on the macbook is also not recognized. This is disappointing because when I first tried fatdog about six years ago it was the first system I found that bootwd and ran on this very macbook. I recall that some troubleshooting was required, but I thought the experience would be easier all these years later. As it is, this system is unusable. I will try again without encryption, but the use case for fatdog is evaporating.

The multisession saves seem not to work at all. I think that is because the boot option looks for an optical disk. Should I waste time testing a multisession save with the usbboot option?

Is anyone actually using Fatdog as it is?

[je55eah]

Update:
I copied the working save file to the sd card I was using earlier then booted some systems with an external usb sd card reader. There must be a problem with the new pny usb drive I am using because the system runs at a reasonable speed from the usb routed sd card which is very old.

Consequently, my remaining issue is that I need fatdog to recognize the macbook keyboard and wifi. More problems could arise, but those are in my face.

I am also curious about multisession on usb.

I also noticed that the encrypted sparse filesystem is 4gb on the disk. I wondered if encrypting a sparse filesysttem would be less secure, and perhaps the answer is that it is so I fatdog didn't actually ive me a sparse save file. Does anyone know how that works?

[JakeSFR]

I copied the working save file to the sd card I was using earlier then booted some systems with an external usb sd card reader. There must be a problem with the new pny usb drive I am using because the system runs at a reasonable speed from the usb routed sd card which is very old.

Ok, one down.

Consequently, my remaining issue is that I need fatdog to recognize the macbook keyboard and wifi. More problems could arise, but those are in my face.

It's most likely missing drivers.
You could try the latest release: viewtopic.php?t=7003&sid=8db3fe0fcc0a3e ... 3220de978d and see it there's any improvement.

I am also curious about multisession on usb.

There are users who use multisession, not sure if on USB, though. Don't remember who exactly. Anyone wants to chime in?

I also noticed that the encrypted sparse filesystem is 4gb on the disk. I wondered if encrypting a sparse filesysttem would be less secure, and perhaps the answer is that it is so I fatdog didn't actually ive me a sparse save file. Does anyone know how that works?

That depends on a filesystem. Some of them, like FAT32, don't support sparse files.
The encryption shouldn't matter.

Greetings!

[mikewalsh]

@JakeSFR :-

Don't I remember user 1111 (you-know-who-I-mean) developing a way of doing multi-session on FatDog from a USB stick.....before he went nutso and started attacking the Forum over its Ukraine stance?

I could be wrong, but I guess you'll find some reference to it within your own pages here. Sounded quite a useful method, from what I recall.

Mike.

[je55eah]

Okay. That's a timely release. I'll take a stab at it. Oddly, I have an older release ( 800 something I think ) that boots up and the wifi works. I didn't try installing it, because I took the newest version a few days ago instead. Hopefully the new fatdog gets it working.

Another Idea I intend to try today is to install relevant packages for wifi and hopefully there is something to fix the keyboard too.

Depending on my time available I will try to search for the notes left by user1111.

The filesystem is ext4 on ext4 and I also made a backup disk with ext4 on ext2. The encrypted sparse file occupies a full 4GB. Aren't sparse files supposed to be small and then grow up to the designated size? I understand why that may not be logical with encryption. I even wondered if encrypting a lot of zero data would weaken the encryption by creating a lot of repeating patterns. Since it is big anyway, I will encrypt a normal (nonsparse) savefile when I install the new version. I tried putting ext4 on exfat, but fatfog complained that it didn't have write access to exfat. Maybe I should try again with the new version.

Thanks for the tips.