| Summary: | mount --bind fail with squashfs (eg:in rescue mode) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | AL13N <alien> |
| Component: | RPM Packages | Assignee: | Thomas Backlund <tmb> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | davidwhodgins, pterjan, thierry.vignaud, tmb |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kernel | CVE: | |
| Status comment: | |||
|
Description
AL13N
2011-03-18 22:26:00 CET
AL13N
2011-03-18 22:27:25 CET
Blocks:
(none) =>
56
Ahmad Samir
2011-03-18 23:40:52 CET
Blocks:
56 =>
(none) even simpler reproducing: 1. boot an existing VM of mageia in vbox, but boot from DVD and choose rescue mode 2. in the menu, choose mount partitions 3. in the menu, choose console 4. use loadkeyb to get your good keyb 5. execute mount --bind /dev /mnt/dev 6. see the failure. mount --bind seems to fail on anything on root filesystem (the ramdisk), and succeed on other filesystems (/sys, /proc, /mnt/*). Same happens during install. CC:
(none) =>
pterjan Is the bug still valid ? Whiteboard:
(none) =>
check bug is still valid, just retested it, in rescue mode you cannot mount --bind /dev
AL13N
2011-10-30 13:27:21 CET
CC:
(none) =>
tmb
AL13N
2011-10-30 13:28:14 CET
CC:
(none) =>
thierry.vignaud
Manuel Hiebel
2011-10-30 14:22:04 CET
Source RPM:
mount =>
klibc Seems it's for tmb, sorry for missing this one. Assignee:
bugsquad =>
tmb This bug is still valid for the alpha 1 pre release iso. I could mount --bind /sys and /proc, but not /dev, which means mkinitrd or dracut will fail in a chroot environment. I get ... mount --bind /dev /mnt/var/mnt/a8/dev -o ro mount: wrong fs type, bad option, bad superblock on /dev What seems to be missing from mounts in rescue mode, that is present in a normal system is /dev on /dev type devtmpfs. CC:
(none) =>
davidwhodgins i'm not sure that's actually it, don't forget, rescue is more like the stage2 installer. if you want to compare, try to do a stage2 and then go to a konsole there, see if the mount points are different I don't know what you mean by a stage2. you're comparing rescue with a full system, while it's sort of like the stage2 installer. boot.iso is sort of like stage1 only, stage2 is what you load after that, (ie: the installer). in any case, perhaps the maintainer has an idea how to fix this...
Thierry Vignaud
2011-11-14 18:27:08 CET
Priority:
Normal =>
Low
Thierry Vignaud
2011-11-17 12:29:28 CET
Source RPM:
util-linux =>
drakx-installer-rescue
Thierry Vignaud
2012-01-25 17:19:32 CET
Hardware:
i586 =>
All @tv: no offense, but iinm this was working in mdv, so this is a bug and not a enhancement. how is it possible to rescue anything if you can't even chroot into it? imho this is pretty major... Chrooting works just fine (I just did it hours ago). What's more,t here's no link between: - being able to mount & chroot into the system to rescue - & being able to run mount --bind (what's more outside of the chroot) Now, since you obviously know the rescue code better than me, you'll show me where we do any mount --bind for /dev... Or for anything else besides KA... And don't talk about what works in mdv, their rescue doesn't work at all, not being able to mount the / of the system to rescue. Whereas we can. If you want to debug this go ahead but I won't spent more time on this one. I've fixed all other rescue bugs. Status:
NEW =>
UNCONFIRMED And as for the --bind issue: https://qa.mandriva.com/show_bug.cgi?id=52062 to rescue a system, i often do (manually): []# mount -t ext3 /dev/sda5 /tmp/disk []# mount -t ext3 /dev/sda1 /tmp/disk/boot []# mount --bind /dev /tmp/disk/dev []# chroot /tmp/disk ... the bind of /dev is needed often for networking or otherwise, like rsyncing from a backup or whatever. i'm pretty sure i don't know the rescue code better than you, even though i did some work on it. but the problem is that i have no idea why it doesn't work... if i had known, i'd likely have fixed it... I'm gonna read more into this issue and see if someone fixed this once... or maybe we forgot some busybox option, i donno... i do appreciate all the work you do on rescue though... in any case, i'm gonna retest this with the beta1 and see if it does or not Like I said, mounting the / and its inner fs now work again (since this evening) since I've fixed all bugs reports. So we agree that the --bind features isn't a priority since its your usage not the way rescues has been designed (mounting /, restoring the boot loader, ...) If you really want to populate the chrooted /dev (which should be somewhat populated through makedev), you may better have to run udev in the chroot. (like we do in rescue since today). Else, regarding the --bind issue, I suspect a kernel bug regarding source fs being squashfs. hmm, oic... starting udev in the chroot... hmm, i never tested that before... i wonder if this also works for network devices and well, everything... how do you start udev these days? because there's only /etc/init.d/udev-post afaik, cause i figured udevd was already started in stage1 and copied... /me 's gonna read some of your last changes and see how this works... running start_udev in the chroot should be enough Anyway reassigning to kernel for the --bind issue Summary:
in rescue mode mount --bind seems to fail =>
mount --bind fail with squashfs (eg:in rescue mode) BTW mount --bind on /dev should work now that we used udev in rescue image Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja Keywords:
(none) =>
NEEDINFO I've just tested using the rescue option from the i586 dvd iso, and comment 17 is correct. Mounting with the --bind option is working. Closing the bug as fixed. Status:
UNCONFIRMED =>
RESOLVED |