- Arch-releng - lists.archlinux.org

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

16 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

Re: [arch-releng] [arch-dev-public] Official Installation guide needs your help!
by Loui Chang 07 Feb '09

07 Feb '09

On Fri, Feb 06, 2009 at 03:33:49PM -0500, Dusty Phillips wrote: > Drop the official install guide. > > We know our wiki is well-maintained and well organized, and it seems > to do that by itself without much developer interference. Go wiki! > Originally, when we first set the wiki up Dennis, Judd, and I felt > that the official install guide should be more... well... official. > But its out of date, its always out of date, and there are wiki texts > that are not out of date. Now, seeing how our wiki experiment has > exceeded our hopes and expectations, I'd say that the install guide > (drop the 'official') should be community maintained as are all our > wiki pages. It will improve. When its time for a release, "somebody > official" should read through it, ensure its accurate, convert it to > plaintext and put it on the iso. I really don't think that would work. The official install guide should be brief really. Only guiding the user to install, set up a network connection and understand pacman usage so more packages can be installed. The fact that the Beginner's guide exists shows that users will start to stick everything under the sun that suits them.

1 0

[arch-releng] 2009.02 name ideas
by Dieter Plaetinck 06 Feb '09

06 Feb '09

some names for the new release along with their rationale... - perseverance (the long&big efforts to produce this masterpiece) - rebirth (new people, new FS, new strategies,..) - valentine (date based) - cupid (date based) (i would pick something along the two above ones, we can still name our releases after dates/times if we lack inspiration in the future)

17 26

[arch-releng] Things beyond 2009.01/02
by Gerhard Brauer 05 Feb '09

05 Feb '09

I have some points we could/should discuss after the upcoming ISO is finally released. So this are things which affect eventually 2009.04. a) Number of different ISOs/Images: We have currently 10 different mediums to install Arch Linux. I like to reduce them for better and easier building and maintenance. Archiso based mediums are both installation and Live-CD mediums. IMHO a user who will install the system uses such a ISO/Img only once, for the installation and maybe to correct errors during installations. These users like small ISOs/Images. For users who would use the mediums for ex. as Live-CD/Maintenance we offer to few tools and programs on this ISO. Another point is the ISO bootloader. We have add already isolinux cause grub has boot problems on a not so few count of PCs. My suggestion on this is: For the core/ftp CD-ISOs we use only isolinux as bootloader. This will boot on all PCs and these mediums a mostly used only for system installation. So we also could keep them small. The USB-Images still should have grub as bootloader (I currently don't know if iso/syslinux work on them and we never have a reported problem about USB images and grub). Also i like to see a combined i686/x86_64 medium, as we produced one for the FrosCon-ISO. The necessary framework is already available for archiso. This ISO/Image has naturally a bigger size. My idea is now to full-fill the remaining space on a cd with programs which are usefully to use this mediums as a base maintenance ISO - for both architectures. And on this we should use grub as ISO bootloader cause we need/benefit here from grub's flexibility above isolinux. Doing this (and using isolinux for core/ftp-ISOs) we would end in a medium count of 9 different mediums (4 x CD-ISOs, 4 x USB-Images, 1 combined). That is still a big count... Other think-games: - Kicking core or ftp. Both alternatives have disadvantages: ftp is small and offers a up to date system during/after install. Core gives a bootable systems also when no internet access during installation. But we will end in a medium count of 5. - Also offer combined mediums (i686 and x86_64) for each core/ftp ISO and USB image. Disadvantage: the download size for each medium is greater, so one who would only install Arch Linux have to download many Megabytes he probably not and never need. But this would reduce medium count also to 5 but we could have separate core and ftp installs. b) Release "branding" Should we have release names? Should we have the release versions (ex. 2009.02) in the splash screens (grub, isolinux) and maybe in /etc/issue? Background is: User should be able to identify which ISO release he currently uses. Having the release version only on ISO/Img-File is sometimes not enough. Release naming is "neet", but are we able/willing to think about nice names? Document the release versions in splash screens/shell overview is quiet easy, but we have to automate this by a script. Otherwise these changes will be surely forgotten sometimes.... c) Installer switch IMHO we are common to try aif as the next installer. So testing should begin closely after 2009.01/02 release. That's also a reason why i would not fix each minor thing or add features to current archlinux-installer for 2009.01/02 if we maybe kick it next months. d) Accessibility support on install mediums There were a discussion on arch-general about that (and the needed tools and modifications sounds not a big work), Aaron brought up an idea with additional speak output, so this supports not only braille reader users. We must see if we could at this support smoothly into the current mediums or if maybe a separate ISO is needed. e) Testing and documentation IMHO we should document such things as archiso's work-flow, HowTo for ISO/image building and releasing steps. Also things like torrent setup etc. And improve our (pre)testing procedures to avoid such things like grub-gfx error on x86_64 in the future. This have to be found on our side before public testing! But i think we all have learned much during the process of releasing 2009.01/02 what crude things could get broken. And that Murphy is still alive ;-) OK, these are the things I mean which await us next releases, we should mention about. Of course we/you will found more... Gerhard

5 10

[arch-releng] LiveCD kernel?
by Smartboy 05 Feb '09

05 Feb '09

Hi, I'm new to the list. I was wondering how the kernel was built for the LiveCD. I am trying to build my own livecd based off of Arch's (with Squashfs LZMA), and thus need to patch the kernel to support it. I have tried searching, but neither Larch nor ArchISO have any info on this, and there is no documentation on the official CD that I could find. Thanks, Smartboy

2 4

[arch-releng] [PATCH 0/2] Fixes to disc capacity detection and automatic partitioning
by Evangelos Foutras 04 Feb '09

04 Feb '09

First patch fixes a possible issue with SCSI drives (needs testing) Related bug report: http://bugs.archlinux.org/task/12949 Second patch modifies the automatic partition preparation step of the installer to use MiB instead of MB, because most users (myself included) are more familiar with MiB (2^20 bytes) than with MB (10^6 bytes) and because that's what sfdisk (used for the actual partitioning) is expecting.

2 4

[arch-releng] Final checklist for 2009.01/02
by Dieter Plaetinck 03 Feb '09

03 Feb '09

Thanks everyone for your efforts in testing and experimenting with the grub stuff. I went over all mails and tickets, and afaict we only have 4 more open remaining issues, for all of which we only need someone with access to apply the fixes / some testing. See the roadmap @ http://bugs.archlinux.org/roadmap/proj6 FS#13070: we have a fix but need a developer who can update archlinux-installer (and it's package) for us FS#13068: we have to wait until grub-gfx package is updated for 64bit FS#13049: should be okay for 64bit users. if you have such system, keep your eyes open during cdrom boot and confirm it's okay now please. FS#12896: need confirmation from usb users that it's okay. I personally have a slow upload.. maybe some else can upload his homebuilt isos (or we can wait a bit for Aaron to surface again, but that will be more then 24 hours from now I think) Anyway, here is the build procedure, it's quite easy: git clone http://projects.archlinux.org/git/archiso.git cd archiso/archiso sudo make install #to be packaged later cd ../configs/install-iso # change version in Makefile # if on x86_64, remove intel-536ep and intel-537 from packages.list ./buildall.sh scp release/* ...somewhere... Dieter

8 18