Re: Problems with initrd and boot modules
On Wed, Dec 19, 2001 at 03:32:51PM -0500, Mark Horn wrote: 1) Is this the correct forum to identify this kind of problem? If not, can you kindly direct me where I should go? Seems logical to me. 2) Did I do something wrong during initial setup that prevented creating a functioning initrd? 3) Is my modified initrd what *should* have been created by the install? Or is there a different/better way to accomplish this? I can't speak for initrd.debinstall, but did you try the 'compact' flavour of the boot floppies? That should have worked without needing to load the cpqarray module and the installed system should have booted from lilo without an initrd. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: check_pending_config() and mounting /target
On Fri, Oct 26, 2001 at 02:05:39PM +1300, Mark van Walraven wrote: Kindly review the change and let me know what you think. I've done three full installs with the change and observed no additional problems. Ok to commit it? Thanks, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Tue, Nov 13, 2001 at 03:06:38PM -0900, Ethan Benson wrote: your missing the point: what good will this do? the permissions of the mount point directory are irrelevant as they will be replaced by the permissions of the root directory of the mounted filesystem. this patch ONLY affects creation of the mountpoint directory which will be covered up by whatever partition/filesystem is mounted there. But not until /etc/rcS.d/S35mountall.sh has run. And not if the admin has un-mounted it for recovery or maintenence purposes. unless your mounting a partition on /var/tmp we don't create it at all, base-files does. That's fine, but the patch addresses the case where /var/tmp is created (as a mount-point) during the initial install. It might happen because the admin temporarily un-mounted /var/tmp to alter its size. Or perhaps the filesystem was damaged and the admin decided to bring the system up without mounting it before trying to recover the data. Maybe we simply one day decide we don't need /var/tmp separate from /var. and for that reason he probably doesn't want lusers filling up /var while he is working. If I didn't have important reason to get the system up quickly, I'd just work away in single-user mode. If /var/tmp is only writeable by root, some critical applications won't work properly. Differing permissions on a filesystem and its mountpoint - in the absence of admin intervention - violate the principle of least surprise for most mount-points (obvious exceptions are /mnt, /cdrom and /floppy). The inconsistency with /tmp is itself surprising. i disagree, lusers suddenly gaining write permission to a filesystem its not granted to them due to mountpoints is a surprise. Hmmm. Lets see: I unmount /var/tmp and now the lusers suddenly have write access to /var/tmp on the filesystem containing /var. Nope, that doesn't surprise me at all. i would bet the only reason there is a special case kludge in boot-floppies here is due to severe misunderstanding of something by some other coder, i found many many instances of mkdir(/foo/bar, 1777) which does not work. the permission you specify is always ORed with the current umask, and the first digit is always ignored. you can't create a sticky directory with mkdir(blah, somemode) afaikt. Yeah, the code in partition_config.c does a chmod() after the mkdir(). if anything this sillyness regarding mountpoint directories should be removed, not expanded. Well, /home and /usr/local have a similar problem, but I hadn't noticed them until now. But that has a much lower impact, unlike the /var/tmp problem, which I discovered early one morning when it bit me in the arse. If I want to stop users writing into the /tmp and /var/tmp mountpoint directories when nothing is mounted on them, then I change the directory permissions in a deliberate act. However, since the system will not automatically boot into multi-user mode without mounting all the filesystems in fstab, I need not fear the mountpoints being exposed without administrative fiat. yes so you agree the permissions of the mountpoint dir don't need to be fiddled with. Provided the default permissions are sensible. The ones created by dbootstrap for /var/tmp are not. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Thu, Nov 15, 2001 at 03:51:55PM -0900, Ethan Benson wrote: On Fri, Nov 16, 2001 at 01:41:52PM +1300, Mark van Walraven wrote: If I didn't have important reason to get the system up quickly, I'd just work away in single-user mode. If /var/tmp is only writeable by root, some critical applications won't work properly. bzzzt. thanks for playing. single-user mode has only one user remember, and that user is root, who can write anything. The context was a system brought up in to multi-user mode without /var/tmp mounted. I wouldn't do that without an important reason, like perhaps a thousand users screaming for a critical application. But if /var/tmp is now writeable only by root, the critical application may well malfunction. Well, /home and /usr/local have a similar problem, but I hadn't noticed them until now. But that has a much lower impact, unlike the /var/tmp problem, which I discovered early one morning when it bit me in the arse. oh now /home and /usr/local are supposed to be world writable? similar, adj. Looking or being almost, but not exactly, the same. [Cambridge International Dictionary of English] The ownership and permissions of the /home and /usr/local mountpoints by dbootstrap should match those of the filesystems mounted on them. That's how they are almost the same. They should not be world writable. That's how they are not exactly the same. I assumed you would realise that. Provided the default permissions are sensible. The ones created by dbootstrap for /var/tmp are not. i have yet to see any proof of this. I don't believe you ever will see it. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Fri, Nov 16, 2001 at 02:44:53PM +1300, Mark van Walraven wrote: On Thu, Nov 15, 2001 at 03:51:55PM -0900, Ethan Benson wrote: - i have yet to see any proof of this. I don't believe you ever will see it. I wish to apologise to Ethan and the list for my petulant and unfair remark. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH] set sticky bit when creating /var/tmp mount-point
Dear list,
partition_config::mount_partition() uses mode 01777 when creating /tmp
as a mount-point, but doesn't for /target/var/tmp. A fix is:
Index: boot-floppies/utilities/dbootstrap/partition_config.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/partition_config.c,v
retrieving revision 1.116
diff -u -r1.116 partition_config.c
--- boot-floppies/utilities/dbootstrap/partition_config.c 2001/11/11 01:00:33
1.116
+++ boot-floppies/utilities/dbootstrap/partition_config.c 2001/11/13 09:36:48
@@ -572,7 +572,9 @@
while (1) {
if ((p = strchr(p + 1, '/')) != NULL)
*p = '\0';
- WithMode = strcmp(real_mount_point,/target/tmp) ? 0755 : 01777;
+ WithMode = strcmp(real_mount_point,/target/tmp)
+ strcmp(real_mount_point,/target/var/tmp)
+? 0755 : 01777;
DEBUGMSG(making mount point %s, real_mount_point);
if (! mkdir(real_mount_point, WithMode)) {
chmod(real_mount_point, WithMode);
Regards,
Mark.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Tue, Nov 13, 2001 at 04:20:36AM -0900, Ethan Benson wrote: On Tue, Nov 13, 2001 at 12:02:18PM +0100, Kjetil Torgrim Homme wrote: Ethan Benson [EMAIL PROTECTED] writes: - what good will this do? the permissions of the mount point directory are irrelevant as they will be replaced by the permissions of the root directory of the mounted filesystem. It enables the use of vi for non-root users even when /var/tmp isn't mounted ... uh ... And many other things too! Bash, for instance uses TMPDIR for 'here documents'. and why would that happen? from a security point of view i think the directory under mountpoints like tmp should not be world writable, if the admin has a different filesystem/partition mounted there he probably did so to keep users from gaining write permission to the underlying filesystem (esp in the case of /). It might happen because the admin temporarily un-mounted /var/tmp to alter its size. Or perhaps the filesystem was damaged and the admin decided to bring the system up without mounting it before trying to recover the data. Maybe we simply one day decide we don't need /var/tmp separate from /var. Differing permissions on a filesystem and its mountpoint - in the absence of admin intervention - violate the principle of least surprise for most mount-points (obvious exceptions are /mnt, /cdrom and /floppy). The inconsistency with /tmp is itself surprising. If I want to stop users writing into the /tmp and /var/tmp mountpoint directories when nothing is mounted on them, then I change the directory permissions in a deliberate act. However, since the system will not automatically boot into multi-user mode without mounting all the filesystems in fstab, I need not fear the mountpoints being exposed without administrative fiat. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LVM enabled boot disks ?
Hi Erik, I'm still preparing some documentation, but here's the rough procedure. I'm sending a copy to debian-boot in case this is useful to anyone else. Check the boot-floppies software out of the Debian CVS archive. See http://cvs.debian.org/boot-floppies/README-CVS?rev=1.9content-type=text/vnd.viewcvs-markupcvsroot=debian-boot for details on how to do this. The version I checked out was the same as, or close to, what ended up being release 3.0.16 of the boot-floppies package. http://lists.debian.org/debian-boot/2001/debian-boot-200110/msg00987.html details some modifications to the boot-floppies source so that dbootstrap will wait until installing the kernel before copying the network settings onto the target root filesystem and creating the dbootstrap_settings file. This is important if the root filesystem is to be mounted outside dbootstrap. Make an LVM-patched 2.4.10-ac11 (a later kernel might be better by now) kernel-image Debian package with the 'kernel-package' package. In boot-floppies/config, set the variable 'kver' to 2.4.10-ac11, or whatever you named your kernel. Copy the kernel-image package (that you just built) and the lvm10 package (from the Debian unstable archive) into sub-directory 'local' of the directory used for 'ftp_archive' in the file boot-floppies/config. Add lvm10 to boot-floppies/scripts/rootdisk/EXTRACT_LIST_i386. Add lib/lvm-10/vgscan, lib/lvm-10/vgchange and lib/lvm-10/lvscan to boot-floppies/scripts/rootdisk/SMALL_BASE_LIST_i386. The boot-floppies were otherwise built as normal - see the README files in the source for details on how to do this. I think I skipped the 1.2MB floppy images, since the root floppy got too big with the LVM tools. Boot and go through the installer until you have created your partitions, then choose Execute a Shell. The LVM tools will be in /lib/lvm-10; run vgscan then pvcreate, lvcreate, etc. Make filesystems on your LVs as required, then mount them in your desired structure below /target. For example: mount /dev/vg0/lv0 /target mkdir /target/tmp /target/usr /target/var /target/home chmod 1777 /target/tmp mount /dev/vg0/lv1 /target/tmp mount /dev/vg0/lv2 /target/usr mount /dev/vg0/lv3 /target/var mkdir /target/var/log /target/var/lib mount /dev/vg0/lv5 /target/var/log mount /dev/vg0/lv6 /target/var/lib mount /dev/vg0/lv7 /target/home Exit the shell to return to the installer and continue from Install Kernel and Driver Modules. The rest of the install should proceed normally, but if /boot is on a LVM logical volume, you won't be able to use Make System Bootable without a patched LILO, an initrd and some adjustment to /target/etc/lilo.conf. (In you do this, I recommend making a boot floppy, as initrd's are easy to get wrong and it's much easier to fix an initrd on a floppy and transfer it to the hard disk once it's working.) Hope this is what you wanted. There may be errors, as I haven't yet done a clean run though to test the procedure. If you find any errors or omissions, please let me know. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LVM-Bootdisk
On Mon, Nov 05, 2001 at 12:39:19AM +0100, Erik Tews wrote: I am currently a little bit experimentating with installing debian directly into lvm. Theory is not so difficult, and it works with a lot of handwork during the installation-process. One of the main problems is I made some private modifications to dbootstrap, adding a 'manual' option to the 'select partition' menus for Initialize a Linux Partition and Mount a Previously-Initialized Partition. These allow the user to type in the path to the block device to be initialised/mounted when the device is not known by dbootstrap, as in the case of LVM logical volumes and MD devices. I was going to abandon them (because I didn't think they would be accepted into the Woody boot-floppies), but will share them if anyone is interested. But for beeing able to install a system into lvm, I need a kernel with LVM-support. So I need some documentation how I can build a bootdisk with a customized kernel. I now got the kernel in /usr/src/linux and making a kernel-image with make-kpkg works. Where can I now find the steps which are needed to create a set of boot-floppies for this kernel? Did you get my earlier email? Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.15 missing ne2k-pci module?
On Mon, Oct 29, 2001 at 04:02:23PM +0100, Eduard Bloch wrote: And how do you download without having the NIC driver? As said before, we have 2.4MB in NIC drivers. With the kernel a bit too much for one floppy. Aggghh! Why do you ignore what was written earlier? I wrote: are compiled into the kernel. But suppose we have a stripped-down kernel with networking, tmpfs and as many common NIC drivers as will fit compiled-in, but basically everything else non-essential (SCSI, IDE, That is, a good selection of NIC drivers. The 'compact' kernel has a reasonable selection even without making NICs a priority. the availability of the network, since earlier in this thread you proprosed installing the kernel-image package from the net! No. Only one guy assumed everybody would have an allways supported Realtek card (or what is the best-seller today?) and a fast network connection. This is just not true for many people, and (at least me) don't want to keep them outside. You wrote: But when Woody stabilize, the kernel installation routine could be modified to get the package from the net and extract its contents. Then the number of driver floppies could be rely minimized to only one, containing NIC and FS drivers. Which I obviously misinterpreted as proposing that the kernel installation routine be modified to get the package from the net. However, the need for a fast network connection (how fast? 28k8?) is a red herring, since my suggestion _does_not_do_away_with_the_driver_disks_!! If you have only popular hardware, you may use the compact flavor, just three floppies. Or reiserfs, they are only few floppies too. If you have a network and a popular NIC, you need only the the rescue and root disks, since you can install the kernel and drivers from the rescue and driver images over the network. And this is exactly what I am talking about! Look Ma, no driver disks! And guess what? It doesn't stop anyone who actually needs to load the driver disk from doing so! (IIRC, Slink was even better in this regards, as the rescue disk alone was often enough to get the network up and download the driver image.) Of course, if you can't get the network up without any driver disks, then you have to feed it the entire set, which is painful for most flavours. Nevermind that most of the drivers are irrelevent to installation. Yuck. So, to sum up my position: two disks is nicer than three and my experiments lead me to think that most flavours could enable the network with just two disks by squeezing a few more NICs into the kernel and root disk, even if at the expense of bumping a few other drivers into the drivers disk (yes, that may mean having the scan one or more drivers disks before you are able to access the device for the target root). And just maybe, a mini-initrd on the rescue floppy might be enough to give some people with some popular system configurations the option to load the root floppy image across the net instead of floppy, cutting the number of floppies down to one. I'm really tired of arguing this now. I still think it could work, but feel free to have the last word. Not as a provisional filesystem, just a temporary filestore for downloaded modules. In fact, transferring the initrd contents into tmpfs and releasing the initrd would use less RAM (just the instantanous size of the tmpfs contents and virtually no metadata overhead) than the initrd. If you think, this is usefull, go ahead and present a concept. But ask Adam first. Adam has already said Woody boot floppies will use a 2.2 kernel, so no tmpfs (nor should blue-sky development happen to it at this stage, anyway). I'll follow debian-installer once the Woody boot floppies are complete. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#81029: Documentation (install.en.txt)
Hi, On Mon, Jan 01, 2001 at 06:55:19PM -0800, Osamu Aoki wrote: The mouse can be used by both in Linux console (gpm) and X window. Preferred configuration / signal flow shall be as follows. mouse = /dev/psaux = gpm = /dev/gpmdata - /dev/mouse = X This made sense when the psaux driver didn't support multiple opens. Linking /dev/mouse to /dev/psaux gives a much better feel and cuts out most lag and jerkiness even on a loaded system. This approach to use gpm even in X has advantages when mouse is unplugged inadvently. Simply restarting gpm with Nice, but not quite worth it, IMO. And unnecessary for USB mice. Just my opinions. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.15 missing ne2k-pci module?
On Fri, Oct 26, 2001 at 11:12:58AM +0200, Eduard Bloch wrote: I presume you mean the target root? It's already mounted by the time the driver disks are installed. Of course, you can also download to a Ramdisk. Yes, this driver should go into the kernel. But the source may be Coda The driver for the target root device? It can be downloaded and installed before mounting the target root. But the source may be Coda FS (for example), then you need the driver for it. And you cannot put every FS driver into the kernel image. The source FS driver can also be downloaded from the network. I assumed the availability of the network, since earlier in this thread you proprosed installing the kernel-image package from the net! I don't think so. Consider this. Currently, all the required drivers are compiled into the kernel. But suppose we have a stripped-down kernel with networking, tmpfs and as many common NIC drivers as will As said before, count the space before starting to make plans. NIC modules take 2.4MB. Add nfs, code, ntfs... about 300kB. Consider this please. I wasn't expecting to fit all the NIC drivers, just a selection of the most popular ones. Additional FS drivers can be download over the network. If you don't have a network, a single floppy probably won't be enough. VFAT is essential. There are people installing from downloaded archives, stored on FAT. We are speaking about an allround setup system, not something which can be used in fast-network environment only. You may consider such installation methods as unimportant, but many people do not. Look, what I'm suggesting here is an organisation where most people need only the rescue disk and a working network to install. Some may need additional modules from another floppy. Without a network or a local mountable filesystem of a reasonably-common type, they may need a full set of driver disks. It should still be an allround setup system. As for network speed, usually only a small number of modules will be needed for an installation on a specific system, and few of them are more than 100KB. Room for FAT would have to be traded against room for more NIC drivers. Tmpfs? Debian should be installable on 12MB machines. With tmpfs as the provisoric filesystem you don't have much space. Of course you could rely on swap. But Not as a provisional filesystem, just a temporary filestore for downloaded modules. In fact, transferring the initrd contents into tmpfs and releasing the initrd would use less RAM (just the instantanous size of the tmpfs contents and virtually no metadata overhead) than the initrd. Please have a look on FAI or create a such disk for yourself (not complicated, few modification in the BF build system). The you have a custom disk, but only you can use it. FAI is interesting, but a much more constrained system. Okay, but that is your hardware. Look at the lots of different components, this is not really easy. For such modifications, dreams, new ideas, please have a look on the future debian-installer project. Yes, I have been watching d-i with interest since Potato went stable. I have no expectation of any interesting development happening on the boot-floppies - beyond what is needed for Woody. But still I experiment for my own purposes. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.X kernels do not support pcimap - hw autodetect only with 2.4 kernels
On Fri, Oct 26, 2001 at 12:12:17PM -0400, Adam Di Carlo wrote: I'm not moving to 2.4 for i386 boot-floppies, the kernels are too big, and it's too late to do that anyhow. I'll take that as a positive sign that release is soon! Mark van Walraven [EMAIL PROTECTED] writes: 2.4.10-ac11 patched to ext3-2.4-0.9.12 works very well for me. I'm suprised you were able to fit it? did you use the 2.88k images? total 1404 -rw-r--r--1 markvusers1179 Oct 25 00:05 config.gz -rw-r--r--1 markvusers1144 Oct 25 00:05 debian.txt -rw-r--r--1 markvusers 804 Oct 25 00:05 f1.txt -rw-r--r--1 markvusers 759 Oct 25 00:05 f10.txt -rw-r--r--1 markvusers 752 Oct 25 00:05 f2.txt -rw-r--r--1 markvusers1071 Oct 25 00:05 f3.txt -rw-r--r--1 markvusers1209 Oct 25 00:05 f4.txt -rw-r--r--1 markvusers1196 Oct 25 00:05 f5.txt -rw-r--r--1 markvusers1373 Oct 25 00:05 f6.txt -rw-r--r--1 markvusers 833 Oct 25 00:05 f7.txt -rw-r--r--1 markvusers1348 Oct 25 00:05 f8.txt -rw-r--r--1 markvusers1269 Oct 25 00:05 f9.txt -rw-r--r--1 markvusers 503934 Oct 25 14:22 initrd.gz -rw-r--r--1 markvusers1521 Oct 25 00:05 install.sh -r--r--r--1 markvusers6900 Oct 25 00:05 ldlinux.sys -rw-r--r--1 markvusers 796668 Oct 25 00:05 linux -rw-r--r--1 markvusers 634 Oct 25 00:05 rdev.sh -rw-r--r--1 markvusers 896 Oct 25 00:05 readme.txt -rw-r--r--1 markvusers 107869 Oct 25 00:05 sys_map.gz -rw-r--r--1 markvusers1235 Oct 25 14:10 syslinux.cfg -rw-r--r--1 markvusers 7 Oct 25 00:05 type.txt I guess the answer is what I leave out of the kernel, compared to, say, the compact flavour. I've attached the config. There are a few oddities: floppy and NIC drivers are modular, IDE is built-in (a mistake, for my purposes) and in-kernel NFSD is built-in (another mistake). The initrd on the rescue disk contains modules and a shell. I used to need that to set up LVM, but now all it does is load a few modules, load a ramdisk from the root floppy and start the installer. It could be obviated by building the floppy and NIC drivers into the kernel. It might be nice to at least document how this could be built, for i386 documentation anyhow. The instructions in the installation manual (section 10.3) and also the README in the boot-floppies source are still apt. If you mean the kernel config, what do you really want to have built-in? I don't mind trying a few configs out for size. Regards, Mark. CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_M686=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_PPRO_FENCE=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PNP=y CONFIG_ISAPNP=m CONFIG_PNPBIOS=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_MD_MULTIPATH=y CONFIG_BLK_DEV_LVM=y CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_NET_SCHED=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_ADMA=y CONFIG_IDEDMA_PCI_AUTO=y
Re: 3.0.16 for testing (debootstrap esp!)
On Thu, Oct 25, 2001 at 07:41:10AM +0200, Gerhard Tonn wrote: It works fine on s390, but where do I get the latest debootstrap from? Look in http://incoming.debian.org/ . Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
check_pending_config() and mounting /target
Dear list,
If a filesystem is manually mounted on /target using the shell on tty2,
dbootstrap will detect it and suggest installing the kernel, but never
copies the network settings or creates the dbootstrap_settings file on
the target root.
This makes installing root on a MD, LVM, NBD or loop device a major pain.
Relocating check_pending_config() from partition_config:mount_partition()
to extract_kernel:extract_kernel_and_modules() fixes the problem.
Having read through the code, the move appears safe and locates the
call to check_pending_config() in a more logical place. I have just
done a test install using boot-floppies built from current CVS and
debootstrap_0.1.15.7 and the change worked perfectly.
Kindly review the change and let me know what you think.
Thanks,
Mark.
Index: partition_config.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/partition_config.c,v
retrieving revision 1.109
diff -u -r1.109 partition_config.c
--- partition_config.c 2001/10/23 19:57:59 1.109
+++ partition_config.c 2001/10/25 22:58:57
@@ -699,12 +705,9 @@
return 1;
}
- if (!strcmp(mount_point, /)) {
-/* we just mounted root, so have some other config tasks to perform */
+ if (!strcmp(mount_point, /))
Boot = Root = partition;
-check_pending_config();/* Must NEVER write to /target/boot. */
- }
- if (!strcmp(mount_point, /boot))
+ else if (!strcmp(mount_point, /boot))
Boot = partition;
free(mount_point);
Index: extract_kernel.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/extract_kernel.c,v
retrieving revision 1.48
diff -u -r1.48 extract_kernel.c
--- extract_kernel.c2001/08/21 09:32:49 1.48
+++ extract_kernel.c2001/10/25 22:58:57
@@ -276,6 +276,8 @@
if ( choose_medium() )
return 1;
+ check_pending_config(); /* Must NEVER write to /target/boot. */
+
INFOMSG(installing kernel and modules from %s, Archive_Dir);
if (! strcmp(Archive_Dir, netfetch)) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.X kernels do not support pcimap - hw autodetect only with 2.4 kernels
On Thu, Oct 25, 2001 at 05:25:24PM -0700, David Kimdon wrote: Or is there any way to build boot-floppies using 2.4.X kernels? In principle we should be able to do that. I've considered re-openning the 2.4/2.2 question myself, but I fear. We need to get woody out, no new features. ISTR the same discussion for Potato. By the time it was finally released, the controversy had melted away. ;-) FWIW, we've gotten unconfirmed reports that boot-floppies doesn't work with 2.4 kernels. I think it turned out something else was the problem. 2.4.10-ac11 patched to ext3-2.4-0.9.12 works very well for me. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] today's treecompare
On Sat, Oct 20, 2001 at 04:23:05AM -0600, Erik Andersen wrote: Umm. What possible good would it do to parse dd output? Check the return code. or stat the output file if you are paranoid. It was a way to determine file size in the absence of wc. But if you've enabled wc in b-f busybox, there is no longer any need. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] today's treecompare
On Mon, Oct 22, 2001 at 06:20:13PM -0600, Erik Andersen wrote: I did indeed re-enable wc. But seriously though, if you know the file's name, couldn't you just stat(2)? Something like: struct stat statbuf; ... stat(filename, statbuf); filesize = statbuf.st_size; Fine for C or Perl, but not for a sh script like debootstrap. I posted some quick-and-dirty C source code for a tiny 'stat' program in http://lists.debian.org/debian-boot/2001/debian-boot-200110/msg00728.html which prints out all the statbuf fields, and might therefore be useful to shell scripts: $ ./stat /boot/vmlinuz-2.2.19 770 0 162419 33188 1 0 0 14199 0 457707 4096 904 1003569432 987719796 990575051 Easy to add to busybox, but definitely outside busybox's scope. And no longer needed, now that wc is back. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] today's treecompare
On Fri, Oct 19, 2001 at 11:20:18PM -0800, Ethan Benson wrote:
On Sat, Oct 20, 2001 at 06:34:12PM +1300, Mark van Walraven wrote:
Substitute FILE for touch FILE.
that should already be done in the last patch or two that were NMUed,
Cool.
but i could have missed one.
debootstrap-0.1.15.5/potato:64:touch $TARGET/var/lib/dpkg/info/${pkg}.list
debootstrap-0.1.15.5/slink:56:touch $TARGET/var/lib/dpkg/info/${pkg}.list
debootstrap-0.1.15.5/woody:87:touch $TARGET/etc/ld.so.conf
debootstrap-0.1.15.5/woody:108:touch $TARGET/var/lib/dpkg/info/${pkg}.list
debootstrap-0.1.15.5/woody:158:touch $TARGET/etc/exim/exim.conf
Substitute sed -e q for head -n 1.
sed is used more often then this ...
Joey's done away with head. Therefore I suggested using sed instead.
Better yet, replace head -n 1 with (read A ; echo $A ).
busybox dd does not produce output like GNU dd.
Works for me:
$ ln /bin/busybox dd
$ ./dd if=/boot/vmlinuz-2.2.19 of=/dev/null bs=1
457707+0 records in
457707+0 records out
BTW: does ls --block-size=1 -s look broken to you?
busybox ls doesn't know what that is.
Sorry, meant fileutils' ls. Bug?
Mark.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] today's treecompare
On Sat, Oct 20, 2001 at 01:03:12AM -0800, Ethan Benson wrote:
but parsing some basically informative verbosity output from a utility
is a damned fragile kludge of a way to do something, what if the
format of this output changes in the future?
Agree with the sentiment, but changing the output of dd after all this
time is probably a shooting offense.
A 'stat' program would be handy, where perl was not readily available.
Here's a prototype:
#include stdio.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
int main(int argc, char *argv[])
{
struct stat buf;
if (argc != 2) {
fprintf(stderr, usage: %s FILE\n, argv[0]);
exit(EXIT_FAILURE);
}
if (stat(argv[1], buf))
perror(stat);
printf(%u %lu %u %u %u %u %u %lu %lu %lu %ld %ld %ld %ld %ld\n,
buf.st_dev, buf.st_ino, buf.st_mode, buf.st_nlink, buf.st_uid,
buf.st_gid, buf.st_rdev, buf.st_size, buf.st_blksize,
buf.st_blocks, buf.st_atime, buf.st_mtime, buf.st_ctime);
exit(EXIT_SUCCESS);
}
Regards,
Mark.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] today's treecompare
On Sat, Oct 20, 2001 at 01:41:25AM -0800, Ethan Benson wrote: BTW: does ls --block-size=1 -s look broken to you? busybox ls doesn't know what that is. Sorry, meant fileutils' ls. Bug? the ls you have available on boot-floppies is busybox, not fileutils. Forget boot-floppies! Please try the above on fileutils ls and see if the numbers look right to you. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status
On Fri, Oct 19, 2001 at 01:11:30AM -0400, Joey Hess wrote: We strip modules as much as is possible. I have never heard of stripping the kernel itself. Stripping all symbols is highly likely to break the kernel. However, GCC generates a .ident field in object files, which seems to be unnecessary: $ strings -a /usr/src/linux-2.4.10-ac11/vmlinux | fgrep 'GCC: (GNU) 2.95.2' 3101860 14260 Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] today's treecompare
On Sat, Oct 20, 2001 at 12:54:23PM +1000, Anthony Towns wrote:
On Fri, Oct 19, 2001 at 06:46:32PM -0400, Joey Hess wrote:
Removed stuff:
/bin/touch
/usr/bin/head
/usr/bin/sort
/usr/bin/wc
...are all used by debootstrap.
Substitute FILE for touch FILE.
Substitute sed -e q for head -n 1.
wcc () { return `dd if=$1 of=/dev/null bs=1 21 | sed -e 's/\+.*//;q'` }
Sort is a little harder, but feasible as a shell function. Wanna? :-)
BTW: does ls --block-size=1 -s look broken to you?
Regards,
Mark.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mount_partition() and filesystem types
On Thu, Oct 18, 2001 at 04:02:19AM -0800, Ethan Benson wrote: On Thu, Oct 18, 2001 at 06:59:40PM +1000, Glenn McGrath wrote: Problems should be reported upstream where apropriate, not to assign blame, but so the upstream author knows about it and can fix it for all users of that piece of software and let boot-floppies be broken for who knows how many monthes/years while upstream thinks about fixing it? No reason not to both report the problem upstream *and* work-around it. mount -t auto is a huge random element which is just ASKING for bugs and random failures, critical failures, to appear in boot-floppies any at time. I don't think anyone actually *is* advocating changing dbootstrap to use mount -t auto. There was a discussion (during which you provided the answer to my question) which moved off b-f and onto fixing a nasty defect in busybox. So, thank you for answering my question. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mount_partition() and filesystem types
On Wed, Oct 17, 2001 at 02:55:11PM -0800, Ethan Benson wrote: thank you for completly missing the point. Ok, no need to be rude. I see I went down the wrong track. I'm sorry. i am not talking about libfdisk, i am talking about busybox. its mount -t auto design is fundementally flawed, it gets a complete list of kernel supported filesystems via sysfs() then it has a static, hard coded list of `blacklisted' filesystems it shouldn't try, these Blech. The util-linux mount, in contrast, has a hard-coded 'whitelist' of filesystems and inspects the superblock for the appropriate magic for each. If that fails, it calls mount(2) on each non-nodev type appearing in /etc/filesystems (or /proc/filesystems if /etc/filesystems doesn't exist). Hopefully, busybox should be able to do the same without excessive inflation. To be honest, I'm surprised that it doesn't. in all your partitions being mounted as foofakefs (because nodev filesystems never fail to mount, even if you hand them a real device, they just ignore that). I didn't know that about nodev filesystems. I see your point very clearly now. Thank you. but as i have stated, even if you fix busybox to be smarter you still have a giant stack of wildcards in all these random filesystems in the kernel, are they going to behave sanly when told to mount a partition not containing thier fstype? or will they fuckup and kill the kernel? If busybox pays attention to the superblock magic, the chance of calling mount(2) with the wrong filesystem should be very low. Beyond that, the kernels on offical Debian boot-floppies should also be a known factor. BTW, I tend to agree with David about not changing the dbootstrap code at this stage. I have been adding a 'manual' option to mount_partition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mount_partition() and filesystem types
On Thu, Oct 18, 2001 at 04:36:14PM +1300, Mark van Walraven wrote: BTW, I tend to agree with David about not changing the dbootstrap code at this stage. I have been adding a 'manual' option to mount_partition Damn, sorry, hit 'y' (send) when I meant 'q' 'y' (postpone). I meant to say that for my own custom boot-floppies I've added a 'manual' option to the Please select the partition to mount menu[1] (so that I can mount LVM and MD block devices, which have no partition type). I've been relying on busybox mount to automatically pick up the filesystem type, but I can see that isn't safe at present. [1] I'll offer my patch soon, for anyone interested. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Boot problem
On Sun, May 13, 2001 at 03:30:56PM +1000, Robert Butler wrote: Problem is I can't press that Continue button, so have never gotten past this screen. No response to any keyboard or mouse commands from this screen, including Ctrl-alt-delete: I have to reboot via the reset button. Of course it did respond to the keyboard up until the enter command to start installation. System is an AMD Athlon processor with 256MB pc133 dram, a Seagate Medalist drive 13GB with a MS natural keyboard connected to the PS2 keyboard connector, and a USB optical mouse connected to 'the first USB port. I don't know what other system info might be relevant to this situation? Just a wild suggestion, but please try a PS/2 mouse. There have been problems in the past with the mouse controller confusing the keyboard driver, for some kernels and some BIOSes. Make sure you don't move the mouse at all from the time you power up. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installation troubles!
Hi, On Mon, Apr 02, 2001 at 05:52:02AM -0400, [EMAIL PROTECTED] wrote: without the floppy. It all went fine until it got to "Verifying DMI pool data", (normally it would then start win me), but then instead of giving me the choice of Linux/windows it just prints 01 01 01 01 01 01 continuously. I Did you install LILO into the MBR on the first disk? Was there an "L" at the very beginning of the "01"s? (I know it's hard to see - the screen fills up so quickly ...) If the answer to both is yes, then lilo is getting a BIOS error when trying to load its second stage. I suspect your BIOS doesn't like 30GB disks. Make sure you don't have "boot sector virus protection" on in your BIOS. It can also happen if you are using an old version of LILO - what version of the boot-floppies are you using? username/passwords. Anyway - it reset again, so I tried without the floppy. Do you mean the system just suddenly crashed? Nasty. FWIW, Debian on the second drive works fine for on my 450MHz K6-II (Via MVP-3 mainboard). My second drive is only 4GB, however. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.1: cramfs and initrd
On Wed, Mar 28, 2001 at 09:29:14PM +1000, Herbert Xu wrote: zhaoway [EMAIL PROTECTED] wrote: Does anyone have this problem for kernel 2.4.1? When I compiled in cramfs, initrd cannot work. Kernel message screen just say: wrong magic == spit out by cramfs(?) which shouldn't be there in the 1st place? The kernel tries every registered partition driver to read the superblock of the initrd image. The cramfs driver disobeys the 'silent' flag passed to it (a bug) and grizzles that the superblock doesn't have the magic numbers expected of a cramfs superblock. cramfs sets the block size to 4096 bytes, which breaks initrd because it was read in 1024 byte blocks. This is worked around in kernel-source 2.4.2 where the rd block size defaults to 4096 if you've got cramfs enableed. I think the cure is worse than the disease. :-) Suddenly your 1k/block ext2 initrd fails to mount and the kernel panics without anything to tell you it's because the filesystem blocksize now no longer matches the new default ramdisk device blocksize ... You can either create the initrd filesystem with 4k blocks, or pass ramdisk_blocksize=1024 as a kernel boot parameter (assuming your ramdisk fs has 1k blocks), though if you do the latter, I don't think cramfs will work anyway. 4k blocks on an ext2 ramdisk probably isn't as bad as it sounds with regards to size - I imagine the wasted space compresses quite well. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.1: cramfs and initrd
On Fri, Mar 30, 2001 at 10:49:37PM +1000, Herbert Xu wrote: But why are you compiling cramfs in if you're using ext2 initrd images? The images I make can't handle ext2 images anyway since ext2 isn't compiled in. Well, I took it from the kernel-source changelog and the description in the mkcramfs deb, that cramfs would be the norm for your kernels in the future. Since I needed an initrd (I'm running boot+root on LVM), I thought I'd give cramfs a go. Unfortunately, I need a writable /etc to activate the LVM volumes. I made it work with tmpfs, but it was clumsy. I switched to ext2 when I discovered I could gzip about 1MB of files in a 4MB ext2 down to 384KB. That's about 2/3 the size of the equivalent cramfs and easily fits on a rescue floppy. I left cramfs in as I thought I might be sorry later if I left it out ... It took me ages to figure out why my ext2 ramdisks broke. :-P Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.16?
On Sat, Jul 01, 2000 at 07:32:18PM -0700, Randolph Chung wrote: 64823 incorrect LILO automatic placement on i386 ISTR some discussions about why we don't allow what the bug submitter wanted, because it doesn't work in certain configurations or something. Mark, are you still around? Maybe you know? The current code *is* defective, but a correct solution is difficult because there are a lot of possible scenarios, many with subtle problems. Karl (and you?) made some changes quite a while back that fixed some situations, but made others worse. I don't believe there is a fully satisfactory solution, short of putting in a tiny inference engine and a set of rules[1] describing the abilities of mbr and lilo to guide the user to suitable configuration. For Potato, however, any change is probably going to upset someone. Not too many people have complained so far, so perhaps we should consider it a known 'limitation.' Leaving the system unbootable is not nice, though. [1] This could be really neat[2], especially if the entire base setup was handled by a single resolution process (allowing 'bootstrap-installed' to be a sub-goal of 'base-system-installed'). [2] I wouldn't mind having a stab at that myself for Woody. Working out how to simultaneously negotiate[3] with the mbr and lilo installers and the user for a satisfactory configuration would be ... interesting. [3] Perhaps some sort of rule-based configuration broker in the base set-up program. I think the rules would have to obtained out of the packages being installed.[4] [4] But I digress ... Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
