LinuxQuestions.org
Page 1 of 3 1 23
Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)
-   slarm64 (https://www.linuxquestions.org/questions/slarm64-132/)
-   -   Getting ssd booting on Slarm64 & RazPi 4 (https://www.linuxquestions.org/questions/slarm64-132/getting-ssd-booting-on-slarm64-and-razpi-4-a-4175705058/)

business_kid 12-17-2021 08:16 AM
Getting ssd booting on Slarm64 & RazPi 4
 
My sdcard boots fine with slarm64.

So I rsync'ed it to a ssd prepared for booting a Pi with /boot, /, & /home partitions. X wouldn't start. I'll spare you the blow-by-blow, but I set to runlevel 3 and it became clear / was being mounted read-only.

There's no sdcard at this stage; /etc/rc.d/rc.4 tries to boot a dm and boot comes unstuck there. Useful to know.

/etc/mtab had an entry about sdcards which presumably was rsync'ed over, but that didn't fix anything. So I tried on /boot
Code:
bash-5.1$ grep -r mmcblk0 *
grep: boot.scr: binary file matches
config:CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
config-5.15.5:CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
grep: Image: binary file matches
rebuild-initrd.sh:if [[ ! -z $(mount | grep -P "(mmcblk0|sd).1.*boot.*fat") ]]; then
grep: start4cd.elf: binary file matches
grep: start4db.elf: binary file matches
grep: start4.elf: binary file matches
grep: start4x.elf: binary file matches
grep: start_cd.elf: binary file matches
grep: start_db.elf: binary file matches
grep: start.elf: binary file matches
grep: start_x.elf: binary file matches
grep: vmlinuz-5.15.5: binary file matches
It was also in boot.cmd, some u-boot file, but I edited it out.

To put it in Royal parlance, I was "not amused" to find the boot drive in the kernel. Does it use that? Does that have to be there? Do I have to recompile the kernel?

sndwvs 12-17-2021 08:52 AM
Quote:
Originally Posted by business_kid (Post 6310309)
My sdcard boots fine with slarm64.

So I rsync'ed it to a ssd prepared for booting a Pi with /boot, /, & /home partitions. X wouldn't start. I'll spare you the blow-by-blow, but I set to runlevel 3 and it became clear / was being mounted read-only.

There's no sdcard at this stage; /etc/rc.d/rc.4 tries to boot a dm and boot comes unstuck there. Useful to know.

/etc/mtab had an entry about sdcards which presumably was rsync'ed over, but that didn't fix anything. So I tried on /boot
Code:
bash-5.1$ grep -r mmcblk0 *
grep: boot.scr: binary file matches
config:CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
config-5.15.5:CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
grep: Image: binary file matches
rebuild-initrd.sh:if [[ ! -z $(mount | grep -P "(mmcblk0|sd).1.*boot.*fat") ]]; then
grep: start4cd.elf: binary file matches
grep: start4db.elf: binary file matches
grep: start4.elf: binary file matches
grep: start4x.elf: binary file matches
grep: start_cd.elf: binary file matches
grep: start_db.elf: binary file matches
grep: start.elf: binary file matches
grep: start_x.elf: binary file matches
grep: vmlinuz-5.15.5: binary file matches
It was also in boot.cmd, some u-boot file, but I edited it out.

To put it in Royal parlance, I was "not amused" to find the boot drive in the kernel. Does it use that? Does that have to be there? Do I have to recompile the kernel?
to transfer to another disk there is a transfer-to-disk script (it will completely format the disk)

for manual transfer, it is enough to make 1 section of the vfat and transfer all the files with /boot. change in /etc/fstab and /boot/uEnv.txt root drive.

HappyTux 12-17-2021 11:14 AM
Quote:
Originally Posted by sndwvs (Post 6310314)
for manual transfer, it is enough to make 1 section of the vfat and transfer all the files with /boot. change in /etc/fstab and /boot/uEnv.txt root drive.
I use LABEL= for the /etc/fstab entries this just simply works for transfers to anything sdcard or SSD it makes no difference it just boots. This would be on Debian but I fail to see why it would not work with another distro.

Code:
root@bullseye-raspi:~# cat /etc/fstab
# The root file system has fs_passno=1 as per fstab(5) for automatic fsck.
LABEL=RASPIROOT / ext4 rw 0 1
# All other file systems have fs_passno=2 as per fstab(5) for automatic fsck.
LABEL=RASPIFIRM /boot/firmware vfat rw 0 2

Not sure if the /boot/uEnv.txt is for the same purpose as the cmdline.txt on Debian but if it is it works in there too.

Code:
root@bullseye-raspi:~# cat /boot/firmware/cmdline.txt
console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0  rootwait
Though for that to be permanent another setting needs to be set a direct edit of the file does not survive the kernel updating for instance, anything that updates the initrd.

Code:
root@bullseye-raspi:~# cat /etc/default/raspi-firmware

# Filesystem to mount on root. If not specified, find what partition
# is mounted as the root using 'findmnt -n --output=source /'; if none
# is reported, fall back to the Raspberry's most usual /dev/mmcblk0p2.
# but you can specify otherwise, including booting by partition label
# (i.e. ROOTPART="LABEL=root")
#
#ROOTPART=/dev/mmcblk0p2

# Added by me for using the partition label to boot with.
ROOTPART="LABEL=RASPIROOT"
Probably do not need it all, but that is the idea I use to prevent the editing needed using any other method of doing it on my install, perhaps similar can be used by the OP.

business_kid 12-17-2021 11:45 AM
Quote:
Originally Posted by sndwvs
for manual transfer, it is enough to make 1 section of the vfat and transfer all the files with /boot. change in /etc/fstab and /boot/uEnv.txt root drive.
Did all that. Changed /boot/cmdline.txt, /bootuEnv.txt, /boot/boot.cmd, /etc/fstab, and /etc/mtab. It seemed like I was getting nowhere. But you've configured the kernel command line with root=/dev/mmcblk0p2 :eek:

Then I added a symlink in /dev from /dev/mmcblk0p2 --> sda2, and moved to runlevel 3 in /etc/inittab.

Now I get to the login, and I can login as root. But / was read-only. So, to see the error, I ran
Code:
mount -0 remount /dev/sda2 /
and there was NO error. I could run 'lightdm', and X started. That's enough for me, as I'm not in a position to fart about with my Pi where it's placed. Every boot I have to limp around an obstacle and sit down, and standing up is a big deal.

I suggest you get to the bottom of this, which you would achieve inside a half an hour, because people won't be happy staying on short-lived sd cards, just like the weren't happy booting from floppies when they had hard disks.

Ditto the incapacity to create a user. Interestingly, I tried an su to my user, ran 'passwd', and entered the same passwd. It threw the error that my passwd was unchanged. So it's able to store and read my password, but
  1. interprets the password match incorrectly.
  2. fails to record that match as it should.
  3. fails to start whatever it should start thereafter.

So I'll not mark this solved, because I don't consider it solved. I'm sure you don't wast to have users stuck in root, or having to hack in when they want to log in. It does partially explain why my earlier install attempts (On an elderly usb disk) died.

For the record, Debian doesn't have uEnv.txt. I read the raspberrypi.org booting bilge, and it uses only files in the /boot top directory, i.e. /boot/config.txt (naming the exact kernel) and /boot/cmdline.txt. Overlays are for adjustments, and firmware is in the /boot top dir.

sndwvs 12-17-2021 12:05 PM
loading raspberry pi 4 in the image on slarm64 is as follows:
Code:
spi -> | -> sdcard  -> u-boot.bin (uEnv.txt) -> Image
      | -> usb ssd
cmdline.txt when using u-boot.bin is not used.
when using г-boot.bin it is unnecessary to modify boot.cmd since there is uEnv.txt for this.

here is my uEnv.txt
Code:
verbosity=8
console=both
extraargs=coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1
fdtfile=bcm2711-rpi-4-b.dtb
rootdev=/dev/sda2
rootfstype=xfs
usbstoragequirks=174c:55aa:u
transfer to disk is described here.

business_kid 12-19-2021 04:24 AM
I have kind of given up on the current ssd install, hoping to rsync over it later. Running now on sdcard. I'll post as I get to move on things. I can still access the ssd media because the bulk of the space is in sda3, a /home partition.

I dd'ed the Slarm64 image to a new 32GB usb key. I left the Pi booting on u-boot.bin, made the minimal adjustments and tried it. On and off screen, (my oversized problem returned) it booted, mounted / rw (hurray), created 128M of Emergency swap and seemed to go AWOL at that point. So I powered off, and trawled the logs dmesg, and syslog. In fact wlan0 couldn’t get firmware and wlan1 had no wpa_supplicant.conf, so it seemed to go out to lunch and I turned off.

But the ext4 install partition had no journal. I made the ext4 journal. I made one
Code:
tune2fs -j /dev/sdxX
tune2fs -O extent,uninit_bg,dir_index /dev/sdxX
because as it identifies as ext4, you presume you have the protections, but you don’t.

Now, unless there’s some way of shrinking the screen in the u-boot Universe, I’ll have to go back to the numbered kernels, and it’s over to you for what combination to try. I think it’s worth remaking the image over the ext4 journal, btw, because as it identifies as ext4, you presume you have the protections, but you don’t. And as I mentioned in the other thread, the kde image is also an option.

sndwvs 12-19-2021 05:43 AM
when transferring manually, you need to remove the parameters from fstab data=writeback

business_kid 12-19-2021 11:00 AM
Quote:
Originally Posted by sndwvs (Post 6310829)
when transferring manually, you need to remove the parameters from fstab data=writeback
I don't have that option set on my pc, where the dd operation happens. However, because there's the holy grail of a reliable slackware install at the end of this, so I'll stay with it. I hope I'm not a pain in the sphincter and we're both learning stuff. Thx for help.

Bullseye, btw in both 32 & 64bit flavours loses sound after a few days. bcm2835 is config.txt; dtparam-audio=on or somnesuch is also; alsa has volume up and is not muted; that widget in X shows volume; pulse isn't installed; but there's no @$#£&€%! sound. And If I update, there's definitely no sound.

sndwvs 12-19-2021 11:23 AM
Quote:
Originally Posted by business_kid (Post 6310882)
Bullseye, btw in both 32 & 64bit flavours loses sound after a few days. bcm2835 is config.txt; dtparam-audio=on or somnesuch is also; alsa has volume up and is not muted; that widget in X shows volume; pulse isn't installed; but there's no @$#£&€%! sound. And If I update, there's definitely no sound.
to understand well, look at the logs after loss of sound for errors.

business_kid 12-19-2021 12:48 PM
Quote:
Originally Posted by sndwvs (Post 6310888)
to understand well, look at the logs after loss of sound for errors.
Not after going this far. Debian for RazPi has systemd and basically no support and is a bitch to find anything on. I don't want to grapple with it,. I want to use this thing. I'm going some flavour of slackware.

business_kid 12-21-2021 10:54 AM
I installed the Enlightenment image with kernel 5.15.10 on a new usb key. My sdcard is new, so time is on my side right now, and the sdcard is running the XFCE image. I have configured MPV in the file manager, so I can double click a video and it awakes. Streaming in FF is not good - I still get blackouts, although if I hit the space bar as soon as the blackout starts, it seems to come back on … weird.

I spent a while in /boot with the files. It seems Image & vmlinuz-version are identical, as are the initrds. So I'm guessing you either
  1. use uboot.bin as a boot loader, which nullifies the rest of config.txt, and brings you into the u-boot universe.
  2. Continue in RazPi firmware. As long as you don't load u-boot.bin,it's normal RazPi booting,

Now I try booting, and it's stopping before mounting /. I get no logs, 1 page of kernel output, no errors. The Raspberries can still be seen top of page Kernel Output

Is anything obviously wrong?

Presuming not, what would happen if I moved the "kernel=u-boot.bin" line to the very end of config.txt? Specifically, would it use other settings from config.txt, notably the Overscan? I could probably sort this that way. I'm unsure of the way that stuff works, and unable to play away as one normally would.

business_kid 12-21-2021 11:39 AM
I installed the Enlightenment image with kernel 5.15.10 on a new usb key. I'm trying to get an image to work on sda, and transfer it to the ssd.

My sdcard is new, so time is on my side right now, and the RazPi is running via my sdcard and the XFCE image. I have configured MPV in the file manager, so I can double click a video and it plays. Streaming in FF is not good - I still get blackouts, although if I hit the space bar as soon as the blackout starts, it seems to come back on … weird.

With the Enlightenment image, I spent a while in /boot with the files. It seems Image & vmlinuz-version are identical, as are the initrds. So I'm guessing you either
  1. use uboot.bin as a boot loader, which nullifies the rest of config.txt, and brings you into the u-boot universe.
  2. Continue in RazPi firmware. As long as you don't load u-boot.bin,it's normal RazPi booting,

Now I try booting, and it's stopping before mounting /. I get no logs, 1 page of kernel output, no errors. The Raspberries can still be seen top of page Kernel Output

I have /dev/sda2 instead of /dev/mmcblk0p2 everywhere I can think of. Is anything obviously wrong? Why does it stop? Apparently it's in the Kernel
Code:
bash-5.1$ sudo grep CONFIG_CMDLINE /mnt/dvd/boot/config-5.15.10
Password:
CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
Does it need that at all? I don't think so.

What would happen if I moved the "kernel=u-boot.bin" line to the very end of config.txt? Specifically, would it use other settings from config.txt, notably the Overscan? I could probably sort this that way. I'm unsure of the way that stuff works, and unable to play away as one normally would.

sndwvs 12-21-2021 11:48 AM
if you commented out the line kernel=u-boot.bin and uncommented kernel=Image then cmdline.txt is used there you need to change the root disk too.

business_kid 12-21-2021 01:38 PM
Quote:
Originally Posted by sndwvs (Post 6311401)
if you commented out the line kernel=u-boot.bin and uncommented kernel=Image then cmdline.txt is used there you need to change the root disk too.
:doh: :doh: :redface:

Why didn't my wildcard grep catched that? I thought I had changed EVERYTHING.:banghead:

With that change, the thing E V E N T U A L L Y booted Enlightenment with some overscan, but I can fix that. Why it was so slow is an issue that may sort itself. I'm keeping this on usb key to mess with it and transfer when I'm ready for final adjustments if needed on the Pi. Logs look OK, but the boot speed is bad. Could be the USB key. I don't know. Enlightenment, BTW, looks as grey and shapeless as XFCE. Have you no wallpapers on the install?

I marked this solved because the Enlightenment image goes mounts / RW, despite XFCE (With cmdline.txt edited) does not. BTW, re the Debian RasPi OS sound errors
Quote:
Originally Posted by sndwvs
to understand well, look at the logs after loss of sound for errors.
Dmesg is AWOL. In your honour I searched and found this in kern.log
Code:
Dec 14 21:31:38 raspberrypi kernel: [    5.486878] vc4_hdmi fef00700.hdmi: Could not register sound card: -517
Very informative and clear as mud. Alsa sees a soundcard, the X widget sees it, but no joy. Let's not pursue it, because the next update/upgrade will only break it again.

sndwvs 12-21-2021 02:35 PM
Quote:
Originally Posted by business_kid (Post 6311423)
Have you no wallpapers on the install?
everything is left to the user to decide this slackware philosophy.

XFCE image is identical to enlightement, the only difference is in packages.


All times are GMT -5. The time now is 12:42 AM.
Page 1 of 3 1 23
Show 50 post(s) from this thread on one page