| Summary: | Update candidate for schroot 1.4.21 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Philippe Makowski <makowski.mageia> |
| Component: | RPM Packages | Assignee: | Philippe Makowski <makowski.mageia> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, eeeemail, geiger.david68210, marja11, qa-bugs, stormi-mageia, tmb |
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | OK | ||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Bug Depends on: | 2606 | ||
| Bug Blocks: | |||
I guess the third one is not relevant as it concerns systemd which is only in cauldron :) CC:
(none) =>
stormi systemd is is 1 too ;) http://sophie.zarb.org/rpms/86ef84643a38e05e3ec7a8f96dab8a9e (In reply to comment #2) > systemd is is 1 too ;) > http://sophie.zarb.org/rpms/86ef84643a38e05e3ec7a8f96dab8a9e my bad :) I'm willing to test it but I don't know how to do it. Can you give me some steps to follow ? CC:
(none) =>
geiger.david68210 you have to create a chroot first (http://mageia.org/wiki/doku.php?id=chroot_howto) and after play with it with schroot you can find ideas of test and usage here : https://wiki.linaro.org/Resources/HowTo/schroot-dev-env http://www.debian-administration.org/articles/566 http://www.enricozini.org/2008/tips/joys-of-schroot/ http://www.pseudorandom.co.uk/2007/sbuild/ man page http://manpages.ubuntu.com/manpages/hardy/man1/schroot.1.html I have tested on i586
All appears OK. I created a cauldron chroot following the chroot_howto and mounted /proc
[root@localhost ~]# chroot /mnt/chroot/cauldron
[root@localhost /]# ls
bin/ dev/ home/ lib/ mnt/ proc/ sbin/ tmp/ var/
boot/ etc/ initrd/ media/ opt/ root/ sys/ usr/
[root@localhost /]# exit
exit
I set /etc/schroot/schroot.conf as..
[cauldron]
description=Mageia Cauldron
directory=/mnt/chroot/cauldron
users=root
groups=root
root-groups=root
then..
schroot -l
chroot:cauldron
schroot -c cauldron urpmi iotop
schroot -c cauldron urpmi iotop
To satisfy dependencies, the following packages are going to be installed:
Package Version Release Arch
(medium "Core Release")
iotop 0.4.3 1.mga1 noarch
python 2.7.2 1.mga2 i586
28MB of additional disk space will be used.
4.3MB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n) y
ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/i586/media/core/release/iotop-0.4.3-1.mga1.noarch.rpm
ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/i586/media/core/release/python-2.7.2-1.mga2.i586.rpm
installing iotop-0.4.3-1.mga1.noarch.rpm python-2.7.2-1.mga2.i586.rpm from /var/cache/urpmi/rpms
Preparing... #############################################
1/2: python #############################################
2/2: iotop #############################################
To check it had installed into the chroot and not the main system..
[root@localhost ~]# which iotop
which: no iotop in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin)
[root@localhost ~]# schroot -c cauldron -p iotop
Brought up the iotop running in chroot.
I will carry out the same tests on x86_64CC:
(none) =>
eeeemail On x86_64..
The same tests, installing 64bit cauldron.
[root@localhost ~]# chroot /mnt/chroot/cauldron
[root@localhost /]# ls
bin/ dev/ home/ lib/ media/ opt/ root/ sys/ usr/
boot/ etc/ initrd/ lib64/ mnt/ proc/ sbin/ tmp/ var/
[root@localhost /]# exit
exit
[root@localhost ~]# which iotop
which: no iotop in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin)
[root@localhost ~]# schroot -l
chroot:cauldron
[root@localhost ~]# schroot -c cauldron urpmi iotop
To satisfy dependencies, the following packages are going to be installed:
Package Version Release Arch
(medium "Core Release")
python 2.7.2 1.mga2 x86_64
(medium "Core 32bit Release")
iotop 0.4.3 1.mga1 noarch
28MB of additional disk space will be used.
4.4MB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n) y
ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/release/iotop-0.4.3-1.mga1.noarch.rpm
ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/release/python-2.7.2-1.mga2.x86_64.rpm
installing iotop-0.4.3-1.mga1.noarch.rpm python-2.7.2-1.mga2.x86_64.rpm from /var/cache/urpmi/rpms
Preparing... #############################################
1/2: python #############################################
2/2: iotop #############################################
[root@localhost ~]# which iotop
which: no iotop in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin)
[root@localhost ~]# schroot -c cauldron -p iotop
Brought up the iotop running in chroot.
As all appear OK in both i586 and x86_64 it should be OK to push this from core/updates_testing to core/updates.
Update Validated
sysadmin-bugs@ml.mageia.org added to CC list
(Please let me know if I've done this wrong)
Source RPM: schroot-1.4.22-1.1.mga1.src.rpm
Advisory:
This update provides schroot-1.4.22-1.1.mga1
It fixes some bugs :
* Large file support is enabled by default. This enables the use
of files over 2 GiB in size on 32 bit architectures
(Closes: Debian#619825).
* dchroot-dsa: Use current interface for loading dchroot.conf,
rather than the old, which caused a fatal exception
(Closes: Debian#626503).
* schroot: Don't use rbind when mounting filesystems in the chroot
(Closes: Debian#622756). Recursive bind mounting of /proc, /dev and
/sys caused breakage with systemd due to its use of autofs mounts.
autofs interacts badly with bind mounting, leading to unmountable
mount points. While rbind is still possible, it is not done by
default, and instead only specific filesystems are mounted;
additional mounts required must be added to the profile fstab file.Keywords:
(none) =>
validated_update Un-validating after taking further advice on this bug. It is required to reproduce the bugs and show that they have actually been solved by this update. It is not enough just to ensure it is *working*. Phillipe Makowski could you please give some detailed instructions how to do this so the update can be properly validated. Thankyou, and sorry for the confusion Keywords:
validated_update =>
(none) in fact the major bug concern 32bits os # Create an empty disk image bigger that 2G. dd if=/dev/zero of=image count=3000 bs=1M # Put a filesystem on the new disk image mkfs.ext3 -F image mount it, create a chroot in it umount it use it with schroot with type=loopback example : cat /etc/schroot/chroot.d/mageia-i386 [mageia-i386] description=Mageia 1 for i386 file=/srv/chroot/mageia-i386 root-users=philippe type=loopback users=philippe schroot -c mageia-i386 it should be ok with previous version, you get : E: /srv/chroot/mageia-i386: Failed to stat file: Value too large for defined data type other major bug concern systemd i586 I created the file /mnt/MGA and filesystem and mounted to /mnt/schroot/Mageia I created the chroot on there and umounted. I set /etc/schroot/schroot.conf to [mageia] description=Mageia file=/mnt/MGA root-users=root type=loopback users=root schroot -c mageia did generate the error stated so I was able to reproduce it. I then upgraded to the new version and received a different error. This is maybe something I have done wrong, could you please check my work here. [root@localhost ~]# schroot -c mageia E: 10mount: /sbin/losetup: invalid option -- 'j' E: 10mount: usage: E: 10mount: /sbin/losetup [options] loop_device file # setup E: 10mount: /sbin/losetup -F [options] loop_device [file] # setup, read /etc/fstab E: 10mount: /sbin/losetup loop_device # give info E: 10mount: /sbin/losetup -a # give info of all loops E: 10mount: /sbin/losetup -f # show next free loop device E: 10mount: /sbin/losetup -d loop_device # delete E: 10mount: /sbin/losetup -R loop_device # resize E: 10mount: options: -e encryption -o offset -s sizelimit -p passwdfd -T -S pseed E: 10mount: -H phash -I loinit -K gpgkey -G gpghome -C itercountk -v -r E: 10mount: -P cleartextkey > I then upgraded to the new version and received a different error. This is > maybe something I have done wrong, could you please check my work here. > > [root@localhost ~]# schroot -c mageia > E: 10mount: /sbin/losetup: invalid option -- 'j' so that's another bug :( seems that losetup under Mageia don't have the -j option !! but why ? /etc/schroot/setup.d/10mount have to be change then, or losetup have to be updated ? in /etc/schroot/setup.d/10mount can you try commenting lines 160, 161,164,165,166 # LOOP_DEVICE="$(/sbin/losetup -j "$CHROOT_FILE" | sed -e 's/:.*$//')" # if [ -z "$LOOP_DEVICE" ]; then CHROOT_MOUNT_DEVICE="$CHROOT_FILE" CHROOT_MOUNT_OPTIONS="-o loop $CHROOT_MOUNT_OPTIONS" # else # CHROOT_MOUNT_DEVICE="$LOOP_DEVICE" # fi I did as you say: # LOOP_DEVICE="$(/sbin/losetup -j "$CHROOT_FILE" | sed -e 's/:.*$//')" # if [ -z "$LOOP_DEVICE" ]; then CHROOT_MOUNT_DEVICE="$CHROOT_FILE" CHROOT_MOUNT_OPTIONS="-o loop $CHROOT_MOUNT_OPTIONS" # else # CHROOT_MOUNT_DEVICE="$LOOP_DEVICE" # fi ;; I now get [root@localhost setup.d]# schroot -c mageia W: Failed to change to directory â/etc/schroot/setup.dâ: No such file or directory W: Falling back to directory â/rootâ [root@localhost ~]# It's strange as with both of these errors it has appeared to be in a chroot but it is chroot'd to the normal system, not the chroot - if that makes sense? I need to exit/logout to get out of it. I added --verbose here is the result, if it helps.. [root@localhost schroot]# schroot --verbose -c mageia I: Executing â00check setup-start okâ I: 00check: STAGE=setup-start I: 00check: STATUS=ok I: 00check: AUTH_GID=0 I: 00check: AUTH_HOME=/root I: 00check: AUTH_RGID=0 I: 00check: AUTH_RGROUP=root I: 00check: AUTH_RUID=0 I: 00check: AUTH_RUSER=root I: 00check: AUTH_SHELL=/bin/bash I: 00check: AUTH_UID=0 I: 00check: AUTH_USER=root I: 00check: AUTH_VERBOSITY=verbose I: 00check: CHROOT_DESCRIPTION=Mageia 1 (session chroot) I: 00check: CHROOT_FILE=/mnt/MGA I: 00check: CHROOT_MOUNT_DEVICE=/mnt/MGA I: 00check: CHROOT_MOUNT_LOCATION=/var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb I: 00check: CHROOT_NAME=mageia I: 00check: CHROOT_PATH=/var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb I: 00check: CHROOT_SCRIPT_CONFIG=/etc/schroot/default/config I: 00check: CHROOT_SESSION_CLONE=false I: 00check: CHROOT_SESSION_CREATE=false I: 00check: CHROOT_SESSION_PURGE=false I: 00check: CHROOT_TYPE=loopback I: 00check: CHROOT_UNION_TYPE=none I: 00check: DATA_DIR=/usr/share/schroot I: 00check: HOST=i586-mageia-linux-gnu I: 00check: HOST_CPU=i586 I: 00check: HOST_OS=linux-gnu I: 00check: HOST_VENDOR=mageia I: 00check: LIBEXEC_DIR=/usr/lib/schroot I: 00check: MOUNT_DIR=/var/lib/schroot/mount I: 00check: PID=624 I: 00check: PLATFORM=linux I: 00check: PWD=/ I: 00check: SESSION_ID=mageia-b4683761-28b0-4489-9a04-5ded933943bb I: 00check: SETUP_DATA_DIR=/usr/share/schroot/setup I: 00check: SHLVL=1 I: 00check: SYSCONF_DIR=/etc/schroot I: 00check: VERBOSE=verbose I: 00check: _=/bin/env I: Executing â05btrfs setup-start okâ I: Executing â05file setup-start okâ I: Executing â05lvm setup-start okâ I: Executing â05union setup-start okâ I: Executing â10mount setup-start okâ I: 10mount: Mounting /mnt/MGA on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb I: 10mount: -v -o loop /mnt/MGA /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb I: 10mount: mount: going to use the loop device /dev/loop0 I: 10mount: mount: you didn't specify a filesystem type for /dev/loop0 I: 10mount: I will try type ext3 I: 10mount: /mnt/MGA on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb type ext3 (rw,loop=/dev/loop0) I: 10mount: /proc on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/proc type none (rw,bind) I: 10mount: /sys on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/sys type none (rw,bind) I: 10mount: /dev on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/dev type none (rw,bind) I: 10mount: /dev/pts on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/dev/pts type none (rw,bind) I: 10mount: /home on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/home type none (rw,bind) I: 10mount: /tmp on /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/tmp type none (rw,bind) I: Executing â15killprocs setup-start okâ I: Executing â20copyfiles setup-start okâ I: Executing â20nssdatabases setup-start okâ I: 20nssdatabases: Copying passwd database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/passwd I: 20nssdatabases: Copying shadow database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/shadow I: 20nssdatabases: Copying group database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/group I: 20nssdatabases: Copying services database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/services I: 20nssdatabases: Copying protocols database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/protocols I: 20nssdatabases: Copying networks database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/networks I: 20nssdatabases: Copying hosts database to /var/lib/schroot/mount/mageia-b4683761-28b0-4489-9a04-5ded933943bb/etc/hosts I: Executing â50chrootname setup-start okâ I: 50chrootname: Setting chroot name to mageia I: Executing â99check setup-start okâ W: Failed to change to directory â/etc/schrootâ: No such file or directory W: Falling back to directory â/rootâ I: [mageia-b4683761-28b0-4489-9a04-5ded933943bb chroot] Running login shell: â/bin/bashâ [root@localhost ~]# Searching online the losetup -j appears to be this..
-j, --associated file
show status of all loop devices associated with given file
but man losetup shows this..
-a Show status of all loop devices.
Could this be used instead?
I have removed the new version and cleared the /etc/schroot directory, then reinstalled from core/release.
10mount appears to be the same, its strange there was no error there. I suppose it must have errored before reaching that stage.
LOOP_DEVICE="$(/sbin/losetup -j "$CHROOT_FILE" | sed -e 's/:.*$//')"
if [ -z "$LOOP_DEVICE" ]; then
CHROOT_MOUNT_DEVICE="$CHROOT_FILE"
CHROOT_MOUNT_OPTIONS="-o loop $CHROOT_MOUNT_OPTIONS"
else
CHROOT_MOUNT_DEVICE="$LOOP_DEVICE"
fi
;;
-a is not exactly the same and yes 10mount did not changed with the update, it is just that nobody (including me) tested type=loopback before under Mageia my bad I only use it with plain directories and lvm snapshots Removing sysadmin from CC as this is not yet ready for updates. CC:
sysadmin-bugs =>
(none) What are the next steps for this update ? Are waiting for tests or for packager input ? Currently waiting for packager input in the form of a patch related to the script using the -j option in losetup, as that options doesn't exist in the Mageia version of losetup. CC:
(none) =>
davidwhodgins As this is not a regression and was present in the release version also could it be pushed with a note in the advisory and a new bug created for losetup to add the -j option? Suggested advisory:
-------------------------------------------------------------------------------
This update provides schroot-1.4.22-1.1.mga1
It fixes some bugs :
* Large file support is enabled by default. This enables the use
of files over 2 GiB in size on 32 bit architectures
(Closes: Debian#619825).
*** Please note that currently, mounting of loop devices requires losetup
to be updated to add the -j option schroot requires.
* dchroot-dsa: Use current interface for loading dchroot.conf,
rather than the old, which caused a fatal exception
(Closes: Debian#626503).
* schroot: Don't use rbind when mounting filesystems in the chroot
(Closes: Debian#622756). Recursive bind mounting of /proc, /dev and
/sys caused breakage with systemd due to its use of autofs mounts.
autofs interacts badly with bind mounting, leading to unmountable
mount points. While rbind is still possible, it is not done by
default, and instead only specific filesystems are mounted;
additional mounts required must be added to the profile fstab file.
------------------------------------------------------------------------------
It might be worth waiting though as the major bug fixed was with the large file support which currently won't work anyway.
claire robinson
2011-09-03 14:24:46 CEST
Depends on:
(none) =>
2606 I created bug 2606 requesting an update to losetup, part of util-linux-ng. This is really blocked by this as we are unable to carry out proper validation. Feel free to overrule :o) Assigning back to Philippe Makowski until bug 2606, which blocks this update, is fixed. CC:
(none) =>
qa-bugs may be we can close this one as "solved in next release" ? unless someone else than me can solve bug #2606 (I'm not sure that I want and have the skills to resolve bug #2606 myself, sorry) Well, aside from the losetup problem, which is not a regression as it affects the existing version too, is it worth validating or awaiting a fix? It depends: are the fixes useful in spite of the losetup bug ? - if yes: we can validate the update without waiting for a fix in losetup - in not: validating the update would bring nothing to the user, so we must first fix losetup Claire, Philippe, what is your opinion concerning this update? Is it useful to deliver it or must we first try to solve bug #2606 ? for me we are for most users in option 2 : - validating the update would bring nothing to the user, so we must first fix losetup because I guess that very few people use systemd in Mageia1 ;) I think the most useful bug being fixed with this update is broken anyway because of our losetup missing the necessary option for it to work. If losetup could be updated so the option was included then the update seems worthwhile. Removing from QA list for the time being as we can go no further with this until bug 2606 is fixed. Please reassign to QA when there is progress. Thankyou. CC:
qa-bugs =>
(none) (In reply to comment #28) > Removing from QA list for the time being as we can go no further with this > until bug 2606 is fixed. > > Please reassign to QA when there is progress. Thankyou. tmb just got pinged for that bug CC:
(none) =>
marja11, tmb 3-monthly ping putting OK on whiteboard because the assignee has worked on this bug Whiteboard:
(none) =>
OK
Samuel Verschelde
2012-08-26 14:53:30 CEST
CC:
(none) =>
qa-bugs This message is a reminder that Mageia 1 is nearing its end of life. In approximately 25 days from now, Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad Status:
NEW =>
RESOLVED |
This update provides schroot-1.4.22-1.1.mga1 It fixes some bugs : * Large file support is enabled by default. This enables the use of files over 2 GiB in size on 32 bit architectures (Closes: Debian#619825). * dchroot-dsa: Use current interface for loading dchroot.conf, rather than the old, which caused a fatal exception (Closes: Debian#626503). * schroot: Don't use rbind when mounting filesystems in the chroot (Closes: Debian#622756). Recursive bind mounting of /proc, /dev and /sys caused breakage with systemd due to its use of autofs mounts. autofs interacts badly with bind mounting, leading to unmountable mount points. While rbind is still possible, it is not done by default, and instead only specific filesystems are mounted; additional mounts required must be added to the profile fstab file.