Puppy 4.3.1 -- bug reports and suggestions

Please post any bugs you have found
Message
Author
User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#286 Post by Karl Godt »

mount: /dev/sdb1: can't read superblock
fsck

if fsck can't read the superblock also

# dumpe2fs /dev/hdd1
dumpe2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 235d2897-72ab-4945-b443-30dc0eeeb3e0
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 404000
Block count: 1614524
Reserved block count: 80726
Free blocks: 1039906
Free inodes: 344866
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 394
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8080
Inode blocks per group: 505
Filesystem created: Sat Jan 1 16:15:12 2011
Last mount time: Thu Jan 13 11:57:19 2011
Last write time: Thu Jan 13 11:57:19 2011
Mount count: 3
Maximum mount count: 36
Last checked: Wed Jan 12 13:25:14 2011
Check interval: 15552000 (6 months)
Next check after: Mon Jul 11 13:25:14 2011
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 5cfa5913-9096-4114-836b-7ee7bfaa00bf
Journal backup: inode blocks
Journal size: 128M


Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-395
Block bitmap at 396 (+396), Inode bitmap at 397 (+397)
Inode table at 398-902 (+398)
23777 free blocks, 4927 free inodes, 565 directories
Free blocks: 915-6143, 6225-20479, 20482-24575, 29253, 29258-29265, 29313-29316, 32582-32767
Free inodes: 3154-8080
Group 1: (Blocks 32768-65535)

Backup superblock at 32768, Group descriptors at 32769-32769

which should give an average backup superblock

# fsck --help fsck 1.41.9 (22-Aug-2009)
fsck.ext3: invalid option -- h
Usage: fsck.ext3 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
[-I inode_buffer_blocks] [-P process_inode_size]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] device

Emergency help:
-p Automatic repair (no questions)
-n Make no changes to the filesystem
-y Assume "yes" to all questions
-c Check for bad blocks and add them to the badblock list
-f Force checking even if filesystem is marked clean
-v Be verbose

-b superblock Use alternative superblock

fsck -b 32768 -n -f -v /dev/DEVICE

photor
Posts: 17
Joined: Wed 21 May 2008, 01:51

#287 Post by photor »

What's the default user name and password?
I need this when it is dropped to a terminal login.
:roll:

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

#288 Post by Shep »

SundayForever wrote:Unless I had made some mistake (which I suspect I haven't), Puppy saw that there was another Puppy nearby and mixed things. In the partition in which the folders are located the are an opera and profile folders that were created when I installed Opera in Puppy 4.3. Maybe this confounded the boot process.
If you have been using a previous frugal install and decided to use a 4.3.1 live CD then I expect it would see the older savefile and ask did you wish to upgrade it to 4.3.1.

If you had puppy software on the HDD but outside the savefile then that software is accessible by any puppy. It may be advantageous to install additional browsers this way, so that you need to install only once and it can be used by your other puppies.

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

#289 Post by Shep »

photor wrote:What's the default user name and password?
I need this when it is dropped to a terminal login.
:roll:
Welcome back! 8)

Normally you don't encounter a login. MENU > Utility > Terminal Emulator

Once you get to the terminal, what do you want to do?

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

-grabserver Xlock option and JWM transparency effects!

#290 Post by Argolance »

Hello,
When transparency enabled (/root/.xinitrc => #composite & transparency kcompmgr -n &), Xlock doesn't show both screen saver picture and text that prompts user to give the password. However I noticed this problem disappears if the option -grabserver is deleted in /usr/local/apps/Xlock/AppRunn lines n°34 et n°143 and in /.config/Xlock/xlockscreenparams...
My question: what is the option -grabserver used for and what kind of other problem(s) may this modification possibly cause?

Thank you!
Best regards.

kalisti
Posts: 23
Joined: Wed 11 May 2011, 16:14

#291 Post by kalisti »

I guess this may be a silly thing to write a bug report about, but it bugs me, so here it is..

The clock is reset each time I boot puppy 4.3.1 from my save file. I don't boot often from RAM, and I am not about to get this puppy running the way I want it to all over again just to fix the time.

I go to Menu > Desktop, Set Time Zone > Set to GMT +1 > OK -- time is still off. If I set it by going Menu > Desktop > Set time and date -- the clock only gives the correct time for that session, untill I power off/reboot.

Jasper

#292 Post by Jasper »

Hi,

It may be worth setting your time zone to a city rather than using the GMT method.

It may be a waste of your time, but it worked for me when I tried 4.3.1.

My regards

kalisti
Posts: 23
Joined: Wed 11 May 2011, 16:14

#293 Post by kalisti »

Well, I gave it some time, and it seems to be completely random, no matter which method I use. Sometimes she will give the right time for a few days, and then it keeps setting it back to 5:30 AM for the next few days.

How is the clock updated, does it use a clock in my hardware or from the internet, or..? Maybe it's not puppy's fault but my computer?

Edit: Actually I gave up constantly resetting the time, but I just tried again, and no matter whether I use the GMT or the Country method, it doesn't change the time. Only using 'Set time and date' it will, but for this session only..

I forgot to mention I upgraded my 4.3.1 using rerwin's upgrade. I can't recall if the clock did do it's job properly before upgrading.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#294 Post by Karl Godt »

check

Code: Select all

readlink /etc/localtime
look for rtc-cmos,rtc_core,rtc_lib drivers are loaded using `lsmod | grep rtc` , put them into `bootmanager` if not ( I'll have to do this , too ) .
of course , check battery .
you could try something like

Code: Select all

hwclock --debug --adjust
see man hwclock .

kalisti
Posts: 23
Joined: Wed 11 May 2011, 16:14

#295 Post by kalisti »

Karl, thanks for helping,

Where are these drivers located?

Check battery, don't have laptop.

Time should be GMT +1
Clock is reset to 19:06 even though it was displaying the correct time(I told puppy what the right time was last time I posted, maybe that is why it shows. I'm too hungover to read a man page on a clock I'm afraid.

Can't seem to paste from rxvt selecting and pasting with middle mouse button, so here's an screenshot.

Changing the hwclock time didn't change the time on my desktop BTW.

Why 'so many seconds since 1969'? Is 1969 the year of the first HW clock?
Attachments
screen.jpg
Screen rxvt
(51.65 KiB) Downloaded 546 times

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#296 Post by Karl Godt »

Oops : Puppy kernels are configured with rtc inside :

Code: Select all

grep -n -i rtc /mnt/hdb5/etc/modules/DOTconfig-K2.6.30.5-01SEPT09-TICKLESS-SMP
240:CONFIG_HPET_EMULATE_RTC=y
1939:CONFIG_RTC=y
2757:CONFIG_SND_RTCTIMER=m
2758:CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
3194:# CONFIG_RTC_CLASS is not set

I had much more drivers enabled as usual puppies in my kernel configurations and applying the Standard-431.config into `make menuconfig` revealed :
< > Real Time Clock --->
which normally means : ""# CONFIG_RTC is not set""

So there is not much in
find /sys -name "*rtc*"
/sys/devices/virtual/misc/rtc
/sys/class/misc/rtc
or
modprobe -l | grep -i rtc
but

Code: Select all

 file /proc/driver/rtc
/proc/driver/rtc: empty

Code: Select all

cat !$
cat /proc/driver/rtc
rtc_time : 10:11:19
rtc_date : 2011-06-13
rtc_epoch : 1900
alarm : **:**:**
DST_enable : no
BCD : yes
24hr : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 0
batt_status : okay

I am running the 2.6.31.14 IDE kernel today and it is the same about "rtc"

And this is from the kernel source documentation rtc.txt :
All PCs (even Alpha machines) have a Real Time Clock built into them.
Usually they are built into the chipset of the computer, but some may
actually have a Motorola MC146818 (or clone) on the board. This is the
clock that keeps the date and time while your computer is turned off.

ACPI has standardized that MC146818 functionality, and extended it in
a few ways (enabling longer alarm periods, and wake-from-hibernate).
That functionality is NOT exposed in the old driver.

However it can also be used to generate signals from a slow 2Hz to a
relatively fast 8192Hz, in increments of powers of two. These signals
are reported by interrupt number 8. (Oh! So *that* is what IRQ 8 is
for...) It can also function as a 24hr alarm, raising IRQ 8 when the
alarm goes off. The alarm can also be programmed to only check any
subset of the three programmable values, meaning that it could be set to
ring on the 30th second of the 30th minute of every hour, for example.
The clock can also be set to generate an interrupt upon every clock
update, thus generating a 1Hz signal.

The interrupts are reported via /dev/rtc (major 10, minor 135, read only
character device) in the form of an unsigned long. The low byte contains
the type of interrupt (update-done, alarm-rang, or periodic) that was
raised, and the remaining bytes contain the number of interrupts since
the last read. Status information is reported through the pseudo-file
/proc/driver/rtc if the /proc filesystem was enabled. The driver has
built in locking so that only one process is allowed to have the /dev/rtc
interface open at a time.
For the +-1 GMT confusion there is written some in the 5series projects threads also ; but /usr/sbin/timezone-set contains code to try to translate '-' to '+' and reverse for GMT but maybe grep sometimes likes +- escaped and sometimes not or there is missing a !not in the if-statement .

Code: Select all

89,90c89,90
< 
< if [ "`echo -n "$ZONERETVAL" | grep 'GMT' | grep '\+'`" = "" ];then
---
> 
> if [ "`echo -n "$ZONERETVAL" | grep 'GMT' | grep '+'`" != "" ];then
The second file would be /usr/sbin/set_hwclock_type for the content of /etc/clock (localtime<>utc) .

And I meant the button-cell of 3V on the board inside the tower .

And for the year 1970 thingy try to read wikipedia about computing languages A and B .

kalisti
Posts: 23
Joined: Wed 11 May 2011, 16:14

#297 Post by kalisti »

Ok, well, thanks. I tried those things, aside from the coding you posted at the end, here's the output again in a screenshot.

Another thing I did was follow the help in psync, which reads
FIRST:
If you have not already done so via Menu/Desktop/Set Timezone, then you must first set your Timezone geographically.
i.e Europe/London - Europe/Madrid etc to match your nearest location. Scroll through the Puppy menu Timezone list to set it to nearest location.
NOT by GMT offset. This is because the built in commands use the locale settings.
You must now reboot to make the setting active. This is before running Psync
Locale zoneinfo contains information on offset plus DST etc. (Daylight Savings Time) allowing Psync to set time correctly according to your location.
Setting the timezone this way also allows the desktop clock to auto change for DST.
GMT file is just a numerical offset etc. which means Psync may ignore it and set your clock according to server location. Which may be set to UTC and cause your clock to be set up to 2 hours off.
Which, once again, worked for that session only.
Attachments
screen2.jpg
(29.63 KiB) Downloaded 1054 times

kalisti
Posts: 23
Joined: Wed 11 May 2011, 16:14

#298 Post by kalisti »

Basically what is happening is that Puppy, or Computer, or whoever, is not keeping time when turned off. If I power off at 5:30am, and power on at 6PM, it will read 5:31am.

Another thing, small, but buggy, is the 'show desktop' icon on the tray. I have to click twice when windows are open on screen. First time is simply ignore.

I can deal with the time being messy and having to click twice on the desktop icon. But, as I see it, they're bugs, and this is a bug thread.

User avatar
rjbrewer
Posts: 4405
Joined: Tue 22 Jan 2008, 21:41
Location: merriam, kansas

#299 Post by rjbrewer »

kalisti wrote:Basically what is happening is that Puppy, or Computer, or whoever, is not keeping time when turned off. If I power off at 5:30am, and power on at 6PM, it will read 5:31am.

Another thing, small, but buggy, is the 'show desktop' icon on the tray. I have to click twice when windows are open on screen. First time is simply ignore.

I can deal with the time being messy and having to click twice on the desktop icon. But, as I see it, they're bugs, and this is a bug thread.
Motherboards (laptop or desktop) have a button cell battery that
the bios (cmos) needs for changing settings and keeping track of
time, etc.
A worn out battery gives a time from years ago on each reboot.

Inspiron 700m, Pent.M 1.6Ghz, 1Gb ram.
Msi Wind U100, N270 1.6>2.0Ghz, 1.5Gb ram.
Eeepc 8g 701, 900Mhz, 1Gb ram.
Full installs

Jasper

#300 Post by Jasper »

Hi all,

Does 4.3.1 have Psync (possibly in the Desktop menu) and if not is there a pet that would work?

My regards

kalisti
Posts: 23
Joined: Wed 11 May 2011, 16:14

#301 Post by kalisti »

rjbrewer: Grand. Didn't know that. I'll assume that's the case.

Jasper: Yep, it's in menu > Desktop > Psync Time Server Synchroniser

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#302 Post by greengeek »

Kalisti - I think you have a flat (dead) battery on the motherboard of your computer. (even though it is not a laptop it still has a battery that supplies power to the system clock.

Try to find out what motherboard you have and we can help you locate the battery. Usually the battery looks like a silver coin, but sometimes it is a black rectangular box that looks like an integrated circuit chip.

Also, the other issues you mentioned sound like maybe your CD burning may have created an error in the code on the CD? Possibly try reburning puppy 4.3.1 to a new CD (choose the slowest burn speed) and see if you still have the same issues.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#303 Post by greengeek »

Actually, now that I look at your posts again Kalisti, I think your RTC battery is probably good, but the circuit that the battery supplies power to is not continuing to count up after the power is turned off.

If it shows 5.30 when you turn the PC off, and 5.31 when you turn it back on, then it has remembered the actual time (so battery must be good enough to remember the turn off time) but has not incremented the time any further (so the clock counting circuit must be bad).

Never actually seen something like that before...but I would consider swapping out the motherboard unless you are convinced that this problem only occurs with Puppy, and not any other operating system too.

Post Reply