Fatdog64 710 Beta2 [CLOSED]

[borzeh]

@jamesbond

hi

As there isnt any default keyboard switch in Fatdog(openbox) , I'm trying to use fbxkb package that you have fix to run on fatdog.
fbxkb install without problem , i have set "setxkbmap" , but its not work.

after some try , i found that fbxkb keyboard shortcut conflict with Sven(default keyboard switcher) and by close sven , fbxkb works fine.

I need sven as it controls brightness and volume!
Is there any suggestion to this confliction?

I think if there's a command for change between languages , then this precedure can be done only with sven. but i cant find a command for permanent input language switch.

thank you

[Gobbi]

I think if there's a command for change between languages ...

Try : Control Panel/Localisation/Keyboard Localization

[jamesbond]

If you are talking about the ability to switch between multiple keyboard layouts, you can't do it from the GUI. The GUI is simple tool assuming you want to use a single keyboard layout.

The command-line you need is this (change the language as needed):

Code: Select all

setxkbmap -option grp:alt_shift_toggle "us,de,fr,ru"

To make this persistent (executed at every boot), edit the file $HOME/.fatdog/xkeymap, and inside put this one:

Code: Select all

-option grp:alt_shift_toggle "us,de,fr,ru"

Basically, everything after setxkbmap, you put in that file.

Once you've done this **do not** use the Keyboard Localisation GUI (it cannot understand these complex options) or your setting will be gone.

[jamesbond]

Transported from 710beta thread:

I have been trying out Fatdog64 710 beta 2 (2016-Oct-21), installed on a USB stick from a live CD.

In general, things are working well.

However, the wifi profile and settings do not survive a reboot. The system does not automatically reconnect to the router after reboot, and I have to rerun the network wizard to reestablish a wifi connection each time.

The ‘fd64save’ folder (on same partition as /boot) seems to be working normally, and ‘remembers’ other files created during a session when I had an established wifi connection.

Any suggestions as to how to make my wifi connection data persistent would be appreciated.

Ed, please open Control Panel, click "Utilites" tab, scroll down and run "Bug Info collector". Send the file to me (via PM if you wish).

cheers!

[prehistoric]

...
@prehistoric: re: corruption
This has happened before when aufs was involved, long time ago, and it was fixed.
But new bugs may have made its way in.
But if I read your report carefully, I don't see aufs involved here.

Can you please tell us the source/target?
In your latest experiment I assume source is NTFS, target is portable drive formatted in ext4?
In this case aufs isn't involved at all, so it's either ntfs-3g, kernel filesystem ext4 driver, kernel disk block driver, or kernel USB driver (or hardware problem).
With an earlier unpublished beta (I can't remember - 4.4.18 or 4.4.20) I copied from NTFS to ext4, about 70GB and, it worked well (I used "cp -a").
Let's isolate this: would you be able to simulate similar copying workload, this time using different kernels?...

Working on this, and I'll get back to you when I have more information.

One example of corruption did take place when copying from my Downloads directory on an ext3 partition to an ext4 partition. This is the one where deleted files reappeared, which caused me to suspect aufs. I've eliminated the kernel USB driver by copying to an internal hard drive, but still found I/O errors. When I copied from NTFS partitions I did not see old files reappear, but I did see files dropped.

I also suspect the kernel block device driver because this kind of behavior only takes place at very high data rates on long transfers. I remember seeing similar crap when people started using the higher UDMA numbers. The workaround was to limit very high data rate transfers to less than 100 KB. at a whack, or disable them entirely. That also involved a hardware problem which could be mitigated by adjusting latency on the PCI bus in the BIOS, something that I'm not sure is even effective any more. Modern kernels seem to take over everything, and disregard BIOS settings they don't like.

It will take me a few days to run experiments with different kernels. I don't want to risk the system which is now handling all my email. (Yes, I know this is a beta. I was having such good luck I moved over ahead of release. ) I would be quite happy to set a kernel parameter which reduced performance, but guaranteed reliability, on this one machine.

I still don't know if this is an isolated bug or merely one where the probability changes with different speeds. I've been through such problems where faster machines made the problem behavior less likely without eliminating it. I've also had battles with programmers who kept making the problem harder to find in the belief they were making it better, in the old days when I managed software. That experience was one reason my hair turned white.

Other people running Fatdog on slow machines might attempt large transfers to see if this is unique to the Nforce2 chipset.

[Wognath]

The "volume is too low" has been a known complaint on Fatdog with no known solution.

I have never had this problem in Fatdog. In Precise, it helped to add a preamp as described here:
https://wiki.archlinux.org/index.php/Ad ... und_Volume
This works in Fatdog by saving the suggested text as /etc/asound.conf. The preamp shows up in alsamixer after starting and stopping a media player once, as this guy says.
Maybe this is useful to someone until a solution is found.

[artsown]

I ran into a kernel panic problem while setting up a Dell Inspiron 530 in my
usual way ... multi-booting some pups and Win XP in Lin 'n Win style. Both
64 bit pups ... Fatdog710B2 and Xenial64 kernel panic, while two 32 bit
pups ... Xenial32 pup and Tahrpup32 are OK. A live CD of Fatdog works Ok.

Shooting in the dark, I tried moving vmlinuz and initrd out of their fd64
folder and placing them directly on /mnt/home. This worked But the
method didn't work for Xenial64 pup (in a different partition).

The panic message is: Kernel panic - not syncing: VFS: Unable to mount
root fs on unknown-block (0,0)

The hard drive was freshly partitioned, and I used Windows chkdsk to
look for bad sectors, etc. No problems found.

Any suggestions as to what I might try in order to find what's causing the
problem with 64 bit pups (under some conditions)?

Edit: All is ok now. I suspect that copying puppy files from usb sticks was at
least part of the problem. Fresh copying from the downloaded isos
did the trick.

[dr. Dan]

Hello again!

Also working happily on a Dell Optiplex 380 and an Asus X54c.

However, when trying to customize the Application Menu button, I cannot change the keyboard shortcut. The first time I click it, it flashes "10" then reverts to the default "Alt+F1". After that it merely flashes.

Also, in anticipation of switching to the final 710, will there be a tool to strip the incompatibilities from my savefolder for smoother transition? I can probably accomplish it, but people I recommend it to might have more difficulty.

Thanks!

[SFR]

However, when trying to customize the Application Menu button, I cannot change the keyboard shortcut. The first time I click it, it flashes "10" then reverts to the default "Alt+F1". After that it merely flashes.

Yeah, it's broken for some reason...
But the Alt+F1 shortcut actually invokes Openbox's menu, no LxQtPanel's, so you can redefine it in /etc/xdg/openbox/rc.xml (or ~/.config/openbox/rc.xml, which takes precedence, if exists), in this section:

Code: Select all

    <keybind key="A-F1">
      <action name="ShowMenu">
        <menu>root-menu</menu>
      </action>

After saving the modified file you just need to 'Right-click the desktop -> Openbox -> Reconfigure' or run this in terminal:

Code: Select all

openbox --reconfigure

Also, in anticipation of switching to the final 710, will there be a tool to strip the incompatibilities from my savefolder for smoother transition? I can probably accomplish it, but people I recommend it to might have more difficulty.

So far the changes between Beta2 and Final are practically only some updated applications/libs and bugfixes, so I think there should be no problem using a savefile/folder from B2 with it.

Greetings!

[dr. Dan]

Thanks for the response, but I was not clear enough. My savefile is on 702. I'm not facile enough to feel like installing the beta. Also, my friends using Fatdog64 are on 702 as well.

One other thing, that bizarre "stream of consciousness" thread the other day, which ended in strange combative terms, made me aware of useful details about uefi, so as is said, it's an ill wind that blows no one good.

[spandey]

Fatdog710 beta2 is incorrectly recognizing my ext4 srives as ext3 drives.

EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities

These messages are there for each partition.Any clues how to find the reason?

[drunkjedi]

Fatdog710 beta2 is incorrectly recognizing my ext4 srives as ext3 drives.

EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities

These messages are there for each partition.Any clues how to find the reason?

Hello Pandey Ji,
I don't know why that's happening someone more knowledgeable will come along.

Meanwhile run following command in a terminal and post the results.

Code: Select all

file -sL /dev/sd*

[spandey]

@drunkjedi,
Here you go:

/dev/sda: DOS/MBR boot sector
/dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=fe40d76e-d22d-4df0-81e1-f32413d2dc0e, volume name "rootMX-15" (extents) (large files) (huge files)

/dev/sda2: Linux rev 1.0 ext4 filesystem data, UUID=f91adf0c-16c4-4923-aed3-3454979bc6ff, volume name "homeMX" (extents) (large files) (huge files)

/dev/sda3: Linux/i386 swap file (new style), version 1 (4K pages), size 1572863 pages, LABEL=MXswap, UUID=34a7716c-445b-43a8-aa24-6fb5d86862f3

/dev/sdb: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 "Invalid partition table" at offset 0x17b "Error loading operating system" at offset 0x19a "Missing operating system", disk signature 0x126724c; partition 1 : ID=0x83, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 2048, 31264768 sectors

/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=59d7a756-c1c6-4f07-a1ee-8ca361dfe507 (needs journal recovery) (extents) (large files) (huge files)

[kirk]

These messages are there for each partition.Any clues how to find the reason?

That's normal. Newer kernels removed the ext2 and ext3 drivers and now the ext4 driver does them all. When you mount using auto type you'll get those messages. Would be nice if the kernel folks would clean that up.

[spandey]

My problem is Ram layer is not owrking with savefile. While investigating I found these errors. Here's my situation
1. I have main files on sdb2 which is SSD.
2. SAvefile is on sdb1 which is connected to USB2
3. I boot from SSD using savefile=ram:uuid:59d7a756-c1c6-4f07-a1ee-8ca361dfe507:fd64save waitdev=5

The problem is the savefile is loaded but RAM layer is missing. How to fix this?

[Nym1]

Hello,

While testing Fatdog64 710 Beta2, I have observed that the Engrampa archive manager, if executed via the GUI, will fail to unpack deadbeef-static_0.7.2-2_x86_64.tar.bz2. One will be presented with the message “An error occurred while extracting files.

[SFR]

Yes, I can confirm that Engrampa occasionally has problems with extraction of some archives.

As for for your findings regarding DeaDBeeF, here are my results:
- extraction via "Extract" button -> OK
- extraction via drag'n'drop -> FAIL

And indeed, upgrading tar to 1.29 fixed the second case.
Same results with this one: http://taskwarrior.org/download/task-2.5.1.tar.gz

However there are archives out there that still won't extract, e.g.: http://www.xl-project.com/download/atari++_1.80.tar.gz
[note: if downloaded via browser, the file may turn into plain tar, in which case just remove the '.xz' extension]
It works fine if you repack it, though.,,

Anyway, thank you for nailing tar as the culprit, hopefully it will be upgraded for Final.
___________

[later]

Just noticed that the common factor for all those problematic tarballs is that their top-most directory has empty "Data Modified" field displayed in Engrampa.
The 'atari++' archive also has this field empty for "manual" subfolder and most likely that's why it still fails.

For some reason no directory from the archive gets listed:

Code: Select all

# tar tvf atari++_original.tar | grep ^d
# 

After repacking, they're there:

Code: Select all

# tar tvf atari++_repacked.tar | grep ^d
drwxr-xr-x root/root         0 2016-11-16 00:41 atari++/
drwxr-xr-x root/root         0 2016-11-16 00:41 atari++/manual/
#

Greetings!

[Nym1]

Hello,

I believe that the occasional failure of extraction of some archives may be due more to a problem with Engrampa version 1.41.1 than with Tar 1.27.1.

Xarchiver version 0.5.2 (available via Gslapt package in the Fatdog64 Control Panel) unpacked both task-2.5.1.tar.gz and atari++_1.80.tar.gz without errors while tar version 1.27.1 was active although Engrampa failed under the same condition.

Respectfully submitted,

Nym1

[SFR]

Xarchiver also fails if you use drag'n'drop.
I also wanted to test Peazip, but it segfaults on any archive I tried.

But I agree, it may be not tar's fault.
Perhaps the authors of these archive managers have never stumbled across (and/or didn't try to extract them via DND) this special "kind" of directoryless tarballs...

Greetings!

[jamesbond]

seamonkey-2.46, firefox-gtk2 50.0 and palemoon 26.5.0 in the repo.

Note: firefox-gtk2 is compiled in Fatdog and does not require GTK3. On the other hand, it will not update to any newer version. If you like continuous update please continue to use official Mozilla version.

Final coming soon.

EDIT: The repo contains more updates than just the above. Please resist the temptation to update --- some of these contains **breaking** changes meant for final.

But if you want to update, kirk built 4.4.33 kernel and that should work with existing 710b2.