Bug#968391: Please support the Librem 5
Hi, On Mon, Aug 24, 2020 at 11:24:25AM -0700, Vagrant Cascadian wrote: > Control: tags 968391 pending > > On 2020-08-24, Guido Günther wrote: > > On Fri, Aug 14, 2020 at 11:36:50AM +0200, Guido Günther wrote: > >> To make it simpler to run plain Debian on the Librem 5 it would be great > >> to have flash-kernel support. The device tree is in the process of being > >> upstreamed: > >> > >> > >> https://lore.kernel.org/linux-arm-kernel/20200731082725.21878-1-martin.kepplin...@puri.sm/ > >> > >> Patch at: > >> > >> > >> https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/22 > ... > > The DTS is in linux-next now so on it's way for 5.10: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dts > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts > > Merged. Thanks for the patches! Thanks for merging! -- Guido > > live well, > vagrant
Bug#968391: Please support the Librem 5
Hi, On Fri, Aug 14, 2020 at 11:36:50AM +0200, Guido Günther wrote: > Package: flash-kernel > Version: 3.102 > Severity: wishlist > Tags: patch > > To make it simpler to run plain Debian on the Librem 5 it would be great > to have flash-kernel support. The device tree is in the process of being > upstreamed: > > > https://lore.kernel.org/linux-arm-kernel/20200731082725.21878-1-martin.kepplin...@puri.sm/ > > Patch at: > > https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/22 > > Remaining blockers for using plain Debian are uboot and atf support but > the uboot/atf shipped with the device is able to boot Debian kernels > just fine. The DTS is in linux-next now so on it's way for 5.10: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dts https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts Cheers, -- Guido > > Cheers, > -- Guido > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), > (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armhf, arm64 > > Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages flash-kernel depends on: > ii debconf [debconf-2.0] 1.5.74 > pn devio > ii initramfs-tools0.137 > ii linux-base 4.6 > ii mtd-utils 1:2.1.1-1 > ii ucf3.0042 > > Versions of packages flash-kernel recommends: > ii u-boot-tools 2020.04+dfsg-2 > > flash-kernel suggests no packages.
Bug#968391: Please support the Librem 5
Package: flash-kernel Version: 3.102 Severity: wishlist Tags: patch To make it simpler to run plain Debian on the Librem 5 it would be great to have flash-kernel support. The device tree is in the process of being upstreamed: https://lore.kernel.org/linux-arm-kernel/20200731082725.21878-1-martin.kepplin...@puri.sm/ Patch at: https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/22 Remaining blockers for using plain Debian are uboot and atf support but the uboot/atf shipped with the device is able to boot Debian kernels just fine. Cheers, -- Guido -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.74 pn devio ii initramfs-tools0.137 ii linux-base 4.6 ii mtd-utils 1:2.1.1-1 ii ucf3.0042 Versions of packages flash-kernel recommends: ii u-boot-tools 2020.04+dfsg-2 flash-kernel suggests no packages.
Bug#788062: tagging 788062
Hi Thomas, On Mon, Sep 28, 2015 at 02:10:11PM +0200, Thomas Lange wrote: > tags 788062 + pending Is there any link to a discussion how this is going to be fixed, anything I can help with? I discussed with Nigel (cc:) if this needs to be fixed by using ro,noload when mounting the partition via grub-mount? The bug seems to be there since at least /usr/lib/os-probes/50mounted-tests invokes grub-mount which should use "noload"[1] for the fuse mount (IIRC). Cheers, -- Guido [1] http://www.kernel.org/doc/Documentation/filesystems/ext4.txt
Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
Hi, On Wed, Apr 01, 2015 at 07:54:52PM +0200, Cyril Brulebois wrote: Hi, and sorry for the lag. Sam McLeod s...@fastmail.com (2015-03-07): Thanks Cyril, I did indeed miss that, that's great - I'll test it today. It looks like the example pressed hasn't been updated to include this feature: https://www.debian.org/releases/jessie/example-preseed.txt This seems to be fixed by: 69619 sthibault # Due notably to potential USB sticks, the location of the MBR can not be 69619 sthibault # determined safely in general, so this needs to be specified: 69619 sthibault #d-i grub-installer/bootdev string /dev/sda 69619 sthibault # To install to the first device (assuming it is not a USB stick): 69619 sthibault #d-i grub-installer/bootdev string default Just wanted to confirm that adding: d-i grub-installer/bootdev string default to the preseed.cfg file Petter mentioned in the very beginning of this thread[1] makes the Jessie install succeed without prompts for me in a kvm virt-install installation so it indeed looks fixed. Cheers, -- Guido (svn blame en/appendix/preseed.xml in the manual; confirmed by looking at the website now.) Mraw, KiBi. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712907#10
Bug#629146: installation-reports: netinst ISO from 6/3/2011 faulty: cdrom-retriever: error: No components listed in /cdrom/dists/stable/Release
On Fri, Jun 03, 2011 at 11:53:29PM +0200, Paul Menzel wrote: [..snip..] Jun 3 21:33:09 anna[1861]: grep: /cdrom/dists/stable/Release: No such file or directory Jun 3 21:33:09 cdrom-retriever: error: No components listed in /cdrom/dists/stable/Release. Jun 3 21:33:48 anna[1861]: WARNING **: bad d-i Packages file Jun 3 21:33:48 anna[1861]: grep: /cdrom/dists/stable/Release: No such file or directory Jun 3 21:33:48 cdrom-retriever: error: No components listed in /cdrom/dists/stable/Release. Jun 3 21:33:49 anna[1861]: WARNING **: bad d-i Packages file Jun 3 21:33:49 anna[1861]: grep: /cdrom/dists/stable/Release: No such file or directory Jun 3 21:33:49 cdrom-retriever: error: No components listed in /cdrom/dists/stable/Release. Jun 3 21:34:11 anna[1861]: WARNING **: bad d-i Packages file I can confirm this with the images from today (16-Jul-2011). The installer looks in dists/stable but the iso has dists/testing. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110716231452.ga17...@bogon.sigxcpu.org
Bug#630424: Maybe a Problem with tip22
Hi Dann, On Tue, Jul 05, 2011 at 05:29:04PM -0600, dann frazier wrote: On Sun, Jun 19, 2011 at 01:35:28PM +0200, Guido Günther wrote: On Sun, Jun 19, 2011 at 02:39:05AM -0700, Edwin Kwan wrote: Hi Guido, Your package tested out OK. I only have an Indy. So I only tried tip22. Thanks for testing! I've uploaded a new version to unstable. I'm not sure what's the correct procedure to get the installer images rebuilt with that for the next point release though. Can somebody from debian-boot shed some light on this? I assume it includes uploading a new arcboot version to stable-proposed-updates but is that enough? Cheers, -- Guido I believe what needs to be done is: 1) Propose an arcboot update for squeeze. You can coordinate this with the stable release team on debian-release@l.d.o. Please include a debdiff vs. current squeeze. 2) Once that's accepted, we need to ask the mips buildd maintainer to ensure this update gets included in the squeeze chroot(s). 3) Finally, we need to do a d-i rebuild (which we usually do with each point release anyway). You can coordinate with me on that. Thanks for the heads up, besides 2) it's what Adam suggested: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631007 I'll add that to the report. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110706164858.ga7...@bogon.sigxcpu.org
Bug#630424: Maybe a Problem with tip22
On Sun, Jun 19, 2011 at 02:39:05AM -0700, Edwin Kwan wrote: Hi Guido, Your package tested out OK. I only have an Indy. So I only tried tip22. Thanks for testing! I've uploaded a new version to unstable. I'm not sure what's the correct procedure to get the installer images rebuilt with that for the next point release though. Can somebody from debian-boot shed some light on this? I assume it includes uploading a new arcboot version to stable-proposed-updates but is that enough? Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110619113528.ga24...@bogon.sigxcpu.org
Bug#630424: Maybe a Problem with tip22
On Thu, Jun 16, 2011 at 02:15:56AM -0700, Edwin Kwan wrote: I don't know whether the kernel and initrd were released separately. But I could extract them from the bad netboot-boot.img using objdump and dd by just looking for the symbols __kernel_start, __kernel_end and __rd_start, __rd_end. I actually modified ld.script.IP22 by putting 0x89702000 in the start address and built myself a netboot image using the extracted kernel and initrd. I got to the installer screen but I don't need to reinstall right now. :) Geat, could you also try to use http://honk.sigxcpu.org/linux-mips/arcboot/tip22_0.3.14_mips.deb to build that image? This should fix the issue. It also fixes the messed up addresses on IP32. Cheers, -- Guido Guido Günther wrote: Hi, On Tue, Jun 14, 2011 at 02:22:17AM -0700, Edwin Kwan wrote: Hi, The screen shot in Attilio's bug report was done by me on my Indy. I am not experienced in this beginning of the universe kind of code. But I found the following clues which may be useful. I can reproduce the problem here now. A the same kernel+initrd that works with 0.3.12 doesn't with 0.3.13 (unlucky number it seems). I try come up with a patch during the next couple of days. BTW can I directlry fetch the initrd and kernel that was used to build: http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-mips/current/images/r4k-ip22/netboot-boot.img I thought these used to be on the mirrors but can't seem to find them. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110616215111.ga8...@bogon.sigxcpu.org
Bug#630424: Maybe a Problem with tip22
Hi, On Tue, Jun 14, 2011 at 02:22:17AM -0700, Edwin Kwan wrote: Hi, The screen shot in Attilio's bug report was done by me on my Indy. I am not experienced in this beginning of the universe kind of code. But I found the following clues which may be useful. I can reproduce the problem here now. A the same kernel+initrd that works with 0.3.12 doesn't with 0.3.13 (unlucky number it seems). I try come up with a patch during the next couple of days. BTW can I directlry fetch the initrd and kernel that was used to build: http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-mips/current/images/r4k-ip22/netboot-boot.img I thought these used to be on the mirrors but can't seem to find them. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110615205556.ga19...@bogon.sigxcpu.org
Re: Multipath support in Squeeze
Hi Frans, On Wed, Mar 10, 2010 at 01:56:57AM +0100, Frans Pop wrote: Hi Guido, What's the status of multipath support in Squeeze? Especially given the switch to grub2. To be honset I don't know. I haven't had the time to check multipath d-i after squeeze. I'll try to find some time to look into this but am not very confident that this will happen soon. If anybody wants to try it out: I did most of the later testing with qemu and SCSI disks so no real SAN or iSCSI target required. Cheers, -- Guido Could you perhaps update the wiki page [1]? It currently refers to loads of closed bug reports, which only makes one wonder. If possible, please clarify the status both for Lenny and for Squeeze. TIA. Cheers, FJP [1] http://wiki.debian.org/DebianInstaller/MultipathSupport -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100311161541.ga11...@bogon.sigxcpu.org
Re: UUID in fstab for device mapper devices?
On Wed, Sep 02, 2009 at 08:13:09PM +0200, Max Vozeler wrote: Hi Guido, On Sun, Aug 09, 2009 at 01:32:42PM +0200, Guido Günther wrote: What's the reasoning for using UUID= instead of /dev/disk/by-uuid/ in fstab? Non udev systems? I wanted to research this question, took me a bit. The non-udev case you mentioned is the only reason I could make out for going with UUID= rather than /dev/disk/by-uuid/. In the multipath case we have to rely on udev anyway so we can easily use the /dev/disk/by-uuid/ version. Those systems rely on mount using blkid to find the matching partition and mount only does it itself when the UUID= notation is used in fstab. Which isn't the best thing to do with e.g. multipath and some other solutions. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Hi Ferenc,
On Sun, Aug 09, 2009 at 09:31:48PM +0200, Ferenc Wagner wrote:
Guido Günther a...@sigxcpu.org writes:
On Sun, Aug 09, 2009 at 04:57:28PM +0200, Ferenc Wagner wrote:
OK, so the problem is identifying multipath devices in d-i. So that
option would be better called d-i_friendly_names, because from the
user PoV losing name persistence -- which this option implies --,
isn't friendly or useful, in my opinion. If only multipath used
To avoid we're furhter talking past each other: which device names
aren't persistent from your PoV when using user_friendly_names?
I was wrong. The friendly mpathn names are persistent, because
/var/lib/multipath/bindings takes care of the persistence. But they
are arbitrary, and subject to change between machines. (Actually,
I've never used them, please correct me if I'm wrong again.)
It's correct this way. The names are of course persistent across reboots
since they're stored in a mapping file but not persistent across
machines. Good to have this sorted out.
Dropping user_friendly_names won't give you name persistence with and
without mp all by itself. You'll either have to use disk/by-id or
disk/by-uuid to achive that.
Why not? The WWIDs, which are used to name the devices by default,
are persistent and also consistent between machines, aren't they?
Yes, these are persistent across machines but they aren't persistent as
to switching multipath on and off (see below).
I've been using them on this assumption for years, and it seems to
work out... Please explain why the udev symlinks would be any better
(given that I'm not interested in using filesystem UUIDs).
We could have the same fstab with and without multipath. This would be
convenient for our users since they'd have easier means of error
recovery (and an easy way to turn multipath on and off):
Without multipath:
/dev/disk/by-uuid/UUID - /dev/sdaY
With multipath:
/dev/disk/by-uuid/UUID - /dev/mapper/WWID-partY
Udev would handle this transparently. Something similar can possibly be
done by looking at /dev/disk/by-id/scsi-WWID-partY (using the WWID
instead of the fs UUID) but I'd have to check the details for that.
To get really friendly names, I define aliases in multipath.conf, but
that's mostly sugar, I could do without them. Losing name consistency
amongst different machines would be a major inconvenience, though.
I wouldn't object getting rid of user_friendly_names in multipath.conf,
but preferably by switching to /dev/disk/by-{uu,}id then.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Mon, Aug 10, 2009 at 12:20:30PM +0200, Ferenc Wagner wrote:
Guido Günther a...@sigxcpu.org writes:
On Sun, Aug 09, 2009 at 09:31:48PM +0200, Ferenc Wagner wrote:
Guido Günther a...@sigxcpu.org writes:
Dropping user_friendly_names won't give you name persistence with
and without mp all by itself. You'll either have to use disk/by-id
or disk/by-uuid to achive that.
Why not? The WWIDs, which are used to name the devices by default,
are persistent and also consistent between machines, aren't they?
Yes, these are persistent across machines but they aren't persistent
as to switching multipath on and off (see below).
Hi Guido,
Thanks, I got your point now.
We could have the same fstab with and without multipath. This would
be convenient for our users since they'd have easier means of error
recovery (and an easy way to turn multipath on and off):
And to run without multipath without noticing until the first path
failure.
Without multipath:
/dev/disk/by-uuid/UUID - /dev/sdaY
With multipath:
/dev/disk/by-uuid/UUID - /dev/mapper/WWID-partY
Multipath is critical enough in my systems that I prefer explicit
control and early failure dealing with it. Others may have different
preferences, of course.
I see your point. Maybe we can even have both /dev/mapper/wwid as well
as /dev/disk/by-uuid/ support in d-i. This would be even simpler if d-i
would use /dev/disk/by-uuid instead of UUID= by default. Is there any
good reason not to do this? Udevless systems?
Also, how does this carry over to multipathed root? I'd guess
initramfs needs the real device name after root= anyway, doesn't it?
Haven't checked but shouldn't a /dev/disk/by-id/ path also work. We have
all the stuff up in the initramfs already.
To get really friendly names, I define aliases in multipath.conf,
but that's mostly sugar, I could do without them. Losing name
consistency amongst different machines would be a major
inconvenience, though.
I wouldn't object getting rid of user_friendly_names in
multipath.conf, but preferably by switching to /dev/disk/by-{uu,}id
then.
I'd welcome that. It may not be the exact thing I'd want, but good
enough to start from. I may as well get to love it in the end. :)
Now we only need somebody to work on that ;) Seriously: I won't be able
to spend much time working on it in the near future but at least we have
a direction where we should be heading.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote:
Guido Günther a...@sigxcpu.org writes:
On Fri, Aug 07, 2009 at 04:28:46PM +0200, Max Vozeler wrote:
we recently changed d-i (partman-target, to be precise) to use
UUIDs in fstab in order to get stable device naming. [...]
Since then, we concluded that it is preferable to go back to plain
/dev/mapper/ paths for LVM LVs because those already provide stable
device naming (and are more descriptive).
And filesystem UUIDs are pretty useless as soon as you start using LVM
snapshots, dd backups or multipath for example.
ENV{DM_UUID}==mpath-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
[...]
This is what should idealy be used in d-i for multipath device naming.
We could then start to remove the hacks that use /dev/mapper/mpath* to
reference multipath devices then.
My limited experience shows that multipath uses unique /dev/mapper/WWID
device names by default, or the configured name, as Bastian mentioned.
Is that because I'm lucky, and other types of multipaths don't behave
so nice? Also, I haven't seen mpath-names apart from an obscure
multipath.conf option...
It uses the WWID, the configured name (via multipath.conf) or mpathX if
you set user_friendly_names=yes - which we currently use in d-i to have
an easy way to identify multipath devices.
Anyway, an unfortunate multipath/LVM interaction should also be
considered: without special configuration in lvm.conf, the PV scan
finds the LVM metadata on the individual paths as well as on the
multipath device, then tries to create mappings straight onto the
first path, skipping the multipath layer. Of course it fails, because
that device isn't available any more, but the error is rather hard to
diagnose from the initramfs prompt.
This can be fixed by preferring /dev/mapper/mpathX names.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Sat, Aug 08, 2009 at 04:03:38PM +0200, Max Vozeler wrote: Hi all, Attempt to summarize the discussion so far (please correct): 1) We should use /dev/mapper/ paths rather than UUID in the fstab entries for all device mapper devices. 2) For some type of device mapper devices (multipath), using the /dev/disk/by-id/ symlinks would be better than /dev/mapper/. The last point only makes sense if we work on a stable device naming with _and_ without multipath. I think Novell does this with /dev/disk/by-id/scsi-X-partY. This points to the underlying block device(s) (e.g. /dev/sda1) without multipath and points to /dev/mapper/wwwid-partY when turning on multipath. Looking at /dev/disk/by-uuid/ also seems to do the trick: it points to /dev/sdaY without and to /dev/mapper/wwid-partY with multipath. So if we'd use this turning multipath on and off would be transparent to the user. What's the reasoning for using UUID= instead of /dev/disk/by-uuid/ in fstab? Non udev systems? Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Sun, Aug 09, 2009 at 04:57:28PM +0200, Ferenc Wagner wrote: OK, so the problem is identifying multipath devices in d-i. So that option would be better called d-i_friendly_names, because from the user PoV losing name persistence -- which this option implies --, isn't friendly or useful, in my opinion. If only multipath used To avoid we're furhter talking past each other: which device names aren't persistent from your PoV when using user_friendly_names? Dropping user_friendly_names won't give you name persistence with and without mp all by itself. You'll either have to use disk/by-id or disk/by-uuid to achive that. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Hi Max,
thanks for bringing this up!
On Fri, Aug 07, 2009 at 04:28:46PM +0200, Max Vozeler wrote:
[Resend to @packages.debian.org]
Hello fellow maintainers,
we recently changed d-i (partman-target, to be precise) to use
UUIDs in fstab in order to get stable device naming.
So you're using /dev/disk/by-uuid/uuid in /etc/fstab?
Currently UUIDs are used for all devices except
- /dev/fd*
- cryptsetup mappings
- those specified by explicit /dev/disk/by-* paths
I'm confused. Doesn't every disk have symlnks in /dev/disk/by-id (even
LVM LVs)?
Since then, we concluded that it is preferable to go back to plain
/dev/mapper/ paths for LVM LVs because those already provide stable
device naming (and are more descriptive).
What about your types of devices? (dmraid, multipath)
multipath.udev sets up these links for persistent device naming:
# Create persistent links for multipath tables
ENV{DM_UUID}==mpath-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
# Create persistent links for dmraid tables
ENV{DM_UUID}==dmraid-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
# Create persistent links for partitions
ENV{DM_PART}==?*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}-part$env{DM_PART}
This is what should idealy be used in d-i for multipath device naming.
We could then start to remove the hacks that use /dev/mapper/mpath* to
reference multipath devices then.
I'd be happy to help to get this working for Squeeze.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the second run of research about ext4 support in bootloaders
On Tue, Jun 02, 2009 at 06:58:14PM +0200, Stefano Canepa wrote: Hi all, I continued my research about ext4 support in bootloaders and this is the result till now: ext4 support * grub: amd64, i386, powerpc w/ ubuntu patch * grub2: amd64, i386, powerpc * lilo-installer: amd64 i386 Looks without ext4 support * aboot: alpha * yaboot: powerpc * arcboot: mips Arcboot statically links against e2fslib so this shouldn't be much of an issue. * silo: sparc * delo: mipsel Same here IIRC. -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for testing of RC2 images
On Fri, Jan 30, 2009 at 07:39:54PM -0200, Otavio Salvador wrote: Guido Günther a...@sigxcpu.org writes: Frans Pop schrieb: On Friday 30 January 2009, Guido Günther wrote: The i386 businesscard iso lacks the libaio1-udeb so multipath -l won't work due to lack of libaio.so.1 and the system fails to detect multipath. Can the libaio1-udeb be added? Why isn't it being pulled in as a dependency? The installer tries to, but it's not available on the CD: Jan 30 15:58:00 anna-install: Installing multipath-udeb Jan 30 15:58:00 anna[8103]: DEBUG: resolver (libaio1-udeb): package doesn't exist (ignored) Jan 30 15:58:00 anna[8103]: DEBUG: resolver (kernel-image-2.6.26-1-486-di): package doesn't exist (ignored) Jan 30 15:58:00 anna[8103]: DEBUG: retrieving multipath-modules-2.6.26-1-486-di 1.76 Jan 30 15:58:00 anna[8103]: DEBUG: retrieving multipath-udeb 0.4.8-13 It works fine when using netinst (at least the last time I checked). Cheers, I've fixed it in debian-cd SVN but I don't think a new full image build is worth just for it. This will be fixed in dailies and in final images, obviously ;-) Mind to test dailies and check if it works? Works like a charm now with the daily built i386 business card iso. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Updated multipath patch for grub-legacy
On Thu, Jan 29, 2009 at 04:27:54PM +0100, Guido Günther wrote: Hi, Attached is an updated version of the multipath support patch for grub-legacy. It applies cleanly to 0.97-47lenny2. It's the only missing piece for getting multipath support to work in lenny's d-i: http://wiki.debian.org/DebianInstaller/MultipathSupport I just double checked that installing an accordingly patched grub into /target is enough to make d-i pass smoothly on a multipath setup with the business card iso as of today. -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#442382: Updated multipath patch for grub-legacy
tags 442382 + patch thanks On Sat, Jan 31, 2009 at 09:16:27PM +0100, Robert Millan wrote: tags 442382 - patch thanks On Thu, Jan 29, 2009 at 04:27:54PM +0100, Guido Günther wrote: +--- a/lib/device.c.org 2009-01-29 13:31:54.0 +0100 b/lib/device.c 2009-01-29 13:38:48.0 +0100 This is not the right place. We use grub-mkdevicemap for all new device types, please modify that instead. Please read the patch carefully. I know that we use grub-mkdevicemap for device map generation. The important part of the patch is the last hunk. Independent of the probing (which we currently don't need in d-i, since we use the workaround dmraid uses) we need to pick the right *partition* name [1]. The rest of the patch is just to bring it in line with e.g. cciss, we keep the probing code around for that too. Anyways, I will stop bothering you now, it's just too tiresome and we have workarounds. Cheers, -- Guido [1] and I'd accept any criticism that the code there is far too generic and might incorrectly match LVM volumes but that didn't come up since the first verion was posted about 1.5 years ago. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for testing of RC2 images
Hi Otavio, On Thu, Jan 29, 2009 at 11:19:17AM -0200, Otavio Salvador wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, The Debian-CD Team has built the images based on RC2 installer and I'd like to ask for some tests before we finally announce the release. The images are available at http://cdimage.debian.org/cdimage/.lenny_bibble/ Please send feedback to the mailing list (even successful ones). The i386 businesscard iso lacks the libaio1-udeb so multipath -l won't work due to lack of libaio.so.1 and the system fails to detect multipath. Can the libaio1-udeb be added? After installing the udeb manually everything works smoothly. Installation was done in KVM 83 using disk-detect/multipath/enable=true Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for testing of RC2 images
Frans Pop schrieb: On Friday 30 January 2009, Guido Günther wrote: The i386 businesscard iso lacks the libaio1-udeb so multipath -l won't work due to lack of libaio.so.1 and the system fails to detect multipath. Can the libaio1-udeb be added? Why isn't it being pulled in as a dependency? The installer tries to, but it's not available on the CD: Jan 30 15:58:00 anna-install: Installing multipath-udeb Jan 30 15:58:00 anna[8103]: DEBUG: resolver (libaio1-udeb): package doesn't exist (ignored) Jan 30 15:58:00 anna[8103]: DEBUG: resolver (kernel-image-2.6.26-1-486-di): package doesn't exist (ignored) Jan 30 15:58:00 anna[8103]: DEBUG: retrieving multipath-modules-2.6.26-1-486-di 1.76 Jan 30 15:58:00 anna[8103]: DEBUG: retrieving multipath-udeb 0.4.8-13 It works fine when using netinst (at least the last time I checked). Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for testing of RC2 images
On Fri, Jan 30, 2009 at 07:39:54PM -0200, Otavio Salvador wrote: Guido Günther a...@sigxcpu.org writes: Frans Pop schrieb: On Friday 30 January 2009, Guido Günther wrote: The i386 businesscard iso lacks the libaio1-udeb so multipath -l won't work due to lack of libaio.so.1 and the system fails to detect multipath. Can the libaio1-udeb be added? Why isn't it being pulled in as a dependency? The installer tries to, but it's not available on the CD: Jan 30 15:58:00 anna-install: Installing multipath-udeb Jan 30 15:58:00 anna[8103]: DEBUG: resolver (libaio1-udeb): package doesn't exist (ignored) Jan 30 15:58:00 anna[8103]: DEBUG: resolver (kernel-image-2.6.26-1-486-di): package doesn't exist (ignored) Jan 30 15:58:00 anna[8103]: DEBUG: retrieving multipath-modules-2.6.26-1-486-di 1.76 Jan 30 15:58:00 anna[8103]: DEBUG: retrieving multipath-udeb 0.4.8-13 It works fine when using netinst (at least the last time I checked). Cheers, I've fixed it in debian-cd SVN but I don't think a new full image build is worth just for it. This will be fixed in dailies and in final images, obviously ;-) Sure. It's not really important for rc2 Mind to test dailies and check if it works? Will try to do so during the next couple of days. Thanks for fixing this up. -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Updated multipath patch for grub-legacy
Hi,
Attached is an updated version of the multipath support patch for
grub-legacy. It applies cleanly to 0.97-47lenny2. It's the only
missing piece for getting multipath support to work in lenny's d-i:
http://wiki.debian.org/DebianInstaller/MultipathSupport
Cheers,
-- Guido
diff --git a/debian/patches/00list b/debian/patches/00list
index 8b7b969..42337cc 100644
--- a/debian/patches/00list
+++ b/debian/patches/00list
@@ -25,6 +25,7 @@ intelmac.diff
crossreference_manpages.diff
ext3_256byte_inode.diff
use_grub-probe_in_grub-install.diff
+multipath.diff
# We aren't building amd64 binaries, see #244498
#fix_amd64_compile.diff
diff --git a/debian/patches/multipath.diff b/debian/patches/multipath.diff
new file mode 100644
index 000..040a9a5
--- /dev/null
+++ b/debian/patches/multipath.diff
@@ -0,0 +1,54 @@
+--- a/lib/device.c.org 2009-01-29 13:31:54.0 +0100
b/lib/device.c 2009-01-29 13:38:48.0 +0100
+@@ -567,6 +567,12 @@
+ }
+
+ static void
++get_mpath_disk_name (char *name, int path)
++{
++ sprintf (name, /dev/mapper/mpath%d, path);
++}
++
++static void
+ get_ataraid_disk_name (char *name, int unit)
+ {
+ sprintf (name, /dev/ataraid/d%c, unit + '0');
+@@ -1083,6 +1089,29 @@
+ }
+ }
+ }
++
++ /* This is for multipath with userfriendly_names=yes and the default udev
++ rules: /dev/mapper/mpathpath-partpartition */
++ {
++int path;
++
++for (path= 0; path 9; path++)
++ {
++char name[24];
++
++get_mpath_disk_name (name, path);
++if (check_device (name))
++ {
++ (*map)[num_hd + 0x80] = strdup (name);
++ assert ((*map)[num_hd + 0x80]);
++
++ /* If the device map file is opened, write the map. */
++ if (fp)
++ fprintf (fp, (hd%d)\t%s\n, num_hd, name);
++ num_hd++;
++ }
++ }
++ }
+ #endif /* __linux__ */
+
+ /* OK, close the device map file if opened. */
+@@ -1151,6 +1180,8 @@
+ (strncmp (dev, /dev/cciss/, 11) == 0) ||
+ (strncmp (dev, /dev/rd/, 8) == 0))
+ strcpy (dev + strlen(dev), p);
++ else if (strncmp (dev, /dev/mapper/mpath, 17) == 0)
++strcpy (dev + strlen(dev), -part);
+ }
+ sprintf (dev + strlen(dev), %d, ((partition 16) 0xFF) + 1);
+
please unblock multipath-tools 0.4.18-4
Hi,
please allow multipath-tools 0.4.8-14 into lenny. It fixes partition
handling on devices 2TB and a failure to detect the necessary block
device info from /sys with kernels = 2.6.27. The rest is a
documentation update and a new translation.
The detailed list of changes with links to the commit diffs can browsed
here:
https://honk.sigxcpu.org/cl2vcs/index.cgi?pkg=multipath-tools
The debdiff is attached.
Cheers,
-- Guido
P.S.: cc'ing debian-boot since the package ships a udeb
File lists identical (after any substitutions)
Control files of package kpartx: lines which differ (wdiff format)
--
Installed-Size: [-152-] {+160+}
Version: [-0.4.8-13-] {+0.4.8-14+}
Control files of package multipath-tools: lines which differ (wdiff format)
---
Depends: libaio1 (= 0.3.106-8), libc6 (= 2.7-1), libdevmapper1.02.1 (=
2:1.02.20), libncurses5 (= 5.6+20071006-3), libreadline5 (= 5.2), udev (=
0.124), initscripts (= 2.85-16), kpartx (= [-0.4.8-13),-] {+0.4.8-14),+}
lsb-base (= 3)
{+.+}
{+ If you install this package you may have to change the way you address
block+}
{+ devices. See README.Debian for details.+}
Version: [-0.4.8-13-] {+0.4.8-14+}
Control files of package multipath-tools-boot: lines which differ (wdiff format)
Depends: debconf (= 0.5) | debconf-2.0, initramfs-tools, multipath-tools (=
[-0.4.8-13)-] {+0.4.8-14)+}
Don't install this package if you're not booting from a multipath [-device-]
{+device.+}
Version: [-0.4.8-13-] {+0.4.8-14+}
Control files of package multipath-udeb: lines which differ (wdiff format)
--
Installed-Size: [-372-] {+380+}
Version: [-0.4.8-13-] {+0.4.8-14+}
signature.asc
Description: Digital signature
Bug#473401: grub-installer: grub2 config for Windows partition does not boot
On Mon, Dec 01, 2008 at 12:12:42AM +0100, Robert Millan wrote:
For multipath, I'm not familiar with how it works, and speficically what
does grub-installer do to support it, so I don't know.
Support for multipath in grub-installer is modeled straight after dmraid.
It gets the relevant disk and partition via a call to multipath -l and
then installs grub like:
TERM=linux $chroot $ROOT \
grub --device-map=/dev/null /var/log/grub-${frtype}.log 21
/dev/null EOF
device (hd0,$frgrubroot) $disc_offered
device (hd0) $frdev
root (hd0,$frgrubroot)
setup (hd0)
quit
EOF
This broke as soon as we switched from grub legacy to grub2, so it
probably doesn't hurt much as folks have to fetch a patched grub
(#442381) legacy and install it by hand anyway:
http://wiki.debian.org/DebianInstaller/MultipathSupport
Debian's relevance in these HA storage areas is quiet low anyway and
since RHEL and SLES suport it nicely:
http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide
it's probably not worh bothering too much at all.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473401: grub-installer: grub2 config for Windows partition does not boot
On Sat, Nov 29, 2008 at 10:56:28PM +0100, Robert Millan wrote: [..snip..] Status update: - vdX and xvdX are supported - ida is supported - i2o is supported - I don't know the status of multipath, except that GRUB never supported it. I know grub-installer has some hack which is supposed to make it work, but I have no idea if my proposed change would break that or not The hack to grub installer is basically the same as what dmraid used. It needs a one line fix in grub legacy too: http://git.debian.org/?p=users/agx/grub-legacy.git;a=commit;h=e6dfc970b49a1dbc91ce33f67fa095f89a533a67 Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504095: installation-report: xen paravirt installation
Hi Ian, On Fri, Oct 31, 2008 at 04:32:16PM +, Ian Campbell wrote: On Fri, 2008-10-31 at 17:22 +0100, Bastian Blank wrote: On Fri, Oct 31, 2008 at 04:31:00PM +0100, Guido Günther wrote: So to me it seems the workaround can be removed: * removed for VIA Ester altogeher * removed vor VIA Nehemiah once we ship 2.6.27 Please read #464962 first. OK, so I think the upshot of that long thread is that kernel 2.6.26-8 removed the long nops so even the Nehemiah chips can go back to using 686 kernels and we should just revert svn r55059 altogether. This is unfixed in RC1. Is there a problelm in reverting r55059 or has this just been forgotten? Anything I can help with? Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504095: installation-report: xen paravirt installation
On Fri, Nov 21, 2008 at 03:31:42PM +, Ian Campbell wrote: On Fri, 2008-11-21 at 16:20 +0100, Guido Günther wrote: Hi Ian, On Fri, Oct 31, 2008 at 04:32:16PM +, Ian Campbell wrote: On Fri, 2008-10-31 at 17:22 +0100, Bastian Blank wrote: On Fri, Oct 31, 2008 at 04:31:00PM +0100, Guido Günther wrote: So to me it seems the workaround can be removed: * removed for VIA Ester altogeher * removed vor VIA Nehemiah once we ship 2.6.27 Please read #464962 first. OK, so I think the upshot of that long thread is that kernel 2.6.26-8 removed the long nops so even the Nehemiah chips can go back to using 686 kernels and we should just revert svn r55059 altogether. This is unfixed in RC1. Is there a problelm in reverting r55059 or has this just been forgotten? Anything I can help with? I can't see any reason not to revert r55059, I just didn't want to go reverting other peoples patches, especially in non-Xen specific code. I should add that the rest of the install went totally smooth with: virt-install -n xenfoo1 -r 96 --disk path=/dev/blockdevice,device=disk --location=http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386 Thanks a lot for your nice work on the xen support! Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504753: debian-installer: autodetect correct network card [PATCH]
On Thu, Nov 06, 2008 at 08:49:49PM +, Adrian Bridgett wrote: Package: debian-installer using PXElinux, if you add IPAPPEND=3 in the pxelinux.cfg, /proc/cmdline will contain the boot adapter's MAC address. Using this we can automatically detect which card the box PXEbooted from. This removes the need for us to hardcode eth0 on some servers, eth1 on others, eth5 on yet others. I use the attached script (/bin/set-bootif) run from /lib/debian-installer-startup.d/S32set-bootif: #!/bin/sh /bin/set-bootif This is a nice thing to have! Installations get difficult if not all interfaces are usuable for installation (e.g. if they're crosslinks for DRBD). db_set netcfg/choose_interface $interface # must mark question as seen otherwise you are reprompted db_fset netcfg/choose_interface seen true Isn't prompting o.k. here? Preselecting the correnct interface and giving a message that this was autodetected might be better, because folks might want to choose a different interface. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492878: lenny installer -dosen't detect Broadcom ethernet adapter
On Thu, Nov 06, 2008 at 08:51:54PM +, Adrian Bridgett wrote: I added the firmware from the firmware-bnx2 package into the initrd (we pxeboot the servers) to fix this FWIW. You can't download it via udeb since it could be the network adapter you are trying to use! http://lists.debian.org/debian-boot/2008/11/msg5.html is the current status of the issue. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504095: installation-report: xen paravirt installation
Hi Ian, On Fri, Oct 31, 2008 at 01:26:08PM +, Ian Campbell wrote: [..snip..] d-i should have installed the 686-bigmem image when running under Xen due to the use of the 686-bigmem kernel for the Xen variant of the installer. I'll investigate why this didn't happen. It seems to be down to: /proc/cpuinfo: vendor_id: CentaurHauls which due to the changeset below which will cause the installer to choose the -486 kernel. Strangely the 686 kernel seems to work for you in dom0 and domU but I guess you were just lucky somehow? Or is the changeset below too general? This is not a Nehemiah but an Esther CPU which seems to support nopl (I checked with a small program). Futhermore it seems the whole nopl issue got fixed in the kernel: http://lkml.org/lkml/2008/9/5/374 (b74b06c5f6612a72298f37baa65460a59c26ca67) but unfortunately not for 2.6.26: $ git-name-rev b74b06c5f6612a72298f37baa65460a59c26ca67 b74b06c5f6612a72298f37baa65460a59c26ca67 tags/v2.6.27-rc6~4^2~10 (and it doesn't seem to be in any of the 2.6.26.X series). So to me it seems the workaround can be removed: * removed for VIA Ester altogeher * removed vor VIA Nehemiah once we ship 2.6.27 Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504095: installation-report: xen paravirt installation
On Fri, Oct 31, 2008 at 12:56:48PM +, Ian Campbell wrote: On Fri, 2008-10-31 at 12:58 +0100, Guido Guenther wrote: Package: installation-reports Version: 2.38 Severity: normal Boot method: network Image version: http://people.debian.org/~joeyh/d-i/images/current/ Date: 20081031 Machine: Xen Paravirtual machine on a lenny Dom0 Partitions: Device Boot Start End Blocks Id System /dev/xvda1 * 1 242 1943833+ 83 Linux /dev/xvda2 243 261 152617+ 5 Extended /dev/xvda5 243 261 152586 82 Linux swap / Solaris Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[0] Overall install:[E] Comments/Problems: The installtion itself worked great but d-i failed to install an appropriate kernel for Xen Paravirt so the system failed to boot. To fix this up I mounted the partition in the dom0 and installed the correct kernel. d-i installed linux-image-2.6.26-1-486 while it should have picked linux-image-2.6.26-1-xen-686 (this also pulls in libc6-xen via a Recommends). Seems base-installer/kernel/i386.sh needs an detect_xen_paravirt? d-i should have installed the 686-bigmem image when running under Xen due to the use of the 686-bigmem kernel for the Xen variant of the installer. I'll investigate why this didn't happen. Could you please send /var/log/installer/syslog. Attached. One more thing: in order to get console output via virsh console I had to add xencons=tty to the grub command line. With the 686-bigmem kernel I don't think this will be necessary, if you could try it and let me know that would be great. Yes, the 686-bigmem kernel doesn't need xencons=tty since hvc0 works. But we still need libc6-xen due to nosegneg? Should we schedule this for installtion on xen installs? Cheers and thanks for all your work on xen support, -- Guido syslog.gz Description: Binary data
Bug#504095: installation-report: xen paravirt installation
On Fri, Oct 31, 2008 at 03:38:30PM +, Ian Campbell wrote: On Fri, 2008-10-31 at 16:31 +0100, Guido Günther wrote: Hi Ian, On Fri, Oct 31, 2008 at 01:26:08PM +, Ian Campbell wrote: [..snip..] d-i should have installed the 686-bigmem image when running under Xen due to the use of the 686-bigmem kernel for the Xen variant of the installer. I'll investigate why this didn't happen. It seems to be down to: /proc/cpuinfo: vendor_id: CentaurHauls which due to the changeset below which will cause the installer to choose the -486 kernel. Strangely the 686 kernel seems to work for you in dom0 and domU but I guess you were just lucky somehow? Or is the changeset below too general? This is not a Nehemiah but an Esther CPU which seems to support nopl (I checked with a small program). Futhermore it seems the whole nopl issue got fixed in the kernel: http://lkml.org/lkml/2008/9/5/374 (b74b06c5f6612a72298f37baa65460a59c26ca67) but unfortunately not for 2.6.26: $ git-name-rev b74b06c5f6612a72298f37baa65460a59c26ca67 b74b06c5f6612a72298f37baa65460a59c26ca67 tags/v2.6.27-rc6~4^2~10 (and it doesn't seem to be in any of the 2.6.26.X series). So to me it seems the workaround can be removed: * removed for VIA Ester altogeher * removed vor VIA Nehemiah once we ship 2.6.27 Do you happen to know the Family/Model for the Nehemiah? Your cpuinfo shows that Esther is Family 6 model 9. Perhaps Nehemiah is model 10 since that is the other model removed by the patch? It's the other way around. Esther is family 6/model 10 (maybe you confused this with the stepping) and Nehemiah is family 6/model 9 [1]. BTW, I just tested on a non-VIA system and the correct kernel is installed (not surprising...) Cool. -- Guido Ian. [1] http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-05/msg06226.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504095: installation-report: xen paravirt installation
On Fri, Oct 31, 2008 at 03:46:22PM +, Ian Campbell wrote:
diff --git a/packages/base-installer/kernel/i386.sh
b/packages/base-installer/kernel/i386.sh
index cba6d9b..e8929ea 100644
--- a/packages/base-installer/kernel/i386.sh
+++ b/packages/base-installer/kernel/i386.sh
@@ -36,10 +36,17 @@ arch_get_kernel_flavour () {
esac
;;
CentaurHauls)
- # x86 VIA Nehemiah CentaurHauls does not boot with -686
- # since 2.6.22+ since they lack long NOP instructions.
- # See: http://lkml.org/lkml/2008/7/22/263
- echo 486 ;;
+ case $FAMILY in
+ 6)
+ case $MODEL in
+ 10) echo 686$BIGMEM ;;
+ *) echo 486 ;;
+ esac
+ ;;
+ *)
+ echo 486 ;;
+ esac
+ ;;
*)
echo 486 ;;
esac
Yes, this looks just right!
Thanks,
-- Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504095: installation-report: xen paravirt installation
On Fri, Oct 31, 2008 at 03:52:43PM +, Ian Campbell wrote: [..snip..] d-i should have installed the 686-bigmem image when running under Xen due to the use of the 686-bigmem kernel for the Xen variant of the installer. I'll investigate why this didn't happen. Could you please send /var/log/installer/syslog. Attached. One more thing: in order to get console output via virsh console I had to add xencons=tty to the grub command line. With the 686-bigmem kernel I don't think this will be necessary, if you could try it and let me know that would be great. Yes, the 686-bigmem kernel doesn't need xencons=tty since hvc0 works. Since 2.6.26-9 hvc should work by default for the -xen-686 kernel too. I guess you installed -8 from testing? Yes, this was the version from testing. But we still need libc6-xen due to nosegneg? Should we schedule this for installtion on xen installs? It's an optimisation only and is only required when running a PAE hypervisor, nothing breaks if you don't install it. No, but it just would make things even nicer. The additional package doesn't hurt on non pae. If you are running a PAE guest on a 64 bit hypervisor then you don't need libc6-xen. So far d-i hasn't had to care explicitly about Xen installs or not and certainly hasn't had to care about the bit width of the hypervisor. I'm inclined to say that people still running on a PAE hypervisor can install the package by hand, mainly because it's rather late in the game... Agreed. What would be the right package to file the wishlist bug against? -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] D-I Manual: new section on how to load firmware during installs
Hi Frans, On Sat, Oct 04, 2008 at 04:23:31PM +0200, Frans Pop wrote: The procedure is exactly as described: you will be prompted to load the firmware from removable media. Anything else requires modifying the image, which is totally outside the scope of the manual. In datacenters folks might not be able to insert a removale media since they're PXE installing via a remote console (e.g. iLO). Given that the bnx2 is built into HP servers this isn't an unlikely situation (I know people who already ran into it). So having a link to a generic description that explains howto get firmware into the initrd itself might be a good idea. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please allow multipath-tool 0.4.8-13 into Lenny
Hi, the above release has these changes: * [5585feb] simplify udev dependency * [4cc8116] add a versioned dependency on dmsetup (Closes: #497686) * [9887760] blacklist cciss devices (Closes: #500991) 4cc8116 fixes an etch upgrade issue and 9887760 makes sure we don't try to run multipath on cciss (which doesn't work in 0.4.8 or earlier versions (so no regression)). If a user really wants to try it he can whitelist the device. cc:'ing debian-boot since the package ships a udeb but the it's not currently being used. Cheers, -- Guido signature.asc Description: Digital signature
please allow multipath-tool 0.4.8-13 into Lenny
Hi, the above release has these changes: * [5585feb] simplify udev dependency * [4cc8116] add a versioned dependency on dmsetup (Closes: #497686) * [9887760] blacklist cciss devices (Closes: #500991) 4cc8116 fixes an etch upgrade issue and 9887760 makes sure we don't try to run multipath on cciss (which doesn't work in 0.4.8 or earlier versions (so no regression)). If a user really wants to try it he can whitelist the device. cc:'ing debian-boot since the package ships a udeb but the it's not currently being used. Cheers, -- Guido signature.asc Description: Digital signature
Re: unblocking partman-multipath
On Wed, Sep 17, 2008 at 08:17:32PM -0300, Otavio Salvador wrote: Guido Günther [EMAIL PROTECTED] writes: Hi Otavio On Mon, Jul 28, 2008 at 08:28:24AM -0300, Otavio Salvador wrote: [..snip..] I won't upload 1.9 for Debian now and if we do it fast, after Parted migrates to lenny, we might test it and try to get an exception. However until that is done, I wouldn't like to have unused udebs on lenny. We have a fixed parted in Lenny now we should unblock partman-multipath now too. Until we have partman updated on lenny, new parted is not used on the images. Let's hold it until RC1 is there. The new parted is used if you build current d-i form unstable. This was basically in response to your mail to d-d-a. Pushing partman-multipath would do now harm and would increase test coverage since people could install lenny instead of unstable then. But no problem, I can wait a little longer. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
On Thu, Sep 18, 2008 at 07:31:57PM +0200, Frans Pop wrote: [..snip..] You still have some very basic misconceptions about what is needed to install Lenny. Migrating partman-multipath has got exactly NOTHING to do with the ability to install testing using partman-multipath. Maybe that was my misconception indeed all along. I thought the udebs were already being pulled from testing but /etc/udebs-source still points to unstable - no hurry then. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
Hi Otavio On Mon, Jul 28, 2008 at 08:28:24AM -0300, Otavio Salvador wrote: [..snip..] I won't upload 1.9 for Debian now and if we do it fast, after Parted migrates to lenny, we might test it and try to get an exception. However until that is done, I wouldn't like to have unused udebs on lenny. We have a fixed parted in Lenny now we should unblock partman-multipath now too. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New partman-multipath udeb
On Sun, Mar 09, 2008 at 04:10:05PM +0100, Frans Pop wrote: On Sunday 09 March 2008, Guido Günther wrote: On Thu, Feb 28, 2008 at 03:21:48AM +0100, Frans Pop wrote: However, /usr/lib/post-base-installer.d/ is perfect as that is run after debootstrap but before kernel installation. It works the same as finish-install.d: just dump a script in there and it'll get executed. Because of when it is executed, you can do everything in the same script: run apt-install and copy the config and bindings. And everything will already be in place when the kernel is installed and the initramfs is generated. Does this look better. If so, I'll apply this. Yes, looks excellent. Note that the multipath-tools-boot package will need to be added by default to CD images or else the apt-install may fail. Please remind us of that when the multipath changes are uploaded. The multipath chanages are uploaded now so should we put multipath-tools-boot onto the CD images? -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of multipath support in d-i
On Thu, Sep 04, 2008 at 02:24:45PM +0200, Jérémy Bobbio wrote: On Thu, Sep 04, 2008 at 10:32:24AM +0200, Guido Günther wrote: Yes. This was the problem. It works as expected now. I think we should push partman-multipath into lenny now. Do you think that you could also add some documentation about multipath support in the installation guide? From my distant follower POV, adding multipath has been quite some work. Congrats! :) Thanks. As Frans and Otavio point out we still have some remaining work to do for grub2 before updating the installation guide really makes sense. The wiki already gives some help though. Hinting partman-multipath into lenny would help a lot now to get some broader testing, what do you think. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of multipath support in d-i
Jérémy Bobbio wrote: On Tue, Aug 26, 2008 at 07:00:49PM +0200, Guido Günther wrote: [..snip..] [1] the partitioning method dialog looks broken: http://honk.sigxcpu.org/projects/multipath-tools/d-i/part-method-borked.png When going back to the main menu and selecting Partition Disks the disks to partition pop up fine and the installation can proceed. Still have to debug if this happens with non multipath installs too. This magically has been fixed in lenny but as of yesterday the installer breaks during the installation of the base system arount the initramfs step. The log is attached, any ideas what's going on here? The kernel installs find in /target when doing this manually. This might have been a transient error while base-installer was getting built on all arches (as the source packages builds both an arch: all and an arch: any package). Could you please try again? Yes. This was the problem. It works as expected now. I think we should push partman-multipath into lenny now. Thanks, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of multipath support in d-i
On Thu, Aug 28, 2008 at 06:05:08PM +0200, Jérémy Bobbio wrote: On Tue, Aug 26, 2008 at 07:00:49PM +0200, Guido Günther wrote: [..snip..] [1] the partitioning method dialog looks broken: http://honk.sigxcpu.org/projects/multipath-tools/d-i/part-method-borked.png When going back to the main menu and selecting Partition Disks the disks to partition pop up fine and the installation can proceed. Still have to debug if this happens with non multipath installs too. This magically has been fixed in lenny but as of yesterday the installer breaks during the installation of the base system arount the initramfs step. The log is attached, any ideas what's going on here? The kernel installs find in /target when doing this manually. This might have been a transient error while base-installer was getting built on all arches (as the source packages builds both an arch: all and an arch: any package). Could you please try again? Will do, might be a couple of deays though. Thanks for the heads up! -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of multipath support in d-i
Hi, On Sat, Aug 16, 2008 at 12:09:45PM +0200, Guido Günther wrote: Until this is fixed in order to get grub setup correctly either use the patch in the BTS or flush the multipath map (multipath -F) and mount the devices single path. I've updated the wiki page http://wiki.debian.org/DebianInstaller/MultipathSupport accordingly and put a link to a patched grub legacy there until we have support in grub2. [..snip..] [1] the partitioning method dialog looks broken: http://honk.sigxcpu.org/projects/multipath-tools/d-i/part-method-borked.png When going back to the main menu and selecting Partition Disks the disks to partition pop up fine and the installation can proceed. Still have to debug if this happens with non multipath installs too. This magically has been fixed in lenny but as of yesterday the installer breaks during the installation of the base system arount the initramfs step. The log is attached, any ideas what's going on here? The kernel installs find in /target when doing this manually. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495330: should filter out errors from /sbin/multipath
Package: partman-multipath Version: 2 Severity: normal When the scsi_id callout fails it prints it's error message on stdout. This should be filtered out via: grep -v error calling out since it confuses mp device detection (the devices get detected properly but the underlying SCSI devices get also listed). -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status of multipath support in d-i
Hi, just a short heads up on the status of multipath in d-i (built from unstable on 2008-08-14) [0]: Since the parted-udeb now contains the necessary patches from #440675 (thanks again Otavio!) things are in pretty good shape. Udev is still broken (#493075) and we could do a bit better on error handling (#495330) during partitioning. Besides from that with one minor glitch [1] everything works until the grub installation, which runs but leaves you with a unbootable system (#442382). Until this is fixed in order to get grub setup correctly either use the patch in the BTS or flush the multipath map (multipath -F) and mount the devices single path. Cheers, -- Guido [0] http://honk.sigxcpu.org/projects/multipath-tools/d-i/ [1] the partitioning method dialog looks broken: http://honk.sigxcpu.org/projects/multipath-tools/d-i/part-method-borked.png When going back to the main menu and selecting Partition Disks the disks to partition pop up fine and the installation can proceed. Still have to debug if this happens with non multipath installs too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
On Fri, Aug 08, 2008 at 02:17:14PM -0300, Otavio Salvador wrote: Adeodato Simó [EMAIL PROTECTED] writes: Any news on this one? I'll do some more d-i testing on multipath next week and it would be great if I could do this from daily builds. Yes, you can do it, I'll manage the mini-transition again. Thanks a lot. I'll try to do that later today/tomorrow. Let me know if I can be of any help. Uptodate patches are in the BTS. Putting these into debian/patches should do the trick. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
Hi Otavio, On Fri, Aug 01, 2008 at 05:53:09PM -0300, Otavio Salvador wrote: adeodato simó [EMAIL PROTECTED] writes: Mini transition of what? libparted1.8-9 - libparted1.8-10? Since the 1.8 transition itself hasn't happened yet (any news about that, Otavio?), I guess we could squeeze it in, but... please assess: is the patch safe at this stage for the installer? Yes. libparted1.8-9 - libparted1.8-10. Parted is ready on sid. I've uploaded it and the bug reporter confirmed it works. (#488374) I'd say to migrate it all and do this mini transition on sid. Most of packages are from d-i team and few from outside but binNMU should handle them. The patch itself is very specific and I'd do tests to avoid it breaking any stuff. Anyway I'd like to do that ASAP to get testing from dailies and be sure of that. This depends on RT decision about the ABI bump. Any news on this one? I'll do some more d-i testing on multipath next week and it would be great if I could do this from daily builds. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
On Thu, Aug 07, 2008 at 10:52:38AM +0200, Frans Pop wrote: On Thursday 07 August 2008, Guido Günther wrote: Any news on this one? I'll do some more d-i testing on multipath next week and it would be great if I could do this from daily builds. You *can* do this from daily builds as daily builds use udebs from unstable. No I can't since the parted udeb lacks the necessary patches (#440675). -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
On Thu, Aug 07, 2008 at 12:36:39PM +0200, Frans Pop wrote: On Thursday 07 August 2008, Guido Günther wrote: On Thu, Aug 07, 2008 at 10:52:38AM +0200, Frans Pop wrote: On Thursday 07 August 2008, Guido Günther wrote: Any news on this one? I'll do some more d-i testing on multipath next week and it would be great if I could do this from daily builds. You *can* do this from daily builds as daily builds use udebs from unstable. No I can't since the parted udeb lacks the necessary patches (#440675). Right, and I never said you could. I'm only saying that migrating the partman-multipath udeb to testing does not change anything in your ability to test things. You will always need an updated version of the libparted udeb. That's exactly why I asked if anything happened on the udeb 1.8 front. Sorry if you misinterpreted that for being about partman-multipath. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of last possible inclusions for Lenny
On Mon, Jul 28, 2008 at 10:25:04PM +0200, Jérémy Bobbio wrote: Here are various things that could be included in the installer for Lenny: Multipath support? http://wiki.debian.org/DebianInstaller/MultipathSupport Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
On Mon, Jul 28, 2008 at 08:28:24AM -0300, Otavio Salvador wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido Günther [EMAIL PROTECTED] writes: Hi, please unblock partman-multipath. There's no version in lenny yet. This way folks building custom installers (due to #440675) can pull from lenny instead of sid. Hello Guido, Let's see if we can (I and you) produce a patch Parted's 1.8 branch using the fixes we made for 1.9. I won't upload 1.9 for Debian now and if we do it fast, after Parted migrates to lenny, we might test it and try to get an exception. However until that is done, I wouldn't like to have unused udebs on lenny. I've ported the necessary patches from 1.9 + the Debian specific parts over to Debian's 1.8: http://git.debian.org/?p=users/agx/parted1.8.git;a=summary I can attach one patch that goes into debian/patches to the BTS once you've reviewed that. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
On Fri, Aug 01, 2008 at 08:58:19AM -0300, Otavio Salvador wrote: RT would be acceptable for you to have this mini transition now? That is the last missing part to fully support multipath on d-i. Unfortunately that's not entirely true: we're also still lacking grub2 patches but Robert wanted to work on it (#483971). It is indeed the last missing udeb so we (hopefully) won't have to touch d-i for that anymore. Anyways: providing a patched grub later on is far easier than telling people they'll have to rebuild d-i for multipath. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unblocking partman-multipath
Hi Otavio, On Thu, Jul 31, 2008 at 09:03:39AM -0300, Otavio Salvador wrote: Adeodato Simó [EMAIL PROTECTED] writes: * Otavio Salvador [Mon, 28 Jul 2008 08:28:24 -0300]: Hi, please unblock partman-multipath. There's no version in lenny yet. This way folks building custom installers (due to #440675) can pull from lenny instead of sid. Hello Guido, Let's see if we can (I and you) produce a patch Parted's 1.8 branch using the fixes we made for 1.9. I won't upload 1.9 for Debian now and if we do it fast, after Parted migrates to lenny, we might test it and try to get an exception. However until that is done, I wouldn't like to have unused udebs on lenny. Honest question: why? Does it have any negative impact? Well, if it is not useful for the user why put it in lenny? If someone needs to make a custom image with a compiled parted, he can grab that udeb and put together. I see no gains in have it on lenny. I disagree here. The partman-multipath udeb works with lenny. Once we make a new upload to unstable it will be gone and must be extracted from SVN. We're giving people trying to run Debian on HA workloads a hard time already by not caring much. We could try to ease these things at least. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please review announcement of upcoming release of Debian 4.0r4 etch-and-a-half
(trimmed the cc: list a bit) On Sat, Jul 26, 2008 at 04:24:20PM +0200, Alexander Reichle-Schmehl wrote: Attached you'll find the current draft for the announcement of etch-and-a-half. Please review it; current schedule for it to be send out is tomorrow. We should probably mention in the etch+0.5 release notes that 2.6.24 breaks multipath (since we didn't include the devicemapper/multipath update): http://teams.debian.net/lurker/message/20080430.121446.c24b0824.de.html So people with multipath-tools installed should _not_ install the new kernel. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unblocking partman-multipath
Hi, please unblock partman-multipath. There's no version in lenny yet. This way folks building custom installers (due to #440675) can pull from lenny instead of sid. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multipath on Debian (Boot from SAN )
Hi Marco, On Fri, Jul 18, 2008 at 04:51:30PM +0200, Marco Curradi wrote: Is possible to enable multipath during installation with Lenny or Etch ? I just installed Red Hat and CentOS with the option boot linux mpath but I want to try with Debian the boot from san. No, unfortunately that's still not possible due to the parted udeb lacking the necessary patches (those are mostly already integrated in parted upstream but not in Debian): http://bugs.debian.org/440675 I don't think we see this in time for lenny but if not I intend to provide netinst images externally. Cheers and sorry for the inconvenience, -- Guido P.S.: you can of course build your own netinst images with a patch parted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488321: support labeled mounts
Package: partman-target Version: 55 Severity: wishlist Hi, since device names aren't always persistent between installation and target system, and since people want to create partimages that can be deployed without modification on sata as well as pata systems it would be nice if d-i would support labeled mounts. This would do away with the need for device names in /etc/fstab, one can simply uses the label. Attached is a small patch that adds the basic infrastructure to partman-target. To do this the number of arguments passed around by parted to describe the filesystem has to be extended from 6 to 7. The 7th argument is the label. The first hunk replaces the device name by the label (if set), the second makes sure we mount by device and not by label during installation since busybox can't handle it. Of course every fs module needs to pass on the label if wants to support labeled mounts (I'll attach a patch to partman-ext3). -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488321: Patch attached
...forgot the patch.
-- Guido
From 35a101a2cfe554631b4b80c8cdf9dc9b3817edee Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Fri, 27 Jun 2008 22:41:48 +0200
Subject: [PATCH] add support for labeled mounts
---
.../partman-target/finish.d/fstab_hd_entries | 10 +-
.../partman-target/finish.d/mount_partitions |3 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/packages/partman/partman-target/finish.d/fstab_hd_entries b/packages/partman/partman-target/finish.d/fstab_hd_entries
index 9c1429d..4b9d260 100755
--- a/packages/partman/partman-target/finish.d/fstab_hd_entries
+++ b/packages/partman/partman-target/finish.d/fstab_hd_entries
@@ -7,7 +7,8 @@ fstab=$(
[ -x $i ] || continue
$i
done |
- while read fs mp type options dump pass; do
+ while read fs mp type options dump pass label; do
+ [ -z $label ] || fs=$label
echo $mp $fs $type $options $dump $pass
done |
sort |
@@ -16,8 +17,11 @@ fstab=$(
(/*)
printf %-15s %-15s %-7s %-15s %-7s %s\n $(mapdevfs $fs) ${mp} $type $options $dump $pass
;;
+ (LABEL=*)
+ printf %-15s %-15s %-7s %-15s %-7s %s\n $fs ${mp} $type $options $dump $pass
+ ;;
esac
done
)
echo $fstab /target/etc/fstab
diff --git a/packages/partman/partman-target/finish.d/mount_partitions b/packages/partman/partman-target/finish.d/mount_partitions
index 9c8499e..58b8cb2 100755
--- a/packages/partman/partman-target/finish.d/mount_partitions
+++ b/packages/partman/partman-target/finish.d/mount_partitions
@@ -7,7 +7,8 @@ fstab=$(
[ -x $i ] || continue
$i
done |
- while read fs mp type options dump pass; do
+ while read fs mp type options dump pass label; do
+ # dont try labeled mounts since busybox cant handle this
echo $mp $fs $type $options $dump $pass
done |
sort |
--
1.5.6
Bug#488322: support labeled mounts
Package: partman-ext3 Version: 52 Severity: wishlist Tags: patch This patch uses the infrastructure from #488321 to allow partitons to be mounted by label instead of device name. Note that $id/labeled_mount is currently only settable when doing auto partitioning but should this patch look useful I can add the dialog field too. -- Guido From b40d74b1645607d9db65104d7e6a4bbf331a Mon Sep 17 00:00:00 2001 From: Guido Guenther [EMAIL PROTECTED] Date: Fri, 27 Jun 2008 22:42:32 +0200 Subject: [PATCH] allow for labeled mounts --- packages/partman/partman-ext3/fstab.d/ext3 |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/packages/partman/partman-ext3/fstab.d/ext3 b/packages/partman/partman-ext3/fstab.d/ext3 index 2a064ee..b0d4d36 100755 --- a/packages/partman/partman-ext3/fstab.d/ext3 +++ b/packages/partman/partman-ext3/fstab.d/ext3 @@ -10,6 +10,10 @@ for dev in $DEVICES/*; do [ $fs != free ] || continue [ -f $id/method ] || continue [ -f $id/acting_filesystem ] || continue + if [ -f $id/labeled_mount -a -s $id/label ]; then + label=LABEL=$(cat $id/label | \ +sed 's/\(\).*/\1/g') + fi method=$(cat $id/method) filesystem=$(cat $id/acting_filesystem) case $filesystem in @@ -31,7 +35,7 @@ for dev in $DEVICES/*; do else pass=2 fi - echo $path $mountpoint ext3 $options 0 $pass + echo $path $mountpoint ext3 $options 0 $pass $label ;; esac done -- 1.5.6
Re: [RFC] Debian Installer Lenny Beta2 - Pending stuff and timeline
On Sun, May 04, 2008 at 09:02:12PM -0300, Otavio Salvador wrote: Guido Günther [EMAIL PROTECTED] writes: Hi Otavio, On Sat, May 03, 2008 at 06:06:23PM -0300, Otavio Salvador wrote: [..snip..] . parted update is likely to happen before Lenny is release however we're still working at s390 fixing to get it done. That's great news. Does this include fixing #440675 which is needed for multipath support in d-i (with this fixed it'd be easy for people to start testing things)? Will this be based on parted 1.7 or parted 1.8? Beta2 won't change that. We'll try to update it as soon as possible but probably only after the release. I want to use parted 1.8 mostly After the beta2 release or after the lenny release? In the later case we should add the multipath patch to 1.7. because I'm working at parted upstream side too and it's double work to have to care about Debian specifics and upstream code in so diverted code. Sure, that makes sense - there are other things like libvirt that would benefit from a newer parted. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Debian Installer Lenny Beta2 - Pending stuff and timeline
Hi Otavio, On Sat, May 03, 2008 at 06:06:23PM -0300, Otavio Salvador wrote: [..snip..] . parted update is likely to happen before Lenny is release however we're still working at s390 fixing to get it done. That's great news. Does this include fixing #440675 which is needed for multipath support in d-i (with this fixed it'd be easy for people to start testing things)? Will this be based on parted 1.7 or parted 1.8? Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467324: Gnash in Desktop task?
On Tue, Apr 22, 2008 at 09:28:57PM +0200, Miriam Ruiz wrote: swfdec might be an option too. For what I know, Gnash supports more Flash than swfdec, but swfdec is indeed stable and what it does, it does good. swfdec is, AFAIK, more a one person's project, while Gnash Fedora picking swfdec for FC9 might be another data point: http://fedoraproject.org/f9-beta-relnotes Swfdec proved to be much more stable than gnash for me on ppc. I have it installed by default now since quiet some time. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476836: multipath: missing depmod call
Package: disk-detect Version: 1.60 Severity: normal Tags: patch Hi, when enabling multipath support multipath-udeb gets installed which pulls in the multipath-modules-kver udeb via a dependency. Afterwards these modules are immediately being loaded. This fails currently since we're missing a call to depmod (see attached patch). I didn't notice earlier since I had the udebs added via pkg-lists/local and so any depmod call (e.g. in ethdetect) did the trick. O.k. to apply the attached patch (with an changelog entry of course)? I didn't bother to check if depmod is available since we don't bail out on errors anyway. Cheers, -- Guido diff --git a/disk-detect.sh b/disk-detect.sh index 3290832..8f1c721 100755 --- a/disk-detect.sh +++ b/disk-detect.sh @@ -192,6 +192,7 @@ if [ $RET = true ]; then if anna-install multipath-udeb; then MODULES=dm-mod dm-multipath dm-round-robin dm-emc # We need some dm modules... + depmod -a /dev/null 21 || true for MODULE in $MODULES; do if is_not_loaded $MODULE; then module_probe $MODULE || true
partman-multipath upload
Hi, can I upload partman-multipath? Since it's not being used by default atm this shouldn't cause any harm. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468832: multipath support
On Sat, Mar 08, 2008 at 03:30:36PM -0300, Otavio Salvador wrote: Ack to commit them. Applied, thanks. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New partman-multipath udeb
On Thu, Feb 28, 2008 at 03:21:48AM +0100, Frans Pop wrote:
However, /usr/lib/post-base-installer.d/ is perfect as that is run after
debootstrap but before kernel installation. It works the same as
finish-install.d: just dump a script in there and it'll get executed.
Because of when it is executed, you can do everything in the same script:
run apt-install and copy the config and bindings. And everything will
already be in place when the kernel is installed and the initramfs is
generated.
Does this look better. If so, I'll apply this.
-- Guido
From c2d814d99b6c916f53cf03289fb41e8e4a0f4145 Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Sat, 8 Mar 2008 21:10:44 +0100
Subject: [PATCH] move finish-install and finish.d stuff into
post-base-installer.d/60multipath
saves the slow update-initramfs run, thanks to Frans Pop for the suggestion
---
debian/dirs |1 -
debian/partman-multipath.install |1 +
debian/rules |4 +---
finish-install| 21 -
finish.d/_numbers |1 -
finish.d/aptinstall_multipath |9 -
post-base-installer.d/60multipath | 21 +
7 files changed, 23 insertions(+), 35 deletions(-)
delete mode 100644 debian/dirs
create mode 100644 debian/partman-multipath.install
delete mode 100755 finish-install
delete mode 100644 finish.d/_numbers
delete mode 100755 finish.d/aptinstall_multipath
create mode 100755 post-base-installer.d/60multipath
diff --git a/debian/dirs b/debian/dirs
deleted file mode 100644
index f9cd2dd..000
--- a/debian/dirs
+++ /dev/null
@@ -1 +0,0 @@
-/usr/lib/finish-install.d/
diff --git a/debian/partman-multipath.install b/debian/partman-multipath.install
new file mode 100644
index 000..1ab8f4d
--- /dev/null
+++ b/debian/partman-multipath.install
@@ -0,0 +1 @@
+post-base-installer.d/60multipath usr/lib/post-base-installer.d/
diff --git a/debian/rules b/debian/rules
index 4a70082..98fa561 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,13 +23,11 @@ install: build
dh_installdirs
debian/install-rc init.d
debian/install-rc commit.d
- debian/install-rc finish.d
- install -m 755 finish-install \
-${CURDIR}/debian/${PACKAGE}/usr/lib/finish-install.d/70multipath
binary-indep: build install
dh_testdir
dh_testroot
+ dh_install
dh_installdebconf
dh_fixperms
dh_installdeb
diff --git a/finish-install b/finish-install
deleted file mode 100755
index b31a31d..000
--- a/finish-install
+++ /dev/null
@@ -1,21 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ $(multipath -l | grep '^mpath[0-9]\+' | wc -l) -eq 0 ]; then
- exit 0
-fi
-
-if [ -r /etc/multipath.conf ]; then
- cp /etc/multipath.conf /target/etc/multipath.conf
-fi
-
-# copy over the persistent binding
-if [ -r /var/lib/multipath/bindings ]; then
- mkdir -p /target/var/lib/multipath
- cp /var/lib/multipath/bindings /target/var/lib/multipath/
-fi
-
-# The initrd must contain these files:
-chroot /target update-initramfs -u
-
diff --git a/finish.d/_numbers b/finish.d/_numbers
deleted file mode 100644
index 29ec3a7..000
--- a/finish.d/_numbers
+++ /dev/null
@@ -1 +0,0 @@
-70 aptinstall_multipath
diff --git a/finish.d/aptinstall_multipath b/finish.d/aptinstall_multipath
deleted file mode 100755
index 8bf7fe0..000
--- a/finish.d/aptinstall_multipath
+++ /dev/null
@@ -1,9 +0,0 @@
-#!/bin/sh
-
-set -e
-
-# install multipath-tools-boot in /target if needed
-if [ $(multipath -l | grep '^mpath[0-9]\+ ' | wc -l) -gt 0 ]; then
- apt-install multipath-tools-boot || true
-fi
-
diff --git a/post-base-installer.d/60multipath
b/post-base-installer.d/60multipath
new file mode 100755
index 000..cb21b60
--- /dev/null
+++ b/post-base-installer.d/60multipath
@@ -0,0 +1,21 @@
+#!/bin/sh
+
+set -e
+
+if [ $(multipath -l | grep '^mpath[0-9]\+' | wc -l) -eq 0 ]; then
+ exit 0
+fi
+
+apt-install multipath-tools-boot || true
+
+if [ -r /etc/multipath.conf ]; then
+ cp /etc/multipath.conf /target/etc/multipath.conf
+fi
+
+# copy over the persistent binding
+if [ -r /var/lib/multipath/bindings ]; then
+ mkdir -p /target/var/lib/multipath
+ cp /var/lib/multipath/bindings /target/var/lib/multipath/
+fi
+
+# the initramfs will be updated by the kernel installation
--
1.5.4.3
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468832: multipath support
HI Otavio, On Sat, Mar 08, 2008 at 03:30:36PM -0300, Otavio Salvador wrote: I'm ok with you pushing it for Beta2 but I'd like that you keep around if any issues is discovery with your code changes. I hope we'll be able to do a fast Beta2 release and want to avoid too risky changes. Sure. The potential for breackage without enabling mp should be quiet low. I'd be nice to have as much multipath stuff in Beta2 as possible so people can start testing. I expect to have Beta1 release for next week and then all those changes just be upload for sid to allow us to get testers for them. It would be nice if grub2 support could go at same time so it could be tested too. Ack to commit them. Will commit then, thanks. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468832: multipath support
On Fri, Mar 07, 2008 at 10:34:45PM +0100, Christian Perrier wrote: Of course, GRUB stuff comes pretty late, but it wouldn't really hurst to put WorldWide IDentifier somewhere: I think it's fine to put this in the manual but people not knowing what a WWID is will have a hard time to even set up the FC adapter _before_ they start the installation. So lets put it in the manual (once we have working support in the installer) - o.k.? Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468832: multipath support
On Sat, Mar 08, 2008 at 11:55:54AM +0100, Christian Perrier wrote: I don't exactly agree about meaningless. Knowing that WWID means WorldWide IDentifier helped me to understand that this seems to be a generic way to name a multipath device, so expanding the acronym has at least some teaching benefit. No. It's a generic way to name the exported _SCSI_ device beneath the multipath device. Have a look at: http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468832: multipath support
On Sat, Mar 08, 2008 at 08:10:46AM +0100, Frans Pop wrote: Looks fine to me. Thanks for reviewing. Maybe we can move all things into place after beta1? I'll look into updating partman-multipath with your suggestions and hopefully grub2 support until then. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468832: multipath support
On Sat, Mar 08, 2008 at 05:04:28PM +0100, Frans Pop wrote: It would be great if you could do grub2 support as that would also cover dmraid support with grub2. I originally implemented it, but cannot test it ATM (have a system that supports it, but no spare SATA disks to play with). Can you pass over the patch, even if it's untested? -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installation failure with current lenny packages
On Sun, Mar 02, 2008 at 08:37:53PM +0100, Frans Pop wrote: On Sunday 02 March 2008, Guido Günther wrote: It's d-i trunk revision 51621 with this sources.list.local: This is your problem: Mar 2 18:48:08 main-menu[1192]: INFO: Menu item 'live-installer' selected [..snip..] Make sure that bootstrap-base gets included instead and things should look a lot better. Pulling in bootstrap-base via the pkg-list worked like a charm thanks, this way I can now run presseeded the whole way through the installer again. Thanks, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468832: multipath support
Hi Frans,
On Mon, Mar 03, 2008 at 10:16:17PM +0100, Frans Pop wrote:
In general I'm not sure that this approach is correct. In the case of SATA
RAID, the BIOS actually knows what the RAID devices are and the RAID device
_is_ what you select in the BIOS as the disk to be booted from.
In the multipath case you basically do the same and the select the WWID
in the FC adapter to boot from - I've updated the template accordingly.
Also, I suspect that multipath is not i386/amd64-specific, and is probably
quite interesting for other (mini system) arches. It would be good to contact
porters about supporting multipath setups in their boot loaders
No it isn't. We certainly want to have this at least on powerpc as well.
Things will become much wore interesting once we have iSCSI support in
d-i, then everybody can use this at home.
The current code has:
- if ... [ $frgrubroot -gt 0 ] [ -e $ROOT$frdev$frbootpart ]; then
which I changed to
+ if ... [ $frgrubroot -ge 0 ] [ -e $ROOT$frdev$frbootpart ]; then
since grub starts counting from zero. I wonder why sataraid can only
have partition numbers 0?
I think you are correct. They are basically just sanity checks.
I have committed this fix to SVN. As it is a bugfix, it should not be mixed
in with your other changes.
Thanks.
Some comments on the patch.
+ GRUB is always installed to the master boot record (MBR) of the multipath
+ device. It is also assumed that that this device is listed as the first hard
+ device in the boot order defined in the system's BIOS setup.
first hard _device_ is a meaningless term IMO.
Yes, this should be device only. Fixed.
+ An error occurred while setting up GRUB for the multipathed device.
I have seen you use multipathed before and every time my reaction was
ugh, ugly. Why not just use multipath instead? IMO the meaning remains
identical.
Indeed, let's just use multipath.
Spaces before tabs in indentation.
(There were quite a few of those already in SVN, which I have cleaned up;
you may have to update your patch for that.)
I cleaned that up - most of was came in due copy paste from other places
in the file. Thanks again for the comments, a new version is attached.
-- Guido
From ee695c71e1e71c697087cf32aeec99bdcd016f92 Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Fri, 7 Mar 2008 21:07:28 +0100
Subject: [PATCH] add multipath support modeled after dmraid
---
debian/grub-installer.templates | 21
debian/isinstallable| 13 +-
grub-installer | 50 +-
3 files changed, 71 insertions(+), 13 deletions(-)
mode change 100755 = 100644 grub-installer
diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
index 183d9cd..d6e26bb 100644
--- a/debian/grub-installer.templates
+++ b/debian/grub-installer.templates
@@ -47,6 +47,27 @@ _Description: Unable to configure GRUB
.
The GRUB installation has been aborted.
+Template: grub-installer/multipath
+Type: boolean
+Default: true
+# :sl3:
+_Description: Install the GRUB boot loader to the multipath device?
+ Installation of GRUB on multipath is experimental.
+ .
+ GRUB is always installed to the master boot record (MBR) of the multipath
+ device. It is also assumed that the WWID of this device is selected as boot
+ device in the system's FibreChannel adapter BIOS.
+ .
+ The GRUB root device is: ${GRUBROOT}.
+
+Template: grub-installer/multipath-error
+Type: error
+# :sl2:
+_Description: Unable to configure GRUB
+ An error occurred while setting up GRUB for the multipath device.
+ .
+ The GRUB installation has been aborted.
+
Template: grub-installer/install_to_xfs
Type: boolean
Default: false
diff --git a/debian/isinstallable b/debian/isinstallable
index 73ddfcf..6e2eb41 100755
--- a/debian/isinstallable
+++ b/debian/isinstallable
@@ -24,6 +24,17 @@ is_sataraid () {
return 1
}
+is_multipath () {
+ if type multipath /dev/null 21; then
+ for frdisk in $(multipath -l 2/dev/null | grep '^mpath[0-9]\+ ' | cut -d ' ' -f 1); do
+ if echo $1 | grep -q ^/dev/mapper/${frdisk}-part[0-9]\+; then
+return 0
+ fi
+ done
+ fi
+ return 1
+}
+
ARCH=$(archdetect)
case $ARCH in
@@ -53,7 +64,7 @@ fi
# Check for the control file to work around lvdisplay refusal to work with
# certian lvm device names.
if lvdisplay $bootfs | grep -q 'LV Name' 2/dev/null || [ -e $(dirname $bootfs)/control ]; then
- if ! is_sataraid $bootfs; then
+ if ! is_sataraid $bootfs ! is_multipath $bootfs; then
log /boot is a lvm volume ($bootfs), cannot install grub
exit 1
fi
diff --git a/grub-installer b/grub-installer
old mode 100755
new mode 100644
index 2bf8020..5f86517
--- a/grub-installer
+++ b/grub-installer
@@ -99,12 +99,14 @@ convert () {
tmp_disk=$(echo $1 | sed -e 's%\([sh]d[a-z]\)[0-9]*$%\1%' \
-e 's%\(fd[0-9]*\)$%\1%' \
-e 's%/part[0-9]*$%/disc%' \
- -e 's%\(c[0-7]d[0-9]*\).*$%\1%')
+ -e
Bug#468832: multipath support
On Sat, Mar 01, 2008 at 07:57:15PM +0100, Guido Günther wrote:
attached is a first version of multipath support for grub-install to get
some comments. It basically uses the sataraid code. The current code
...as Frans pointed out I forgot the attachment.
-- Guido
From b36dac79b414d9a9b472f32eecdaa975d829481c Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Sat, 1 Mar 2008 19:41:17 +0100
Subject: [PATCH] multipath support modeled after dmraid
---
.../grub-installer/debian/grub-installer.templates | 21
.../arch/i386/grub-installer/debian/isinstallable | 13 +-
packages/arch/i386/grub-installer/grub-installer | 50 +++-
3 files changed, 71 insertions(+), 13 deletions(-)
mode change 100755 = 100644 packages/arch/i386/grub-installer/grub-installer
diff --git a/packages/arch/i386/grub-installer/debian/grub-installer.templates b/packages/arch/i386/grub-installer/debian/grub-installer.templates
index 183d9cd..7a8441a 100644
--- a/packages/arch/i386/grub-installer/debian/grub-installer.templates
+++ b/packages/arch/i386/grub-installer/debian/grub-installer.templates
@@ -47,6 +47,27 @@ _Description: Unable to configure GRUB
.
The GRUB installation has been aborted.
+Template: grub-installer/multipath
+Type: boolean
+Default: true
+# :sl3:
+_Description: Install the GRUB boot loader to the multipath device?
+ Installation of GRUB on multipath is experimental.
+ .
+ GRUB is always installed to the master boot record (MBR) of the multipath
+ device. It is also assumed that that this device is listed as the first hard
+ device in the boot order defined in the system's BIOS setup.
+ .
+ The GRUB root device is: ${GRUBROOT}.
+
+Template: grub-installer/multipath-error
+Type: error
+# :sl2:
+_Description: Unable to configure GRUB
+ An error occurred while setting up GRUB for the multipathed device.
+ .
+ The GRUB installation has been aborted.
+
Template: grub-installer/install_to_xfs
Type: boolean
Default: false
diff --git a/packages/arch/i386/grub-installer/debian/isinstallable b/packages/arch/i386/grub-installer/debian/isinstallable
index 73ddfcf..6e2eb41 100755
--- a/packages/arch/i386/grub-installer/debian/isinstallable
+++ b/packages/arch/i386/grub-installer/debian/isinstallable
@@ -24,6 +24,17 @@ is_sataraid () {
return 1
}
+is_multipath () {
+ if type multipath /dev/null 21; then
+ for frdisk in $(multipath -l 2/dev/null | grep '^mpath[0-9]\+ ' | cut -d ' ' -f 1); do
+ if echo $1 | grep -q ^/dev/mapper/${frdisk}-part[0-9]\+; then
+return 0
+ fi
+ done
+ fi
+ return 1
+}
+
ARCH=$(archdetect)
case $ARCH in
@@ -53,7 +64,7 @@ fi
# Check for the control file to work around lvdisplay refusal to work with
# certian lvm device names.
if lvdisplay $bootfs | grep -q 'LV Name' 2/dev/null || [ -e $(dirname $bootfs)/control ]; then
- if ! is_sataraid $bootfs; then
+ if ! is_sataraid $bootfs ! is_multipath $bootfs; then
log /boot is a lvm volume ($bootfs), cannot install grub
exit 1
fi
diff --git a/packages/arch/i386/grub-installer/grub-installer b/packages/arch/i386/grub-installer/grub-installer
old mode 100755
new mode 100644
index 1dc80bc..2c25b0c
--- a/packages/arch/i386/grub-installer/grub-installer
+++ b/packages/arch/i386/grub-installer/grub-installer
@@ -99,12 +99,14 @@ convert () {
tmp_disk=$(echo $1 | sed -e 's%\([sh]d[a-z]\)[0-9]*$%\1%' \
-e 's%\(fd[0-9]*\)$%\1%' \
-e 's%/part[0-9]*$%/disc%' \
- -e 's%\(c[0-7]d[0-9]*\).*$%\1%')
+ -e 's%\(c[0-7]d[0-9]*\).*$%\1%' \
+ -e 's%\(/mapper/mpath[0-9]\+\)-part[0-9]\+$%\1%')
tmp_part=$(echo $1 | sed -e 's%.*/[sh]d[a-z]\([0-9]*\)$%\1%' \
-e 's%.*/fd[0-9]*$%%' \
-e 's%.*/floppy/[0-9]*$%%' \
-e 's%.*/\(disc\|part\([0-9]*\)\)$%\2%' \
- -e 's%.*c[0-7]d[0-9]*p*%%')
+ -e 's%.*c[0-7]d[0-9]*p*%%' \
+ -e 's%.*/mapper/mpath[0-9]\+-part\([0-9]\+\)%\1%')
;;
gnu*)
tmp_disk=$(echo $1 | sed 's%\([sh]d[0-9]*\).*%\1%')
@@ -276,9 +278,29 @@ if type dmraid /dev/null 21; then
frdev=/dev/mapper/$frdisk
frbootpart=${disc_offered#$frdev}
frgrubroot=$(($frbootpart - 1))
+ frtype=sataraid
break
fi
done
+# Check if the boot file system is on multipath
+elif type multipath /dev/null 21; then
+ for frdisk in $(multipath -l 2/dev/null | \
+ grep '^mpath[0-9]\+ ' | cut -d ' ' -f 1); do
+ if echo $disc_offered | \
+ grep -q ^/dev/mapper/${frdisk}-part[0-9]\+; then
+ frdev=/dev/mapper/$frdisk
+ frbootpart=${disc_offered#$frdev}
+ frgrubroot=$((${frbootpart#-part} - 1))
+ frtype=multipath
+ break
+ fi
+ done
+ if [ $frdisk ]; then
+ # Create the device nodes for grub:
+ apt-install dmsetup
+ $chroot $ROOT mount /proc
+ $chroot $ROOT dmsetup mknodes
+ fi
fi
info Identified partition label for $bootfs: $bootfslabel
@@ -380,6 +402,10 @@ if ! apt-install $grub_package ; then
exit 1
fi
+if [ $frtype = multipath ]; then
+$chroot $ROOT umount /proc
+fi
installation failure with current lenny packages
Hi, while testing the multipath inststallation the current lenny installer + the multipath patches posted to the bts fails like this during the install system step (it prints running preseed... in the progress bar dialog at this moment: Mar 2 13:12:12 apt-install: Queueing package e2fsprogs for later installation Mar 2 13:12:12 apt-install: Queueing package multipath-tools-boot for later installation Mar 2 13:12:15 main-menu[1192]: INFO: Falling back to the package description for auto-install Mar 2 13:12:15 main-menu[1192]: INFO: Falling back to the package description for ai-choosers Mar 2 13:12:15 main-menu[1192]: INFO: Menu item 'live-installer' selected Mar 2 13:12:15 main-menu[1192]: INFO: Falling back to the package description for squashfs-modules-2.6.22-3-486-di Mar 2 13:12:15 main-menu[1192]: INFO: Falling back to the package description for squashfs-modules-2.6.22-3-486-di Mar 2 13:12:18 base-installer: chroot: cannot execute apt-get: No such file or directory ^ Mar 2 13:12:18 base-installer: warning: apt update failed: 1 Mar 2 13:12:18 in-target: Unexpected error; command not executed: 'sh -c debconf-apt-progress --no-progress --logstderr -- apt-get -o APT::Install-Recommends=false -q -y --no-remove install locales' Mar 2 13:12:18 base-installer: /usr/lib/post-base-installer.d/05localechooser: Mar 2 13:12:18 base-installer: /usr/lib/post-base-installer.d/05localechooser: 49: Mar 2 13:12:18 base-installer: cannot create /target/etc/default/locale: Directory nonexistent Mar 2 13:12:18 base-installer: warning: /usr/lib/post-base-installer.d/05localechooser returned error code 2 Mar 2 13:12:18 preseed: chroot: cannot execute debconf-set-selections: No such file or directory Mar 2 13:12:19 base-installer: warning: /usr/lib/post-base-installer.d/05preseed returned error code 1 Mar 2 13:12:19 base-installer: warning: /usr/lib/post-base-installer.d/05tzsetup returned error code 10 Mar 2 13:12:19 main-menu[1192]: INFO: Priority changed externally, setting main-menu default to 'medium' (OK) Mar 2 13:12:19 main-menu[1192]: INFO: Menu item 'live-installer' succeeded but requested to be left unconfigured. Mar 2 13:12:19 main-menu[1192]: INFO: Modifying debconf priority limit from 'Incorrect number of arguments' to 'low' Mar 2 13:12:19 debconf: Setting debconf/priority to low Any idea what causes this? When I select to install the Grub Bootloader afterwards and then select Install the system form there things work as expected. Any ideas? -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installation failure with current lenny packages
On Sun, Mar 02, 2008 at 06:03:52PM +0100, Frans Pop wrote: On Sunday 02 March 2008, Guido Günther wrote: while testing the multipath inststallation the current lenny installer + *Exactly* which installer image did you use? It's d-i trunk revision 51621 with this sources.list.local: deb copy:/home/guido/debian-installer/d-i/installer/build/ localudebs/ deb http://ftp.de.debian.org/debian testing main/debian-installer The localudebs are: partman-utils partman-base libparted1.7-udeb parted-udeb partman-multipath disk-detect partman-auto grub-installer with the multipath patches posted to the BTS. the multipath patches posted to the bts fails like this during the install system step (it prints running preseed... in the progress bar dialog at this moment: Mar 2 13:12:18 base-installer: chroot: cannot execute apt-get: No such file or directory This would mean that the base installation failed for some reason. Please do not send fragments of syslog, but always the complete file (gzipped!). The cause of a problem is often earlier than the symptoms. Attached. -- Guido syslog.gz Description: Binary data
Bug#468799: add multipath support
Package: partman-auto
Version: 76
Severity: wishlist
Depends: 442236
Hi,
attached patch allows multipathed devices to be used for auto
partitioning.
Cheers,
-- Guido
From 70c808621377cf27f248f772c32ed244465a3713 Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Sat, 1 Mar 2008 15:51:04 +0100
Subject: [PATCH] allow multipathed devices as auto_disks
---
packages/partman/partman-auto/lib/auto-shared.sh | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/packages/partman/partman-auto/lib/auto-shared.sh b/packages/partman/partman-auto/lib/auto-shared.sh
index f426a37..15cca07 100644
--- a/packages/partman/partman-auto/lib/auto-shared.sh
+++ b/packages/partman/partman-auto/lib/auto-shared.sh
@@ -146,16 +146,18 @@ create_partitions() {
}
get_auto_disks() {
- local dev device
+ local dev device dmtype
for dev in $DEVICES/*; do
[ -d $dev ] || continue
- # Skip /dev/mapper/X and /dev/mdX devices
+ # Skip /dev/mapper/X and /dev/mdX but not multipath devices
device=$(cat $dev/device)
$(echo $device | grep -q /dev/md[0-9]*$) continue
- $(echo $device | grep -q /dev/mapper/) continue
-
+ if echo $device | grep -q ^/dev/mapper/; then
+ dmtype=$(dm_table $device)
+ [ $dmtype = multipath ] || continue
+ fi
printf $dev\t$(device_name $dev)\n
done
}
--
1.5.4.1
Bug#468832: multipath support
Package: grub-installer Version: 1.29 Severity: wishlist Tags: patch Hi, attached is a first version of multipath support for grub-install to get some comments. It basically uses the sataraid code. The current code has: - if ... [ $frgrubroot -gt 0 ] [ -e $ROOT$frdev$frbootpart ]; then which I changed to + if ... [ $frgrubroot -ge 0 ] [ -e $ROOT$frdev$frbootpart ]; then since grub starts counting from zero. I wonder why sataraid can only have partition numbers 0? Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documenting how to test multipath devices
On Sat, Mar 01, 2008 at 07:10:30PM +0100, Frans Pop wrote: Agreed. A wiki page for multipath would be very good to have, especially as it is a feature that needs to be activated on the boot prompt. There's http://wiki.debian.org/DebianInstaller/MultipathSupport which I use to keep track of the status. It doesn't have much information on usage yet though. Things should also be testable with SATA/SCSI systems, the multipath would then only consist of a single path but for d-i this makes no difference. I'll update the page once I did more testing with the current patchset myself. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440439: Updated patch
On Thu, Feb 28, 2008 at 08:47:56PM -0300, Otavio Salvador wrote: But why you've change to grep instead checking the $? This way we fail when either: multipath -l returns an error or when the output doesn't contain any valid multipaths. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442236: updated patch
On Fri, Feb 29, 2008 at 01:53:00AM +0100, Frans Pop wrote: On Friday 29 February 2008, Otavio Salvador wrote: Better: _Description: Multipath %s, partition #%s looks more logical and follows rest of templates. Agreed. Feel free to commit (with changelog entry) after that. Thanks, done. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440439: Updated patch
On Fri, Feb 29, 2008 at 01:50:34AM +0100, Frans Pop wrote: P.S. I'm going to assume you're subscribed to the list from now on. No need to CC me on replies either. Sure. But please do cc: me since I'm not reading debian-boot that frequently. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
partman-base: fix part_of_multipath check
Patch moved that hunk outside the actual for loop so $partdev was always empty. I didn't notice earlier since I expected the QEMU devices to showup anyway since they're not SCSI. O.k. to apply? -- Guido --- packages/partman/partman-base/init.d/parted |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/packages/partman/partman-base/init.d/parted b/packages/partman/partman-base/init.d/parted index d30ce1a..ceb4811 100755 --- a/packages/partman/partman-base/init.d/parted +++ b/packages/partman/partman-base/init.d/parted @@ -43,10 +43,6 @@ if [ ! -f /var/run/parted_server.pid ]; then # TODO: How do we signal we couldn't start parted_server properly? exit $RET fi - # Skip devices that are part of a multipathed device - if part_of_multipath $partdev; then - continue - fi rm -rf /var/lib/partman/old_devices if [ -d $DEVICES ]; then @@ -72,6 +68,11 @@ if [ ! -f /var/run/parted_server.pid ]; then fi fi + # Skip devices that are part of a multipathed device + if part_of_multipath $partdev; then + continue + fi + dirname=$(echo $1 | sed 's:/:=:g') dev=$DEVICES/$dirname if [ -d /var/lib/partman/old_devices/$dirname ]; then -- 1.5.4.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
partman-base: silence dmsetup
Subject says it all. Otherwise dmsetup complains loudly when a device
map doesn't exist. O.k. to apply?
-- Guido
---
packages/partman/partman-base/lib/base.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/packages/partman/partman-base/lib/base.sh
b/packages/partman/partman-base/lib/base.sh
index dada3ef..70f87cb 100644
--- a/packages/partman/partman-base/lib/base.sh
+++ b/packages/partman/partman-base/lib/base.sh
@@ -508,7 +508,7 @@ memfree () {
dm_table () {
local type=
if [ -x /sbin/dmsetup ]; then
- type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
+ type=$(/sbin/dmsetup table $1 2/dev/null | head -n 1 | cut
-d -f3)
fi
echo $type
}
--
1.5.4.1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
partman-base: define variables as local in commit.sh
Define variables as local. The partition numbers are still weird in the
dialog, will fix this up at a later iteration. O.k. to apply?
-- Guido
---
packages/partman/partman-base/lib/commit.sh |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/packages/partman/partman-base/lib/commit.sh
b/packages/partman/partman-base/lib/commit.sh
index f5ccfe9..86b6d64 100644
--- a/packages/partman/partman-base/lib/commit.sh
+++ b/packages/partman/partman-base/lib/commit.sh
@@ -5,6 +5,7 @@
confirm_changes () {
local dev part partitions num id size type fs path name filesystem
local x template partdesc partitems items formatted_previously
+ local device dmtype
template=$1
# Compute the changes we are going to do
@@ -52,9 +53,10 @@ confirm_changes () {
filesystem=$(cat $id/visual_filesystem)
# Special case d-m devices to use a different
description
if cat device | grep -q /dev/mapper ; then
- type=$(dm_table $device)
+ device=$(cat device)
+ dmtype=$(dm_table $device)
# multipath devices are partitioned
- if [ $type != multipath ] !
is_multipath_part $device; then
+ if [ $dmtype != multipath ] !
is_multipath_part $device; then
partdesc=partman/text/confirm_unpartitioned_item
fi
fi
--
1.5.4.1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
partman-base: extend regex to handle faked qemu multipath via hda
The multipath output then looks like:
...
\_ #:#:#:# hda 3:0 ...
since there is no controller:bus:id:lun to read. O.k. to apply? Eases
testing with QEMU/KVM a lot.
Cheers,
-- Guido
---
packages/partman/partman-base/init.d/parted |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/packages/partman/partman-base/init.d/parted
b/packages/partman/partman-base/init.d/parted
index ceb4811..6f6fc2e 100755
--- a/packages/partman/partman-base/init.d/parted
+++ b/packages/partman/partman-base/init.d/parted
@@ -26,7 +26,7 @@ part_of_multipath() {
# The block devices that make up the multipath:
# Output looks like \_ 4:0:0:1 sdc 8:32 ...
for mpdev in $(multipath -l | \
- grep '_ \([0-9]\+:\)\{3\}[0-9]\+ sd[a-z]\+
[0-9]\+:[0-9]\+' | \
+ grep '_ \([#0-9]\+:\)\{3\}[#0-9]\+ [hs]d[a-z]\+
[0-9]\+:[0-9]\+' | \
cut -f4 -d' '); do
if [ $(readlink -f /dev/$mpdev) = $1 ]; then
return 0
--
1.5.4.1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman-base: extend regex to handle faked qemu multipath via hda
On Fri, Feb 29, 2008 at 11:50:29PM +0100, Frans Pop wrote:
On Friday 29 February 2008, Guido Günther wrote:
The multipath output then looks like:
...
\_ #:#:#:# hda 3:0 ...
since there is no controller:bus:id:lun to read. O.k. to apply? Eases
testing with QEMU/KVM a lot.
This patch does not make any sense to me as it only _allows_ the #, but I
see nothing that puts the # into the string being tested.
The '#' is being put out by multipath -l if it can't find the necessary
information in sysfs. This only helps testing, so I can leave this out,
but it does now harm either.
How exactly are you testing multipath?
Well, in an ideal world against an EMC Clariion but since this one sits
behind a firewall and the servers attached to it have a hard time
getting up to date packages and since I don't have this at home I use
KVM and a hacked up hw-detect that puts out a multipath.conf like:
defaults {
getuid_callout /bin/scsi_id.sh
}
blacklist_exceptions {
devnode ^hda
}
defaults {
user_friendly_names yes
}
Once I cleaned up the grub-install patch I put out an image for testing.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440439: Updated patch
On Tue, Feb 26, 2008 at 05:03:04PM +0100, Frans Pop wrote:
This line is way to cryptic to my taste:
[ -n $(/sbin/multipath -l) $? ] return 0 || return 1
Could you rewrite that to something that is a bit more intuitive?
This one is simpler and much more robust against weird multipath -l
output. O.k. to apply?
-- Guido
diff --git a/packages/hw-detect/disk-detect.sh
b/packages/hw-detect/disk-detect.sh
index efe55b0..3290832 100755
--- a/packages/hw-detect/disk-detect.sh
+++ b/packages/hw-detect/disk-detect.sh
@@ -102,7 +102,12 @@ defaults {
EOF
fi
log-output -t disk-detect /sbin/multipath -v$MP_VERBOSE
- [ -n $(/sbin/multipath -l) $? ] return 0 || return 1
+
+ if multipath -l 2/dev/null | grep -q '^mpath[0-9]\+ '; then
+ return 0
+ else
+ return 1
+ fi
}
hw-detect disk-detect/detect_progress_title || true
--
1.5.4.2
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442236: updated patch
On Tue, Feb 26, 2008 at 06:38:27PM +0100, Frans Pop wrote:
On Tuesday 26 February 2008, Guido Günther wrote:
I've attached an updated patch. Thanks for the comments.
Thanks for the update, but I'm afraid I have one more.
Please define variables used inside functions with 'local', especially when
defining variables with common names like type.
Make sense. Updated patch attached, it also fixes a call to
is_multipath_part. I just tested it with some hackery in qemu and with a
patched parted (#440675) things look quiet well already. Would be nice
if this could be applied.
Cheers,
-- Guido
diff --git a/packages/partman/partman-base/debian/partman-base.templates b/packages/partman/partman-base/debian/partman-base.templates
index 5bd5e87..001301e 100644
--- a/packages/partman/partman-base/debian/partman-base.templates
+++ b/packages/partman/partman-base/debian/partman-base.templates
@@ -295,6 +295,14 @@ Type: text
# :sl3:
_Description: Serial ATA RAID %s (partition #%s)
+Template: partman/text/multipath
+Type: text
+_Description: Multipath %s (WWID %s)
+
+Template: partman/text/multipath_partition
+Type: text
+_Description: Multipath %s Partition #%s
+
Template: partman/text/lvm_lv
Type: text
# :sl3:
diff --git a/packages/partman/partman-base/init.d/parted b/packages/partman/partman-base/init.d/parted
index b10781b..d30ce1a 100755
--- a/packages/partman/partman-base/init.d/parted
+++ b/packages/partman/partman-base/init.d/parted
@@ -16,6 +16,25 @@ part_of_sataraid () {
return 1
}
+part_of_multipath() {
+ local mpdev
+ type multipath /dev/null 21 || return 1
+
+ if is_multipath_part $1; then
+ return 0
+ fi
+ # The block devices that make up the multipath:
+ # Output looks like \_ 4:0:0:1 sdc 8:32 ...
+ for mpdev in $(multipath -l | \
+ grep '_ \([0-9]\+:\)\{3\}[0-9]\+ sd[a-z]\+ [0-9]\+:[0-9]\+' | \
+ cut -f4 -d' '); do
+ if [ $(readlink -f /dev/$mpdev) = $1 ]; then
+ return 0
+ fi
+ done
+ return 1
+}
+
if [ ! -f /var/run/parted_server.pid ]; then
mkdir -p /var/run
parted_server
@@ -24,6 +43,10 @@ if [ ! -f /var/run/parted_server.pid ]; then
# TODO: How do we signal we couldn't start parted_server properly?
exit $RET
fi
+ # Skip devices that are part of a multipathed device
+ if part_of_multipath $partdev; then
+ continue
+ fi
rm -rf /var/lib/partman/old_devices
if [ -d $DEVICES ]; then
diff --git a/packages/partman/partman-base/lib/base.sh b/packages/partman/partman-base/lib/base.sh
index 1d973cd..a62a099 100644
--- a/packages/partman/partman-base/lib/base.sh
+++ b/packages/partman/partman-base/lib/base.sh
@@ -496,9 +496,36 @@ memfree () {
fi
}
+# return the device mapper table type
+dm_table () {
+ local type=
+ if [ -x /sbin/dmsetup ]; then
+ type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
+ fi
+ echo $type
+}
+
+# Check if a device is a partition on a multipath'ed device by checking if
+# the corresponding multipath map exists
+is_multipath_part () {
+ local type mp name
+
+ type multipath /dev/null 21 || return 1
+
+ type=$(dm_table $1)
+ [ $type = linear ] || return 1
+ name=$(dmsetup info --noheadings -c -oname $1)
+
+ mp=${name%-part*}
+ if [ $(multipath -l $mp | wc -l) -gt 0 ]; then
+ return 0
+ fi
+ return 1
+}
+
# TODO: this should not be global
humandev () {
-local host bus target part lun idenum targtype scsinum linux
+local host bus target part lun idenum targtype scsinum linux wwid
case $1 in
/dev/ide/host*/bus[01]/target[01]/lun0/disc)
host=`echo $1 | sed 's,/dev/ide/host\(.*\)/bus.*/target[01]/lun0/disc,\1,'`
@@ -698,10 +725,7 @@ humandev () {
printf $RET ${type} ${device}
;;
/dev/mapper/*)
- type=
- if [ -x /sbin/dmsetup ]; then
- type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
- fi
+ type=$(dm_table $1)
# First check for Serial ATA RAID devices
if type dmraid /dev/null 21; then
@@ -732,6 +756,16 @@ humandev () {
mapping=${1#/dev/mapper/}
db_metaget partman/text/dmcrypt_volume description
printf $RET $mapping
+ elif [ $type = multipath ]; then
+ device=${1#/dev/mapper/}
+ wwid=$(multipath -l ${device} | head -n 1 | sed s/^${device} \+(\([a-f0-9]\+\)).*/\1/)
+ db_metaget partman/text/multipath description
+ printf $RET ${device} ${wwid}
+ elif is_multipath_part $1; then
+ part=$(echo $1 | sed 's%.*-part\([0-9]\+\)$%\1%')
+ device=$(echo $1 | sed 's%/dev/mapper/\(.*\)-part[0-9]\+$%\1%')
+ db_metaget partman/text/multipath_partition description
+ printf $RET ${device} ${part}
else
# LVM2 devices are found as /dev/mapper/vg-lv. If the vg
# or lv contains a dash, the dash is replaced by two dashes.
diff --git a/packages/partman/partman-base/lib/commit.sh b/packages/partman/partman-base/lib/commit.sh
index 6ab7ede..f5ccfe9 100644
--- a/packages/partman/partman-base/lib/commit.sh
+++ b/packages/partman/partman-base/lib/commit.sh
@@ -52,8 +52,13 @@ confirm_changes
Bug#440439: Updated patch
Hi,
attached is an updated patch for multipath detection in hw-detect. The
patch hasn't changed it's just rediffed against current SVN.
Cheers,
-- Guido
From 96b6e14bf63d4df4ec62d8838ecbdbf2c30a17ba Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Tue, 26 Feb 2008 13:23:38 +0100
Subject: [PATCH] add optional multipath detection to disk-detect.sh
triggered by disk-detect/multipath/enable
---
packages/hw-detect/debian/disk-detect.templates |7
packages/hw-detect/disk-detect.sh | 40 +++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/packages/hw-detect/debian/disk-detect.templates b/packages/hw-detect/debian/disk-detect.templates
index 974c6b5..6383c60 100644
--- a/packages/hw-detect/debian/disk-detect.templates
+++ b/packages/hw-detect/debian/disk-detect.templates
@@ -35,3 +35,10 @@ Type: boolean
Default: false
Description: for internal use; can be preseeded
Check for the presence of Serial ATA RAID (dmraid) disks?
+
+Template: disk-detect/multipath/enable
+Type: boolean
+Default: false
+Description: for internal use; can be preseeded
+ Check for the presence of multipathed devices?
+
diff --git a/packages/hw-detect/disk-detect.sh b/packages/hw-detect/disk-detect.sh
index 325cf4b..67129be 100755
--- a/packages/hw-detect/disk-detect.sh
+++ b/packages/hw-detect/disk-detect.sh
@@ -91,6 +91,20 @@ module_probe() {
fi
}
+multipath_probe() {
+MP_VERBOSE=2
+# Look for multipaths...
+if [ ! -f /etc/multipath.conf ]; then
+cat EOF /etc/multipath.conf
+defaults {
+user_friendly_names yes
+}
+EOF
+fi
+log-output -t disk-detect /sbin/multipath -v$MP_VERBOSE
+[ -n $(/sbin/multipath -l) -a $? ] return 0 || return 1
+}
+
hw-detect disk-detect/detect_progress_title || true
while ! disk_found; do
@@ -166,3 +180,29 @@ if [ $RET = true ]; then
fi
fi
fi
+
+# Activate support for DM Multipath
+db_get disk-detect/multipath/enable
+if [ $RET = true ]; then
+ if anna-install multipath-udeb; then
+ MODULES=dm-mod dm-multipath dm-round-robin dm-emc
+ # We need some dm modules...
+ for MODULE in $MODULES; do
+ if is_not_loaded $MODULE; then
+module_probe $MODULE || true
+ fi
+ done
+
+ # Look for multipaths...
+ if multipath_probe; then
+ logger -t disk-detect Multipath devices found; enabling multipath support
+ if ! anna-install partman-multipath; then
+/sbin/multipath -F
+logger -t disk-detect Error loading partman-multipath; multipath devices deactivated
+ fi
+ else
+ logger -t disk-detect No multipath devices detected
+ fi
+ fi
+fi
+
--
1.5.4.2
Bug#442236: updated patch
Hi,
attached is an updated patch against current partman-base. I attach an
updated version for review since it contains a template which might be
interesting for translators
Template: partman/text/multipath
Type: text
_Description: Multipath %s (WWID %s)
Template: partman/text/multipath_partition
Type: text
_Description: Multipath %s Partition #%s
and since the partman-base code got refactored and the old version
doesn't apply anymore.
Cheers,
-- Guido
From 324593931d62491a75c2061587036062ae9c0c80 Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Tue, 26 Feb 2008 15:37:47 +0100
Subject: [PATCH] teach partman base about multipath ed devices (Closes: #442236)
---
.../partman-base/debian/partman-base.templates |8
packages/partman/partman-base/init.d/parted| 23 ++
packages/partman/partman-base/lib/base.sh | 44 +--
packages/partman/partman-base/lib/commit.sh|9 +++-
4 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/packages/partman/partman-base/debian/partman-base.templates b/packages/partman/partman-base/debian/partman-base.templates
index 5bd5e87..001301e 100644
--- a/packages/partman/partman-base/debian/partman-base.templates
+++ b/packages/partman/partman-base/debian/partman-base.templates
@@ -295,6 +295,14 @@ Type: text
# :sl3:
_Description: Serial ATA RAID %s (partition #%s)
+Template: partman/text/multipath
+Type: text
+_Description: Multipath %s (WWID %s)
+
+Template: partman/text/multipath_partition
+Type: text
+_Description: Multipath %s Partition #%s
+
Template: partman/text/lvm_lv
Type: text
# :sl3:
diff --git a/packages/partman/partman-base/init.d/parted b/packages/partman/partman-base/init.d/parted
index b10781b..b9978a3 100755
--- a/packages/partman/partman-base/init.d/parted
+++ b/packages/partman/partman-base/init.d/parted
@@ -16,6 +16,25 @@ part_of_sataraid () {
return 1
}
+part_of_multipath() {
+ local mpdev
+ type multipath /dev/null 21 || return 1
+
+ if multipath_part $1; then
+ return 0
+ fi
+ # The block devices that make up the multipath:
+ # Output looks like \_ 4:0:0:1 sdc 8:32 ...
+ for mpdev in $(multipath -l | \
+ grep '_ \([0-9]\+:\)\{3\}[0-9]\+ sd[a-z]\+ [0-9]\+:[0-9]\+' | \
+ cut -f4 -d' '); do
+ if [ $(readlink -f /dev/$mpdev) = $1 ]; then
+ return 0
+ fi
+ done
+ return 1
+}
+
if [ ! -f /var/run/parted_server.pid ]; then
mkdir -p /var/run
parted_server
@@ -24,6 +43,10 @@ if [ ! -f /var/run/parted_server.pid ]; then
# TODO: How do we signal we couldn't start parted_server properly?
exit $RET
fi
+ # Skip devices that are part of a multipathed device
+ if part_of_multipath $partdev; then
+ continue
+ fi
rm -rf /var/lib/partman/old_devices
if [ -d $DEVICES ]; then
diff --git a/packages/partman/partman-base/lib/base.sh b/packages/partman/partman-base/lib/base.sh
index 1d973cd..252499c 100644
--- a/packages/partman/partman-base/lib/base.sh
+++ b/packages/partman/partman-base/lib/base.sh
@@ -496,9 +496,36 @@ memfree () {
fi
}
+# return the device mapper table type
+dm_table ()
+{
+type=
+if [ -x /sbin/dmsetup ]; then
+type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
+fi
+echo $type
+}
+
+# Check if a device is a partition on a multipath'ed device by checking if
+# the corresponding multipath map exists
+is_multipath_part ()
+{
+ type multipath /dev/null 21 || return 1
+
+ type=$(dm_table $1)
+ [ $type = linear ] || return 1
+ name=$(dmsetup info --noheadings -c -oname $1)
+
+ mp=${name%-part*}
+ if [ $(multipath -l $mp | wc -l) -gt 0 ]; then
+ return 0
+ fi
+ return 1
+}
+
# TODO: this should not be global
humandev () {
-local host bus target part lun idenum targtype scsinum linux
+local host bus target part lun idenum targtype scsinum linux wwid
case $1 in
/dev/ide/host*/bus[01]/target[01]/lun0/disc)
host=`echo $1 | sed 's,/dev/ide/host\(.*\)/bus.*/target[01]/lun0/disc,\1,'`
@@ -698,10 +725,7 @@ humandev () {
printf $RET ${type} ${device}
;;
/dev/mapper/*)
- type=
- if [ -x /sbin/dmsetup ]; then
- type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
- fi
+ type=$(dm_table $1)
# First check for Serial ATA RAID devices
if type dmraid /dev/null 21; then
@@ -732,6 +756,16 @@ humandev () {
mapping=${1#/dev/mapper/}
db_metaget partman/text/dmcrypt_volume description
printf $RET $mapping
+ elif [ $type = multipath ]; then
+ device=${1#/dev/mapper/}
+ wwid=$(multipath -l ${device} | head -n 1 | sed s/^${device} \+(\([a-f0-9]\+\)).*/\1/)
+ db_metaget partman/text/multipath description
+ printf $RET ${device} ${wwid}
+ elif is_multipath_part $1; then
+ part=$(echo $1 | sed 's%.*-part\([0-9]\+\)$%\1%')
+ device=$(echo $1 | sed 's%/dev/mapper/\(.*\)-part[0-9]\+$%\1%')
+ db_metaget partman/text/multipath_partition description
+
disk-detect template review
Hi, Otavio asked me to put this template snippet out for review. It's been added to svn recently when we added multipath support to disk-detect: Template: disk-detect/multipath/enable Type: boolean Default: false Description: for internal use; can be preseeded Check for the presence of multipathed devices? It's been modeled after disk-detect/dmraid/enable. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442236: updated patch
Hi Frans
On Tue, Feb 26, 2008 at 04:53:52PM +0100, Frans Pop wrote:
On Tuesday 26 February 2008, Guido Günther wrote:
attached is an updated patch against current partman-base. I attach an
updated version for review since it contains a template which might be
interesting for translators
There are two (minor) issues in:
I've attached an updated patch. Thanks for the comments.
Cheers,
-- Guido
From 40d553ebe5fd9189b110dfd70c44b42f17349d4a Mon Sep 17 00:00:00 2001
From: Guido Guenther [EMAIL PROTECTED]
Date: Tue, 26 Feb 2008 15:37:47 +0100
Subject: [PATCH] teach partman base about multipath ed devices (Closes: #442236)
also addressing Frans Pop's concerns
---
.../partman-base/debian/partman-base.templates |8
packages/partman/partman-base/init.d/parted| 23 +++
packages/partman/partman-base/lib/base.sh | 42 +--
packages/partman/partman-base/lib/commit.sh|9 +++-
4 files changed, 75 insertions(+), 7 deletions(-)
diff --git a/packages/partman/partman-base/debian/partman-base.templates b/packages/partman/partman-base/debian/partman-base.templates
index 5bd5e87..001301e 100644
--- a/packages/partman/partman-base/debian/partman-base.templates
+++ b/packages/partman/partman-base/debian/partman-base.templates
@@ -295,6 +295,14 @@ Type: text
# :sl3:
_Description: Serial ATA RAID %s (partition #%s)
+Template: partman/text/multipath
+Type: text
+_Description: Multipath %s (WWID %s)
+
+Template: partman/text/multipath_partition
+Type: text
+_Description: Multipath %s Partition #%s
+
Template: partman/text/lvm_lv
Type: text
# :sl3:
diff --git a/packages/partman/partman-base/init.d/parted b/packages/partman/partman-base/init.d/parted
index b10781b..388d29a 100755
--- a/packages/partman/partman-base/init.d/parted
+++ b/packages/partman/partman-base/init.d/parted
@@ -16,6 +16,25 @@ part_of_sataraid () {
return 1
}
+part_of_multipath() {
+ local mpdev
+ type multipath /dev/null 21 || return 1
+
+ if multipath_part $1; then
+ return 0
+ fi
+ # The block devices that make up the multipath:
+ # Output looks like \_ 4:0:0:1 sdc 8:32 ...
+ for mpdev in $(multipath -l | \
+ grep '_ \([0-9]\+:\)\{3\}[0-9]\+ sd[a-z]\+ [0-9]\+:[0-9]\+' | \
+ cut -f4 -d' '); do
+ if [ $(readlink -f /dev/$mpdev) = $1 ]; then
+ return 0
+ fi
+ done
+ return 1
+}
+
if [ ! -f /var/run/parted_server.pid ]; then
mkdir -p /var/run
parted_server
@@ -24,6 +43,10 @@ if [ ! -f /var/run/parted_server.pid ]; then
# TODO: How do we signal we couldn't start parted_server properly?
exit $RET
fi
+ # Skip devices that are part of a multipathed device
+ if part_of_multipath $partdev; then
+ continue
+ fi
rm -rf /var/lib/partman/old_devices
if [ -d $DEVICES ]; then
diff --git a/packages/partman/partman-base/lib/base.sh b/packages/partman/partman-base/lib/base.sh
index 1d973cd..d3871e8 100644
--- a/packages/partman/partman-base/lib/base.sh
+++ b/packages/partman/partman-base/lib/base.sh
@@ -496,9 +496,34 @@ memfree () {
fi
}
+# return the device mapper table type
+dm_table () {
+ type=
+ if [ -x /sbin/dmsetup ]; then
+ type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
+ fi
+ echo $type
+}
+
+# Check if a device is a partition on a multipath'ed device by checking if
+# the corresponding multipath map exists
+is_multipath_part () {
+ type multipath /dev/null 21 || return 1
+
+ type=$(dm_table $1)
+ [ $type = linear ] || return 1
+ name=$(dmsetup info --noheadings -c -oname $1)
+
+ mp=${name%-part*}
+ if [ $(multipath -l $mp | wc -l) -gt 0 ]; then
+ return 0
+ fi
+ return 1
+}
+
# TODO: this should not be global
humandev () {
-local host bus target part lun idenum targtype scsinum linux
+local host bus target part lun idenum targtype scsinum linux wwid
case $1 in
/dev/ide/host*/bus[01]/target[01]/lun0/disc)
host=`echo $1 | sed 's,/dev/ide/host\(.*\)/bus.*/target[01]/lun0/disc,\1,'`
@@ -698,10 +723,7 @@ humandev () {
printf $RET ${type} ${device}
;;
/dev/mapper/*)
- type=
- if [ -x /sbin/dmsetup ]; then
- type=$(/sbin/dmsetup table $1 | head -n 1 | cut -d -f3)
- fi
+ type=$(dm_table $1)
# First check for Serial ATA RAID devices
if type dmraid /dev/null 21; then
@@ -732,6 +754,16 @@ humandev () {
mapping=${1#/dev/mapper/}
db_metaget partman/text/dmcrypt_volume description
printf $RET $mapping
+ elif [ $type = multipath ]; then
+ device=${1#/dev/mapper/}
+ wwid=$(multipath -l ${device} | head -n 1 | sed s/^${device} \+(\([a-f0-9]\+\)).*/\1/)
+ db_metaget partman/text/multipath description
+ printf $RET ${device} ${wwid}
+ elif is_multipath_part $1; then
+ part=$(echo $1 | sed 's%.*-part\([0-9]\+\)$%\1%')
+ device=$(echo $1 | sed 's%/dev/mapper/\(.*\)-part[0-9]\+$%\1%')
+ db_metaget partman/text/multipath_partition description
+ printf $RET ${device} ${part}
else
Re: New partman-multipath udeb
On Tue, Feb 26, 2008 at 05:11:51PM +0100, Frans Pop wrote: I saw that Otavio committed the multipath udeb. The indentation in various scripts is a complete mess. The indentation used spaces instead of tabs in several spaces, I cleaned that up. Also, it looks like the finish-install script should be a base-installer script (and should include what's in the finish.d script) as that would remove the need to run update-initramfs again. Could you point me to a package that does it like this? I'm fairly disappointed that this was just committed without a proper review. That certainly wasn't intended. Since this happened in separate package there's hopefuly not too much harm done. Thanks for the review, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
