Just a quick update on my problem. I have flashed my 2nd N900 (incl. eMMC) and installed T7.2 via apt-get. Seems I would have had the volume issues before T8. It still sets volume to 0 when disconnecting from "BT headset" (car's MMI). I will do another test with older versions starting from PR1.3

About testing PA, don't know if I can help with that. It's hard to test if I can't pin the error condition (sometime it works, sometimes it doesn't) Lately I haven't had much issues with ringtones, maybe because I am using "custom ringtones for your contacts (1.0.3-0)".

On the other hand, this morning my alarm was default sound (N900 with T8.2). My custom sound would have been something different and is located somewhere in MyDocs. It is a file Rooster.aac (size 12532 b) I copied from my old 9300i. As I tried to replicate this right now I first had no alarm at all (screen still on), on 2nd try it would play the correct sound.

Maybe it is about the file system not being ready while a custom sound is supposed to be playing. Wasn't there someting in the changelog about notification system (dsme) being changed?

When announced the next CSSU-Testing with fixed bugs? Sorry for question, but I not have solution for my bugs.

I will try and find some time this weekend (between spots of gardening, DIY and watching half the French Air Force flying over my house).

I noticed fmask=0000 in vfat_opts line of /etc/default/mount-opts. (and umask=0000 for ntfs_opts)

Out of curiosity, why do we want to have every and each file on vfat/ntfs marked as 'executable' on birth?* Wouldn't something like fmask=0133 be more sane, for both vfat and ntfs?

*In linux filesystems, umask=0000 results in 0666 permissions for files and 0777 permissions for directories, respectively, on birth. For windows filesystems (vfat and ntfs) mounted under linux, it results in 0777 for *both* directories and files, making every single file executable at the very moment of its creation.

That's why it's better to use fmask than umask for vfat/ntfs, and it shouldn't be 0000, unless we explictly want to make everything rwx.

/Estel

I reflashed - all went good without any errors. After installing CSSU testing (thumb version) my filesystem broke again (fortunately mmcblk0p1 so easy to fix doing chkdsk from windows) . I was suspecting that my internal memory wear off but I have no IO errors in dmesg which indicates that there is something in CSSU that breaks my filesystem. I was using CSSU stable for some time and never experienced filesystem errors so it may be related to some changes in testing.

System sounds are fine now, so filesystem corruption was the reason rather than pulse audio.

Interestingly, I had a N900 die with file system errors, too, after updating to the latest CSSU-testing-thumb. I didn't have time to investigate further and thought it had just reached the end of its life. I'm using a backup device now (which I haven't updated yet).

In new, cssu'ish /etc/event.d/rcS-late, we have checks for home_fsck. User that sets it to 0 assume no forced fsck, ever, while '1' results in fsck -p

Still, just few lines later, same /etc/event.d/rcS-late ignore any user settings, and force fsck -y, in case of failure to properly mount /home

Are you (cssu) perfectly sure, that doing so *before* fixed e2fsprogs get included into CSSU? I must admit - in current state, it won't do any harm to booting, as device with umountable /home is unbootable, anyway. So, it won't either help or hurt booting.

But, even unmountable /home can contain salvageable data, important for user. OTOH, stealthy fsck -y'ing it with segfaulting e2fsprogs on board leave filesystem in unsalvageable mess (unless user instantly boot into things like rescueOS and use working e2fsprogs from there).

Also - for future plans of making fsck default thing on boot (when fixed e2fsprogs make it's way to cssu-t) - it would be good, if /etc/event.d/rcS-late would respect user preferences re fsck'ing even in case of unmountable /home. In case of doubt, it may be good to add another line for /etc/default/mount-opts, something like:
... that would control the (currently) stealthy fsck -y in case of /home mount failure.

/Estel

// Edit

For concerned ones - editing out whole "if to fi"" meant for that fsck -y temporary fixes it, of course.

// Edit 2

Well, there is a (not uncommon) case, where it can turn perfectly fixable (to bootable state) filesystem into total, unusable mess. Ironically, I had such possible situation few days ago.

It's situation when filesystem refuses to mount only because checksum errors - in this case, user can run fsck manually, allow it to fix checksum errors, then answer 'no' for all other "fixing" attempts. In most cases, system will be perfectly bootable, afterwards.

Now, stealthy fsck -y'ing it also fixes checksum errors, but then, makes filesystem FUBAR by attempting other fixes and e2fsprogs segfaulting in the middle.

Good enough reason for hotfix?

Possible bug with CSSU-T update and / or install

This post refers, as well as those pre- and pro-ceding.

A number of users of CSSU-T 8.2 (either in vanilla form or in combo with thumb) report that an upgraded mount-ops failed to install and resides in the folder with the .dpkg ext as is the norm. No notice of failure was given, or if it was, was seen by any of the users. No idea of cause at present.

Consequences of failure seen by those running flopswap, as described in referenced post. Users may want to check what /etc/default/mount-opts they have installed.

Well, that was a failure - I underestimated how much wood a woodchuck would chuck if it could chuck wood (I.E. the gardening took a lot more time than I thought). I'll try again this weekend.

Sorry.

While installing via apt-get, every such situation is presented with question what to do (replace old config with new config from package and append .dpkg-old to old version, etc), so using this way, all such problems are avoided. I have habit of doing so to get an idea what scripts/configs CSSU replaces, to re-merge my custom changes, after installation.

Still, CSSU's prefered method of update is via HAM - I suspect that HAM may have (hardcoded) some stupid idea of what to do with new configs by default?

Using fapman (FAM), default hardcoded action was to use new (from package) config file, so, ironically, FAM users aren't hit by that problems during installation of CSSU [and it was reason why I switched to manually update via (f)apt-get - harder to keep track on what got changed, otherwise].

/Estel