ext4 corrupted superblock on USB-stick

I have built EasyOS version 2.2.11 and wrote it to a USB-stick. Booted it on my HP desktop, no problem. Then booted it on my Acer Aspire1 laptop, no problem. Rebooted on the laptop, and Easy could not find the working partition.

There were the little dots as it searched for the boot-partition and working-partition, then it timed out and booted up running in RAM. It is good to have this fallback, as at least there is a running desktop and I can examine what went wrong.

I saw right off, only "sda1" icon was on the screen, the boot-partition. "sda2", the working-partition, was not there. I ran "probepart" in a terminal, and /dev/sda2 was listed as having a filesystem of "none".

Running "fsck.ext4 /dev/sda2" returned a message "Bad magic number in super-block". In other words, the superblock is corrupted.

So how did that happen? USB-stick failing?

Fortunately, ext4 maintains backup superblocks. Running "mkfs.ext4 -n /dev/sda2" will list them. one of them is "32768". So, I ran this:

# fsck.ext4 -y -b 32768 /dev/sda2

...the "-y" means say yes to all questions. The "-p", automatic repair, did not work.

That did the trick, rebooted a few times, no problem.

I am wondering whether I should put code into the initrd to attempt this automatic recovery of a corrupted superblock. Hmmm, don't know. This is the first time that I have encountered this particular failure, and perhaps it is a warning of a deeper problem, like the USB-stick on the way out. Perhaps just attempting an automatic repair, if it succeeds, will not be sufficient warning to the user that perhaps the USB-stick should be retired. Or, there could be bad RAM, in which case corruption could be happening all over the place. 

Tags: easy

HelpSurfer internal help viewer crashes

Easy has HelpSurfer, executable /usr/bin/surfer, which is a tiny HTML v4 viewer, for viewing local help pages.

Fine, except that it crashes under a certain circumstance. Instability of HelpSurfer has been an ongoing problem, but this latest one is probably the last straw.

The menu "Help -> Help Links", will bring up /usr/share/doc/easy/help.htm. If you then click on the "Welcome" link, HelpSurfer crashes. However, it can be brought up OK directly:

# surfer /usr/share/doc/easy/welcome.htm

The HTML in 'welcome.htm' is very simple, so it is mighty peculiar that HelpSurfer crashes when coming via the hyperlink. I did test taking bits out of welcome.htm and then the hyperlink worked, no crash. But there is no apparent logic to what is causing the crash.

HelpSurfer is currently at version 0.5, see blog post in 2017:

https://bkhome.org/news/201708/helpsurfer-03.html

There was a lot of help from forum member SFR to improve HelpSurfer back in 2017, see this forum thread:

http://murga-linux.com/puppy/viewtopic.php?t=111186

I liked the mods we did to it. Any "http://" or "https://" hyperlinks brought up the full web browser (SeaMonkey). Hyperlinks with "exec:" prefix launched local applications.

So, stuck. maybe should take another look at Netsurf. 

EDIT 2020-02-19:
I have implemented a workaround, that avoids the crash. HelpSurfer is now version 0.6, with a patch to run a hyperlink prefixed with "file://" in the default browser (SeaMonkey). Here is the patch to apply to HelpSurfer 0.5:

diff -Naur helpsurfer-0.5/src/ghtml-gtkhtml.c helpsurfer-0.6/src/ghtml-gtkhtml.c
--- helpsurfer-0.5/src/ghtml-gtkhtml.c	2017-08-07 18:39:56.000000000 +0800
+++ helpsurfer-0.6/src/ghtml-gtkhtml.c	2020-02-19 20:02:06.452973984 +0800
@@ -558,6 +558,8 @@
 		return g_strdup(url);
 	if(strncmp("https://", url, 8) == 0)
 		return g_strdup(url);
+	if(strncmp("file://", url, 7) == 0) /*BK v0.6*/
+		return g_strdup(url);
 	if(strncmp("mailto:", url, 7) == 0)
 		return g_strdup(url);
 	//BK highly non-standard!...
@@ -1073,7 +1075,7 @@
 	fprintf(stderr, "DEBUG: %s(\"%s\") base=\"%s\" => \"%s\"\n", __func__,
 			url, _ghtml_get_base(ghtml), link);
 #endif
-	if (g_regex_match_simple("^http://|^https://|^ftp://", link, 0, 0))
+	if (g_regex_match_simple("^http://|^https://|^ftp://|^file://", link, 0, 0)) /*BK v0.6 add file://*/
 	{
 		syscmd = g_strdup_printf("%s '%s' %s", "defaultbrowser", link, "&");
 		system(syscmd);

And here is the source:

http://distro.ibiblio.org/easyos/source/alphabetical/h/ 

HelpSurfer has three dependencies, gnet, libSystem and libgtkhtml. I have recompiled the first two. These are my notes:

gnet 2.0.8
d/l: http://distro.ibiblio.org/easyos/source/oe/pyro/gnet-2.0.8.tar.bz2
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu --disable-network-tests --enable-debug=no
edited examples/Makefile and examples/xmlrpc/Makefile, appended:
LIBS = -lresolv -lnsl -lgobject-2.0 -lglib-2.0
# make
# new2dir make install

libSystem 0.1.6-patched1
d/l: http://distro.ibiblio.org/easyos/source/oe/pyro/libSystem-0.1.6-patched1.tar.bz2
src/Makefile, commented out this line:
#CPPFLAGS= -D WITH_SSL
# make
# new2dir make install DESTDIR=/

helpsurfer 0.6
# make
# new2dir make install

I have changed the hyperlinks, for example in help.htm:

<td valign="top"><b><a href="/usr/share/doc/easy/welcome.htm">${MSGg3}</a></b>
to:
<td valign="top"><b><a href="file:///usr/share/doc/easy/welcome.htm">${MSGg3}</a></b>

...probably not ideal, would prefer to open welcome.htm in the local HTML viewer.  

Tags: easy

German translation for EasyOS updated

Lutz (L18L in the Puppy Forum) maintains the German langpacks for Puppy and EasyOS, as well as MoManager (the GUI utility for creating translations).

Lutz has provided updated translations, and I have created 'langpack_de-200219.pet', not yet uploaded. This will be used in the next German build of EasyOS, perhaps version 2.2.11.

Lutz has also provided extra translations for EasyPup. These are .mo files for scripts that are different from EasyOS, or not in EasyOS. Lutz has narrowed-down the list of scripts that need .mo files for EasyPup, see my edit dated 2020-02-19 in this blog post:

https://bkhome.org/news/202002/international-translation-of-easypup.html

...see the red text.

For EasyPup development more generally, this is also a good read:

https://bkhome.org/news/202002/files-that-transform-easyos-to-easypup.html 

The EasyPup .mo files are not in a PET, they are in WoofQ, in the puppy/rootfs-skeleton folder. When EasyPup is built, that folder will over-write the EasyOS build, transforming 'easy.sfs' to 'puppy.sfs'. 

Tags: easy

French translation updated

Esmourguit has been extremely helpful, not just with translating to French, but also fixing scripts that are not fully gettext'ed, or not at all.

I have worked through everything that he has sent me, and created a new "langpack" PET, 'langpack_fr-20200218.pet'. I will upload it soon. This is for EasyOS, and will be in the next release, probably version 2.2.11, coming very soon.

There are also some extra translations for EasyPup. These are not in a PET, instead are in the puppy/rootfs-skeleton folder in WoofQ. 

Tags: easy

Setting system time in initrd fixed

When the Linux kernel boots, the default date is January 1, 1970, which is not so good in the initrd as there are various file operations performed. If for example, a file is created or edited, after the switch_root to the main filesystem, where the date and time are set correctly, those files will have that old modify date, which could cause trouble. Also, the initrd may modify the working-partition size, or do a filesystem check, and it will have that very old date.

It is much better if the correct date and time is known in the initrd. Which means that the system time has to be set from the hardware clock.

I made an interesting discovery. The /dev nodes in the intrd are static, there is no devtmpfs mounted on /dev, which is a very "old school" way to do things. There is /dev/rtc (major, minor=10,135), and what I have discovered is that it is no longer valid. It is for old kernels prior to 2.6. What we need now is /dev/rtc0 (major,minor=253,0), with /dev/rtc a symlink to it.

Also, I have compiled the 5.4.20 kernel with all of the "rtc*.ko" drivers builtin, so the appropriate one will be working in the initrd. I did check that none of them need firmware. Though, it may be that modern PCs do not load any rtc*.ko driver, as the RTC functionality is builtin to the SoC -- that is the case with my Apollo Lake SoC in my laptop.

Now, the 'init' script in the initrd in EasyOS has been modified:

###set date and time###
#could read .session/etc/clock and run hwclock, but for now this probably good enough (refer: rc.shutdown)...
#200218 fixed /dev/rtc0 and symlink /dev/rtc for modern kernels, replacing old /dev/rtc
#       also have rtc drivers builtin to kernel >=5.4.20. can now use hwclock...
CLKflg=1
if [ -e /sys/class/rtc/rtc0 ];then
 if [ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/etc/clock ];then
. /mnt/${WKG_DEV}/${WKG_DIR}.session/etc/clock #has HWCLOCKTIME=localtime or utc
  case "$HWCLOCKTIME" in
   localtime) hwclock -s --localtime -f /dev/rtc0; CLKflg=$? ;;
   utc)       hwclock -s -u -f /dev/rtc0; CLKflg=$? ;;
  esac
 else #first bootup, assume hw clock is locatime...
  hwclock -s --localtime -f /dev/rtc0
 fi
fi
if [ $CLKflg -ne 0 ];then
 if [ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/root/.var/local/shutdown_date_saved ];then
  date -s "`cat /mnt/${WKG_DEV}/${WKG_DIR}.session/root/.var/local/shutdown_date_saved`" > /dev/null
 fi
fi 

...dark-red is the new code.

EasyOS was not too bad anyway, before doing this, as /etc/rc.d/rc.shutdown saves the date in /var/local/shutdown_date_saved, so the system clock would have got set to the date that last shutdown the computer. Now we are being a bit more accurate. 

Of course, at the very first bootup, say from a USB-stick, /var/local/shutdown_date_saved will not exist, so the date will be January 7, 1970 if hwclock is not working. Various operations, such as resizing the working-partition to fill the drive and file /etc/rc.d/PUPSTATE, will have that old date. 

Tags: easy

SeaMonkey 2.53.1beta1 compiled

Here are some notes for those who are into compiling SeaMonkey.

I downloaded 2.53.1beta1 from here:

http://www.seamonkey-project.org/releases/2.53.1b1

It requires 'rust' and 'cargo', that can be installed via PETget (PPM) -- I am running EasyOS 2.2.10, Debian-based.

This is my 'mozconfig' file:

#mk_add_options MOZ_MAKE_FLAGS='-j3'
mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite
ac_add_options --enable-system-hunspell
ac_add_options --prefix=/usr
ac_add_options --host=x86_64-pc-linux-gnu
ac_add_options --disable-dbus
ac_add_options --disable-accessibility
ac_add_options --with-system-bz2
ac_add_options --disable-updater
ac_add_options --disable-parental-controls
ac_add_options --disable-system-sqlite
ac_add_options --enable-system-cairo
ac_add_options --enable-strip
ac_add_options --without-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --disable-tests
#NOTWORKac_add_options --with-default-mozilla-five-home=/usr/lib/seamonkey
ac_add_options --enable-default-toolkit=cairo-gtk3
ac_add_options --disable-crashreporter
ac_add_options --with-system-libvpx
#ac_add_options --enable-gio
ac_add_options --disable-necko-wifi
#ac_add_options --disable-gconf
ac_add_options --without-system-nspr
ac_add_options --without-system-nss
#ac_add_options --enable-ldap
ac_add_options --with-system-icu
ac_add_options --disable-pulseaudio
ac_add_options --enable-alsa
ac_add_options --enable-system-ffi
#NOTWORKac_add_options --disable-gnomeui
ac_add_options --with-pthreads
ac_add_options --enable-system-pixman
ac_add_options --disable-debug
ac_add_options --without-system-libevent
ac_add_options --enable-optimize='-O2'
ac_add_options --enable-cpp-rtti
#NOTWORKac_add_options --disable-rust
ac_add_options --enable-js-shell
ac_add_options --enable-elf-hack
ac_add_options --enable-ffmpeg
ac_add_options --disable-stylo

..."--disable-stylo" as stylo requires LLVM/clang. Stylo is some kind of faster CSS thing. Note, despite having system nspr and nss libraries, I have not used them, as wary about doing so from past experience. Then:

# export CC=gcc
# export CXX=g++
# export CFLAGS+=' -fno-delete-null-pointer-checks'
# export CXXFLAGS+=' -fno-delete-null-pointer-checks'
# make -f client.mk
# make -f client.mk install

Yep works, using it right now.

There is an international language tarball, 'seamonkey-2.53.1b1.source-l10n.tar.xz'. To make use of that, I would need to convert each language into an .xpi file, and I don't know how to do that. After SeaMonkey is released, someone does that and makes the individual language .xpi files available for download. Wish that I knew how to do it myself. 

Tags: easy

SFS collections are not good

Over the last six months, a couple of people commented that their SFS files did not work in EasyOS. The same will hold for EasyPup.

These people have a collection of SFSs, that they can use in different puppies. However, I need to point out that such collections are a very bad idea. Not entirely, they should only be used in the same Puppy derivative for which they were created.

There is of course the problem of library mis-match. An SFS designed to run in "archpup", is then tried to be used in "bionicpup", or whatever, there is a very real likelihood of the libraries in the underlying 'puppy.sfs' being inappropriate versions. Like, for example libjpeg, or libssl -- typical libraries that may have API changes with different versions.

But there is another very fundamental problem. Many of the puppies have /lib64 and /usr/lib64 as symlinks to /lib and /usr/lib, or to /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu. Also, the Debian and Ubuntu-based pups may have /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu as symlinks to "./".

EasyOS is currently Debian-based, and follows the library paths exactly. /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu are actual folders, not symlinks. /lib64 and /usr/lib64 are symlinks to /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu.

If you try to use a SFS that has, for example, /lib/x86_64-linux-gnu a symlink to "./", typical of the Debian and Ubuntu-based pups (but not all, it is settable in woof-CE when building the pup), or another example, an Slackware-based SFS that has /lib64 and /usr/lib64 as either symlinks to "./" or are actual folders, as a layer on top of 'easy.sfs' will totally break Easy.

You must use SFSs that are designed to run in EasyOS, Debian-based series (2.x). Ditto for EasyPup. 

Tags: easy