Re: Remastering of 64-bits version: Trouble with isofs? Huge .rr_mved
On Sun, Jul 17, 2011 at 03:01:21PM +0000, Capri Corny wrote:
> I have just tried the first remastering of a 64-bits version, and
> everything looks fine.� The init halts, however, at the end of the init
> script, when /home is to be mounted by /bin/mount and /sbin/init is to be
> run.� Knoppix complains it can't find those files, but I have loop-mounted
> the KNOPPIX image and run mount from it - works perfectly fine.� So I
> wonder what is wrong here.
> It is a large image - 7.5 GB (compressed from ca 20GB, 4700 packages) ,
> and there were lots of complaints during the creation of isofs.
If you mean the "warnings" about file renaming in the
iso9660-convention, don't worry, files will automatically be
retranslated into Unix naming conventions since you have used the -R
flag.
Btw, here are my options for the compressed image (KNOPPIX/KNOPPIX):
mkisofs -input-charset ISO-8859-15 -R -l -D \
-no-split-symlink-components -no-split-symlink-fields \
-V KNOPPIX_FS \
-hide-rr-moved -cache-inodes -pad \
-exclude-list /tmp/mkisofs.exclude /path/to/chroot/tree | \
create_compressed_fs -B $BLOCKSIZE -t 8 -1 -f KNOPPIX.tmp - KNOPPIX
(Choose $BLOCKSIZE and Compression level according to the machine used
for compression).
The next probem that can arise is, that iso9660 does not handle file
sizes larger than 4GB. If your KNOPPIX/KNOPPIX image is larger than 4
GB, it will be truncated on the DVD (either a single- or double-sided),
and cloop will probably complain that the image is incomplete.
Solution: Split the image into several files of sizes of smaller than
4GB. You cannot simply use "split", of course. You have to exclude the
files that you plan to put into the second image from the first, and
exclude files from the first image on the second one. Alternately, you
can use graft-points in order to INCLUDE only selected files and
directories. Make sure that the files needed for booting prior to aufs
are working from the first image alone (i.e. /lib, /bin, /usr/lib,
/usr/bin).
Name the first image KNOPPIX/KNOPPIX, and the second KNOPPIX/KNOPPIX2,
and aufs will assemble them in the right order as one large filesystem.
> is huge:
>
> � r-xr-xr-x 4956 root root 632832 Jul 17 09:52 .rr_moved
>
> But everything seems fine under loop-mounting, from df output:
>
> �/dev/cloop1���������� 19578442� 19578442�������� 0 100% /tmp/KNOPPIX
You can mount an iso larger than 4GB, but you cannot put an iso larger
than 4 GB inside another iso, because of the iso max file size
limitation.
> So I wonder if the problems may stem from isofs?� Or is there some kind of
> difficulty inherent in remastering from HD?� Or is there something with 64
> bits in play?
There is no genuine 64bit problem I'm aware of, but a maximum filesize
limit in iso9660. Btw, the same problem for FAT32 as container.
Putting squashfs inside the compressed image will not help if the file
size of the image is still above 4GB.
You will either have to split the image, or use a surrounding filesystem
that can handle files larger than 4GB, like ext*, reiserfs, ntfs. You
will need a different bootloader than isolinux/syslinux, though, or you
will have to put the large compressed file on a second partition with a
>4GB supporting file system.
> I copied /dev from a KNOPPIX cloop image, not from the HD install.� Could
> this lead to such problems?
Probably not, if you used cp -a.
> I also think I might switch to squashfs, or is the present cloop-based
> system much to prefer?
I gave not used squashfs much yet, I still like cloop because it is
filesystem-independent and quite robust when physical read errors occur
(i.e. it does not crash easily, working on the block-device level).
Regards
-Klaus
Reply to: