[arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

older
[arch-dev-public] [signoff] tzdata...

Thomas Bächler

7 Jun 2009 7 Jun '09

1:41 p.m.

Going into testing in a few minutes: mkinitcpio changes: - Finally fix a bug where required HID modules were missing - Add a new COMPRESSION option that accepts gzip, lzma and bzip2 parameters (gzip is the default, the others are only supported on 2.6.30 and later) - Add a new poll_device function that waits for a block device to appear. This is used in the init function and the resume hook, with rootdelay as a maximum timeout (default to 10 seconds) - Remove the unmaintained and untested modload hook - Remove the runtime filesystems hook - Rework the code that checks whether a root device has been found, don't reboot when exiting the emergency shell, but try to continue. - Due to the new poll_device behaviour, the usb and fw runtime hooks are no longer required, remove them - Parse arguments to init properly, using the "$@" parameter from the commandline the kernel generated - also needs the new fix in the latest kinit from testing (this allows us to use init=/bin/sh again) - Adjust for the latest filesystem/module-init-tools changes - Fix an autodetection bug that would sometimes omit some filesystems cryptsetup changes: - Use poll_device when waiting for the encrypted device and the (optional) key container device (default to rootdelay), added conflicts=(mkinitcpio<0.5.25) - Add a warning if the deprecated root= syntax is used on the commandline

Attachments:

signature.asc (application/pgp-signature — 260 bytes)

Show replies by date

Roman Kyrylych

7 Jun 7 Jun

5:40 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

On Sun, Jun 7, 2009 at 16:41, Thomas Bächler wrote:

...

Going into testing in a few minutes:

mkinitcpio changes: - Finally fix a bug where required HID modules were missing - Add a new COMPRESSION option that accepts gzip, lzma and bzip2 parameters (gzip is the default, the others are only supported on 2.6.30 and later) - Add a new poll_device function that waits for a block device to appear. This is used in the init function and the resume hook, with rootdelay as a maximum timeout (default to 10 seconds) - Remove the unmaintained and untested modload hook - Remove the runtime filesystems hook - Rework the code that checks whether a root device has been found, don't reboot when exiting the emergency shell, but try to continue. - Due to the new poll_device behaviour, the usb and fw runtime hooks are no longer required, remove them - Parse arguments to init properly, using the "$@" parameter from the commandline the kernel generated - also needs the new fix in the latest kinit from testing (this allows us to use init=/bin/sh again) - Adjust for the latest filesystem/module-init-tools changes - Fix an autodetection bug that would sometimes omit some filesystems

cryptsetup changes: - Use poll_device when waiting for the encrypted device and the (optional) key container device (default to rootdelay), added conflicts=(mkinitcpio<0.5.25) - Add a warning if the deprecated root= syntax is used on the commandline

mkinitcpio -p kernel26 finished flawlessly, and I was able to boot my system with encrypted root, so I sign off both. -- Roman Kyrylych (Роман Кирилич)

Roman Kyrylych

5:51 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

On Sun, Jun 7, 2009 at 20:40, Roman Kyrylych wrote:

...

On Sun, Jun 7, 2009 at 16:41, Thomas Bächler wrote:

...
- Add a warning if the deprecated root= syntax is used on the commandline

I think this could be added to post_upgrade, because it's easy to miss when booting. -- Roman Kyrylych (Роман Кирилич)

Thomas Bächler

7:37 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

Roman Kyrylych schrieb:

...

On Sun, Jun 7, 2009 at 20:40, Roman Kyrylych wrote:

...
On Sun, Jun 7, 2009 at 16:41, Thomas Bächler wrote:

...
- Add a warning if the deprecated root= syntax is used on the commandline

I think this could be added to post_upgrade, because it's easy to miss when booting.

It has been deprecated for ages and causes bugs. In a post_install, you can't provide the whole information, thus I decided to only include it when booting.

Eric Bélanger

9:19 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

On Sun, Jun 7, 2009 at 3:37 PM, Thomas Bächler wrote:

...

Roman Kyrylych schrieb:

...
On Sun, Jun 7, 2009 at 20:40, Roman Kyrylych wrote:

...
On Sun, Jun 7, 2009 at 16:41, Thomas Bächler wrote:

...
- Add a warning if the deprecated root= syntax is used on the commandline

I think this could be added to post_upgrade, because it's easy to miss when booting.

It has been deprecated for ages and causes bugs. In a post_install, you can't provide the whole information, thus I decided to only include it when booting.

cryptsetup source url is broken: $ zcat /var/log/sourceballs/cryptsetup.gz ==> Making package: cryptsetup 1.0.6-3 x86_64 (Sun Jun 7 16:12:06 EDT 2009) ==> Retrieving Sources... -> Downloading cryptsetup-1.0.6.tar.bz2... --2009-06-07 16:12:06-- http://luks.endorphin.org/source/cryptsetup-1.0.6.tar.bz2 Resolving luks.endorphin.org... failed: Name or service not known. wget: unable to resolve host address `luks.endorphin.org' ==> ERROR: Failure while downloading cryptsetup-1.0.6.tar.bz2 Aborting...

Thomas Bächler

9:35 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

Eric Bélanger schrieb:

...

cryptsetup source url is broken:

$ zcat /var/log/sourceballs/cryptsetup.gz ==> Making package: cryptsetup 1.0.6-3 x86_64 (Sun Jun 7 16:12:06 EDT 2009) ==> Retrieving Sources... -> Downloading cryptsetup-1.0.6.tar.bz2... --2009-06-07 16:12:06-- http://luks.endorphin.org/source/cryptsetup-1.0.6.tar.bz2 Resolving luks.endorphin.org... failed: Name or service not known. wget: unable to resolve host address `luks.endorphin.org' ==> ERROR: Failure while downloading cryptsetup-1.0.6.tar.bz2 Aborting...

This tarball has been in my source directory for ages. I fixed the source URL, didn't build a new package as the URL is not included in the package file anyway.

Dan McGee

10:50 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

On Sun, Jun 7, 2009 at 8:41 AM, Thomas Bächler wrote:

...

Going into testing in a few minutes:

mkinitcpio changes: - Finally fix a bug where required HID modules were missing - Add a new COMPRESSION option that accepts gzip, lzma and bzip2 parameters (gzip is the default, the others are only supported on 2.6.30 and later) - Add a new poll_device function that waits for a block device to appear. This is used in the init function and the resume hook, with rootdelay as a maximum timeout (default to 10 seconds) - Remove the unmaintained and untested modload hook - Remove the runtime filesystems hook - Rework the code that checks whether a root device has been found, don't reboot when exiting the emergency shell, but try to continue. - Due to the new poll_device behaviour, the usb and fw runtime hooks are no longer required, remove them - Parse arguments to init properly, using the "$@" parameter from the commandline the kernel generated - also needs the new fix in the latest kinit from testing (this allows us to use init=/bin/sh again) - Adjust for the latest filesystem/module-init-tools changes - Fix an autodetection bug that would sometimes omit some filesystems

cryptsetup changes: - Use poll_device when waiting for the encrypted device and the (optional) key container device (default to rootdelay), added conflicts=(mkinitcpio<0.5.25) - Add a warning if the deprecated root= syntax is used on the commandline

I rebooted fine after regenerating on x86_64. I'm using the mdadm hook if you want to know if that still works. -Dan

Thomas Bächler

8 Jun 8 Jun

9:37 a.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

Forgot to mention: If anyone has the time, please test booting from USB (or other "slowly detected" media like firewire), it should work much better now.

Eric Bélanger

9:37 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

On Sun, Jun 7, 2009 at 9:41 AM, Thomas Bächler wrote:

...

Going into testing in a few minutes:

mkinitcpio changes: - Finally fix a bug where required HID modules were missing - Add a new COMPRESSION option that accepts gzip, lzma and bzip2 parameters (gzip is the default, the others are only supported on 2.6.30 and later) - Add a new poll_device function that waits for a block device to appear. This is used in the init function and the resume hook, with rootdelay as a maximum timeout (default to 10 seconds) - Remove the unmaintained and untested modload hook - Remove the runtime filesystems hook - Rework the code that checks whether a root device has been found, don't reboot when exiting the emergency shell, but try to continue. - Due to the new poll_device behaviour, the usb and fw runtime hooks are no longer required, remove them - Parse arguments to init properly, using the "$@" parameter from the commandline the kernel generated - also needs the new fix in the latest kinit from testing (this allows us to use init=/bin/sh again) - Adjust for the latest filesystem/module-init-tools changes - Fix an autodetection bug that would sometimes omit some filesystems

cryptsetup changes: - Use poll_device when waiting for the encrypted device and the (optional) key container device (default to rootdelay), added conflicts=(mkinitcpio<0.5.25) - Add a warning if the deprecated root= syntax is used on the commandline

I'm experience a small problem (it might be due to the changes you made.). On my i686 system with lvm, after the lvm group has been activated, I get a: "Waiting 10 seconds for device fe00" message. After the timeout, it says that "root device fe00 doesn't exits attempting to create it /bin/mknod /dev/root b 254 0" The booting continues successfully and everything seems to be working fine except I've noticed that I have a /dev/root symlink that points to a non-existing fe00 device. I don't know if this is expected because of the new poll_device function or if there's another problem elsewhere. BTW, this system use lilo in case it's related.

Thomas Bächler

9:57 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

Eric Bélanger schrieb:

...

I'm experience a small problem (it might be due to the changes you made.).

On my i686 system with lvm, after the lvm group has been activated, I get a: "Waiting 10 seconds for device fe00" message. After the timeout, it says that "root device fe00 doesn't exits attempting to create it /bin/mknod /dev/root b 254 0"

The booting continues successfully and everything seems to be working fine except I've noticed that I have a /dev/root symlink that points to a non-existing fe00 device. I don't know if this is expected because of the new poll_device function or if there's another problem elsewhere. BTW, this system use lilo in case it's related.

Ah, I didn't count on lilo ... lilo parses the block device id when you run "lilo" and passes that as the root= argument (see /proc/cmdline). That used to be necessary ages ago and apparently, it is still supported by linux (and by klibc's parseblock tool). However, it leads to problems with things like LVM, encryption and so on: The major/minor numbers at "lilo" time are not guaranteed to be the same on the next boot. The problem was already there before, you just didn't notice (as was the /dev/root symlink problem). Now we just wait until the device exists, which we cannot really check, as it is a real device. I have two solutions for you: 1) (which I gave to people for a long time now) in lilo.conf: Remove root=/dev/.... and add append="root=/dev/..." (or addappend=, see the lilo manpage) That will circumvent lilo's deprecated build-time root-device id parsing and simply pass the device to the kernel. 2) add rootdelay=0 as a parameter to your kernel commandline, that will stop us from waiting so long. Note that we will move away from klibc to uclibc soon, and also drop the klibc parseblock and kinit tools - and I seriously doubt busybox's mount command parses "fe00" as a major/minor number pair. We might add such parsing for backwards compatibility, but personally, I think it's a waste of time.

Eric Bélanger

10:22 p.m.

New subject: [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

On Mon, Jun 8, 2009 at 5:57 PM, Thomas Bächler wrote:

...

Eric Bélanger schrieb:

...
I'm experience a small problem (it might be due to the changes you made.).

On my i686 system with lvm, after the lvm group has been activated, I get a: "Waiting 10 seconds for device fe00" message. After the timeout, it says that "root device fe00 doesn't exits attempting to create it /bin/mknod /dev/root b 254 0"

The booting continues successfully and everything seems to be working fine except I've noticed that I have a /dev/root symlink that points to a non-existing fe00 device. I don't know if this is expected because of the new poll_device function or if there's another problem elsewhere. BTW, this system use lilo in case it's related.

Ah, I didn't count on lilo ... lilo parses the block device id when you run "lilo" and passes that as the root= argument (see /proc/cmdline). That used to be necessary ages ago and apparently, it is still supported by linux (and by klibc's parseblock tool).

However, it leads to problems with things like LVM, encryption and so on: The major/minor numbers at "lilo" time are not guaranteed to be the same on the next boot. The problem was already there before, you just didn't notice (as was the /dev/root symlink problem). Now we just wait until the device exists, which we cannot really check, as it is a real device. I have two solutions for you:

1) (which I gave to people for a long time now) in lilo.conf:

Remove root=/dev/.... and add append="root=/dev/..." (or addappend=, see the lilo manpage)

That will circumvent lilo's deprecated build-time root-device id parsing and simply pass the device to the kernel.

2) add rootdelay=0 as a parameter to your kernel commandline, that will stop us from waiting so long.

Note that we will move away from klibc to uclibc soon, and also drop the klibc parseblock and kinit tools - and I seriously doubt busybox's mount command parses "fe00" as a major/minor number pair. We might add such parsing for backwards compatibility, but personally, I think it's a waste of time.

Thanks for that nice explanation. I did solution #1 and everything is fine. Signoff mkinitcpio for i686. Eric

Thomas Bächler

10 Jun 10 Jun

9:15 p.m.

New subject: [arch-dev-public] [signoff] klibc and family (WAS: Re: [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3)

I completely forgot, I also need signoffs for all klibc-* packages to be moved to core.

Eric Bélanger

9:41 p.m.

New subject: [arch-dev-public] [signoff] klibc and family (WAS: Re: [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3)

On Wed, Jun 10, 2009 at 5:15 PM, Thomas Bächler wrote:

...

I completely forgot, I also need signoffs for all klibc-* packages to be moved to core.

klibc is missing the license file: http://bugs.archlinux.org/task/14775 I haven't checked the license for the other klibc-*. BTW, there are several bugs for these packages (http://bugs.archlinux.org/index.php?string=klibc&project=1). Are these fixed in the testing packages?

Jan de Groot

9:55 p.m.

New subject: [arch-dev-public] [signoff] klibc and family (WAS: Re: [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3)

On Wed, 2009-06-10 at 17:41 -0400, Eric Bélanger wrote:

...

On Wed, Jun 10, 2009 at 5:15 PM, Thomas Bächler wrote:

...
I completely forgot, I also need signoffs for all klibc-* packages to be moved to core.

klibc is missing the license file: http://bugs.archlinux.org/task/14775 I haven't checked the license for the other klibc-*.

BTW, there are several bugs for these packages (http://bugs.archlinux.org/index.php?string=klibc&project=1). Are these fixed in the testing packages?

I prepared packages for uclibc and Thomas is working on a new initramfs system based on it. Do we actually care about build problems with a library that we want to replace anyways?

Thomas Bächler

10:04 p.m.

New subject: [arch-dev-public] [signoff] klibc and family (WAS: Re: [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3)

Eric Bélanger schrieb:

...

On Wed, Jun 10, 2009 at 5:15 PM, Thomas Bächler wrote:

...
I completely forgot, I also need signoffs for all klibc-* packages to be moved to core.

klibc is missing the license file: http://bugs.archlinux.org/task/14775 I haven't checked the license for the other klibc-*.

BTW, there are several bugs for these packages (http://bugs.archlinux.org/index.php?string=klibc&project=1). Are these fixed in the testing packages?

As for the "klibc-* doesn't build" issues, I am pissed because instead of just reporting them as one reported, the reporter opened a separate report for clearly related issues. However, I cannot reproduce any of those issues. About the license, this is a apparently of mix GPL and BSD licensed code, there seems to be a license file in some directories and none in others. In short: it is unclear what the right license would actually be (I don't know who put the license line in the PKGBUILD in the first place). I am not motivated to fix any of this, because it is a mess and klibc and all related packages should disappear soon and be replaced by a uclibc+busybox-based setup: Jan already put a first toolchain for uclibc in testing, the biggest change is the early userspace scripts. klibc is unmaintained (an unpatched version still doesn't build with 2.6.28 or newer) and there has been no activity on the project in a long time.

Allan McRae

16 Jun 16 Jun

12:49 p.m.

New subject: [arch-dev-public] [signoff] klibc and family (WAS: Re: [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3)

Thomas Bächler wrote:

...

Eric Bélanger schrieb:

...
On Wed, Jun 10, 2009 at 5:15 PM, Thomas Bächler wrote:

...
I completely forgot, I also need signoffs for all klibc-* packages to be moved to core.

klibc is missing the license file: http://bugs.archlinux.org/task/14775 I haven't checked the license for the other klibc-*.

BTW, there are several bugs for these packages (http://bugs.archlinux.org/index.php?string=klibc&project=1). Are these fixed in the testing packages?

As for the "klibc-* doesn't build" issues, I am pissed because instead of just reporting them as one reported, the reporter opened a separate report for clearly related issues. However, I cannot reproduce any of those issues.

About the license, this is a apparently of mix GPL and BSD licensed code, there seems to be a license file in some directories and none in others. In short: it is unclear what the right license would actually be (I don't know who put the license line in the PKGBUILD in the first place).

I am not motivated to fix any of this, because it is a mess and klibc and all related packages should disappear soon and be replaced by a uclibc+busybox-based setup: Jan already put a first toolchain for uclibc in testing, the biggest change is the early userspace scripts. klibc is unmaintained (an unpatched version still doesn't build with 2.6.28 or newer) and there has been no activity on the project in a long time.

Well, they are working so I will signoff i686. Allan

5428

Age (days ago)

5437

Last active (days ago)

List overview

Download

15 comments

6 participants

participants (6)

Allan McRae
Dan McGee
Eric Bélanger
Jan de Groot
Roman Kyrylych
Thomas Bächler