LS-QVL installs, reboots then only option is install again #138
-
|
Hi, TLDR; Debian installs, reboots on finish then only access is via ssh as installer@device which kicks off install again in a loop. I'm unable to login as root or user account setup during installation. Hopefully I'm missing something simple... Long version: And setup partitions as per referenced video at Based on video above, partition table was setup as follows: RAID1 device #0 - 1.0 GB Linux Software RAID Array dmesg (when logged in as installer@device immediately after install/reboot) [ 0.000000] Booting Linux on physical CPU 0x0 Any tips appreciated. Have tried variety of LVM, manual partition, whole disk etc Re, |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 2 replies
-
|
Good to hear from you! if it’s booting back into the installer then the boot files aren’t getting wiped out by formatting then replaced by the install as expected. I think a next step would be to try again and post a screenshot of the partitioning menu before moving forward so I can take a look. |
Beta Was this translation helpful? Give feedback.
-
|
Hi,
Thanks for the prompt reply.
Just solved.
After trying lots of partition combinations I eventually ended up with the
NAS in emergency mode.
To fix I formatted the drives in Windows to single NTFS partition, then
reinstalled into the NAS
Using LinkStation Updater to reinstall factory firmware and partitioning.
Transferred boot files with acp commander, repartitioned as before (boot,
root, swap)
This time messing around with advanced mode I selected (sorry forget exact
name) make bootable menu item, then went back to installing packages.
I've seen a fair few run throughs and seems to previously have gone from
installing packages to reboot, without the making bootable tasks appearing
on screen.
Wasn't a precise process but hopefully the above helps someone else muddle
through if they have the same issue.
Re,
Chris
…On Thu, Apr 7, 2022 at 7:53 PM 1000001101000 ***@***.***> wrote:
Good to hear from you!
if it’s booting back into the installer then the boot files aren’t getting
wiped out by formatting then replaced by the install as expected.
I think a next step would be to try again and post a screenshot of the
partitioning menu before moving forward so I can take a look.
—
Reply to this email directly, view it on GitHub
<#138 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEG3EASGIPBWW7QUG6D2O7TVD3EDNANCNFSM5SYDVAMQ>
.
You are receiving this because you authored the thread.Message ID:
<1000001101000/Debian_on_Buffalo/repo-discussions/138/comments/2523055@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I think it boils down to "started over from fresh stock firmware install and it worked". Though having a big NTFS partition likely caused the disk detection to fail entirely and force it to NAND boot into EM mode. That could be a handy trick, though only for devices that have NAND to boot from I imagine. Glad to hear you got it working! I can think of a few reasons it got to that state, high on the list being the old /boot array got out of sync and the device kept choosing one with the old boot files etc. I should have probably mentioned earlier, I should have the Bullseye installer up for this device in the next few days if you want to try that out when the time comes. |
Beta Was this translation helpful? Give feedback.
-
|
I originally tried removing all partitions, which triggered emergency mode I'm redoing the factory firmware now as
Quite possibly I'll still be trying things for a while so should be able check out the Bullseye installer |
Beta Was this translation helpful? Give feedback.
-
|
feel free to post your partitioning screen when you get there, I can take a look. the bootable flag shouldn't be a factor, at least it hasn't been for the previous few hundred installs I'm aware of. The presence of disks with a 2tb "partition #1" can be a factor, but only a negative one. |
Beta Was this translation helpful? Give feedback.
-
|
Where I was at: To 'fix' I mounted the 3Tb drives on another system and removed the stock boot files. Followed the steps from scratch and installed Debian without issue - this time with both 2Tb and 3Tb pairs inserted. Before install (may have typos took screenshot drag and paste didn't want to play) RAID1 device #0 - 1.0 GB Linux Software RAID Array
I changed the first couple of partitions to
After install: parted /dev/md0 Model: Linux Software RAID Array (md) parted /dev/md1 Model: Linux Software RAID Array (md) parted /dev/sda Model: ATA WDC WD30EFRX-68E (scsi) sdb is the same as above Model: ATA SAMSUNG HD204UI (scsi) Now to sort out the buttons and full speed fan... Cheers, |
Beta Was this translation helpful? Give feedback.
-
|
That makes some sense. I haven't spent too much looking at that aspect of the boot process other than to notice that it is there: I could probably add some utility to the installer to set that value and/or clear it etc but that would likely be unreliable since other tools like fdisk could just overwrite and would risk side effects etc. You can prevent that issue from happening a number of ways:
|
Beta Was this translation helpful? Give feedback.
I think it boils down to "started over from fresh stock firmware install and it worked". Though having a big NTFS partition likely caused the disk detection to fail entirely and force it to NAND boot into EM mode. That could be a handy trick, though only for devices that have NAND to boot from I imagine. Glad to hear you got it working!
I can think of a few reasons it got to that state, high on the list being the old /boot array got out of sync and the device kept choosing one with the old boot files etc.
I should have probably mentioned earlier, I should have the Bullseye installer up for this device in the next few days if you want to try that out when the time comes.