Bug 234881
| Summary: | Run from RAM ends up requiring crazy RAM if iso burned to a DVD | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeremy Katz <katzj> |
| Component: | LiveCD | Assignee: | David Zeuthen <davidz> |
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dcantrell, mclasen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-04-04 15:27:32 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 224205 | ||
|
Description
Jeremy Katz
2007-04-02 18:29:18 UTC
Ideally we would write a small C program to dd the bits that also prints out progress etc. A simpler solution right now, however, is to use something like SIZE=$((`cat /sys/block/sr0/size` * 2048)) Replace 2048 with 512 if the media is not a disc. Ideally we wouldn't have to write anything and could just use standard utilities and get progress :) It'd be nice to have a cp with progress in a lot of cases, really But dd'ing (or even using a custom program) to go off of the block device is somewhat fundamentally flawed. The block device can actually have more data than the filesystem due to cd writers padding out to the end of the device. I wonder if we'd be better off switching to just grabbing the filesystem image (either squashfs.img or ext3fs.img) as those won't have that problem. NUM_BLOCKS=$(cat /sys/$(udevinfo --query path --name=$CDROM_DEVICE)/size) is even better I think. Back in the day this number wasn't exactly reliable (especially when the media changed) although I think we're good now. HTH. (In reply to comment #3) > I wonder if we'd be better off switching to just grabbing the filesystem image > (either squashfs.img or ext3fs.img) as those won't have that problem. Yeah, copying squashfs.img to RAM sounds like a much better idea actually (you don't want to copy ext3fs.img to RAM; it will require approx 3x times as much RAM). (In reply to comment #5) > (In reply to comment #3) > > I wonder if we'd be better off switching to just grabbing the filesystem image > > (either squashfs.img or ext3fs.img) as those won't have that problem. > > Yeah, copying squashfs.img to RAM sounds like a much better idea actually (you > don't want to copy ext3fs.img to RAM; it will require approx 3x times as much RAM). ext3fs.img only in the case of it not being squashed. Which shouldn't be anything that anyone actually distributes I wouldn't think (In reply to comment #6) > ext3fs.img only in the case of it not being squashed. Which shouldn't be > anything that anyone actually distributes I wouldn't think Good point. We should support copying both to RAM then (with squashfs being preferred to ext3fs). (In reply to comment #7) > Good point. We should support copying both to RAM then (with squashfs being > preferred to ext3fs). (just to clarify; I'm not proposing more than _one_ "run to RAM" option here) Btw, if we do this (and I think we should), mayflower should make the OS export /dev/livecd_squashfs /dev/livecd_ext3fs in addition to /dev/livecd so the installer can pick this up; this is necessary to make the installer use the in-RAM image when doing an install. Sounds good? Implemented all of this |