February 2009 - Arch-releng - lists.archlinux.org

[arch-releng] Dates, times, timezones.
by Dieter Plaetinck 27 Feb '09

27 Feb '09

Hi all, Some people have reported issues with the way we do time/date/timezone stuff. most of them are already fixed but we still have 2 open. (http://bugs.archlinux.org/task/12933, http://bugs.archlinux.org/task/13196) One of the issues is cosmetical, the other functional. I would like to implement this correctly so now is a very good time to all think about how time _should_ be handled, and since I'm not an expert in this, I need your advice. A good starting point would be Gerhard's excellent comment from http://bugs.archlinux.org/task/12933#comment40281 I'll quote it here and add my thoughts below. =========== QUOTE Gerhard ================= +1 for using a own dialog for timezones. We should avoid each tool which changes the time during any selection - until we wan't to change it. tzselect for ex. changes the time when selecting a timezone (this is bad cause the hwclock and system time is mostly correct after a boot). Same when copying timezone files to /etc/localtime. But when one only set and export TZ with his timezone then the system time is kept and only displayed with correct timezone value. 2009.02 time/date setting (in installer) is IMHO better than 2008.06 (tzselect, "hardcoded" timezone was CDT IMHO), but not optimal. In 2009.02 timezone was UTC after boot which is IMHO optimal for all installations. What times have we after booting the live/install ISO? 1) hwclock a) BIOS datetime is correct and set to localtime, or b) BIOS datetime is correct and set to UTC, or c) BIOS datetime is not correct 2) system time (this is interpreted with the timezone, first with UTC) a) date shows false time when 1.a is given (localtime vs. UTC). Could be corrected when setting/exporting TZ with correct value, but we should avoid using tzselect or copy a timezone to /etc/localtime cause this *changes* the time value! but we need only a different interpretation) b) date shows correct time when 1.b is given (hwlock UTC vs. date with UTC). When a user would change UTC to his local timezone then also the system time value (not the hwclock) must be changed. Here this is could be done ex. with tzselect tool or copying timezone file to /etc/localtime, but better do this in a own step. c) date shows false time when 1.c is given (all clocks wrong). For this (and as a fallback) we should have a step where a user should be able to set the timezone and value by hand/dialog, with this values we modify system time(date) and BIOS clock(hwclock). So what's our steps for timesetting? Ideally we never would have any problem when users would set HWCLOCK and TIMEZONE in bootloader as boot parameters ;-) But if a user boot boot the cd without these in Peking, Chicago or Brussel we must ask him some questions: a) Is your hardware clock set to localtime or UTC? b) Based on this answer whe should present the output of date or date -u c) Ask him: Is this the correct time displayed also on your watch? (timezone is nor relevant this step!) Based on his answer time value must probably set by hand/dialog and corrected with date -s "value". d) Next question is: Where do you live, what's your timezone? Based on the answer we should set/export TZ and display the time again with date e) Assumed that last step shows the correct local time for the user (datetime value AND timezone) we should ask: Do you want keep your hardwareclock(BIOS) in localtime or UTC? What we have this moment? A correct system time based on users selections. We have also TIMEZONE var and HARDWARECLOCK for the generated rc.conf later. As a last step we now should set the hwclock/BIOS according to the system time (either as localtime or UTC, based on HARDWARECLOCK). During system config we must also copy the according timezone file to /mnt/etc/localtime early (before any chroot'ing), but we should NOT do this in the live cd system! IMHO this could be the way we should handle time setting things during installer/aif. ========== END QUOTE ======== > During system config we must also copy the according timezone file > to /mnt/etc/localtime early (before any chroot'ing), but we should > NOT do this in the live cd system! Why before any chrooting? what do you mean with "we should NOT do this in the live cd system!" ? I mean, the installer runs in the liveCD, so from the livecd we have to copy /etc/localtime to /mnt/etc/localtime, no? Some thoughts: 2a) If a user would happen to live in the UK (GMT timezone, eg UTC+0) then for him UTC === localtime right? so by "coincidence" he would have the correct time. Is there any functional difference between a hardware clock running "as UTC" or a hardware clock running "in localtime for the UTC/GMT timezone" ? I think not but I'm not sure. Similarly 2b) On the installCD we use UTC by default, so this means the time will _only_ be correct if the users clock is in UTC _and_ he lives in a UTC/GMT timezone, no? I think it would be really interesting to compare your ideas to what tpowa has written: http://projects.archlinux.org/?p=archboot.git;a=blob;f=usr/share/archboot/t… About Gerhard's solution: if the clock is UTC, shouldn't we first ask for the timezone and then ask for the date? because the time we will present in 2b) is probably incorrect if we don't know the timezone yet. Shouldn't we do a->d->b->c->e ? About tpowa's stuff: what's line 47-49 for? in dohwclock, why don't you add --noadjtime ? Note that I have sort of ported tpowa's tz script into aif ( see http://github.com/Dieterbe/aif/commit/5cd407fbb9b44b476ae7c9d460594322f465c… ) but of course it will probably need to change depending on this discussion. Dieter

3 3

[arch-releng] /usr/bin/km, loadkeys and dumpkeys
by Dieter Plaetinck 26 Feb '09

26 Feb '09

While figuring out http://bugs.archlinux.org/task/13374, I was inspecting /usr/bin/km, it does "loadkeys" from the kbd package to load the keyboard table. But unfortunately it looks to me you can't just get the name of that table afterwards (eg with dumpkeys), you can only get the table itself from the kernel. I am correct or am I missing something? How will we fix this, let km export an environment variable which we pull in the installer? Who maintains the "km" tool? it is not included in any package. Dieter

3 4

[arch-releng] size of the "display" (framebuffer?) on our images
by Dieter Plaetinck 20 Feb '09

20 Feb '09

Hi all, I find that the size of our "display" (this is the framebuffer resolution, right?) is quite small. Most distro's that I know of have a bigger size/resolution when booting their isos. Is there a reason we keep it so small? compatibility with older systems? If we could make it a bit bigger, that would be really useful, See for example http://users.edpnet.be/dieter/aif/aif-alpha_0.6-disks-overview-dia.png I just have sometimes many things to show which doesn't fit in the screen anymore :) Dieter

7 11

[arch-releng] Fw: [arch-dev-public] Arch Linux release in the press
by Dieter Plaetinck 19 Feb '09

19 Feb '09

Cool stuff. Aren't we the first distro to officially release images with 2.6.28/ext4 et al ? Dieter Begin forwarded message: Date: Tue, 17 Feb 2009 13:50:44 +0100 From: Andrea Scarpino <andrea(a)archlinux.org> To: Public mailing list for ArchLinux development <arch-dev-public(a)archlinux.org> Subject: Re: [arch-dev-public] Arch Linux release in the press 2009/2/17 Thomas Bächler <thomas(a)archlinux.org>: > I just noticed by accident that our release announcement made it to > heise open. This is the first time that Arch has been mentioned on > heise at all, so I am a bit psyched. Anyway, for those who know > German, read here: > http://www.heise.de/open/Arch-Linux-2009-02--/news/meldung/132693 > > It's not much more than a translation of the release announcement, but > should still attract some more German users. > > I'd like to use this thread to collect more press coverage of our > release, so if you see anything, post it here (or reply on > arch-general). Also a popular Italian site[1] have announced the our ISO is released :) nice [1] http://www.ossblog.it/post/4672/rilasciata-archlinux-20092 -- Andrea `BaSh` Scarpino Arch Linux Developer

8 20

[arch-releng] website improvements
by Dieter Plaetinck 19 Feb '09

19 Feb '09

Hi all, some releng-related ideas for improvements of the website, loosely based on the suggestions from someone on the forums ( http://bbs.archlinux.org/viewtopic.php?pid=497610#p497610 ) @ http://www.archlinux.org/download/ I would create a new section above "Buy a CD" called "Latest release" or something. This section would contain: * the last release version + date of release. * release notes of that specific release. * a tiny note that you don't need to reinstall if you want to upgrade your system. * links to the bugtracker, mailinglist your thoughts?

5 8

[arch-releng] RC2 ISOs and final release
by Aaron Griffin 17 Feb '09

17 Feb '09

The new RC2 ISOs are up. http://dev.archlinux.org/~aaron/archiso/ Roadmap: http://bugs.archlinux.org/roadmap/proj6 Bugs fixed in RC1 and RC2: http://bugs.archlinux.org/task/12896 http://bugs.archlinux.org/task/12949 http://bugs.archlinux.org/task/13068 http://bugs.archlinux.org/task/13070 http://bugs.archlinux.org/task/13140 http://bugs.archlinux.org/task/13101 http://bugs.archlinux.org/task/13102 http://bugs.archlinux.org/task/13057 http://bugs.archlinux.org/task/13038 (I think that's it) Please test the above bugs, and anything else on the bug tracker. This should be pretty much the final ISO, so I'm just looking for some confirmations on the above bugs. Known issues: grub "Release notes" is empty (whoops, blame me!)

12 47

[arch-releng] AIF: a call for testing
by Dieter Plaetinck 17 Feb '09

17 Feb '09

Hello beloved release fanatics, you may have already heard of aif. (Arch Linux Installation Framework[1]). A project of mine that originally begun to allow me to do automated installations, but soon was extended to contain all things needed to do full "interactive" installations (a la /arch/setup) [2]. It's actually really a framework where all backend code (ui, partitioning, ...) is available as libraries, making it possible to cleanly implement different kinds of installers (automated, interactive etc) (lots of the code in those libraries is actually a refactoring of the code in /arch/setup) It also supports dm_crypt and lvm. It got much interest from the Arch devs, and later they told me they want to use it as the next official installer. That's great :). Now, it would be very good if we could shift to it asap. I'm not saying this to promote my own stuff, rather I think we all agree on the technical advantages (old installer is hard to maintain, it's "spaghetticode", we don't want to maintain 2 installers at the same time, aif is a better longterm solution etc) But, we need to start testing and patching. In it's current state, aif is actually quite usable and most of the time produces installations just as well as /arch/setup does. But there are probably bugs that I'm not aware of yet. I want to get most, if not all of the bugs ironed out before 2.6.29 is out. So that when we start releasing images for the new release, aif does not become the bottleneck. How can you test? Simple: aif will be included on 2009.02. That's a good starting point. However: there are also git packages on aur. I recommend you install aif-experimental-git which contains the latest features and fixes. You can easily install a git package on the installation cd : see http://github.com/Dieterbe/aif/tree/experimental/HOWTO I also have a TODO file, which contains a list of issues (most of them minor) and some thoughts. http://github.com/Dieterbe/aif/tree/experimental/TODO Thanks, Dieter [1]http://bbs.archlinux.org/viewtopic.php?id=58110 [2]http://www.nabble.com/Fifa:-Flexible-Installer-Framework-for-Arch-linux-t…

3 3

[arch-releng] Fw: SI/IEEE, MiB,MB bits (pun intended)
by Dieter Plaetinck 15 Feb '09

15 Feb '09

(Foutrelis didn't see the "reply to all" button :) ) Begin forwarded message: Date: Sun, 15 Feb 2009 02:59:52 +0200 From: Evangelos Foutras <foutrelis(a)gmail.com> To: Dieter Plaetinck <dieter(a)plaetinck.be> Subject: Re: SI/IEEE, MiB,MB bits (pun intended) Dieter Plaetinck wrote: > As far as I understand: > SI prefixes are, and always have been multiples of 10. ( eg > 10^3,10^6) > > But, many people have abused SI prefixes to denominate numbers like > 2^10 (1024), 2^20 etc. > Eg OS vendors and many software developers have used this definition, > while hard disk vendors used the real meaning > > So, along came IEEE to introduce prefixes for these binary multiples, > so that we can use SI prefixes only for what they are > meant (ieee at the same time also definined some more things like > b=bit, B=byte, etc) > That's pretty much my understanding too. > But, if I create in the installer a partition of the size 10.000MiB: > > echo $(((2**20)*10000)) > 10485760000 <-- this is the amount of bytes I expect to see on the > blockdevice. > > fdisk -l says: > 10487232000 bytes > Why is it not the same? > Perhaps rounding takes place? 10487232000 bytes is about 10001.4 MiB, which is pretty close to the 10000 you specified. > Also a df -m (-m is not documented? but it says "1M" blocks) of the > filesystem (ext2) yields 9845M. If 1M means 10^6 then this is wrong > because it would be way too few, and if it means 1MiB than it's also > still wrong. how much space can you loose by formatting a block > device as ext2? Even after setting reserved blocks to 0 (tune2fs -r > 0 /dev/sda3) It still is 9845M. (the amount available is 9823M I believe there is around one percent file system overhead (I don't have any documentation to support my claim though). And probably this is used to store inodes (amongst other information?): [root@archiso ~]# tune2fs -l /dev/sda3 | grep -P '(Inode count)|(Inode size)' Inode count: 640848 Inode size: 256 [root@archiso ~]# echo $((640848*256/2**20)) 156 So, with each inode taking up 256 bytes of space, and a total of 640848 inodes, it adds up to 156 MiB. Add that to what df -m reports (9845 MiB) and you get ~10000 MiB. PS: If someone knows more about this stuff, please do share your knowledge! :3

1 0

[arch-releng] SI/IEEE, MiB,MB bits (pun intended)
by Dieter Plaetinck 15 Feb '09

15 Feb '09

Hi Evangelos/team, I was wondering if you could help me figure out some MiB/MB related things. As far as I understand: SI prefixes are, and always have been multiples of 10. ( eg 10^3,10^6) But, many people have abused SI prefixes to denominate numbers like 2^10 (1024), 2^20 etc. Eg OS vendors and many software developers have used this definition, while hard disk vendors used the real meaning So, along came IEEE to introduce prefixes for these binary multiples, so that we can use SI prefixes only for what they are meant (ieee at the same time also definined some more things like b=bit, B=byte, etc) Thanks to your patch (http://bugs.archlinux.org/task/12949) the installer to use both the IEEE nomenclature and powers of 1024. But: df has these options (man df) -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G -H, --si likewise, but use powers of 1000 not 1024 So 'df -h' uses the SI nomenclature ('K','M','G') but calculates in powers of 1024, so their values are actually in Ki, Mi, Gi etc But, if I create in the installer a partition of the size 10.000MiB: echo $(((2**20)*10000)) 10485760000 <-- this is the amount of bytes I expect to see on the blockdevice. fdisk -l says: 10487232000 bytes Why is it not the same? Also a df -m (-m is not documented? but it says "1M" blocks) of the filesystem (ext2) yields 9845M. If 1M means 10^6 then this is wrong because it would be way too few, and if it means 1MiB than it's also still wrong. how much space can you loose by formatting a block device as ext2? Even after setting reserved blocks to 0 (tune2fs -r 0 /dev/sda3) It still is 9845M. (the amount available is 9823M) Any ideas? Thanks, Dieter

1 0

[arch-releng] RC1 ISOs and final release
by Gerhard Brauer 11 Feb '09

11 Feb '09

Hello, as discussed we build a new set of ISOs/USB-Images with the state of a ReleaseCandidate. http://dev.archlinux.org/~aaron/archiso/ Roadmap: http://bugs.archlinux.org/roadmap/proj6 Bugs fixed in 2009.02-RC1: http://bugs.archlinux.org/task/12896 http://bugs.archlinux.org/task/12949 http://bugs.archlinux.org/task/13068 http://bugs.archlinux.org/task/13070 Please test them (esp. for the open bug-reports above). Test phase should go over this weekend, so that we probably could make the final release (sic!) during next week. Known issues: low -> grub entry "Release Notes" present a empty To-Do list Regards Gerhard PS; Upload of most ISO and IMG files are already finished, the missing core-* files will be there in 1,2 hours. (@Aaron: could you provide an updated sha1sums file when finished?)

14 40