[Bug 106209] Re: fsck Unable to resolve UUID
** Changed in: partman-target (Ubuntu) Importance: Undecided = Wishlist Status: New = Triaged -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
This is not a bug that will affect newbies since, very few if any, will already have an installation of linux installed in another partition. As matter of fact, one has to be an OS junkie to have enough partitions defined to be installing a new version of linux when you've already got one installed! I ran into this problem recently (Oct. 21, 2008) when I installed Intrepid to a partition where I had previously installed Hardy, with Gutsy being the version I use every day. Searching for a solution, I found https://bugs.launchpad.net/bugs/132762 and it's duplicate https://bugs.launchpad.net/bugs/134763 , both of which appear to me to be duplicates of this bug. I added my comment at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/132762/comments/5 As asked in my comment on bug #132762, is there any harm in not altering the UUID of partitions that are referenced in fstabs on other partitions? I think it would be a nice touch if partman could scan for fstabs in other partitions and report back to the user, for example: /dev/sda7 is mounted as /home for an installation on /dev/sda6. Are you sure you want to format this partition? Warning! You will lose any data you have stored on that partition!. Another example for this laptop I am using to post this: /dev/sda5 is mounted on the followining as /media/sda5 for an installation on /dev/sda6. as / for an installation on /dev/sda5 Are you sure you want to format this partition? Warning! You will lose any data you have stored on that partition! Another nice touch would be to have a Preserve UUID check box in the Prepare Partitions dialog (see http://img.xrmb2.net/images/801816.png for an example of the current dialog).This check box could be made unavailable if the results of preserving the UUID would be dangerous or if the file system being used has changed. This check box could also be informative in the case of indicating that swap partitions will have their UUIDs preserved, but at the same time made unavailable so that it just serves to inform. That would have prevented this https://bugs.launchpad.net/bugs/287539. An option to comment out references to obsolete UUIDs in fstabs that contain them would round out a set of patches that could possibly eliminate this problem. I continue to be amazed at the progress of linux and ubuntu in particular. It's just that this is one of two relatively straightforward issues were the only negatives in an otherwise absolutely flawles install procees. Apart from this issue and an issue with my installed version of grub not handling the 256bit inodes on the newly formatted ext3 root partition, everything worked out of the box, iincluding wireless networking! Alan -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
OFFTOPIC I've run into the fsck.ext3: Unable to resolve 'UUID=d073d821-427e-4aea-bd1f-53fcad4e0e81' error and halting on boot, and found this bug report. I have a hotswap bay and sometimes drives are not in the bay during boot. I wanted boot to continue without checking these absent drives. The solution, as described in the fsck man page was to make sure that there was 0 in the 6th field of fstab, rather than non-zero. (The 6th field specified the order for boot-time filesystem check, with 0 being skip.) I'm not sure if this helps out with any of the situations described here, but basically what I did was change UUID=7855008b-966e-4e4f-85ca-21f84ff13a03 /media/nearline ext3 noauto,rw,suid,dev,exec,nouser,async0 1 to UUID=7855008b-966e-4e4f-85ca-21f84ff13a03 /media/nearline ext3 noauto,rw,suid,dev,exec,nouser,async0 0 -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I have this problem after a second installation of WinXP2 in another logical disk. I installed two separate copies of winxp and one ubuntu. When the system tried to do routine filesystem check, the terminal complained: fsck.ext3: Unable to resolve 'UUID=x...' I successfully fixed the problem by typing: sudo vol_id /dev/sdaX Thanks for everyone who makes Ubuntu better. I can completely migrate to Ubuntu now. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
partman-basicfilesystems (56ubuntu4) hardy; urgency=low * Disable automounting unless partman/automount is preseeded to true. This makes LP #106209 much less likely to occur, since future installations are less likely to format a partition whose UUID we have in /etc/fstab. -- Colin Watson [EMAIL PROTECTED] Wed, 09 Apr 2008 08:18:47 +0100 ** Also affects: partman-target (Ubuntu) Importance: Undecided Status: New ** Changed in: partman-basicfilesystems (Ubuntu Hardy) Assignee: (unassigned) = Colin Watson (kamion) Status: Confirmed = Fix Released -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
The proposed partman-target change to make UUID adjustments to foreign OSes' /etc/fstab files is (a) not for Hardy and (b) possibly far too risky to contemplate at all. Making sure that the system behaves gracefully if a partition in /etc/fstab goes missing is another facet of this bug; for example we could present some kind of UI in usplash for the user to resolve this, rather than just falling over to a prompt. At any rate, disabling automounting will make sure that fresh 8.04 installations shouldn't encounter this class of problem. ** Changed in: partman-target (Ubuntu Hardy) Status: New = Won't Fix -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Was just hit by this problem in fully updated Ubuntu 7.10 Apparently, for whatever reason, the UUID of my Windows NTFS partision changed name from UUID=49862ec3-2b4b-4f20-a8b6-a57c75ee9952 to UUID=B460AD0660ACD082 1) OBVIOUSLY not automounting a windows partition should NOT halt booting into Linux (CTRL-D/d didnt do anything, had to ALT-CTRL-DEL... which then BTW took me to the desktop?!?... talk about unexpected behaviour). 2) Were on earth is the UUID change coming from? Is it some changes to ntfs-3g? The drive has obviously NOT been formated or had the UUID changed by me manually. 3) Somehow, after getting into the desktop, and opening /etc/fstab the NEW UUID has replaced the old UUID (in the console the old UUID was still there). Is this some kind of autofix/recovery? If it is, then it's still a bit broken since the update happens only AFTER the boot grinds to a halt and you manage to bypass it... by ALT-CTRL-DEL... (?!?!?) --- Log of fsck -C -R -A -a Sat Mar 1 07:02:08 2008 fsck 1.40.2 (12-Jul-2007) /dev/sda5: clean, 38/44176 files, 39660/88294 blocks /dev/sdc5: clean, 26900/61063168 files, 101604714/122095992 blocks /dev/sdb5: clean, 29431/30539776 files, 51986176/61048992 blocks /dev/sda7: clean, 21514/1310720 files, 1060626/2620595 blocks /dev/sda9: clean, 61076/24363008 files, 44087874/48705055 blocks fsck.ext3: Unable to resolve 'UUID=49862ec3-2b4b-4f20-a8b6-a57c75ee9952' fsck died with exit status 8 Excerpt from /etc/fstab ... # Entry for /dev/sda1 : UUID=B460AD0660ACD082 /media/WinXP ntfs-3g defaults,locale=en_US.UTF-8 0 0 #WTF happened, below UUID got replaced by above automatcally... #UUID=49862ec3-2b4b-4f20-a8b6-a57c75ee9952 -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I've had this same problem for months after upgrading from edgy to feisty and have been hitting Ctl+D to bypass. I'm not sure why this worked, but I was having issues with /dev/hdd. It would show up fine in /etc/fstab and in vol_id. I noticed that if I ran blkid, it would NOT show /dev/hdd. Running blkid /dev/hdd seemed to detect it. When running blkid this time, it showed up! I rebooted to verify things worked and they did... no UUID errors this time. I guess when fsck runs on boot, it must look to the information in blkid to reference the UUID's/ Anyways, hope this helps people out there. I'm glad to rid this annoyance. MikeB -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I forgot to mention that I am not using a multi-boot system. Also when using 2.6.20-16 I get the same problem - but interminably. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I also forgot to mention that I am using RAID 1 -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I am having this trouble in Gutsy when I use kernel 2.6.22-14. I get the message from fsck that it is unable to resolve a uuid, but the uuid exists. I have reverted to 2.6.20-16, which does boot - although there are some problems with booting at times with that kernel a swell. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Right, as I said, swap shouldn't be a problem. We are going to stick with UUIDs because the kernel has a fun habit of changing device names every so often. Frankly, we'd much rather have a problem on a relatively small number of multi-boot systems than on all upgrades on whatever disk controllers have had their drivers ported over to libata this release - or whatever else might happen in future. I know the result is a bit tedious, and I'm not dismissing your problem, but going back to device names at this point would regress a lot of other stuff unless we wrote a significant chunk of (very likely long-winded and error-prone) migration code. As I said in my previous post, I think my preference is to stop automounting altogether and recommend that new users use the point-and- click desktop facilities rather than explaining how to use the command line. People who know how to use mount can obviously continue to do so. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Colin, on the surface, stopping automounting sounds like a good direction for the situation - what are the consequences? Would seem to me, it would be O.K. if booting a previous installed partition didn't try to automount the newly installed partition (right now it stops the boot anyway). Hopefully it wouldn't be too complex for the user to point and click to mount when desired. Point and click for new users or even old ones is fine. I've been doing command line (or even machine code) for over 40 years but my mistake rate is higher on command line than point and click. Thanks, Jerry -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Colin, That sounds like a reasonable solution to me. It would certainly end the current problem. I'm not against CLI, though I prefer not to use it. And being forced to use it and alter system files can be scary, without knowledge and experience behind it. It's too bad that Gutsy can't be modified to do that, now. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I am an inexperienced user. Yes, you can call me a n00bie, the label doesn't bother me. What does bother me is that this bug goes back to APRIL of 2007 without a resolution. To a programmer or developer who has experience with dealing with all sorts of strange bugs, this isn't a problem. Just hit CTLD and continue on. No sweat. Then bring up 2 terminals. In one, enter blkid. In the other, enter sudo gedit /etc/fstab and compare the UUID's in each, and revise as necessary. See? Problem solved. Except that an inexperienced user wouldn't know that it's that simple to do. Nor would they feel comfortable with going in and manually editing a system file like that. Especially if the user is fresh out of that other OS that has taught him/her so well NOT to touch system files. To an inexperienced user, this is a SERIOUS bug. I run a dual boot system. That gives me a valid partition for serious work, and a second partition to use as a playground. When a playground partition proves itself to be stable, and set up the way I want, then the purposing of the two partitions switches. I currently have 4 partitions: swap (of course), /home (ok, so I finally got smart), and 2 installation partitions. I am running Ubuntu 7.10 Final (Gutsy Gibbon) on both installation partitions. I recently had a problem with one partition, and did a clean install. The new installation came up with no problem. When I went back to the old partition, I encountered the, fsck Unable to resulve UUID=. . . problem. I then spent the better part of a day searching through the Ubuntu Community Forum for a solution. That, and asking some of the wizz-kids that frequent #ubuntu- arizona on irc.freenode.net. After finally gathering up the courage to change the /etc/fstab file (using the procedure in paragraph 1), and with fear and trembling, I rebooted into the old partition. I was relieved to see that the problem had gone away. I'd actually done something right. Two days ago, I came across another problem that decided me it was time to reinstall on the playground partition (I'm hard on playgrounds). Yesterday, I booted back into the old partition (my stable source) and encountered the same problem of fsck Unable to resolve UUID=. . .. So, today, I went looking for a bug report on the problem, and discovered the above long list of bugs, comments, and possible solutions. I respectfully request that this situation be addressed and corrected. It's gone on way too long. Thank you, Craig A. Eddy (tyche) Member, Ubuntu-Arizona LoCo Team Member, Ubuntu Marketing Team https://launchpad.net/~tyche -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Part of the reason why this problem hasn't been fixed is that it has been tagged incorrectly. It is not an e2fsprogs bug, but, as described above it is an Ubuntu installer issue. Unfortunately, I have not been able to find a way correctly tag this problem inside Launchpad as an installer issue, so the wrong people are paying attention to this bug. To be fair to the installation people, this is somewhat of a hard problem, since different people use different partition schemes, and partitions that should be shared (such as /home) and partitions that shouldn't (like /var) aren't necessarily easily determinable by a program not possessing artificial intelligence. You can use heuristics, of course, but heuristics are often incorrect. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Theodore, thanks for the reply. And I think you have nailed part of the problem, if it's been tagged wrong. Yes, I understand that the problem could be hard if it were handled solely by a program. But an interaction between a program and a user might be possible, similar to the way the manual partitioning is done. Plus, a search for an /etc/fstab file shouldn't be that difficult to do. I know, I'm not a programmer (though I have done some limited shell scripting in UNIX SVR4, about 20 years ago, as well as some limited Lisp programming). It just seems to me that a conditional search would rule out many types of partitions. Just as equally, the default would be for the boot sequence to flag the problem, with a potential fix, and/or a comment it out choice for the user (defaulting to comment it out). That could avoid the confusion, and the image of our distro that such a problem creates. Is there some way that an individual can alert the right people, in this case, to what's happening? I'm too new to membership in Ubuntu to know the right people to address, or to have made such contacts. But if I'm going to be going around with an Ubuntu-Arizona golf shirt, trying to interest people in trying our distribution, then I don't want it reflecting poorly on Ubuntu because this bug exists. Thanks again, Craig -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
This appears to be no bug of e2fsprogs, as per comments. ** Changed in: ubuntu Sourcepackagename: e2fsprogs = None -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
The one thing I don't understand about this bug is that Ted has said (e.g. in https://bugs.launchpad.net/ubuntu/+bug/106209/comments/20) that Ubuntu trashes swap UUIDs by running mkswap, but as far as I know this isn't true any more. Since Ubuntu 7.04, we don't just run mkswap; we extract the old UUID with dd, run mkswap, and reinsert the old UUID again. (The reason we run mkswap at all is that it turns out to be a lot faster than asking libparted to check whether the swap partition is valid.) If we discount swap as a red herring - or at the very least a bug that's been fixed for some time, even if it still hangs around due to 6.06 and 6.10 - then there are two parts to this bug: 1) Some component of partman, probably partman-target, should check before formatting whether any of the partitions you're formatting are referred to by /etc/fstab in any of the other filesystems on the system, and issue a warning that doing this will confuse those other installations. The suggestion to add an option to save the UUID and put it back after formatting is intriguing, though of course we can only do this for sure if we're still using the same filesystem. 2) Arguably, partman-auto should not automatically mount filesystems that contain (say) /etc/fstab. I'm a little more sceptical about this, because I think we're going to be caught between a rock and a hard place. Let's say you're migrating from Red Hat to Ubuntu, and your Red Hat installation doesn't have a separate /home. In that case, it's convenient to be able to get at /home anyway, and certainly it feels inconsistent to have /home automounted only if it's on a separate partition. (Jerry may be happy to mount it by hand, but we added the automounting precisely because not everyone knew how to do that.) That said, I take Ted's point that there's no way to specify the difference between something that's in fstab for convenience and something that's there out of necessity, short perhaps of setting fs_passno to 0. However ... the desktop has got better since we did all this automounting stuff originally. Nowadays you can go to Places - Computer, double-click on the filesystem you want to use, enter your sudo password, et voilà. That wasn't the case in 5.10 when this was first implemented. Thus, perhaps it's no longer worth it, and I'm moving this bug over to partman-auto and targetting it to Hardy for further consideration. If you still want the automounting done in the installer, then speak now or forever hold your peace ... ** Changed in: partman-auto (Ubuntu) Sourcepackagename: None = partman-auto Importance: Undecided = High -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Er, yeah, the automounting is actually in partman-basicfilesystems, not partman-auto. Whoops. ** Changed in: partman-basicfilesystems (Ubuntu Hardy) Sourcepackagename: partman-auto = partman-basicfilesystems -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Colin, thanks for looking at this broken situation. For whatever reason, when I install another Ubuntu into an existing triple boot system, swap UUID's have not been a problem to fsck. The new Ubuntu happily uses whatever swap(s) it can find. Booting one of the existing partitons fails because the UUID's don't match since fsck insists on looking for a superceded UUID it doesn't need. My reaction is What the ?? then fumble around to get the system booted, remember what the problem is, and then do some tedious editing and copying. If I've been doing a bunch of installs like in the later stages of Gutsy, I may remember to do the tedious editing and copying on the other partitions while the latest install is booted up. And again the next install a few days later. It would be a whole lot less trouble for me if boot didn't automatically do that; if I happen to want to access the new partition when booted on the older, I can just sudo mkdir /media/x, then sudo mount /dev/hda1 (or sda1) /media/x. If I remember the syntax right. No long winded UUID's required. I think I could explain this to a newbie easier than explaining how to edit UUID's in /etc/fstab and /boot/grub/menu.lst without screwing up these system files. Easist for me is gedit. Under Xubuntu, remembering vim commands is a contest. What is it under Kubuntu, Kate? For the next bunch of Ubuntu tribes or eggs or flights whatever they are, maybe I'll remember to go into the existing /etc/fstab's and comment out the test partition. Is there anything in the Installation Upgrades stickies that has a preferred solution for newbie's? Jerry -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Take a look at /etc/fstab and see if the swap is being specified via a UUID or not. Then use swapon -s to see if you are actually using swap. Fortunately, if the swap partition isn't found, the system will stlil boot correctly. I agree that there's no point in changing the UUID for the swap partition --- actually the right thing to do is if there is a valid swap signature, the install procedure should simply skip the mkswap entirely. For filesystems, the reason why we change the UUID when we reformat the partition is because it is fundamentally a different filesystem at one point. For example, suppose at one point the filesystem contains the critical data files for a MySQL e-commerce database. Now suppose a college intern is given the root password to the server and typo's a mke2fs command, and blows away the filesystem and uses it to restore some backup tapes. Fundamentally, that filesystem now contains something else. Hence, it should have a new UUID. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
You've just guaranteed that dual boot Ubuntu's will fail to boot as is without user intervention. With a new UUID, and Install putting every UUID's it can find in fstab, boot's automatic fsck is guaranteed to fail when booting the second image. How do you propose to fix the problem you've created? You've got choices like: 1. Install not putting the UUID's it doesn't need into fstab. 2. fstab not causing a boot failure when it can't find a UUID that's listed in fstab. 3. At least put a message on boot that says how the user is supposed to get by the failure, i.e. Ubuntu development doesn't want to fix the problem, dump it onto the user. Thanks, Jerry p.s this is a triple boot, just installed a Gutsy Tribe 6 now I'll boot the other two images to fix their fstab's. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Yep, I'd call it an installer bug, especially if Ubuntu is actively encouraging users to do install multiple systems. Either the installer should be less greedy about installing filesystems into its fstab, or the installer should #1, ask the user if they are sure about reformatting a filesystem, and #2, ask the user whether they want to keep the UUID (in which case it should save the original UUID, and then restore it via tune2fs after running mke2fs), or #3, if the user answered no to #2, search all other filesystems if they have an fstab file referencing that UUID, and ask the user if they would like to remove or modify the line in the other filesystem's fstab file. Note that no other distribution has had this problem, probably because they as aggressively using UUID's in /etc/fstab, and they aren't encouraging users to install alternative boot filesystems on their system for successive beta releases (and hence causing those filesystems to be reformatted). For example, most Debian testers just use apt-get dist-upgrade, and so they won't run into this particular problem. I suspect that Ubuntu is also reaching out to more novice users, who don't automatically consider the need to modify /etc/fstab or to omit unneeded filesystems in /etc/fstab in the first place. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Comment preceding asked about the UUID on the swap partition. I use the same swap for all three Ubuntu's. Looking in /etc/fstab on each, the swap UUID came out the same for the three installs; I wasn't paying that close attention, but I'd conclude format didn't change the UUID for the swap partition. After some activity like downloading updates the swap does show Used. Next install I'll look a bit more closely at the swap UUID. Trying several Linux distro's and levels of Ubuntu, sometimes they don't work very well at all on one or another of our computers. Sure saves a lot of grief having a backup Ubuntu so the computer isn't dead altogether. Now it can be messy, for example Tribe 4 blew up partway thru install but after botching Grub so I had to use CD Live to re-install Grub, but as soon as that was fixed my other partition was running fine. How do we get Install to consider some means where the boot of the existing system doesn't always fail? The current Ubuntu Tribe 6 boot message after the fsck fail says a maintenance shell is being started, use Control-D to resume. That doesn't work. Exit does. Is this a new bug for launchpad? Jerry -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
This isn't an e2fsprogs bug. This is a bug in the Ubuntu installation scripts, in that: (a) Ubuntu by default greedily tries to pull all partitions that are present in the system in /etc/fstab. (Maybe that isn't a good idea if you don't need a particular partition for a particular multiboot setup... i.e., if /dev/sda1 is your Tribe1 install, and /dev/sda2 is your Tribe2 install, and you are installing /dev/sda3 with Tribe 3, you DON'T want to put /dev/sda1 and /dev/sda2 in Tribe 3's /etc/fstab --- since you don't need multiple system's root filesystems mounted in Tribe3, and at some point you might overwrite your Tribe1 install in /dev/sda1 with Tribe 4, and at that point the /etc/fstab in your Tribe 3 install is totally bogus. On the other hand if /dev/sda4 is your /home directory, then obviously that should be in the Tribe 3 install.) (b) Ubuntu insists on re-running mkswap on each new install, so if you have multiple boot systems all sharing the same swap partition, you don't want to break the other ones by re-running mkswap and blowing away the UUID used for the swap partition, because then you have to update all of the other systems' /etc/fstab files. So yes, multi-boot is a great way to test multiple versions of distros --- I don't argue with that. But the problem is that fsck has no way of knowing whether or not /dev/sda1 was *really* important (i.e., it's an old Tribe1 install, it's OK if the filesystem with uuid FOO is no longer present), or whether it's some critical part of the filesystem where if it is no longer present, bringing up the system would result in a non-functional server, and so it's better to keep the system down and NOT let it to come up all the way. For example, if you have a critical e-commerce server, and you lose the filesystem containing the database, it's better to let your High Availability system let your backup servers take over, than to let a machine which is just going to answer http requests with help I've fallen and I can't get up responses; it's considered poor form. :-) One thing I am willing to do is to add support for an fstab mount options field, non-essential, which will cause fsck to simply skip a filesystem which can't be found. Then on desktop systems, system administrators or Desktop distros could by default mark filesystems as non-essential so that systems with missing filesystems can continue coming up. Note that this could be quite confusing even on Desktop system if your /home partition is missing, since users will then log in and not have any home directories, but that transfer the responsibility to whoever is setting up the /etc/fstab file --- it definitively makes it the Distro installer's fault. Also, teaching the non-essential mount option may not be enough, since I suspect it will still cause mount -a to barf, and I believe that will cause the init scripts to bomb out, just later --- so if people really want this, they will probably also have to teach mount to understand the non-essential mount option. But, short of fixing the Ubuntu installer not do dumb things such as greadily including other root filesystems for other Linux installs in /etc/fstab by default, so that things break when you reinstall a newer version of Linux or another distro in a partition referenced by other installs' /etc/fstab, that's about the best I can do. Any comments from the Ubuntu installer folks? -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Even in Sweden we find the same problem. I have used Ubuntu 7.04 and Xubuntu without problems. After that I installed Kubuntu. After some updates this problem starts. I cannot use Ubuntu 7.04 or Xubuntu if I will not write in terminal, init 3 or init5 or sometimes I use reboot, it does not matter. How do I make it work? On the same PC I run XP, Fedora6 and Mandriva without any problems. It is Kubuntu which has got the /GRUB/menu.lst -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
From a user's standpoint, Install should not ever automatically put UUID's in fstab that Ubuntu does not need to run. If I want to mount some file system I can do it, I don't need Ubuntu making it a boot requirement for some file system that is not integral to the Ubuntu being installed. A good example is Places, Network. That finds out what systems are on the network without doing an obligatory fsck during boot and demanding that every system on the network that was there during install be there as a condition of boot. I think I can do all I need if Places Network or something similar found the other file systems that are not needed for boot. Personally I have no problem with making a directory on /media and mounting /dev/sd whatever when I need to. I do have a problem with boot stalling because fsck can't find a file system I don't need anyway. As it is, every time I do a new install, I go back and reboot previously installed systems which then hang on boot because fsck can't check a UUID that format changed, I do exit or whatever to get by that, then sudo gedit /etc/fstab and comment out the obsoleted UUID's. I presume I could patch in the current UUID's but by this time I'm usually angry at having to do it at all. This whole mess would be much less complicated if format didn't change the UUID's. What's the absolute requirement to change the UUID's anyway? On this three boot system, there's one swap partition that is used by whichever Ubuntu I'm booting at the moment. Every install always reformats the one swap. Again. I don't recall the swap ever being a problem on boot. Jerry -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
** Changed in: e2fsprogs (Ubuntu) Assignee: Brian Murray = (unassigned) Status: Incomplete = Confirmed -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
I'm installing Tribe 6 into partition 1 of a three boot system. Another partition has a running Tribe 5 in case Tribe 6 has a problem, and also has master copy of saved files. UUID culprits: Install to a partition requires formatting that partition. Format changes the UUID, example Gutsy Tribe 6 install into sda1 of a three boot system: Before install /dev/sda1: UUID=9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1 SEC_TYPE=ext2 TYPE=ext3 After install /dev/sda1: UUID=f23f7c06-5228-4b6e-8103-0adbc524f920 SEC_TYPE=ext2 TYPE=ext3 Further muddying the water, Install puts the UUID's of all three partitions in fstab. Now when I go back to boot the Tribe 5 in the other partition, boot fails because its fsck tries to do a file systems check on a UUID that no longer exists. Now Install is smart enough to recognize another Ubuntu and wants to know if I want to model things from it, like bookmarks. Why isn't it smart enough to know the fstab in the other Ubuntu is going to be wrong now, since it points to the old UUID not the new UUID that Install just created? Where in the Ubuntu instructions or in Install does it then say, formatting this partition changes the UUID so you have to manually edit any other fstab's to match, otherwise the other Ubuntu stops when it is booted? By the way, multi boot is the way to go, when trying out new distro's or new builds so there is an old partition that works in case the new one doesn't. Example on this system Tribes 1 2 did, Tribe 4 wouldn't install and botched up the partition, but I had a partition with Tribe 2 to fall back on. Jerry -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Unlinking from bug 110138, which should have been fixed for Gutsy. Gutsy has e2fsprogs 1.40.2-1, now. jerrylamos, can you take a look at bug 110138 and see if you can get some hint from there, e.g. what does blkid /dev/... display for you (try all partitions)? ** Changed in: e2fsprogs (Ubuntu) Status: Invalid = Incomplete -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
This is a three boot system. Booting Xubuntu, the middle partition, and the last one installed, gives this on blkid: [EMAIL PROTECTED]:~# blkid /dev/sda1 /dev/sda1: UUID=9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~# blkid /dev/sda3 /dev/sda3: UUID=b66f5d82-95a1-4efe-a410-55bc62e29a38 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~# blkid /dev/sda5 /dev/sda5: UUID=e804340d-a020-4bf0-87cf-6683ed868417 SEC_TYPE=ext2 TYPE=ext3 Let me attach fstab as well Let me boot up another partition to see what it gets. Jerry ** Attachment added: fstab from Xubuntu on sda3 http://launchpadlibrarian.net/9143940/fstab -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Here's the blkid's from the first partition, the Tribe 5 Ubuntu on sda1: [EMAIL PROTECTED]:~$ blkid /dev/sda1 /dev/sda1: UUID=9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~$ blkid /dev/sda3 /dev/sda3: UUID=b66f5d82-95a1-4efe-a410-55bc62e29a38 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~$ blkid /dev/sda5 /dev/sda5: UUID=e804340d-a020-4bf0-87cf-6683ed868417 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~$ Same as Xubuntu from sda3 saw, but not the same as in sda1's fstab attached. Some code changes the UUID's on install. Jerry ** Attachment added: fstab from Ubuntu Tribe 5 sda1 http://launchpadlibrarian.net/9144046/fstab -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Here's blkid's from Kubuntu Tribe 5 sda5 [EMAIL PROTECTED]:~$ blkid /dev/sda1 /dev/sda1: UUID=9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~$ blkid /dev/sda3 /dev/sda3: UUID=b66f5d82-95a1-4efe-a410-55bc62e29a38 SEC_TYPE=ext2 TYPE=ext3 [EMAIL PROTECTED]:~$ blkid /dev/sda5 /dev/sda5: UUID=e804340d-a020-4bf0-87cf-6683ed868417 SEC_TYPE=ext2 TYPE=ext3 Same as Ubuntu and Kubuntu saw, but not the same as in Kubuntu's fstab attached. All three are Tribe 5 and installed on existing partitions using edit to change mount point to / and checking format in each case. All installed within a day or so, as I remember, presumably the date is on the partitions someplace. Next I had planned on downloading the 20070906 as Tribe 6 (if they fit on a CD, 20070905 Ubuntu is pushing it at 699 mb); from what I read, it may not be officially called Tribe 6? If the Ubuntu CD Live works, I'll try install; two bits the UUID's won't be the same as in this post. If the Ubuntu install works, I'll download the Xubuntu and Kubuntu as time permits, and try the installs and marvel over the UUID's. Somebody tell me why they should ever change? What code decides what they are, anyway? Based on Tribe 5, as soon as I install Kubuntu, the previously installed Ubuntu will have UUID problems again. We'll see. Jerry ** Attachment added: fstab from Kubuntu on sda5 http://launchpadlibrarian.net/9144173/fstab -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
