Newbie alert - it has been _years_ since I've tried to boot from USB - today I have tried two TW ISOs - first TW Rescue CD i686, next TW DVD x86_64. Copied them to USB with 'dd'. Booting either one produces $SUBJ. Any hints? -- Per Jessen, Zürich (17.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 22.04.2023 17:10, Per Jessen wrote:
Newbie alert - it has been _years_ since I've tried to boot from USB - today I have tried two TW ISOs - first TW Rescue CD i686,
TW stopped bulding 32 bit since the beginning of April. It is now maintained in ports, although it seems to be stalled.
next TW DVD x86_64. Copied them to USB with 'dd'. Booting either one produces $SUBJ.
I tested openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230420-Media.iso and openSUSE-Tumbleweed-LegacyX86-NET-i586-Snapshot20230403-Media.iso in QEMU with legacy BIOS presenting them as USB drive and both show boot menu. x86_64 image failed to boot rescue system, I had to manually select ISO partition as installation source then it worked. i586 image booted rescue normally.
Any hints?
Sounds like BIOS problem. The message comes from extlinux boot code that tries to read from partition. How exactly did you create USB?
Andrei Borzenkov wrote:
On 22.04.2023 17:10, Per Jessen wrote:
Newbie alert - it has been _years_ since I've tried to boot from USB - today I have tried two TW ISOs - first TW Rescue CD i686,
TW stopped bulding 32 bit since the beginning of April. It is now maintained in ports, although it seems to be stalled.
Yep, I have switched to ports/i586. and yes, it does seem to have stalled.
next TW DVD x86_64. Copied them to USB with 'dd'. Booting either one produces $SUBJ.
I tested openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230420-Media.iso and openSUSE-Tumbleweed-LegacyX86-NET-i586-Snapshot20230403-Media.iso in QEMU with legacy BIOS presenting them as USB drive and both show boot menu. x86_64 image failed to boot rescue system, I had to manually select ISO partition as installation source then it worked. i586 image booted rescue normally.
Okay, thanks for checking.
Any hints?
Sounds like BIOS problem. The message comes from extlinux boot code that tries to read from partition. How exactly did you create USB?
dd if=isofile of=/dev/sdx bs=4M ISTR that being the standard with the NET images. -- Per Jessen, Zürich (15.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 22.04.2023 19:15, Per Jessen wrote:
Andrei Borzenkov wrote:
On 22.04.2023 17:10, Per Jessen wrote:
Newbie alert - it has been _years_ since I've tried to boot from USB - today I have tried two TW ISOs - first TW Rescue CD i686,
TW stopped bulding 32 bit since the beginning of April. It is now maintained in ports, although it seems to be stalled.
Yep, I have switched to ports/i586. and yes, it does seem to have stalled.
next TW DVD x86_64. Copied them to USB with 'dd'. Booting either one produces $SUBJ.
I tested openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230420-Media.iso and openSUSE-Tumbleweed-LegacyX86-NET-i586-Snapshot20230403-Media.iso in QEMU with legacy BIOS presenting them as USB drive and both show boot menu. x86_64 image failed to boot rescue system, I had to manually select ISO partition as installation source then it worked. i586 image booted rescue normally.
Okay, thanks for checking.
Any hints?
Sounds like BIOS problem. The message comes from extlinux boot code that tries to read from partition. How exactly did you create USB?
dd if=isofile of=/dev/sdx bs=4M
Did you try another USB stick? I had cases when there were no errors during write but USB stick happily returned zeroes for the half of its capacity.
ISTR that being the standard with the NET images.
On 4/22/23 10:31, Andrei Borzenkov wrote:
dd if=isofile of=/dev/sdx bs=4M
Did you try another USB stick? I had cases when there were no errors during write but USB stick happily returned zeroes for the half of its capacity.
I've heard about fraudulent high-capacity USB sticks that can be purchased on Amazon. Make sure you purchase name-brand sticks, they may cost more and be of lower capacity, but you won't get ripped off! Regards, Lew
Le 22/04/2023 à 20:19, Lew Wolfgang a écrit :
On 4/22/23 10:31, Andrei Borzenkov wrote:
dd if=isofile of=/dev/sdx bs=4M
Did you try another USB stick? I had cases when there were no errors during write but USB stick happily returned zeroes for the half of its capacity.
I've heard about fraudulent high-capacity USB sticks that can be purchased on Amazon. Make sure you purchase name-brand sticks, they may cost more and be of lower
not true. counterfakes products may have nice brand names. Some time ago I tested this (on aliexpress, not amazon - and have been refunded), I have perfectly nice looking kingston, including blister, that are obvious fakes. uses (windows) h2tstw or f3 (same for linux) to test them. but the per problem seems to me different (two different models) jdd -- mon serveur usenet: dodin.fr.nf c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet
Andrei Borzenkov wrote:
Sounds like BIOS problem. The message comes from extlinux boot code that tries to read from partition. How exactly did you create USB?
dd if=isofile of=/dev/sdx bs=4M
Did you try another USB stick?
I used two different ones, an older 4Gb one for the Rescue image, and a new Sandisk Cruzer 32Gb for the DVD image. I think I'm going to try to install regular 64bit Tumbleweed on this test box, I don't really have any reason to continue running 32bit. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Andrei Borzenkov wrote:
Sounds like BIOS problem. The message comes from extlinux boot code that tries to read from partition. How exactly did you create USB?
dd if=isofile of=/dev/sdx bs=4M
Did you try another USB stick?
I used two different ones, an older 4Gb one for the Rescue image, and a new Sandisk Cruzer 32Gb for the DVD image.
I think I'm going to try to install regular 64bit Tumbleweed on this test box, I don't really have any reason to continue running 32bit.
Just to finish off this thread - I have just now booted the machine from a CD copy of "openSUSE 13.1 NET 32bit". No problem whatsoever, and the update issue was quickly fixed. I am slightly concerned about the difficulties I had booting tw64 over PXE, but I'll probably play with that later today. Maybe start another thread :-) -- Per Jessen, Zürich (14.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Just to finish off this thread - I have just now booted the machine from a CD copy of "openSUSE 13.1 NET 32bit". No problem whatsoever, and the update issue was quickly fixed.
I am slightly concerned about the difficulties I had booting tw64 over PXE, but I'll probably play with that later today. Maybe start another thread :-)
Nah I won't. It's been a rainy and wet Sunday here, so time to play around with this sort of thing. I did have weird and wonderful issues trying to boot TW64 over PXE, made me wonder if the CPU actually supported 64bits. In the end it turned out to be a memory issue. Get rid of some bad DIMM modules and it works just fine :-) I don't rememeber the last time I did a TW installation from scratch. -- Per Jessen, Zürich (15.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
* Per Jessen <per@opensuse.org> [04-23-23 10:54]:
Per Jessen wrote:
Just to finish off this thread - I have just now booted the machine from a CD copy of "openSUSE 13.1 NET 32bit". No problem whatsoever, and the update issue was quickly fixed.
I am slightly concerned about the difficulties I had booting tw64 over PXE, but I'll probably play with that later today. Maybe start another thread :-)
Nah I won't. It's been a rainy and wet Sunday here, so time to play around with this sort of thing. I did have weird and wonderful issues trying to boot TW64 over PXE, made me wonder if the CPU actually supported 64bits. In the end it turned out to be a memory issue. Get rid of some bad DIMM modules and it works just fine :-)
I don't rememeber the last time I did a TW installation from scratch.
yeah, once you get it installed the first time, "It Just Works" :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Patrick Shanahan wrote:
* Per Jessen <per@opensuse.org> [04-23-23 10:54]:
Per Jessen wrote:
Just to finish off this thread - I have just now booted the machine from a CD copy of "openSUSE 13.1 NET 32bit". No problem whatsoever, and the update issue was quickly fixed.
I am slightly concerned about the difficulties I had booting tw64 over PXE, but I'll probably play with that later today. Maybe start another thread :-)
Nah I won't. It's been a rainy and wet Sunday here, so time to play around with this sort of thing. I did have weird and wonderful issues trying to boot TW64 over PXE, made me wonder if the CPU actually supported 64bits. In the end it turned out to be a memory issue. Get rid of some bad DIMM modules and it works just fine :-)
I don't rememeber the last time I did a TW installation from scratch.
yeah, once you get it installed the first time, "It Just Works" :)
Still, occasionally some minor surprises - network config now is networkmanager only, at least by default. It was easy to install wicked though. Next I had to add 'net.ifnames=0' to the boot config. Good stuff. -- Per Jessen, Zürich (14.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Patrick Shanahan wrote:
* Per Jessen <per@opensuse.org> [04-23-23 10:54]:
I don't rememeber the last time I did a TW installation from scratch.
yeah, once you get it installed the first time, "It Just Works" :)
Still, occasionally some minor surprises - network config now is networkmanager only, at least by default. It was easy to install wicked though. Next I had to add 'net.ifnames=0' to the boot config. Good stuff.
Another small surprise - unable to restart syslog. "Unit var-run.mount" not found. It does in fact not exist. On a 2nd TW system, that unit seems to have been provided by systemd-sysvcompat. -- Per Jessen, Zürich (13.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 23.04.2023 18:48, Per Jessen wrote:
Another small surprise - unable to restart syslog.
I do not even have syslog.service here. So you probably need to elaborate what "restarting syslog" means.
"Unit var-run.mount" not found. It does in fact not exist. On a 2nd TW system, that unit seems to have been provided by systemd-sysvcompat.
/var/run is symlink to /run since I do not remember how long. If there is still some unit that depends on /var/run being mount point, it probably should be considered a bug in this unit.
Andrei Borzenkov wrote:
On 23.04.2023 18:48, Per Jessen wrote:
Another small surprise - unable to restart syslog.
I do not even have syslog.service here. So you probably need to elaborate what "restarting syslog" means.
Hehe, okay :-) With syslog-ng installed: systemctl restart syslog (syslog.service is a symlink to syslog-ng.service)
"Unit var-run.mount" not found. It does in fact not exist. On a 2nd TW system, that unit seems to have been provided by systemd-sysvcompat.
/var/run is symlink to /run since I do not remember how long.
Yeah, I see that too, e.g. on Leap15.2. Looking at the var-run.mount unit, it is a bind mount, but conditional on the mount point not being a symlink .....
If there is still some unit that depends on /var/run being mount point, it probably should be considered a bug in this unit.
This is what it looks like: office24:/etc/postfix # systemctl cat syslog-ng # /usr/lib/systemd/system/syslog-ng.service [Unit] Description=System Logging Service Requires=var-run.mount # Requires=syslog.socket After=var-run.mount network.target Conflicts=rsyslog.service syslogd.service Looking at package systemd-sysvcompat, there doesn't seem to be anything I need and I can live without the "var-run.mount" unit. -- Per Jessen, Zürich (15.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Andrei Borzenkov wrote:
On 23.04.2023 19:38, Per Jessen wrote:
Requires=var-run.mount
The right way to do it is
RequiresMountsFor=/var/run/...
for whatever paths it needs.
Yet another systemd option I was unaware of :-) I created a new syslog-ng unit, changed the symlink and did a daemon-reload. systemctl restart syslog now works. I guess the next thing for me is to submit a PR. -- Per Jessen, Zürich (17.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
participants (5)
-
Andrei Borzenkov -
jdd＠dodin.org -
Lew Wolfgang -
Patrick Shanahan -
Per Jessen