Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
On Tue, Dec 20, 2005 at 01:59:55PM -0600, Steve Greenland wrote: On 19-Dec-05, 09:21 (CST), Theodore Ts'o [EMAIL PROTECTED] wrote: Specifically, what I would propose is /etc/localtime.conf contain something like US/Eastern, and let /etc/zoneinfo be a copy of the file /usr/share/zoneinfo/`cat /etc/zoneinfo`. Um, /usr/share/zoneinfo/`cat /etc/localtime.conf`, right? Yes, of course. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
On 19-Dec-05, 09:21 (CST), Theodore Ts'o [EMAIL PROTECTED] wrote: Specifically, what I would propose is /etc/localtime.conf contain something like US/Eastern, and let /etc/zoneinfo be a copy of the file /usr/share/zoneinfo/`cat /etc/zoneinfo`. Um, /usr/share/zoneinfo/`cat /etc/localtime.conf`, right? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
On Sun, Dec 18, 2005 at 10:37:06PM -0500, Anthony DeRobertis wrote: Theodore Ts'o wrote: (for example if the US Congress changes the definition of daylight savings time), That should be when, not if, unfortunately. AFAIK, they've already done it. On my system, /bin, /etc, /lib, and /sbin together are 156M; /usr/share/zoneinfo is 5.5M. So, while a 3.5% increase in the size of / would fix it, it seems rather wasteful for the need of ~1K. Maybe just copy (in, e.g., postinst) the one file needed to /lib/zoneinfo, and create the symlink to that. It really shouldn't be in /etc; binary files do not belong there. I was only proposing to copy the one file. I don't think it's quite so important to put it in /lib and then put a symlink from /etc/localtime to /lib/localtime. There _are_ other binary files in /etc. Just do: find /etc -type f | xargs file | grep data and you'll find files such as /etc/apt/trusted.gpg /etc/ld.so.cache /etc/prelink.cache ...as well as image files, PPD files, pcmcia data files, and many others. Specifically, what I would propose is /etc/localtime.conf contain something like US/Eastern, and let /etc/zoneinfo be a copy of the file /usr/share/zoneinfo/`cat /etc/zoneinfo`. Does anyone have any objections with this proposal? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
ma, 2005-12-19 kello 10:21 -0500, Theodore Ts'o kirjoitti: Specifically, what I would propose is /etc/localtime.conf contain something like US/Eastern, and let /etc/zoneinfo be a copy of the file /usr/share/zoneinfo/`cat /etc/zoneinfo`. Does anyone have any objections with this proposal? I think it sounds quite acceptable. The (compiled) time zone data files are pretty small (there's just a lot of them, and the each use a disk block). -- Yet another quit message no-one will ever comment on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
Theodore Ts'o wrote: (for example if the US Congress changes the definition of daylight savings time), That should be when, not if, unfortunately. AFAIK, they've already done it. On my system, /bin, /etc, /lib, and /sbin together are 156M; /usr/share/zoneinfo is 5.5M. So, while a 3.5% increase in the size of / would fix it, it seems rather wasteful for the need of ~1K. Maybe just copy (in, e.g., postinst) the one file needed to /lib/zoneinfo, and create the symlink to that. It really shouldn't be in /etc; binary files do not belong there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
Fixing this the right way will require changing when Debian boot scripts run hwclock (as the first very thing), and will require making changes to util-linux, the installer (so that /etc/zoneinfo is not a symlink, and so that the information about what the local timezone is stored somewhere else other than the symlink), and libc (so that /etc/zoneinfo can be refreshed as part of the postinstall package). This is messy, but it's what Red Hat does, and fixes the bug reported below. It really is bad that the system clock is wrong for a large part of the initial boot process (until possibly after /etc/rcS.d/S50hwclock.sh is run, if /usr is a separately mounted filesystem). I can't see another way of fixing this, though; before I start lobbying the maintainers of the above-mentioned packages, does anyone have any suggestions about a better way to deal with this issue? Thanks, regards, - Ted ---BeginMessage--- On Fri, Dec 16, 2005 at 04:16:42PM -0800, Andrew Sackville-West wrote: Package: e2fsprogs Version: 1.39 This is specifically version 1.39 WIP (10-Dec-2005) /dev/hda3: Superblock last mount time is in the future /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY Are you using your system with hardware time set to some non-GMT local time zone? (i.e. /etc/defaults/rcS has UTC=no) I didn't test for this case, and so I didn't realize a problem --- the timezone offset isn't corrected at the time when fsck is run (at least not on Debian systems) and e2fsck depends on the time being correct. In the past, we more or less got by with the time being wrong (for systems who use a non-GMT hardware clock); it meant that the last checked time was set incorrectly, and inode delete times would also be set correctly, but the failures were more or less harmless. Unfortunately, I added this test in order to address problems caused by the last mount time not being correct (see Debian bug #327580) only to realize this was a much larger issue. This isn't an issue on Red Hat systems, because /etc/localtime is not a symlink (into possibly a not-yet mounted /usr filesystem), and they make sure the system clock is correct *before* running fsck on the root filesystem. I personally keep my system clock on UTC, and so this problem doesn't show up. I think you can make the problem go away by making /etc/localtime contain a copy of what it is currently symlinked to in /usr/share/zoneinfo/timezone, and renaming /etc/rcS.d/S22hwclockfirst.sh to /etc/rcS.d/S09hwclockfirst.sh. This is obviously not the proper fix; since among other things if the localtime file needs to get updated (for example if the US Congress changes the definition of daylight savings time), we need a way to make sure /etc/localtime gets updated when the package gets updated. But I believe if you were to apply the above as a workaround, it should address your problem. Fixing this in the more global sense will require making changes in the overall Debian boot setup, and I'm going to have to take this up on debain-devel and consult other Debian developers. Regards, - Ted ---End Message---
