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.
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_64
CC: (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_updateCC: (none) => sysadmin-bugs
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.
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-bugsAssignee: qa-bugs => makowski.mageia
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
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 => RESOLVEDResolution: (none) => WONTFIX