Re: Refactoring commit_changes in partman
On Monday 03 December 2007, Max Vozeler wrote: I've carefully gone through them and noted the differences, hoping to replace them all with a common commit_changes in partman-base/definition.sh I agree that factoring this out makes sense. I've looked over your patch and the thorough analysis and can't see any holes in it. Have you done any testing with the new code? Would be great if you could do that before committing. The only problem I see is that it is not possible to add a versioned depends on -base (= 113) in -partitioning, because -base depends on -partitioning and this would introduce a circular dependency. I don't think a circular dependency would do any harm in this case. Suggest you just add it. Some nitpicks. The changelog entry for partman-base could be a bit more elaborate IMO and should include an explanation why the function was added. I'd also change the changelog entries for the other udebs. Something like: * Code to commit changes factored out to new function commit_changes in definitions.sh. Requires partman-base (= 113). Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#409042: dmsetup executed even if not available
On Sunday 02 December 2007, Frans Pop wrote: The patch for partman-lvm may have fixed the symptom for normal installs, but it is not a structural fix. Similar errors still occurs when a user selects Guided LVM partitioning: /bin/autopartition: 35: dmsetup: not found /bin/autopartition-lvm: 8: dmsetup: not found Forgot to BCC control, but that is probably a good thing as I confused this BR with #425829, which is still open. signature.asc Description: This is a digitally signed message part.
[RFC] Erase LVM/crypto issues and proposed partman reorg
I've spent about 6 hours yesterday looking at #396023 and #425829, the
issues introduced after implementation of support for erasing encrypted
volumes. I've looked at both the original patch and the changes proposed by
Jérémy.
The main issues are that the original patch:
- relies on dmsetup to be loaded basically for all installs
- introduces a lot of code specific to crypto support in partman-auto
- introduces new functions with names that can easily be confused with
existing functions in partman-crypto
The patch proposed by Jérémy has some good ideas and does improve things to
some extend, but the end result is still a spaghetti of interrelated
functions in weird places.
For example, it moves quite a few lvm/crypto specific functions into
definitions.sh in partman-base. As definitions.sh is sourced by almost
every script in partman, I do not think this is desirable.
I also found that I had real problems following the patches and that
stacking major corrections on top of David's original changes is not a good
idea.
I therefore suggest reverting David's changes (which luckily is quite
straightforward) and then first do some refactoring of existing code as
preparation for a reimplementation of support for erasing encrypted
volumes.
For refactoring, I propose the following changes.
1) Rename current wipe functions
Both partman-auto and partman-crypto have wipe functions. In the first case
it is basically erasing existing data on a disk by creating a new disk
label; in the second case it is actually wiping the data on a device.
Using wipe for both is confusing.
I suggest we rename the functions in partman-auto to erase or init
instead of wipe to better match what actually happens.
For partman-crypto I have a patch that renames the existing functions to
include the crypto namespace:
- wipe - crypto_do_wipe
- dev_wipe - crypto_wipe_device
2) Reorder function libraries
We currently have various function libraries: definitions.sh, resize.sh,
recipes.sh, *_tools.sh.
- definitions.sh since long contains more than just definitions
- the various tools libraries don't really contain tools
- in come cases they are starting to contain a somewhat random mix of
functions and scripts that source them often use only a small subset
- they all sit in /lib/partman together with the hook dirs and are only
recognizable because of the .sh extention
I suggest we move all function libraries into /lib/partman/lib/ [1].
definitions.sh could be renamed to just base.sh.
The various *_tools.sh files could be renamed to lvm-base.sh, lvm-*.sh,
auto-base, etc.
This would also lower the barrier to introduce additional new function
libraries when that is warranted.
For definitions.sh I plan to temporarily include a symlink to the current
location to ease the transition. For others that is probably not necessary
if uploads are coordinated.
3) Further reduce memory consumption for LVM and crypto
Both partman-lvm and partman-crypto have huge sets of templates and load
additional modules and library/utility udebs. As they currently are loaded
by default for normal installs, they contribute heavily to D-I's memory
footprint.
I propose we make partman-(auto-){lvm,crypto} optional and create a new
init.d script that only loads them if there is sufficient memory available.
This script should probably just be part of partman-base.
If this is implemented, I also do not have any real problems with depending
on dmsetup-udeb for both lvm and crypto as it would no longer increase the
memory usage for systems that cannot afford it. Still, it would be better
if requiring dmsetup could be avoided for partman-lvm.
4) Possibly create a partman-dm-support udeb
From the current patches to support erasing encrypted volumes, it looks like
partman-lvm and partman-crypto may need to share some code. Moving that
code into partman-base or partman-auto is IMO undesirable, so the best
solution seems to be to create a new udeb for it which both depend on.
Cheers,
FJP
[1] I also considered /usr/share/partman, but it seems better to keep things
together under /lib/partman/. Other idea was to rename all to functions-*.sh
but moving them to a subdir seems clearer. An alternative could be to use
/lib/partman/functions/ instead of /lib/partman/lib/.
signature.asc
Description: This is a digitally signed message part.
Re: How to force d-i to ask for domain name?
Op 02-12-2007 om 14:26 schreef Josef Wolf: On Sat, Dec 01, 2007 at 12:44:30PM +0100, Geert Stappers wrote: snip/ An option might be a modified netcfg. Build the udeb after your hack and place it in the local udeb directory before rebuilding d-i. Sorry, I don't really understand what you try to tell me here. After the An option might be a modified netcfg., I added a few words how to include a modified netcfg. Now more words how to include a modified netcfg: * the source of netcfg is the d-i source under the packages directory * hack the source of netcfg * do dpkg-buildpackage to get a netcfg udeb * place that udeb in the local udeb directory under d-i/installer/build * do ./daily_build build to get your modified d-i Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454159: installation report: successful, through pain and tears however
Package: installation-reports Boot method: netinst CD Image version: daily build 2007-11-25-#2 for amd64, using installer build from sid http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd Date: 2007-11-29 Machine: Dell Precision 490 workstation Processor: 2 x 4-core Intel Xeon E5320 @ 1.86 GHz Memory: 3.25 Go Partitions: [EMAIL PROTECTED]:~$df -Tl Sys. de fich. Type1K-blocs Occupé Disponible Capacité Monté sur /dev/sda6 ext3 2885780286740 2452452 11% / tmpfstmpfs 2026776 0 2026776 0% /lib/init/rw udev tmpfs 10240 120 10120 2% /dev tmpfstmpfs 2026776 0 2026776 0% /dev/shm /dev/sda7 ext3 2885780 77900 2661292 3% /home /dev/sda10ext3 1114724 34256 1023844 4% /tmp /dev/sda8 ext312491804 2198544 9658696 19% /usr /dev/sda9 ext3 1154276213860881784 20% /var /dev/sda2 fuseblk 256003804 1487784 254516020 1% /donnees computer:~#fdisk -l Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xeede9d79 Device Boot Start End Blocks Id System /dev/sda1 * 1255020482843+ 7 HPFS/NTFS /dev/sda22551 34421 256003807+ 7 HPFS/NTFS /dev/sda3 34422 3595112289725 7 HPFS/NTFS /dev/sda4 35952 3891323792265 5 Extended /dev/sda5 35952 36316 2931831 82 Linux swap / Solaris /dev/sda6 36317 36681 2931831 83 Linux /dev/sda7 36682 37046 2931831 83 Linux /dev/sda8 37047 3862612691318+ 83 Linux /dev/sda9 38627 38772 1172713+ 83 Linux /dev/sda10 38773 38913 1132551 83 Linux Output of lspci -nn and lspci -vnn: [EMAIL PROTECTED]:~$lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 5000X Chipset Memory Controller Hub [8086:25c0] (rev 12) 00:02.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 2 [8086:25e2] (rev 12) 00:03.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 [8086:25e3] (rev 12) 00:04.0 PCI bridge [0604]: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7 [8086:25fa] (rev 12) 00:05.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 [8086:25e5] (rev 12) 00:06.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 6 [8086:25e6] (rev 12) 00:07.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 [8086:25e7] (rev 12) 00:10.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Error Reporting Registers [8086:25f0] (rev 12) 00:10.1 Host bridge [0600]: Intel Corporation 5000 Series Chipset Error Reporting Registers [8086:25f0] (rev 12) 00:10.2 Host bridge [0600]: Intel Corporation 5000 Series Chipset Error Reporting Registers [8086:25f0] (rev 12) 00:11.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Reserved Registers [8086:25f1] (rev 12) 00:13.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Reserved Registers [8086:25f3] (rev 12) 00:15.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FBD Registers [8086:25f5] (rev 12) 00:16.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FBD Registers [8086:25f6] (rev 12) 00:1b.0 Audio device [0403]: Intel Corporation 631xESB/632xESB High Definition Audio Controller [8086:269a] (rev 09) 00:1c.0 PCI bridge [0604]: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 [8086:2690] (rev 09) 00:1d.0 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 [8086:2688] (rev 09) 00:1d.1 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 [8086:2689] (rev 09) 00:1d.2 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 [8086:268a] (rev 09) 00:1d.3 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 [8086:268b] (rev 09) 00:1d.7 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller [8086:268c] (rev 09) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d9) 00:1f.0 ISA bridge [0601]: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller [8086:2670] (rev 09) 00:1f.1 IDE interface [0101]: Intel Corporation 631xESB/632xESB IDE Controller [8086:269e] (rev 09) 00:1f.2 IDE interface [0101]: Intel Corporation 631xESB/632xESB/3100 Chipset SATA Storage Controller IDE [8086:2680] (rev 09) 00:1f.3 SMBus [0c05]: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller [8086:269b] (rev 09) 01:00.0 PCI bridge [0604]: Intel Corporation
Re: [RFC] Erase LVM/crypto issues and proposed partman reorg
On Mon, Dec 03, 2007 at 11:26:22AM +0100, Frans Pop wrote: I've spent about 6 hours yesterday looking at #396023 and #425829, the issues introduced after implementation of support for erasing encrypted volumes. I've looked at both the original patch and the changes proposed by Jérémy. Your suggested changes seem sane and I'm very grateful that you spent the time looking into this :) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#428329: Bug in debian-Installer/initramfs when I use GUID Partition Table (GPT) with a crypted root filesystem]
Andreas Gerlich [EMAIL PROTECTED] wrote: In the following screens I setup the same like in the first situation: /boot SWAP / ,, ,, ,, | BOOT | | SWAP | | ROOT | `---*´ `---*´ `*---´ | | | | | | | | | | ,---*--, ,*---, | |sda2_crypt| |sda3_crypt | | | key | | Key| | | random | | Passphrase | | `---*--´ `---*´ | || | || ,-*--, ,-*--,,*-, |sda1| |sda2|| sda3 |/dev/sda `´ `´`--´ (/dev/sda is the 2.3TB Host-drive of the ICP Vortex RAID controller) Ah, I understand now why it fails (see explanation below) ¦ --Install the GRUB boot loader on a hard disk¦ ¦ --Install the LILO boot loader on a hard disk¦ ¦Continue without boot loader ¦ ¦ --Finish the installation¦ ¦Change debconf priority¦ ¦Check the CD-ROM(s) integrity ¦ ¦Save debug logs¦ ¦Execute a shell¦ ¦Abort the installation ¦ ¦ ¦ ¦ ¦ ¦ ¦ +---+ It it necessary to go through GRUB before select LILO !!! What happens if you don't? This sounds like a separate bug report should be filed against the appropriate part of debian-installer (discuss on debian-boot@lists.debian.org if you're unsure which component to report it against). (initramfs) _ (initramfs) cat /proc/cmdline auto BOOT_IMAGE=Linux ro root=fe01 (The information which you request) Aha! root=fe01 means that root is on the block device with major 254 (0xfe) and minor 1 (0x01). Major 254 is device-mapper and devices are dynamically allocated minor numbers starting from 0. This means that when you setup the devices in debian-installer, you got the following layout: /dev/mapper/sda2_crypt (swap), major 254, minor 0 /dev/mapper/sda3_crypt (root), major 254, minor 1 Root is on /dev/mapper/sda3_crypt so lilo encoded root=fe01, but the next time you boot, /dev/mapper/sda3_crypt is brought up first, which gives it major 254, minor 0, which is why it can't be found. I'm pretty certain that everything would have worked if the root device would have been created first during installation (making it /dev/mapper/sda2_crypt with major 254, minor 0) and swap second. So this is not really a bug in cryptsetup, but a problem in the interaction between device-mapper devices and lilo in debian-installer. Unfortunately, I'm not sure what would be the best fix for this, so I've sent a copy of this mail to debian-boot, let's see if we can get some feedback. (For those of you just joining, see #428329 for background info) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Refactoring commit_changes in partman
Hi Frans, On Mon, Dec 03, 2007 at 10:37:32AM +0100, Frans Pop wrote: On Monday 03 December 2007, Max Vozeler wrote: I've carefully gone through them and noted the differences, hoping to replace them all with a common commit_changes in partman-base/definition.sh I agree that factoring this out makes sense. I've looked over your patch and the thorough analysis and can't see any holes in it. Have you done any testing with the new code? Would be great if you could do that before committing. Yes, I've tested -auto-crypto, -auto-lvm, -md, -lvm, -crypto and -partitioning by doing some random setups and injected the two error cases with failing commit.d/init.d scripts. I didn't test -dmraid because I couldn't figure out how, :-) Does dmraid require special hardware? The only problem I see is that it is not possible to add a versioned depends on -base (= 113) in -partitioning, because -base depends on -partitioning and this would introduce a circular dependency. I don't think a circular dependency would do any harm in this case. Suggest you just add it. Tried this and ended up with a Deep recursion configuring partman-base (dep loop?) (IIRC) from main-menu. It seems that main-menu tries to configure partman-base and all its dependencies, and this fails. Some nitpicks. The changelog entry for partman-base could be a bit more elaborate IMO and should include an explanation why the function was added. Agreed, I'll try to write something more of an explanation. Thanks for your review. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Erase LVM/crypto issues and proposed partman reorg
On Mon, Dec 03, 2007 at 11:26:22AM +0100, Frans Pop wrote: I therefore suggest reverting David's changes (which luckily is quite straightforward) and then first do some refactoring of existing code as preparation for a reimplementation of support for erasing encrypted volumes. I tend to agree. The existing code is indeed a bit messy and difficult to follow. Starting to untangle the scripts and cleaning up the code now seems a good idea. David's changes include good code that can be reintroduced later on to a large extent when we can start from a more maintainable code base. 1) Rename current wipe functions For partman-crypto I have a patch that renames the existing functions to include the crypto namespace: - wipe - crypto_do_wipe - dev_wipe - crypto_wipe_device Good change, agreed. In fact I have a patch sitting here that does the exact same change, among others. 2) Reorder function libraries I suggest we move all function libraries into /lib/partman/lib/ [1]. definitions.sh could be renamed to just base.sh. The various *_tools.sh files could be renamed to lvm-base.sh, lvm-*.sh, auto-base, etc. This would also lower the barrier to introduce additional new function libraries when that is warranted. Yep, this seems worthwile. I'm willing to put in some work to help deal with the implementation and fallout of this and the other proposed changes, (and eventually contribute to the reimplementation of the removal of crypto devices). I'm happy to set aside some time this weekend and review or test changes. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453749: Fix serial console detection on ia64
Thanks for your responses. As I was writing this report, I began to wonder why exactly the proc trick doesn't work on some ia64 configs - I'm investigating this now. If I can find a workable solution there, we may be able to forego these changes - if not, I'll regenerate new patches based on your comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 453749 to rootskel, found 453749 in 1.57
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.11 reassign 453749 rootskel Bug#453749: Fix serial console detection on ia64 Bug reassigned from package `finish-install' to `rootskel'. found 453749 1.57 Bug#453749: Fix serial console detection on ia64 Bug marked as found in version 1.57. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453749: simpler solution
I couldn't find any difference in how the kernel was setting up the console that would affect the /proc/$dipid/fd/0 link, so I started looking into userspace. Busybox's console_init() tries to find and use the real console device. It starts by checking to see if its a serial device in much the same way that serial-console-info does. After determining what it thinks *should* be the right device name, init tries to open that device file. If this fails, it falls back to using /dev/console, which I believe leads to this problem. It turns out that rootskel init only creates two serial devices before calling busybox init - ttyS0 and ttyS1. My system where /proc/$dipid/fd/0 was pointing to /dev/console used ttyS3 as the real console, while my system where /proc/$dipid/fd/0 pointed to the real device used ttyS0. ttyS3 as a serial console is very commonplace for HP ia64 systems, as this is the device typically emulated by the management processor to make the console available over the network. Index: debian/changelog === --- debian/changelog(revision 50286) +++ debian/changelog(working copy) @@ -1,3 +1,11 @@ +rootskel (1.58) UNRELEASED; urgency=low + + * Create more serial device files in the ramdisk before calling +busybox init, in case they are needed for a serial console. +Closes: #453749. + + -- dann frazier [EMAIL PROTECTED] Mon, 03 Dec 2007 20:25:03 -0700 + rootskel (1.57) unstable; urgency=low * debian-installer-startup.d/S02netwinder-net: restructure so Index: src/lib/debian-installer/init-udev-devices === --- src/lib/debian-installer/init-udev-devices (revision 50286) +++ src/lib/debian-installer/init-udev-devices (working copy) @@ -13,6 +13,6 @@ for i in 0 1 2 3 4; do makedev 600 /dev/tty$i c 4 $i done -for i in 0 1; do +for i in 0 1 2 3; do makedev 600 /dev/ttyS$i c 4 $(($i + 64)) done -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation on NSLU2 does not complete (initramfs nslu2 hook requires user interaction)
* Gordon Farquharson [EMAIL PROTECTED] [2007-12-03 00:12]: nslu2-utils is version 0.10+r71-13, but I don't see any changes to the initramfs hook that should cause this problem. I am using a DFSG image that does not contain the NPE-B firmware. I guess the best way this should be handled is to look whether the interface assigned to the ixp driver is actually in use. I've no idea how to do this though, although I suspect it might be possible to do it using udev. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
