On Sunday 31 August 2008 05:56:57 Daniel Baumann wrote: > Hi, > Hi. :) > Thank you, any help with improving the documentation is very welcome. > np I still would like to finish the wiki page that I started long ago. The one that makes a short description of what each lh_(something) script does and the stage files it requires and creates. I've not been in a position to be able to do this in a long time, but that seems to be changing. This is also something that should probably go into the live-manual that you mention below. > Rather than to put it into the wiki, that wiki page should me extended > and incorporated into the live-manual > (git://git.debian.org/git/debian-live/live-manual.git); let us know if > you have something to commit/merge/$whatever or if you want to do it > yourself. > All I have to do is cut the paella parts out, and pull in the setup script that has the config files in it (and cut the paella parts out of that, too). I'll check out the git repos later today, if I get time. I have to prepare for a hurricane today, and that's going to take up a lot of time, since there's a lot of stuff scattered around. > > Recently, with the updates, I've noticed a peculiar change that really > > surprised me. It seems that the new live-initramfs package searches for > > swap partitions on the system that's being booted, and automatically > > enables them. > > I don't remember who and when did enabled that (or if it even came from > ubuntu), it's quite some time ago. Anyway, at the time, this was done on > purpose. The code works more or less like this: > > *If* a usable (unencrypted) linux swap partition is found > *and* that swap partition does not contain a suspended system This is the main part that concerned me. I didn't know it did this. For my purposes, placing noswap as a boot parameter works fine, but I wanted to bring this to your attention, since I didn't know if data could be accidently destroyed by the change. > *then* it is enabled to use automatically > *unless* noswap is given as a boot parameter. > > In practise, I think that this is a very reasonable way on how to handle > it, as I can not imagine a situation where you don't want to make use of > the swap partition if you have one (except for rescue, see below). For > me, this is comparable to the behaviour of how linux threats free pages > in the ram: rather than wasting it and not using it at all, it uses it > to cache disk accesses. So I do like this setting for the desktop > oriented live flavours. > > In theory however, a live system should not touch any filesystem at all, > except the one it is bootet from. I personally would also not expect any > live system to use a swap partition by default. > Yes, this is the impression I was under, and I was quite surprised to see swap enabled without me explicitly allowing it at boot time. > On the other hand, on the rescue flavour, which is primarily target at > actually do some manipulation of the disk filesystems, the absence of > noswap varies between beeing inconvenient (you have to swapoff manually > before you can e.g. repartition/format disks) and beeing distructive > (you want to do some forensic analysis on the swap partition of a given > system). Therefore, in my opinion, for the rescue flavour we really do > need to make noswap the default behaviour. > Here's my two cents. > Since having different settings for the desktop flavours and the rescue > flavours sucks too, let's do a poll: > > [ ] Use swap partitions automatically in all flavours (leave as is) > [x ] Don't use swap partitions automatically in all flavours > [ ] Use swap partitions for standard and desktop flavours, > use noswap for rescue flavour. > This decision basically follows from my impression that a live system shouldn't write to any drives by default. I also think that we should keep in mind that people who use the live system for privacy concerns may unwittingly leave data on the swap partition and be totally unaware of it. As a compromise, I think that creating an fstab with the swap partitions having the noauto option would be a nice alternative. This allows the live user to type "sudo swapon -a" when he/she needs to. A swapon.desktop file in ~/Desktop would also be nice on desktop flavors. > > I would've probably never noticed this on another system, or if I was > > booting from a live cd. My installer, however, noticed immediately, as I > > couldn't repartition a disk due to a swap partition already being > > enabled. > > We will have the same problem the day we make d-i working to be launched > as application from the desktop by loop mounting the initrd, though this > is easy to handly by just swappoff before launching d-i. > I'd be really interested in this. I'd really like to d-i to do the disk/partition management, and mount the target, then let paella takeover with the install after this is done. This would help me greatly, as the disk/partition part of the installer is the most difficult, and I'd like to keep from reinventing the wheel when the d-i people have already done an excellent job in this area. I'm just put off by the fact that partman isn't available in a regular .deb, and the d-i people don't seem to see any use for partman outside of the debian-installer. This is an area I'd be really glad to help out in, as it stands to help me make a better installer. :) > > On a side note, I've been having problems with the /etc/resolv.conf > > file. In my setup, mentioned above, the system that builds the live > > image is running bind, and it's resolv.conf uses "nameserver 127.0.0.1". > > I can't seem to replace this file using the local-includes. > > According to the code, 23networking only creates a resolv.conf if it is > not existing or empty. So the problem lies in live-helper, which is a > bug I'm looking at in a few hours. > I even tried putting /etc/resolv.conf.orig in the includes, to try and trick the lh_(can't remember) script, but that didn't work either. > > Thanks for making it easier to concentrate on other things! :) > > That's probably the nicest compliment you can make us, thanks ;) Y'all have earned it! :) > > Regards, > Daniel > > -- > Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: daniel.baumann@panthera-systems.net > Internet: http://people.panthera-systems.net/~daniel-baumann/ -- Thanks: Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.