garnet:/home/uml1# cp --sparse=always Debian-3.0r0.ext2 Debian-3.0r0.ext2~
garnet:/home/uml1# resize2fs -p Debian-3.0r0.ext2 $((1024*512))
resize2fs 1.27 (8-Mar-2002)
The containing partition (or device) is only 61389 blocks.
You requested a new size of 524288 blocks.
garnet:/home/uml1# resize2fs -p Debian-3.0r0.ext2 $((1024*512)) -f
resize2fs 1.27 (8-Mar-2002)
Begin pass 1 (max = 56)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 2 (max = 5)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 8)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on Debian-3.0r0.ext2 is now 524288 blocks long.
----- Original Message -----From: Ridgeway, AlanSent: Monday, June 16, 2003 4:58 PMSubject: RE: [uml-user] filesystem size>> Don't you get these error/warnings?no.>> Shouln't I use fdisk or a program like it? The manpage of resize2fs talks about that...The man page assumes your using a real disk, I doubt the advice would apply to a filesystem of a UML VM.Sorry I don't have much insight about your problem.When I did it, it worked on the first try.Do you have any more information about what happened ?Has anything changed since your last message ?Alan-----Original Message-----
From: Erik de Bruijn - LowVoice [mailto:Erik@LowVoice.nl]
Sent: Friday, June 13, 2003 4:56 AM
To: Ridgeway, Alan; email@example.com
Subject: Re: [uml-user] filesystem sizeHi,I got to the same problem, the root_fs' are 100% used and need resizing before usage. I've done exactly this on a working filesystem (as you suggested to the list):1) Shutdown the guest OS2) In the host OS run "e2fsck -f <name of filesystem>"3) In the host OS run "resize2fs -p <name of filesystem> <new size of file>"4) Rerun UML with the resized file system.Afterward the UML runs (with init=/bin/bash), boots up but shows on e2fsck /dev/ubd0 from within the UML. When I check the filesystem it give's a serious warning:init-2.05a# e2fsck /dev/ubd0
e2fsck 1.27 (8-Mar-2002)
The filesystem size (according to the superblock) is 524288 blocks
The physical size of the device is 516349 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>?Don't you get these error/warnings?When I boot the UML without init=/bin/bash it goes pretty weird, though I'm not sure that's because of the filesystem.Shouln't I use fdisk or a program like it? The manpage of resize2fs talks about that...Thanks for looking in to this.Erik----- Original Message -----From: Ridgeway, AlanSent: Monday, June 09, 2003 10:48 PMSubject: RE: [uml-user] filesystem sizeHere is how I resolved my issue.1) Shutdown the guest OS2) In the host OS run "e2fsck -f <name of filesystem>"3) In the host OS run "resize2fs -p <name of filesystem> <new size of file>"4) Rerun UML with the resized file system.In my case the default filesystem was 61 Meg, I resized it to 200 Meg.Now that I can edit files within the filesystem, I am writing a script to make basic network functioningin addition to what uml_net does. Like checking for /etc/resolv.conf and /etc/hostand if it does not exist, then write the file.When I finish the script I can then start splitting off COW files.Since the COW are sparse, I can't image I will run into thissame problem unless I install a lot of programs. If anyonehas experienced anything different with COW files, please let me know.ThanksAlan-----Original Message-----
From: Ridgeway, Alan
Sent: Monday, June 09, 2003 9:24 AM
Subject: [uml-user] filesystem size
Host OS: Debian unstable
Guest OS: Debian 3.0 Woody
Problem: I have created a COW for my filesystem. I was planning to write a script
to recreate my network settings when I boot my COW file the next time. But
when I try to save anything I have typed in VI, it reports that it does not have
any space left on the file system. So I run "df -am" and from the Guest OS point of view
I see it thinks that "/" is 100% used.
How do I get the guest OS to see more space in the file system so I can
save changes ?