Trying to boot the gnome live cd from a usb stick fails. The first error message shown is ... Could not find filesystem 'LABEL=Livecd-1-GNOME' blkid /dev/sdc /dev/sdc: LABEL="Livecd-1-GNOME" TYPE="iso9660" however, blkid |grep sdc /dev/sdc1: SEC_TYPE="msdos" LABEL="RESIZE_ME" UUID="5481-E153" TYPE="vfat" I suspect the output of blkid without any parameters is being parsed, rather then running blkid on each device. Same thing happens with the kde iso.
Hi, thanks for reporting this bug. Assigned to the package maintainer. Blino maybe I'am wrong in the rpm package is not draklive ?
Keywords: (none) => TriagedComponent: Installer => RPM PackagesAssignee: bugsquad => mageia
The same problem happens with the live iso burned to an optical disk.
I managed to boot a kde live cd under virtualbox once, where the iso is being treated as a dvd drive. To me this indicates it may be a problem only on older hardware like mine, and related to Bug 3315 - udev Timeout is too short.
As indicated in Bug 3385, I've found the current kernel has a regression that loads the pata_acpi kernel module before the pata_via module, so this is likely the cause of the problem for me, when using an optical drive.
CC: (none) => sysadmin-bugsComponent: RPM Packages => Release (media or process)
I'm having exactly the same result with the updated pre-release alpha 1 iso's today.
CC: sysadmin-bugs => (none)Component: Release (media or process) => RPM Packages
Keywords: (none) => PATCHCC: (none) => sysadmin-bugsComponent: RPM Packages => Release (media or process)Assignee: mageia => bugsquadSummary: Booting live alpha pre-release iso from usb fails with Could not find filesystem => Booting live iso fails with Could not find filesystem
(sysadmin, I don't know why you are in cc...)
Assignee: bugsquad => mageia
@ Dave Did you still have this problem with alpha 2?
CC: (none) => marja11
dave you can reproduce with the pre-beta3 or it's the same bug as the hp one ? (read realy fast :) )
I have to wait till tomorrow to test this (Won't have my large usb stick back till then).
Still fails with todays beta 3 pre-release. Here's the dmesg output [ 11.292906] mount: sending ioctl 5310 to a partition! [ 11.300155] mount: sending ioctl 5310 to a partition! [ 11.358750] ISOFS: Unable to identify CD-ROM format. [ 11.413776] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 11.414865] bio too big device loop0 (2 > 0) [ 11.414872] SQUASHFS error: squashfs_read_data failed to read block 0x0 [ 11.414876] SQUASHFS error: unable to read squashfs_super_block [ 11.468644] Registering unionfs 2.5.11 (for 3.3.0-rc3) [ 11.500256] dracut Warning: /sysroot has no proper rootfs layout, ignoring and removing offending mount hook [ 11.562974] dracut Warning: Can't mount root filesystem I'll dig more to see if I can figure out what's going wrong.
Looks to me like it's a udev problem. [dave@hodgins ~]$ ls -l /dev/disk/by-label|grep KDE lrwxrwxrwx 1 root root 10 Apr 8 19:31 LiveCD-2-KDE4 -> ../../sdd1 [dave@hodgins ~]$ blkid /dev/sdd1 [dave@hodgins ~]$ blkid /dev/sdd /dev/sdd: LABEL="LiveCD-2-KDE4" TYPE="iso9660" The label should be linking to /dev/sdd, not sdd1.
Blocks: (none) => 4299
CC: (none) => tmb
This is definitely a udev problem. In Mageia 1 ... $ ll /dev/disk/by-label/|grep Live lrwxrwxrwx 1 root root 10 Apr 11 15:57 LiveCD-2-KDE4 -> ../../sdd1 In a fully up-to-date Cauldron installation ... $ ls -l /dev/disk/by-label/|grep Live lrwxrwxrwx 1 root root 9 Apr 11 15:12 LiveCD-2-KDE4 -> ../../sdd So the beta 3 iso image must not have the latest udev version, and/or udev rules.
Severity: normal => critical
CC: (none) => anaselli
Colin, sorry if i bother you, but could this problem related to dracut and LABEL?
CC: (none) => mageia
This is even worse than I thought. I was trying to figure out which rule was causing the problem, so I captured the output of udevadm monitor on Mageia 1. I then rebooted back to the Cauldron install, captured the output, and compared the differences. Only differences appeared to be timestamps. I then checked /dev/disk/by-label, and in the Cauldron install, it is now LiveCD-2-KDE4 -> ../../sdd1. So, it is inconsistent. Sometimes the label points to the partition. Sometimes it points to the device. I have no idea why. It is a problem with dracut and label, but it isn't the usage of the label by dracut that is causing the problem. It's the inconsistency of udev sometimes realizing the label points to the device, and sometimes incorrectly assigning the label to the partition. Either we need a way to have udev provide consistent correct results, or dracut should use blkid directly, rather then /dev/disk/by-label to find the boot device.
Also note that when using blkid, it will only show the blkid of the device, if the device is specified as a parameter. [dave@hodgins ~]$ blkid |grep Live [dave@hodgins ~]$ blkid /dev/sd*|grep Live /dev/sdc: LABEL="LiveCD-2-KDE4" TYPE="iso9660"
Is this maybe more to do with how the ISO is created rather than udev itself specifically?
(In reply to comment #16) > Is this maybe more to do with how the ISO is created rather than udev itself > specifically? Hmm, wait, that's a daft comment, this is using the same live CD on both mga1 and cauldron... it shouldn't be a factor. I'll ask upstream.
In the meantime, can you give the output of: udevadm test /block/sdd and udevadm test /block/sdd/sdd1 (modify the sdd -> sdc as appropriate)
Created attachment 1976 [details] Output of udevadm test sdd
Created attachment 1977 [details] Output of udevadm test sdd1
Created attachment 1978 [details] Output of udevadm monitor while connecting the usb drive
Hmm, are you sure you ran the udevadm commands as I posted? It looks like you used /dev/sdd* arguments but that's not what I asked for! It has to be the path into the /sys tree that is given as an argument. Run them as root. Also, before you were talking about an CD ROM ISO but in your latest comment it it seems to be a USB drive. Can you clarify?
Created attachment 1979 [details] Output of udevadm test /block/sdd Sorry, misread the requested command. I'm trying to boot the pre-release beta 3 live cd image created using dd if=Mageia-2-beta3-LiveCD-GNOME-Europe1-Americas-i586-CD.iso of=/dev/sdd bs=1M
Created attachment 1980 [details] Output of udevadm test /block/sdd1
Arggh. Sorry, had the stick out. I'll replace those attachments shortly.
Created attachment 1981 [details] Output of udevadm test /block/sdd
Attachment 1976 is obsolete: 0 => 1 Attachment 1977 is obsolete: 0 => 1 Attachment 1979 is obsolete: 0 => 1 Attachment 1980 is obsolete: 0 => 1
Created attachment 1982 [details] Output of udevadm test /block/sdd1
Created attachment 1983 [details] Output of udevadm test /block/sdd/sdd1
Attachment 1982 is obsolete: 0 => 1
If I'm reading the attachments correctly, udev is taking the output of blkid -o udev /dev/sdd which has ID_FS_LABEL_ENC=LiveCD-2-KDE4, to create the /dev/disk/by-label > /dev/sdd, and then when sdd1 is parsed, blkid -o udev doesn't return any output, so it's using the old value for ID_FS_LABEL_ENC, and replacing the link with one pointing to /dev/sdd1. The ID_FS_LABEL_ENC needs to be initialized before trying to parse the blkid output. Why this doesn't seem to be affecting other people, I have no idea.
Although dd should work can you try using unetbootin instead do make your USB key from ISO? Just a try.
Or you could do a: dd if=/dev/zero of=/dev/sdd first, unplug, replug to make sure that /dev/sdd1 does not exist. Then do the dd of the image, and unplug/replug and check to see if /dev/sdd1 is created. I've seen some strange things in the past where my drives had two different labels attached to them. e.g. even though I overwrite /dev/sdd with an ISO, the /dev/sdd1 still had the old label I'd previously given the drive. Not sure how it was preserved but it was. Lets start with a clean slate. Also I don't think it's reusing the old value. I don't really see where it gets the label from in the sdd1 case (it doesn't seem to come from blkid) so I will try and get some advice from Kay about how that works.
(In reply to comment #30) > Although dd should work can you try using unetbootin instead do make your USB > key > from ISO? Just a try. With unetbootin, dracut fails to find the rootfs, as the label doesn't get set anywhare. Setting it on the fat32 fielsystem doesn't work.
(In reply to comment #31) > Or you could do a: > dd if=/dev/zero of=/dev/sdd > first, unplug, replug to make sure that /dev/sdd1 does not exist. > > Then do the dd of the image, and unplug/replug and check to see if /dev/sdd1 is > created. As expected, zeroing the drive before copying the image makes no difference.
Ok, so we are getting screwed by udev when making the isohybrids default to 1 like Mageia 1 (where we didn't rely on udev) It works for some but not for others... :/
(In reply to comment #34) > Ok, so we are getting screwed by udev when making the isohybrids default to 1 > like Mageia 1 (where we didn't rely on udev) > > It works for some but not for others... :/ I tried to speak to Kay about it but he wasn't really around on Friday. I'll try again speaking to him, but if anyone can investigate the full cause that would be great. I'll try and dig into it tomorrow if no one beats me.
Found some random info on this rather old thread, but not looked further than that yet. http://mailman.archlinux.org/pipermail/arch-releng/2010-March/000934.html
(In reply to comment #36) > Found some random info on this rather old thread, but not looked further than > that yet. > http://mailman.archlinux.org/pipermail/arch-releng/2010-March/000934.html That makes it clear why sdd1 is inheriting the label from sdd on my system, but deosn't explain why it isn't doing that for everyone. I think the safest way to handle this situation is to ensure isohybrid uses sector 1 for the start sector, so it doesn't lock up computers with the buggy bios, and change dracut to use blkid directly, instead of relying on /dev/disk/by-label, to find the boot device.
I don't like using blkid directly and would prefer to find a proper fix, but if we cannot work out another way then this is a reasonable fall back. Do WE have to use LABEL? Can we use UUID instead? Is that more reliable? It is perhaps harder to make work with the building process.
I have fixed it by parsing the point the label ends up pointing to, and if it points to a partition, I strip that away and mount the real device. I have tested it in virtualbox, burned to a real cd, and dd to a usb stick and they all work here :)
(In reply to comment #38) > Do WE have to use LABEL? Can we use UUID instead? Is that more reliable? It is > perhaps harder to make work with the building process. Keep in mind iso9660 filesystems don't have a uuid. (In reply to comment #39) > I have fixed it by parsing the point the label ends up pointing to, and if it > points to a partition, I strip that away and mount the real device. > > I have tested it in virtualbox, burned to a real cd, and dd to a usb stick and > they all work here :) I'll watch for the updated iso images, and retest as soon as they are available. Thanks.
Both kde and gnome live cds can now boot. Thanks for all the effort.
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Dave Hodgins from comment #10) > Still fails with todays beta 3 pre-release. Here's the dmesg output > > [ 11.292906] mount: sending ioctl 5310 to a partition! > [ 11.300155] mount: sending ioctl 5310 to a partition! > [ 11.358750] ISOFS: Unable to identify CD-ROM format. > [ 11.413776] squashfs: version 4.0 (2009/01/31) Phillip Lougher > [ 11.414865] bio too big device loop0 (2 > 0) > [ 11.414872] SQUASHFS error: squashfs_read_data failed to read block 0x0 > [ 11.414876] SQUASHFS error: unable to read squashfs_super_block > [ 11.468644] Registering unionfs 2.5.11 (for 3.3.0-rc3) > [ 11.500256] dracut Warning: /sysroot has no proper rootfs layout, > ignoring and removing offending mount hook > [ 11.562974] dracut Warning: Can't mount root filesystem > > I'll dig more to see if I can figure out what's going wrong. I see this as well. ACPI-related?
CC: (none) => kristoffer.grundstrom1983