|
Description
Paul Blackburn
2022-11-13 01:45:41 CET
Created attachment 13494 [details]
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on boot fail
This is the file "/run/initramfs/rdsosreport.txt" which was saved via additional USB from the debug shell when the boot failed.
Rebooted to Mageia 8 to get some additional data on the Acer Aspire one ZA3. $ lspci 00:00.0 Host bridge: Intel Corporation US15W/US15X SCH [Poulsbo] Host Bridge (rev 07) 00:02.0 VGA compatible controller: Intel Corporation US15W/US15X SCH [Poulsbo] Graphics Controller (rev 07) 00:1b.0 Audio device: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] HD Audio Controller (rev 07) 00:1c.0 PCI bridge: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] PCI Express Port 1 (rev 07) 00:1c.1 PCI bridge: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] PCI Express Port 2 (rev 07) 00:1d.0 USB controller: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] USB UHCI Controller #1 (rev 07) 00:1d.1 USB controller: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] USB UHCI Controller #2 (rev 07) 00:1d.2 USB controller: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] USB UHCI Controller #3 (rev 07) 00:1d.7 USB controller: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] USB EHCI Controller (rev 07) 00:1f.0 ISA bridge: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] LPC Bridge (rev 07) 00:1f.1 IDE interface: Intel Corporation US15W/US15X/US15L/UL11L SCH [Poulsbo] IDE Controller (rev 07) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 02) 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01) It boots ok on my desktop system using a usb drive. Most likely the write didn't finish. Sometimes the dd command returns to the command prompt before the writing is actually finished. The only way to know when it's really finished to to ensure there are no usb_storage threads showing the device wait status. Try using isodumper to write the image again, which ensures it's finished writing. CC:
(none) =>
davidwhodgins Thanks Dave. Tried using isodumper as suggested. Still fails to boot. I will document details here shortly. reference: Mageia bug => https://bugs.mageia.org/show_bug.cgi?id=31114 As suggested by Dave Hodgins, used iso dumper to create LiveUSB from Mageia-9-alpha1-Live-Xfce-i586.iso $ ls -lh total 2.8G -rw-r--r-- 1 mpb mpb 32 Nov 6 18:09 DATE.txt -rw-r--r-- 1 mpb mpb 2.8G Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.iso -rw-r--r-- 1 mpb mpb 69 Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.iso.md5 -rw-r--r-- 1 mpb mpb 165 Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.iso.sha3 -rw-r--r-- 1 mpb mpb 165 Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.iso.sha512 -rw-r--r-- 1 mpb mpb 27 Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.langs -rw-r--r-- 1 mpb mpb 69K Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.lst -rw-r--r-- 1 mpb mpb 51K Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.lst.full -rw-r--r-- 1 mpb mpb 4.1K Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.lst.leaves -rw-r--r-- 1 mpb mpb 35K Nov 6 18:09 Mageia-9-alpha1-Live-Xfce-i586.lst.names $ sha512sum -c Mageia-9-alpha1-Live-Xfce-i586.iso.sha512 Mageia-9-alpha1-Live-Xfce-i586.iso: OK $ cat DATE.txt Sun Nov 6 07:08:07 PM CET 2022 isodumper screenshots: 26% => https://i.imgur.com/YU5lJtr.png 70% => https://i.imgur.com/Iz4uBUn.png 88% => https://i.imgur.com/9DODBzV.png 100% => https://i.imgur.com/7hWAyzV.png Screenshot of no boot: => https://i.imgur.com/oTzmxoi.jpg Will attach 2nd "/run/initramfs/rdsosreport.txt" to this bug shortly Created attachment 13497 [details]
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 2nd boot fail (after using isodumper)
This is the "/run/initramfs/rdsosreport.txt" saved from debug shell on 2nd boot fail (after using isodumper to create the LiveUSB).
(ref: 2022_11_13_at_1536_rdsosreport.txt)
Currently my usb stick is /dev/sdf # blkid /dev/sdf* /dev/sdf: BLOCK_SIZE="2048" UUID="2022-11-06-18-08-07-00" LABEL="Mageia-9-a1-Live-Xfce-i586" TYPE="iso9660" PTTYPE="dos" /dev/sdf2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-ESP" UUID="6A79-3196" BLOCK_SIZE="512" TYPE="vfat" What's the output (as root) for that usb stick? From the rdosreport ... [ 24.039442] sd 2:0:0:0: [sdb] Media removed, stopped polling I'd try a different usb plug. Thanks Dave. "I'd try a different usb plug." OK, I guess you mean a different USB socket. Will do. Just now, I am just testing that liveUSB on an ancient IBM T40 (kind of dusty and mega slow... :-)) Dave > "What's the output (as root) for that usb stick?" [root@z600-mageia8 ~]# blkid /dev/sdc* /dev/sdc: BLOCK_SIZE="2048" UUID="2022-11-06-18-08-07-00" LABEL="Mageia-9-a1-Live-Xfce-i586" TYPE="iso9660" PTTYPE="dos" /dev/sdc2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-ESP" UUID="6A79-3196" BLOCK_SIZE="512" TYPE="vfat" Dave, here is what gparted shows for the Mageia-9-a1-Live-Xfce-i586.iso image USB flasah drive connected as /dev/sdc https://i.imgur.com/9tI1izM.png Dave, I mounted the mga8-alpha1 iso liveUSB with: [root@z600-mageia8 ~]# mkdir /mnt/Mageia-9-a1-Live-Xfce-i586 [root@z600-mageia8 ~]# mount /dev/sdc /mnt/Mageia-9-a1-Live-Xfce-i586 mount: /mnt/Mageia-9-a1-Live-Xfce-i586: WARNING: source write-protected, mounted read-only. [root@z600-mageia8 ~]# ls -lh /mnt/Mageia-9-a1-Live-Xfce-i586/boot/ total 55M drwxr-xr-x 1 root root 2.0K Nov 6 18:02 grub2/ -rw-r--r-- 1 root root 49M Nov 6 18:02 initrd.img -rw-r--r-- 1 501 501 136K Nov 4 01:45 memtest -rw-r--r-- 1 root root 6.3M Nov 6 18:01 vmlinuz Dave, I visually inspected the USB ports. "air dusted" them (with compressed air). Look clean and OK. Tried booting the mga8-alpha1 Xfce i586 live USB again (in a diferent USB socket). Same "Could not boot" message and debug shell. Saved the "/run/initramfs/rsdosreport.txt" and will attach here. Will try one more time but with "rd.debug" added to kernel command line. Created attachment 13499 [details]
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 3rd boot fail
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 3rd boot fail
Assigning to the iso builders group. Hopefully they can figure out what's causing it to fail. Assignee:
bugsquad =>
isobuild You've already spotted the root cause Dave: [ 23.083440] usb-storage 1-3:1.0: USB Mass Storage device detected [ 23.086218] scsi host2: usb-storage 1-3:1.0 [ 23.089493] usbcore: registered new interface driver usb-storage [ 23.100013] usbcore: registered new interface driver uas [ 24.098628] scsi 2:0:0:0: Direct-Access SMI USB MEMORY BAR 1000 PQ: 0 ANSI: 5 [ 24.102965] sd 2:0:0:0: [sdb] Media removed, stopped polling The 6.0.7-desktop586-1.mga9 kernel is failing to even read the partition table from the USB device. Did the output from blkid in comment 10 come from the same machine? CC:
(none) =>
mageia booted again and at the Mageia boot splash screen hit "e" and added "rd.debug" to tye kernel command line. saved the /run/initramfs/rdsosreport.txt Tried to attach the "rd.debug" rdsosreport.txt to this bug but found that it exceeds the 1mb limit. See: https://i.imgur.com/q5J6pyS.png $ ls -lh 2022_11_13_at_2049_with_rd.debug_rdsosreport.txt -rw-r--r-- 1 mpb mpb 1.1M Nov 13 20:50 2022_11_13_at_2049_with_rd.debug_rdsosreport.txt Hmm, perhaps the bugzilla attachment limit needs to be raised just a little? Martin > "Did the output from blkid in comment 10 come from the same machine?" No, from another Mga8 machine. I will rerun on the Acer and post result here. Martin > "Did the output from blkid in comment 10 come from the same machine?" Re-done on the Acer (where the LiveUSB boot is failing). [root@wiki-mga8 ~]# blkid /dev/sdb* /dev/sdb: BLOCK_SIZE="2048" UUID="2022-11-06-18-08-07-00" LABEL="Mageia-9-a1-Live-Xfce-i586" TYPE="iso9660" PTTYPE="dos" /dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-ESP" UUID="6A79-3196" BLOCK_SIZE="512" TYPE="vfat" Created attachment 13500 [details]
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 5th boot fail + rd.debug added to kernel command line options. Part 1of2
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 5th boot fail + rd.debug added to kernel command line options. Part 1of2
Split into two parts to circumvent the bugzilla 1mb limit for attachments.
part 1of2 is lines 1 to 8000 inclusive.
Created attachment 13501 [details]
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 5th boot fail + rd.debug added to kernel command line options. Part 2of2
file: "/run/initramfs/rdsosreport.txt" saved from debug shell on 5th boot fail + rd.debug added to kernel command line options. Part 2of2
Split into two parts to circumvent the bugzilla 1mb limit for attachments.
part 2of2 is lines 8001 to 15072 inclusive.
As suggested by Dave, I will find and prepare a 2nd LiveUSB. Did you ever try the Mageia 8 Live on that machine? Also, does Mageia-9-alpha1-Live-Xfce-x86_64.iso boot? It has the start sector for the first partition as sector 0 while the 32 bit iso has the start sector as sector 1 to prevent old buggy bios from looping while trying to read the partition table. Maybe this bios has problems with the sector being one. Ignore comment 24. I just checked and realized the atom is a 32 bit cpu. Martin > "Did you ever try the Mageia 8 Live on that machine?" I just checked it with: $ ls -lh Mageia-8-Live-Xfce-i586.iso -rw-r--r-- 1 user user 2.6G Feb 21 2021 Mageia-8-Live-Xfce-i586.iso $ sha512sum -c Mageia-8-Live-Xfce-i586.iso.sha512 Mageia-8-Live-Xfce-i586.iso: OK This ^ works fine on the Acer Aspire ZA3 with Mageia8 on liveUSB. BTW, it also works fine with Mageia8 32bit network install image on USB: $ ls -lh Mageia-8-netinstall-nonfree-i586.iso -rw-r--r-- 1 mpb mpb 99M Nov 14 01:11 Mageia-8-netinstall-nonfree-i586.iso $ sha512sum -c Mageia-8-netinstall-nonfree-i586.iso.sha512 Mageia-8-netinstall-nonfree-i586.iso: OK It's looking like a kernel/driver regression. Could you try the desktop586-6.0.8 kernel from backports_testing in your Mageia 8 system on the ZA3 to see if that has the same behaviour. Martin > "Could you try the desktop586-6.0.8 kernel from backports_testing in your Mageia 8 system on the ZA3 to see if that has the same behaviour." Thanks Martin, I will check this and post details. Hello Martin, I installed kernel-desktop586-6.0.8-3.mga8-1-1.mga8 from backports_testing on the ZA3 (running mga8). It boots OK with 6.0.8. :-) $ uname -r 6.0.8-desktop586-3.mga8 I also dusted down an old IBM T40 laptop (32bit) which is exhibiting the same boot failure with liveUSB Mageia-8-Live-Xfce-i586.iso (sam as tested on the ZA3). The T40 has mga6 installed. With kernel-desktop586-6.0.8-3.mga8 running, what is the output of blkid after you insert the Live USB stick? And also blkid /dev/sdb ls /dev/disk/by-uuid ls /dev/disk/by-label (substituting sdb with the appropriate drive identifier if necessary) [ref: comment 30] Martin > "With kernel-desktop586-6.0.8-3.mga8 running, what is the output of blkid after you insert the Live USB stick?" [mpb@wiki-mga8 ~]$ /bin/sudo blkid /dev/sda1: LABEL="BOOT" UUID="283f309b-0bd2-48d1-8c69-64a2e320ac1b" BLOCK_SIZE="1024" TYPE="ext4" /dev/sda5: LABEL="INSTALL-ISO" UUID="0d1b4485-192a-415c-84c5-318d1fe4ba22" BLOCK_SIZE="4096" TYPE="ext4" /dev/sda6: UUID="ed2f3a9e-941e-4f56-9e19-72222e85c630" TYPE="crypto_LUKS" /dev/sda7: UUID="a2a6f411-ac5f-40d4-8982-7ebf78c78ebf" TYPE="crypto_LUKS" /dev/sda8: UUID="be9fad61-aad3-4a3f-b8c1-ca0fe628b68b" TYPE="crypto_LUKS" /dev/sda9: UUID="016409df-cadc-4ea2-9c7f-dd7843b56daf" TYPE="crypto_LUKS" /dev/mapper/crypt_sda6: LABEL="SWAP" UUID="474fd2f0-625c-4671-8c6f-bc9c1b2a7fd7" TYPE="swap" /dev/mapper/crypt_sda7: LABEL="ROOT" UUID="e6347049-aa33-408f-8cdd-30d0d64f888a" BLOCK_SIZE="4096" TYPE="ext4" /dev/mapper/crypt_sda9: LABEL="HOME" UUID="0bbdd3ad-8426-42a9-ac0c-29c556a08683" BLOCK_SIZE="4096" TYPE="ext4" /dev/mapper/crypt_sda8: LABEL="USR-LOCAL" UUID="8070bdd9-2d11-496b-9b0c-bfffceb5964d" BLOCK_SIZE="4096" TYPE="ext4" /dev/loop0: BLOCK_SIZE="2048" UUID="2021-02-21-22-32-07-00" LABEL="Mageia-8-i586" TYPE="iso9660" PTTYPE="dos" /dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="MGAISO-ESP" LABEL="MGAISO-ESP" UUID="6A79-3196" BLOCK_SIZE="512" TYPE="vfat" [ref: comment 31] Martin > "And also blkid /dev/sdb" $ /bin/sudo blkid /dev/sdb /dev/sdb: BLOCK_SIZE="2048" UUID="2022-11-06-18-08-07-00" LABEL="Mageia-9-a1-Live-Xfce-i586" TYPE="iso9660" PTTYPE="dos" Martin > "And also ls /dev/disk/by-uuid" $ ls /dev/disk/by-uuid 016409df-cadc-4ea2-9c7f-dd7843b56daf@ 0d1b4485-192a-415c-84c5-318d1fe4ba22@ 2022-11-06-18-08-07-00@ 474fd2f0-625c-4671-8c6f-bc9c1b2a7fd7@ 8070bdd9-2d11-496b-9b0c-bfffceb5964d@ be9fad61-aad3-4a3f-b8c1-ca0fe628b68b@ ed2f3a9e-941e-4f56-9e19-72222e85c630@ 0bbdd3ad-8426-42a9-ac0c-29c556a08683@ 2021-02-21-22-32-07-00@ Martin > "And also ls /dev/disk/by-label" $ ls /dev/disk/by-label BOOT@ HOME@ INSTALL-ISO@ Mageia-8-i586@ Mageia-9-a1-Live-Xfce-i586@ MGAISO-ESP@ ROOT@ SWAP@ USR-LOCAL@ For completeness, here are the "-l" versions also: $ ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 10 Nov 15 21:21 016409df-cadc-4ea2-9c7f-dd7843b56daf -> ../../sda9 lrwxrwxrwx 1 root root 10 Nov 15 21:21 0bbdd3ad-8426-42a9-ac0c-29c556a08683 -> ../../dm-2 lrwxrwxrwx 1 root root 10 Nov 15 21:21 0d1b4485-192a-415c-84c5-318d1fe4ba22 -> ../../sda5 lrwxrwxrwx 1 root root 11 Nov 15 21:21 2021-02-21-22-32-07-00 -> ../../loop0 lrwxrwxrwx 1 root root 9 Nov 15 23:38 2022-11-06-18-08-07-00 -> ../../sdb lrwxrwxrwx 1 root root 10 Nov 15 21:21 283f309b-0bd2-48d1-8c69-64a2e320ac1b -> ../../sda1 lrwxrwxrwx 1 root root 10 Nov 15 21:21 474fd2f0-625c-4671-8c6f-bc9c1b2a7fd7 -> ../../dm-0 lrwxrwxrwx 1 root root 10 Nov 15 23:38 6A79-3196 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Nov 15 21:21 8070bdd9-2d11-496b-9b0c-bfffceb5964d -> ../../dm-3 lrwxrwxrwx 1 root root 10 Nov 15 21:21 a2a6f411-ac5f-40d4-8982-7ebf78c78ebf -> ../../sda7 lrwxrwxrwx 1 root root 10 Nov 15 21:21 be9fad61-aad3-4a3f-b8c1-ca0fe628b68b -> ../../sda8 lrwxrwxrwx 1 root root 10 Nov 15 21:21 e6347049-aa33-408f-8cdd-30d0d64f888a -> ../../dm-1 lrwxrwxrwx 1 root root 10 Nov 15 21:21 ed2f3a9e-941e-4f56-9e19-72222e85c630 -> ../../sda6 $ ls -l /dev/disk/by-label total 0 lrwxrwxrwx 1 root root 10 Nov 15 21:21 BOOT -> ../../sda1 lrwxrwxrwx 1 root root 10 Nov 15 21:21 HOME -> ../../dm-2 lrwxrwxrwx 1 root root 10 Nov 15 21:21 INSTALL-ISO -> ../../sda5 lrwxrwxrwx 1 root root 11 Nov 15 21:21 Mageia-8-i586 -> ../../loop0 lrwxrwxrwx 1 root root 9 Nov 15 23:38 Mageia-9-a1-Live-Xfce-i586 -> ../../sdb lrwxrwxrwx 1 root root 10 Nov 15 23:38 MGAISO-ESP -> ../../sdb2 lrwxrwxrwx 1 root root 10 Nov 15 21:21 ROOT -> ../../dm-1 lrwxrwxrwx 1 root root 10 Nov 15 21:21 SWAP -> ../../dm-0 lrwxrwxrwx 1 root root 10 Nov 15 21:21 USR-LOCAL -> ../../dm-3 So, this message in the system log from the Live boot [ 24.098628] scsi 2:0:0:0: Direct-Access SMI USB MEMORY BAR 1000 PQ: 0 ANSI: 5 [ 24.102965] sd 2:0:0:0: [sdb] Media removed, stopped polling indicates that Linux couldn't read the partition table, but the tests on Mageia 8 show that it is readable. It's just possible this was a bug in 6.0.7 that has been fixed in 6.0.8, but I wouldn't bank on it. Just to be sure it's not a marginal USB stick, can you test with a different one. Martin > "Just to be sure it's not a marginal USB stick, can you test with a different one." Thanks Martin. I used a brand new USB drive (USB 2.0 Integral 32gb) and that is working on both the ZA3 and also my ancient IBM T40 (also 32 bit). The previous "failed-to-boot" USB is a recently bought USB 3.0 Philips 16gb which I have used before and not noticed issues. I should probably ask for a refund. I double checked on yet another USB (USB 2.0 Verbatin 14gb) on both the ZA3 and T40. This boots to the Mageia9 alpha1 Xfce i586 live image. Thank you for your help and patience with this. I am wondering if there is a simple way to check and test USB drive for reliability (something like the RAM meory tester)? I think we can close this as "faulty hardware". I found this (wipes the USB data test) and am trying it out on the USB 3.0 Philips 16gb: $ duration "/bin/sudo badblocks -w -s -o error.log /dev/sdc" 2022_11_16_at_20:35:22 duration: commenced: /bin/sudo badblocks -w -s -o error.log /dev/sdc [sudo] password for user: Testing with pattern 0xaa: 11.23% done, 1:22 elapsed. (0/0/0 errors) (ref: https://www.cyberciti.biz/faq/linux-check-the-physical-health-of-a-usb-stick-flash-drive/ ) checked the "failed-to-boot" mga9-alpha1 USB 3.0 Philips 16gb: $ duration "/bin/sudo badblocks -w -s -o error.log /dev/sdc" 2022_11_16_at_20:39:03 duration: commenced: /bin/sudo badblocks -w -s -o error.log /dev/sdc Testing with pattern 0xaa: 0.71% done, 0:05 elapsed. (0/0/0 errors) done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done 2022_11_16_at_21:41:33 duration: completed 2022_11_16_at_21:41:33 duration: total duration: 1 hour 2 minutes 30 seconds $ ls -l error.log -rw-r--r-- 1 root root 0 Nov 16 20:39 error.log Hmm, what does this suggest about the USB drive? Is that connected to the same usb port used when it fails? Also what type of usb port (color) is used when it fails? https://ourtechroom.com/tech/guide-usb-port-colors-red-blue-yellow-black-white-orange-teal/ Dave> "Is that connected to the same usb port used when it fails?" No, the three USB ports on the ZA3 are all USB 2.0 (it's an old machine). Likewise, the two ports on the IBM T40 are also USB 2.0. Dave> "Also what type of usb port (color) is used when it fails?" It failed to boot on any of the ports on the ZA3 and T40. Those ports have a black plastic edge. I ran the "badblocks" test on my HP z600 which to which I added a USB3 PCIe card. The adapter card's USB type-A ports have the blue plastic edge like USB 3 ports do. This leaves me wondering how to properly verify a USB flashdrive? Normally, I just trust that a new or newish drive will work reliably. In any case, the workaround of using a different USB drive so get a working Mageia-8-Live-Xfce-i586.iso LiveUSB image seems, empirically, to work. For completness, I will run the badblocks test again versus the Philips 3.0 16gb flash drive on the ZA3 booted to mga8. It will take longer. I will leave it running overnight and post results here. test started in ZA3: duration "/bin/sudo badblocks -w -s -o error.log /dev/sdb" 2022_11_17_at_01:10:10 duration: commenced: /bin/sudo badblocks -w -s -o error.log /dev/sdb [sudo] password for user: Testing with pattern 0xaa: 0.01% done, 0:27 elapsed. (0/0/0 errors) On my test from comment 3 I also used a usb 3 stick in a usb 2 (Black) port. Among the output in "lsusb -v" for that usb stick is a line with ... Lowest fully-functional device speed is Full Speed (12Mbps) As 12Mbps is usb 1.0, the stick should work in any usb port. What's the Lowest speed for that stick? It could be a bug in the controller inside the USB stick. GRUB will have left the USB stick in some particular state after loading the Linux kernel and initrd. The Linux kernel will treat the USB stick as if it has just been plugged in and go through the USB initialisation sequence. Possibly the USB stick controller doesn't properly handle this state transition. When you tried the Mageia 8 Live, was that on the same USB stick? Created attachment 13520 [details]
output from: lsusb -v 2>&1 >2022_11_17_lsusb_report.txt
Dave > "Among the output in "lsusb -v" for that usb stick is a line with ...
Dave > Lowest fully-functional device speed is Full Speed (12Mbps)"
Thanks Dave.
I connected the failed-to-boot-mga9-alpha1-Xfce-LiveUSB (USB 3.0 Philips 16gb)
to one of the ports on the ZA3 and started running this late last night:
duration "/bin/sudo badblocks -w -s -o error.log /dev/sdb"
2022_11_17_at_01:10:10 duration: commenced: /bin/sudo badblocks -w -s -o error.log /dev/sdb
[sudo] password for user:
Testing with pattern 0xaa: 0.01% done, 0:27 elapsed. (0/0/0 errors)
Now, some 14 hours later it is still running. It is churning out messages like:
badblocks: Invalid argument during seek4/395642/0 errors)
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek4/395652/0 errors)
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek4/395662/0 errors)
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek
badblocks: Invalid argument during seek4/395673/0 errors)
etc etc
The error.log file is huge:
$ ls -lh error.log
-rw-r--r-- 1 root root 82M Nov 17 15:12 error.log
$ wc -l error.log
10144731 error.log
$ head -8 error.log
5406976
5406977
5406978
5406979
5406980
5406981
5406982
5406983
$ tail -8 error.log
397236
397237
397238
397239
397240
397241
397242
397243
I had a look at the output from "lsusb -v" and searched for "speed".
$ lsusb -v 2>&1 >2022_11_17_lsusb_report.txt
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
Couldn't open device, some information will be missing
I have attached this output ("2022_11_17_lsusb_report.txt") and welcome comments.
Martin > "When you tried the Mageia 8 Live, was that on the same USB stick?" The first time I tried this was with the Philips USB 3 16gb. I created the liveUSB two times (as described above: comment 0 - dd and comment 5 - isodumper) once using dd and once using isodumper. Both failed to boot on the ZA3 and the IBM T40. I then tried two different USB flash drives a Verbatim and an Integral (both USB 2). Both of these booted OK in both the ZA3 and the T40. Since these were OK, I suspected there might be something wrong with the Philips USB 3 16gb so I have been running the "badblocks" test. First on my HP z600 (with USB 3 ports) that was OK (see comment 36 anabove). Now I am running the badblocks test on the ZA3 and it is spewing many errors (comment 41). (In reply to Paul Blackburn from comment #42) > Martin > "When you tried the Mageia 8 Live, was that on the same USB stick?" > > > The first time I tried this was with the Philips USB 3 16gb. > > I created the liveUSB two times (as described above: comment 0 - dd and > comment 5 - isodumper) once using dd and once using isodumper. Both failed > to boot on the ZA3 and the IBM T40. It was the Mageia 8 Live (comment 26) I was interested in. That worked on the ZA3 - but was that because you used a different USB stick? If not, there's still a bit of a mystery, although your badblocks test does seem to confirm there's an incompatibility between the Philips USB stick and the ZA3. Martin > "It was the Mageia 8 Live (comment 26) I was interested in. That worked on the ZA3 - but was that because you used a different USB stick?" Yes, Mageia 8 live was a different stick (a Verbatim 2.0 14gb). The badblock test is still running on the ZA3 with the Philips USB 3 16gb. Started it some 17 hours ago. It is still spewing out errors. I am thinking just to leave it to finish. Thanks for your help and support Martin. I learned some useful things with this: installing a backports kernel, how to test and verify a USB flash drive. Thanks Paul. I think we can close this now. I'm setting it to invalid not because it wasn't a real problem, but because it wasn't a bug in the Mageia ISO. Resolution:
(none) =>
INVALID |
