Fatdog64-800RC [13 Feb 2019] [CLOSED]

[rufwoof]

How to you drop capabilities in Fatdog?

EDIT: Sorted. I've added new lines into this otherwise it just widens out the forum (posting) width too much)

This (I think) runs seamonkey-spot with additionally many capabilities also dropped

Code: Select all

#!/bin/sh
cd /home/spot
capsh --drop=cap_dac_override,cap_dac_read_search,cap_fsetid,
cap_kill,cap_setpcap,cap_linux_immutable,cap_net_bind_service,
cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,
cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,
cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,
cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,
cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,
cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,
cap_block_suspend,cap_audit_read -- /usr/bin/seamonkey-spot

I just call it seamonkey-cap ... as a wrapper for seamonkey-spot

Also serves as a reminder to not forget to change the default woofwoof root password ... as otherwise spot can easily/commonly su into root.

[jake29]

Already fixed, thanks.
The scale factor for screen thumbnails used to be calculated as follows:
thumbnails_area_height (300px) / virtual_screen_height (32767px in your case) = ~.009
Now it's set to 0.1 by default, so the thumbnails are much larger.

Thanks SFR, that is much better.

LxRandR saves its settings as a .desktop file in ~/.config/autostart dir.
In order to launch stuff from there at startup you need to enable:
Control Panel -> Desktop -> Manage desktop startup programs -> System startup programs -> launch-autostart.

Anyway, we'll thinking about patching it to use ~/Startup dir instead.

It does feel more logical for LXRandR to use ~/Startup dir considering it is a built-in system app and it would be expected that if you save a configuration - no other steps are needed.

One other thing I noticed related to dual-monitor setup is that Google Chrome (installed via Menu > Internet) will cause graphical issues on my extended monitor when 'Use Hardware Acceleration when available' is enabled. This only occurs when I play a YouTube video (or other video format) in full-screen. Kodi does not cause this sort of issue, and hits the CPU much less anyway.

[rufwoof]

DVD multi-session ... not saving

My DVD writer is half-dead, so can't test it, but hopefully someone else will chime in soon.
Thanks for the detailed debug, though!

I think changing the growisofs command to look something like

Code: Select all

growisofs -M /dev/sr0 -J -r somefile.txt

might do the trick. Presently I've zapped the DVD content but repeated use of the above is adding files correctly to it. Just logging the syntax here before I reboot to reburn afresh etc. and then I'll give that a try.

... No luck. Same version of growisofs as 721, some difference in libs (ldd growisofs). Now wondering if how the initial burn is made might be the cause (a earlier run of xorriso blanked the disk and after that I could add files to that).

After booting the clean FD8 DVD, if I swap that for a FD721 DVD that already has some multi-session saves on it and run save2session ... it adds another save session to the set OK.

... Ahh! Redoing a fatdog 8 freshly using the main iso ... and multi saves OK. I tend to install/use peasydisc, pburn and isomaster. The main as-is iso is slow to boot (fd64.sfs inside initrd) as that's BIOS loading it, so usually I split out the fd64.sfs and reform the smaller initrd, and adjust my isolinux.cfg to add basesfs=ram:local kernel boot parameter. It's starting to look like isomaster might be the culprit. Seemingly each of remaster, build-iso, peasydisc, pburn and isomaster ...etc all have to use the same mkisofs parameters. Not sure yet, but it looks like reforming a iso using isomaster from the Fatdog 8's repo might be using a different choice; So when I recreate a new iso using isomaster, to open the as-is fd8 iso and delete the initrd from within that, add in the new smaller version and add in fd64.sfs alongside that, tweak the isolinux.cfg to boot fatdog-multi by default and recreate/burn/use a new iso ... then that's when the problems of creating a multi-save occur.

In short, isomaster is compiled, not a script. Has a new version been used in FD8 that might perhaps be using a different set of mkisofs type parameters?

[jamesbond]

rufwoof, thanks for testing. I no longer has the media, I was about to go and buy some DVD+RW for testing, but I'm glad you find the root cause of the problem. (I might still go and buy the media anyway).

From FD64 side, there is no major changes for the savesession script or the mkisofs parameters. They're considered complete and done; the only thing we do to them is for bug fixes (or regressions) only.

isomaster however was updated from version 1.3.11 in 721 to 1.3.14 in 800.
It's a straight compile, no patching etc. Note that isomaster doesn't make use of mkisofs or anything else; it has its own internal functions to make an ISO.

The changelogs reads:

28 Mar 2018 - 1.3.14
====================
- Migrated to iniparser 4.1.
- Switched default text editor to leafpad.

16 Nov 2014 - 1.3.13
====================
- Used the OSTD ( http://littlesvr.ca/ostd/ ) to add 77 more translations:

13 Oct 2014 - 1.3.12
====================
- Fixed serious bug that caused corrupt files when editing images over 4.2GB in size.

So I suppose something happened in 1.3.12 (that's the only time the writing logic seems to be changed) that breaks compatibility with multi-session.

[rufwoof]

Thanks James. I've just done a clean start and instead of importing other things from gslapt I just used the integral programs. Used pburn to burn the full as-is iso (that's slower to boot from DVD as fd64.sfs is inside the initrd), configured that and saved. Rebooted and then remastered. With that remastered iso on HDD I blanked the DVD I'd just booted from using pburn, then burnt the remastered iso to that and that's now saving multi-sessions fine. That's a neater way to do it really, I was just in the habit of more manually setting things up using isomaster etc.

[jamesbond]

Glad to hear you managed to clear it up. I just want to confirm that yes, the mkisofs parameters used in the original ISO creation, the one used in remaster, and the one used by save2session, all of them must be identical (and indeed they are - you can look into the FD ISO builder's build-iso.sh and see the parameter for the creation of the ISO).

As for the slow-boot - did you try to boot with the initrd-nano (the last entry in the boot menu)? Did it not help you?

[jajk]

Managed to get Fatdog installed and booting off hard drive on Acer ES 15 Laptop despite the (intentionally) buggy UEFI implementation designed to keep Win 10 as the only option.
Love the new O.S apart from not being able to connect to a wifi accesspoint.
The wifi applet can see my accesspoint but something is not working when I try to enter the password and connect......no connection is established.
Any clues as to why I cant' connect? Is there some information I can provide to make it clearer what is going on?

[mavrothal]

Trying RC on mbp works almost perfect
A small typo on mbp-kb-backlight.sh blocks it from working (#!/bin[dot]dash).
Also the volume control keys are not working and need some xmodmap(ing) to do the job.

Code: Select all

keycode 113 = XF86AudioMute NoSymbol XF86AudioMute
keycode 114 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume
keycode 115 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume

You may want to add in in rc.platform.
Other than that nothing major besides the remaining spot/Downloads on fat/vfat media that is still useless and makes running the browser as spot annoying at least.
Also, is a kernel change still in the cards?

[quirkian2new]

Thanks guys for 800RC. just downloaded, and posting from 800RC now

I noted on page 1 there is -----> fatdog-remaster supports "medium initrd" (kernel modules inside, basesfs outside)

I usually fatdog with huge initrd if 4gb ram or more, small initrd with 2gb ram or less.

My last remaster is FD702 and haven't done any remaster after FD702.

Medium initrd sounds similar to small initrd in that the basesfs is outside, and just want to know how different is medium initrd with small initrd ? (any boot parameter )



My laptop is 2 gb ram and i am considering making a remaster for it when 800 final. (of course running in a manner similar to small initrd, that is, basesfs NOT totally load into ram )

[stemsee]

Medium initrd sounds similar to small initrd in that the basesfs is outside, and just want to know how different is medium initrd with small initrd ? (any boot parameter )

I suggested this option, so maybe I can offer some info.

When remastering with the huge option the modules and aufs 'stuff' is in the basesfs. For swapping kernels manually, at least, this adds a few more steps which could provide opportunities for mistakes. With the small initrd option the basesfs and kenel-modules.sfs are both inddependently in the initrd. The medium option gives the advantage of the maybe very big basesfs not in the initrd and not then copied into ram, but the initrd and the modules are independently in the initrd and loaded to ram. This is more similar to regular pups.

stemsee

[rufwoof]

As for the slow-boot [DVD] - did you try to boot with the initrd-nano (the last entry in the boot menu)? Did it not help you?

No I didn't try it. Humongous takes around 4 minutes power button pressed to desktop, with the fd65.sfs outside of initrd that halves down to around 2 minutes which is fine for me as typically its a case of hit the power on button and head for the Out house to prepare a brew (tea/coffee) which also takes around the same time. In order to boot direct to desktop I have to change the DVD's isolinux.cfg to default to fatdog-multi ... and edit the kernel boot line to include basesfs=ram:local ...etc. so a remaster (or modification to the iso) is required anyway. Seem to recall trying nano in a (much) earlier version of FD and hit problems and haven't tried it since .. but I should/will.

[rufwoof]

When remastering with the huge option the modules and aufs 'stuff' is in the basesfs. For swapping kernels manually, at least, this adds a few more steps which could provide opportunities for mistakes. With the small initrd option the basesfs and kenel-modules.sfs are both independently in the initrd. The medium option gives the advantage of the maybe very big basesfs not in the initrd and not then copied into ram, but the initrd and the modules are independently in the initrd and loaded to ram. This is more similar to regular pups.

I think (not sure) that when remastering 800 humongous I opted for the small option and did see separate fd64.sfs and kernel-modules.sfs in the temporary folders, but in the final iso I just have a small initrd (4.5MB) and a 418MB fd64.sfs ... and no separate kernel-modules.sfs.

So I think its humongous has all inside initrd, medium has separate initrd, fd64.sfs and kernel-modules sfs, small has separate initrd and fd64.sfs (with kernel modules contained within that).

[rufwoof]

My laptop is 2 gb ram and i am considering making a remaster for it when 800 final. (of course running in a manner similar to small initrd, that is, basesfs NOT totally load into ram )

I'm running fine with 2GB and everything loaded into ram. Multisession DVD booting so once booted the DVD can be ejected and just has to be reinserted for saving (I have Event Managers save session interval set to zero so it only ever saves when I click the desktop Save Session icon). Mostly, once set up I don't save as all data is outside of FD). I think you select which of humongous/medium/small more in alignment to how you boot rather than for memory considerations, except perhaps if available memory is very limited (500MB or less I guess).

[don570]

I suggest that Create Nvidia Driver SFS page be re-written
http://www.lightofdawn.org/wiki/wiki.cg ... aDriverSFS

since there is no patch for current nvidia download. This simplifies the instructions.

https://us.download.nvidia.com/XFree86/ ... 418.30.run

___________________________________________________

[quirkian2new]

so from the readings, i presume that medium initrd will probably behaves exactly like small initrd, but medium initrd has the advantage of more easily change/swap kernel than small initrd (just download and replace the kernel-modules.sfs within the medium initrd) ?

i would also presume that the size of the medium initrd is approx. 70MB ?

thanks

[jamesbond]

1. standard initrd (aka huge initrd aka humongous initrd)
- fd64.sfs inside
- kernel-modules.sfs inside
- size ~400MB
- easy to replace kernel (just replace kernel-modules.sfs and vmlinuz)

2. small initrd
- fd64.sfs outside, merged with kernel-modules.sfs
- no independent kernel-modules.sfs inside or outside
- minimum number of kernel modules (individual modules) inside
- size less than 10MB
- not easy to replace kernel as kernel-modules.sfs is split into two:
=> large part is merged with fd64.sfs
=> a few small ones are merged inside initrd.

3. medium initrd
- fd64.sfs outside
- kernel-modules.sfs inside
- size ~70MB
- easy to replace kernel (just replace kernel-modules.sfs and vmlinuz)
- if you frugal install on hdd/usb you can do this manually yourself, just unpack initrd, take fd64.sfs out; and re-pack initrd.

4. nano initrd
- fd64.sfs outside
- kernel-modules.sfs outside
- size ~4MB
- no kernel-dependent stuff inside initrd
- may not boot properly if hardware requires kernel modules (e.g can't select from multiple savefiles/savedirs if keyboard requires kernel module loaded)
- if you frugal install on hdd/usb you can do this manually yourself, just unpack initrd, take fd64.sfs & kernel-modules.sfs out; and re-pack initrd.

Additional notes:
- The ISO contains both huge initrd and nano initrd. Remaster support 1/2/3 not but 4.
- even though fd64.sfs and kernel-modules.sfs are outside they can be loaded into RAM too if you wish.

[jamesbond]

Trying RC on mbp works almost perfect

Thanks to your feedback

A small typo on mbp-kb-backlight.sh blocks it from working (#!/bin[dot]dash).
Also the volume control keys are not working and need some xmodmap(ing) to do the job.

Code: Select all

keycode 113 = XF86AudioMute NoSymbol XF86AudioMute
keycode 114 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume
keycode 115 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume

You may want to add in in rc.platform.

All done.

Other than that nothing major besides the remaining spot/Downloads on fat/vfat media that is still useless and makes running the browser as spot annoying at least.

I thought we've fixed this. Let me check again.

Also, is a kernel change still in the cards?

Yes

[jamesbond]

Managed to get Fatdog installed and booting off hard drive on Acer ES 15 Laptop despite the (intentionally) buggy UEFI implementation designed to keep Win 10 as the only option.
Love the new O.S apart from not being able to connect to a wifi accesspoint.
The wifi applet can see my accesspoint but something is not working when I try to enter the password and connect......no connection is established.
Any clues as to why I cant' connect? Is there some information I can provide to make it clearer what is going on?

Please launch Control Panel, choose the Utilities tab, scroll down to the bottom, and run "Bug Report Info Collector".

[jamesbond]

How to you drop capabilities in Fatdog?

EDIT: Sorted. I've added new lines into this otherwise it just widens out the forum (posting) width too much)

Good to know. So what went wrong before?

[jamesbond]

I suggest that Create Nvidia Driver SFS page be re-written
http://www.lightofdawn.org/wiki/wiki.cg ... aDriverSFS

since there is no patch for current nvidia download. This simplifies the instructions.

Thanks. I think the general statement is still true in the sense that newer kernels usually do need patches. The article pointed out at the time of writing 4.14 was the bleeding edge, so it needed patches. By now of course it isn't true anymore, but I also said that "older kernels don't need it".